"프리코스 2주 차 회고" 프리코스 목표와 나의 변화를 돌아보기

우선, 주도적인 문제 해결 능력을 키우기 위해 가장 중요한 것은 스스로 학습하는 습관을 기르는 것이라고 생각합니다. 새로운 문제나 어려움에 직면할 때마다 스스로 해결 방법을 찾아보고, 부족한 부분을 주도적으로 학습하는 자세가 매우 중요합니다. 또한, 그 과정에서 반드시 메모 습관도 병행해야 한다고 생각합니다.

이에 따라 저는 프리코스를 진행하는 동안 매일 빠짐없이 블로그에 하루 동안 고민했던 점들, 어려웠던 부분들, 해결 과정, 그리고 그 과정에서 배운 것들을 꼼꼼하게 기록해왔습니다. 새로운 개념을 알게 되면 먼저 그것을 학습하고, 제가 원래 알고 있던 개념과 결합해 보며 더 깊이 이해하려고 노력했습니다.

또한, 한 주차를 시작할 때마다 큰 그림의 계획을 세우고, 매일 작지만 구체적인 학습 또는 작업 목표를 설정해왔습니다. 매일 이러한 작은 목표들을 모두 달성하기 위해 최선을 다하다 보니, 새벽까지 잠을 못 자는 날들도 많았습니다.

매일 구체적으로 학습 또는 작업 목표를 세우는 습관은 "1만 시간의 재발견"이라는 책에서 알게 된 '의식적인 연습'의 개념을 통해 생겼습니다. 이 책에서 강조하는 의식적인 연습이란, 목표를 명확히 설정하고 즉각적인 피드백을 통해 실수를 교정하며 계속해서 자신에게 도전하는 방식으로 이루어집니다. 저는 개발을 제대로 시작한 것이 대학교 2학년 때부터였습니다. 남들보다 늦게 시작한 바람에 급해지고, 점점 개발에 재능이 없다고 느끼던 시점에 이 책을 접했습니다. 이 책은 저에게 재능보다는 '의식적인 연습'을 통한 체계적이고 전략적인 목표 설정과 노력이 성공의 핵심이라는 메시지를 전해주었습니다.

이렇게 돌아보니, 프리코스의 절반을 지나며 제가 설정했던 목표들을 잘 지키고 있다고 느껴집니다. 매일 목표를 세우고, 주도적으로 문제를 해결하며, 그 과정에서 배운 것을 꼼꼼히 기록해온 점에서 목표 달성에 가까워지고 있다고 생각합니다.

[ 지금까지 생각의 변화와 깨달은 점 ]

사실 프리코스를 시작하기 전에 자신감이 있었고, 그때부터 최종 코딩 테스트만 걱정했던 제 자신이 지금은 부끄럽게 느껴집니다. 프리코스를 진행하면서 객체지향에 대해 내가 정말 모르는 것이 많고, 아직 배워야 할 것이 많다는 것을 깨달았습니다. 객체지향에서 가장 중요한 개념 중 하나가 단일 책임 원칙이라는 것은 알고 있었지만 제가 그 원칙을 제대로 이해하고 있다고 착각하고 있었습니다.

단일 책임 원칙을 고려하면서 MVC 구조를 설계한 후 실제 코드 구현을 시작할 때마다 단일 책임 원칙을 위반하는 클래스나 메서드들이 등장했습니다. 이를 통해 제가 객체를 바라보는 시각과 설계 과정에서의 접근 방식이 잘못되었음을 인지했습니다. 설계를 마치고 리팩토링을 거치며 스스로 수정한 부분도 있었지만 1주차 미션 코드 리뷰에서도 몇 가지 지적을 받았습니다. 그중 가장 큰 깨달음을 준 것은 Validator 클래스는 데이터의 유효성 검증만을 책임져야 하며 파싱 로직은 별도의 책임을 가진 코드로 분리되어야 한다는 내용이었다. 저는 당시에는 숫자를 문자열에서 파싱하는 것이 유효성 검증의 일환이라고 생각하여 같은 역할로 간주했다. 그러나 다시 생각해보니 Validator 메서드의 주된 역할인 '유효성 검사하기'에 집중을 하면 자연스럽게 "파싱하기"가 빠지게 되고, 그럼에도 불구하고 Validator 메서드의 역할은 명확하게 그대로 유지되었다.

