본문 바로가기
회고

데브코스 백엔드 중간 회고

by hseong 2023. 8. 27.

중간 회고

데브코스 시작 후 3개월이 되었습니다. 후반기로 접어들면서 본격적인 프로젝트에 들어가기 앞서 지금까지 배운 것들, 느낀 것들을 정리해볼 필요성을 느꼈습니다.

코드리뷰

항상 제게 필요하다고 느꼈던 부분이었고 과제를 수행하면서 부족한 점들을 많이 찾고 고칠 수 있는 기회였다고 생각합니다.

멘토님들께 코드 리뷰를 받고 질의응답을 하면서 느낀 점은 객체지향, 스프링, JPA, 계층형 아키텍처 등 그동안 구현하면서 잘 쓰고 있다고 생각했던 것들이 사실은 그렇지 않다는 것이었습니다.

첫 번째 계산기 과제에서 어떤 객체에 책임을 할당해야할지 알지 못했습니다. 책임을 할당한다. 라는 말은 알고 있었지만 말 그대로 알고만 있었습니다. 객체지향에 대한 제대로 된 학습이 필요하다 느꼈습니다. 다행히 객체지향 스터디에서 이에 대해 학습하며 조금씩 나아지고 있습니다. 이에 관해서는 뒤에 한 번 더 다루기로 하겠습니다.

두 번째 바우처 과제에서는 계층형 아키텍처에 대해서 제대로 알지 못한다고 느꼈습니다. 도메인 객체를 표현 계층에서 사용하고, 서비스 계층은 표현 계층을 의존했습니다. 계층간의 의존성이 하나의 방향으로 흐르지 않고 양방향 의존이 생겨서 높은 결합도를 보였습니다. 계층형 아키텍처는 나의 것이 아니었습니다. 그저 김영한님이 사용하시는 것을 보고 아무런 고민 없이 따라 사용하고 있을 뿐이었지요.

멘토님께서는 아키텍처에 관해 읽어볼만한 서적으로 클린 아키텍처, 만들면서 배우는 클린 아키텍처, 도메인 주도 개발 시작하기를 추천해주셨습니다. 클린 아키텍처는 아직 다 읽지는 못했습니다만 저자 분의 경험을 통해 계층 간 경계를 나누는 것이 어째서 중요한지에 대해 이해할 수 있었습니다. 만들면서 배우는 클린 아키텍처는 애플리케이션의 핵심인 비즈니스 규칙을 지키기 위해 어떤 식으로 구현할 수 있는지 보여주는 짧은 책이었습니다.

세 번째 게시판 과제에서는 스프링을 다루고 API를 작성하는데 부족한 점이 있었습니다. API 중복을 줄이고, 스프링 6에서는 어떤 것들이 바뀌었는지 좀 더 학습을 할 필요가 있었습니다.

세 차례의 과제를 수행했으면서도 여전히 어려운 것 또한 있습니다. 의미 있는 로깅을 위해서는 어떻게 해야하는가? 가 그것입니다. 예외를 던지는 상황에서 반복적인 로깅을 줄여보기 위해서 AOP를 사용해봤는데 이 경우 표준 예외만 사용한다면 의미 있는 로깅을 어떻게 해야할 지 감이 잘 잡히지 않았습니다.

다른 것으로는 예외 메시지를 관리하는 것입니다. 처음에는 메시지만 관리하는 클래스를 따로 두었습니다. 하지만 코드를 읽는 사람 입장에서는 예외를 던지는 클래스가 메시지를 가지지 않아 보기 힘들다는 리뷰를 받았습니다. 이후로는 읽는 사람 입장에서 어떤 것이 더 편할까를 생각하며 예외를 던져줄 때 문자열을 그냥 넣어주거나, 클래스 최상단에 상수로 빼주거나 다양하게 시도해보고 있습니다.

이러한 과정을 통해 가장 크게 느꼈던 점은 제가 작성한 코드, 계층간의 의존성, 패키지 구조, 객체가 가진 책임... 내가 선택한 모든 것에는 이유가 있어야 한다는 점입니다. 더 나은 구조로 나아가기 위해, 다른 사람을 설득하기 위해 언제나 고민 해야한다는 것을 알았습니다.

스터디

본 과정이 시작하고 일주일이 지나기 전 곧바로 객체지향 스터디에 들었습니다. 스프링 입문을 위한 자바 객체 지향의 원리와 이해(개구리책)를 읽으며 객체지향의 기초를 다졌고 현재는 조영호님의 오브젝트를 읽으며 심화 과정을 거치고 있습니다.