지금 단계에서는 이 실수가 미묘할 수도 있지만 코드가 확장되고, 복잡해질수록 파싱과 검증을 명확히 구분하지 않으면 유지보수나 확장성 측면에서 문제가 발생할 수 있다는 점을 깨달았습니다. 코드가 커질수록 작은 책임 분리가 중요한 역할을 한다는 것을 느꼈고, 단일 책임 원칙에 대한 시각이 더욱 깊어졌습니다.

또한, 단위 테스트에 대해 제대로 학습하고 이를 코드에 적용해보니 마치 새로운 세계를 만난 듯한 경험이었습니다. 항상 어떤 작업이나 시스템의 효율성을 중요하게 생각하는 저로서는 단위 테스트를 이제야 알게 된 것이 후회스럽고, 지금까지의 시간들이 아깝게 느껴지기도 했습니다.

지금까지 팀 프로젝트에서 API를 구현할 때 항상 DTO부터 시작해 Controller 클래스까지 완성해야만 Postman으로 해당 API를 테스트할 수 있었습니다. 그런데 그 과정에서 오류가 발생하면 어디에서, 무엇 때문에 문제가 생겼는지 파악하기가 어려웠습니다. 결국 디버거를 사용해 각 클래스와 메서드를 하나하나 확인해야 했고, 이는 시간 소모가 큰 작업이었습니다.

이제는 단위 테스트가 단순한 테스트 도구가 아니라, 코드 구현의 효율성을 높이고 시간을 절약하는 데 핵심적인 도구임을 깨달았습니다.

[ 목표 변화가 아닌, 목표 추가 ]

1주 차 미션 끝나고 다른 사람들의 코드를 리뷰했을 때 그들의 다양한 폴더 구조를 볼 수 있었습니다. 그 과정에서 제 스스로 다음과 같은 질문들이 생겼고, 궁금증을 풀기 위해 학습했습니다.

상수 관리를 Enum으로 하는게 맞을까, Common으로 하는게 맞을까?

상수 관리를 누구는 Enum으로 누구는 Common으로 했습니다. Enum도 상수를 관리하고, Common 클래스도 상수를 관리하는 역할이 있어서 두 방식이 비슷하게 보일 수 있지만 실제로는 타입 안전성이나 가독성 측면에서 차이가 있다는 것을 알게 되었습니다. Common 클래스는 모든 메시지를 한 곳에 모아 관리할 수 있는 편리함을 제공하지만 규모가 커지면 복잡해질 수 있습니다. 반면 Enum은 특정 메시지 그룹(예: 성공/실패 메시지, 예외 메시지 등)을 더 체계적으로 관리하기 위한 것입니다. Enum을 사용하면 타입 안전성을 보장받을 수 있지만 Common 클래스의 상수 문자열은 실수로 잘못된 문자열을 사용할 가능성이 있습니다.

그래서 저는 상수 관리를 Enum을 사용하는 방식으로 결정했습니다. 예외가 발생했을 때 출력되는 문자열 상수들을 Enum으로 관리하고, 입출력 메시지도 동적으로 변하는 것이 아니라 고정된 메시지임으로 Enum으로 관리하는것이 효과적이라고 판단했습니다.

Model과 Domain이 서로 어떻게 다를까?

비즈니스 로직을 Model에서 처리하는 것과 Domain에서 관리하는 차이점이 궁금했습니다. 정의에 따르면, MVC 패턴에서 Domain 폴더는 핵심 비즈니스 로직을 처리하는 엔터티, 값 객체, 도메인 서비스 등으로 구성되며 독립적으로 동작해야 합니다. 반면, Model 폴더는 데이터베이스와 상호작용하거나 데이터를 전송하는 DTO, 리포지토리 등을 포함하며, 주로 데이터 저장과 전송을 담당합니다.

따라서 Domain은 비즈니스 규칙에, Model은 데이터 처리에 중점을 둡니다. 프리코스 미션들은 비즈니스 로직에 집중되어 있어 Domain 개념이 더 적합합니다. 하지만 저는 MVC 패턴에 중점을 두고 프리코스 미션을 수행하고 있으므로 Model을 유지하는 것이 더 적절하다고 판단했습니다.

그래서 추가로 찾아본 자료에 따르면 초기 단계의 단순한 프로젝트에서는 Domain과 Model 폴더를 하나의 Model 폴더로 합쳐 사용하는 것은 문제 없다고 나와 있었습니다. 즉, 비즈니스 로직과 데이터 처리를 단일 Model 폴더로 관리하는 것이 가능하다는 것이였습니다.

이에 따라 저는 프리코스 미션을 위한 나의 MVC 디자인 페턴에서는 비즈니스 로직 처리를 Model로 하기로 결정했습니다.

이외에도 유틸리티 클래스를 한 폴더로 관리하기 위해 utilities 폴더를 추가하면서 나만의 MVC 패턴 방식이 형성되고 있다는 것을 느꼈습니다. 코드 리뷰를 통해 사람마다 MVC 패턴을 해석하는 방식과 각자의 코드 철학이 다르다는 것을 깨달았습니다. 그래서 프리코스를 진행하면서 저에게 하나의 목표가 더 생겼습니다. 그것은 바로 '자신만의 개발 철학과 스타일을 찾아가는 것'입니다. 단순히 미션을 완수하는 것을 넘어서 제가 작성하는 코드에 일관성 있고 명확한 철학을 담아내는 것이 중요하다는 것을 깨달았습니다. 이 목표를 달성하기 위해 앞으로도 코드 구조와 설계에 대해 깊이 고민하며 나만의 개발 스타일을 꾸준히 만들어갈 계획입니다.

[ 마무리 및 앞으로의 Plan ]

프리코스 3주 차에는 우아한테크코스 크루들이 관심 있는 기술 주제를 스스로 공부하고 공유하는 테코톡 문화를 경험해보고 싶습니다. 이번 프리코스를 진행하며 가장 인상 깊었던 주제인 '단위 테스트(Unit Testing)'를 블로그에 정리할 계획입니다. 개념부터 시작해 이해를 돕기 위해 2주 차 미션에 적용했던 예시까지 포함시켜, 2주 차가 끝나면 프리코스 커뮤니티에서 사람들과 공유할 예정입니다. 이를 통해 학습한 내용을 다시 정리하고, 다른 사람들과 제 지식과 생각을 나누며 그 들의 생각도 듣고, 단위 테스트에 대해 더 깊이 이해하는 기회를 만들고자 합니다.

또한, 이번 주차 미션을 마무리하면서 마지막에 구현한 클래스들의 관계와 구성을 한눈에 파악할 수 있도록, 클래스 다이어그램을 설계하고 그려보았습니다. 그 과정에서 코드 구현할 때는 몰랐지만 클래스들의 연관 구조를 시각화해서 보니까 강한 관계를 형성하는 클래스들이 있는 것을 알게 되었다. 얼마전에 "소프트웨어 공학의 모든 것"이라는 책에서 이러한 강한 관계가 클래스 간의 의존성을 높이고, 결합도를 증가시킬 수 있다는 점을 알게 되었습니다. 그래서 3주 차 때는 클래스 간에 발생하는 의존성 문제와 높은 의존성을 낮추는 방법에 대해 학습할 계획입니다.

끝입니다.

티스토리