스터디에 들어가 있는 것 자체만으로 학습할 강제성이 생기는 게 도움이 되었습니다. 만일 스터디에 들지 않았으면 언제쯤이나 오브젝트를 읽을 수 있었을지 감도 잡히지 않네요.

더 좋았던 것은 서로 공통의 내용을 학습하고 자신의 경험 속에서 객체지향에 대해 고민한 것에 대해 이야기를 나누는 자리였습니다. 내가 했던 실수와 그것을 개선한 경험을 스터디원들에게 설명하는 과정에서 비록 사소했으나 단일 책임 원칙과 다형성에 맞닿아 있었다는 것을 깨달았습니다.

강의

데브코스 백엔드 강의에서 전반기 동안 가르쳐주는 것은 스프링 프레임워크가 절반 정도 됩니다. 대충 6주 정도만에 Spring, Spring Web MVC, Srping Boot, JDBC, JPA, Security를 다루다보니 아무래도 기초와 꼭 필요한 내용정도만 배우고 넘아가는 편입니다. 확실히 과정을 진행하는데 있어서 스프링에 대한 학습을 미리 진행하거나 병행, 복습할 필요성이 있었습니다. 저의 경우 이전에 스프링 강의를 한 차례 수강한 경험이 있어 따로 내용을 복습하면서 진행하였습니다.

다만 아쉬운 부분이라고 해야할지 최신 버전을 다루고 있지는 않다보니 Spring Security의 경우 직접 해결해야하는 부분이 있었습니다. 개인적으로 Security를 접한게 겨우 1년 밖에 되지 않았지만 그 짧은 시간동안에도 이리 저리 바뀐 점들이 있다보니 어쩔 수 없는 부분이라는 생각은 들었습니다. 설정 정보와 일부 구현의 변경은 공식문서와 spring 블로그를 보고 충분히 해결할 수 있었기에 큰 문제는 없었습니다. 하지만 JWT 인증 프로세스 구현의 경우 커스텀 SecurityContextRepository를 구현하는 부분에서 이전 버전과 차이가 있어 조금 곤란했던 기억이 있습니다.

전반기의 마지막 강의는 협업, 애자일 스크럼에 대한 강의입니다. 애자일은 항상 궁금했던 내용이었기에 이번 기회에 깔끔하게 정리할 수 있었습니다.

그동안 팀원들을 온라인으로만 만나다가 최근에 오프라인으로 만나게 되었습니다. 아무래도 오프라인으로 만났을 때가 더 많은 이야기, 더 빠른 진행을 하기가 좋았습니다. 온라인으로만 봤을 때는 팀원들이 내향적인 부분이 모두 있나보다 했는데 전혀 아니었습니다.

이야기를 하다보니 보이는 것만이 전부는 아니었습니다. 팀원들은 보이지 않는 자리에서 훨씬 더 많은 노력을 하고 있었습니다. 반면에 저는 보이는 것에만 너무 집중하고 있었습니다. 한 팀원은 팀원들이 프로젝트에 적극적이지 않을까봐 걱정이라는 이야기를 한 적이 있습니다. 저 또한 그렇게 느꼈습니다. 하지만 이제는 제 노력이 부족하다는 생각이 듭니다.

팀원들 모두가 저보다 팀 활동, 프로젝트 경험이 많다보니 앞으로 있을 프로젝트가 조금 걱정되기도 합니다. 그래도 들이박다 보면 뭐든 되겠죠.

고쳐야할 점

과정 시작할 때만 해도 호기롭게 '블로그 열심히 하겠다!'라고 다짐했었는데 최근에는 글 작성하기가 잘 되지 않습니다. 사실 그런 의미에서 회고 글을 작성한 것이기도 합니다. 노션에다가 정리는 하고 있습니다만 TIL을 블로그에 계속 올리는 것이 의미가 없다는 이야기도 보이고, 그걸 남들이 보기 좋게 하나의 게시글로 만드는 것도 쉽지 않은 것 같습니다.

그래도 꾸준히 작성해나가려고 하다보면 나아질 것이라 생각합니다.

학습 시간을 분배하는 것도 다시 한 번 바꿔볼 생각이 있습니다. 최근들어 학습에 집중하는 시간이 줄어들었다는 것을 느끼고 있습니다. 마침 애자일 스크럼 강의에서 뽀모도로와 KMN 작업법에 대한 내용을 들었고 이를 받아들여 실천해보려 합니다.