미션을 수행할 때 어떤 접근 방법으로 무엇을 중요하게 생각하며 해결했는지 스스로 돌이켜보는 시간을 가질 계획입니다.
어떻게 생각했는가
미션을 수행할 때 어떤 접근 방법으로 무엇을 중요하게 생각했는지 작성하려고 합니다. 순서의 의미는 없고 키워드별로 나열해보려고 합니다.
경쟁자랑 함께 성장하라고요?
프리코스 과정은 소프트웨어 생태계에 선한 영향력을 이란 비전을 가진 우아한테크코스에 들어가기 전 성장 과정을 경험하는 공간이기 때문에 많은 것을 경험하고 나누고 싶었습니다. 또한, 부담 없이 질문할 수 있는 프로그래머라는 목표를 가진 저에게는 큰 어려움 없이 비전에 공감했습니다.
- 토론하기, 함께 나누기, 코드 리뷰 등 적극적으로 확인하고 가능하면 참여하려고 했습니다.
규칙 정하기
프리코스 진행 방식
- 기능 요구 사항에 기재되지 않은 내용은 스스로 판단하여 구현한다.
위 요구 사항을 보고, 커스텀 구분자에 대한 규칙을 미리 정해두는 것이 추후 변경을 줄이는 데 도움이 될 것이라 판단했습니다. 여러 경우의 수를 고려하여 다음과 같은 규칙을 세웠습니다.
구분자는 단일 문자만 사용할 수 있으며, 수학적 기호는 제외하도록 했습니다.
수학적 기호를 배제한 이유는 문자열 덧셈 계산기라는 특성 때문입니다. 예를 들어, "5-2"라는 문자열을 입력하면 뺄셈을 기대할 수 있지만, 실제 계산 결과는 7이 나와 혼란을 줄 수 있습니다. 이러한 혼동을 방지하기 위해 널리 사용되는 수학적 기호들은 커스텀 구분자에서 제외하는 규칙을 세웠습니다.
구분자는 단일 문자로 타입이 같고, 카테고리컬하게 묶을 수 있는 특성을 활용하기 위해 enum으로 관리하도록 했습니다.
- 기본 구분자 유형 : 기본으로 사용할 수 있는 구분자 목록
- 지원되지 않는 구분자 유형 : 사용할 수 없는 구분자 목록 (+ 사유)
프로젝트 구조
1주 차 문자열 덧셈 계산기 미션을 진행하며, 저는 "객체지향은 실제 사물의 동작을 모방하는 것"이라고 생각했습니다. 그래서 일상에서 볼 수 있는 진짜 계산기를 참고하여 구현했습니다.
project/
├── service/ # 사용자가 볼 수 없는 부분
│ ├── command/ # 사용자 입력과 관련된 패키지
│ ├── expression/ # 계산할 식과 관련된 패키지
│ └── separator/ # 구분자와 관련된 패키지
├── view/ # 사용자가 볼 수 있는 부분
├── util/ # 현재는 상수를 관리
└── Application.java # 계산기 어플리케이션각 패키지마다 가져야 할 역할과 책임을 쉽게 이해할 수 있었습니다.
객체로 다뤄보기
이번 미션에서 사용자 입력은 단순한 문자열 형태로 주어졌습니다. 처음에는 이 문자열을 검증하거나 필요한 정보를 추출하는 과정이 반복되면서 코드에 중복이 발생했습니다. 검증 로직이 곳곳에 흩어지다 보니 클래스의 책임이 불명확해지고, 기능을 수정할 때마다 여러 부분에서 이미 수행된 검증을 고려해야 하는 번거로움이 있었습니다.
특히, 문자열은 자체적으로 특별한 메서드를 가지지 않기 때문에, 원하는 값을 얻기 위해서 외부에서 작업해줘야 합니다. 이 때문에 사용자의 입력값인 문자열은 수동적인 존재로 다뤄집니다.
이 문제를 해결하기 위해, 저는 사용자 입력을 객체로 다루기로 방향을 잡았습니다. 사용자 입력을 Command 객체로 만들고, 구분자(Separator)와 계산할 식(Expression)을 객체로 분리하여 다루기 시작했습니다.
예를 들어, 입력 문자열이 “//$\n1$2$3”일 경우, 빈 문자열 검증, 커스텀 구분자 확인, 기본 구분자와의 구분 등 다양한 규칙을 문자열 기반으로 일일이 처리해야 했습니다. 그런데 이를 구분자 객체로 만들면서 생성자에서 유효성 검증을 하도록 했습니다. 즉, 생성된 구분자(인스턴스)는 언제나 유효한 구분자임을 보장했습니다. 또한, 구분자 객체 스스로가 자신의 역할을 수행할 수 있도록 여러 메서드를 제공함으로써 코드가 훨씬 명확해졌습니다.
결과적으로, 여러 개념을 객체로 분리한 덕분에 검증과 추출 로직의 중복이 줄어들었고, 다른 객체로 데이터를 전달할 때 검증된 값만을 제공할 수 있었습니다.
깃 활용하기
깃 커밋 메시지도 다른 사람에게 의도를 전달할 수 있는 좋은 방법이라고 생각했습니다. 컨벤션을 미리 지정하여 각 순간마다 어떤 변경이 일어났는지 파악하기 쉽게 전달하려고 노력했습니다.
또한, 브랜치를 활용하여 여러 구현 방법을 시도해보고 적용하거나 롤백(아닌 것 같으면 폐기)하는 방식으로 도전적이지만, 코드는 안전하게 관리하려고 했습니다.
배운 것을 공유하기
Java record 포스팅 미션을 수행하며 학습한 record에 대해서 학습한 내용을 공유했습니다.
생성형 AI 토론
저는 프리코스 미션을 진행할 때 생성형 AI의 사용을 지양하려고 합니다. 평소에 생성형 AI는 빠르고 편리하게 해결책을 제시하지만, 문제를 해결하면서 직접 고민하고 선택하는 과정이 없어진다는 느낌을 받았습니다.
위 문장은 제가 학습 목표로 작성했던 내용 중 일부입니다.
그러나, 프리코스 커뮤니티에서 GPT, 어디까지 활용해야 할까요? 토론 채널에서 생성형 AI 사용한 공부 방식에 관한 다양한 사람의 생각을 볼 수 있었습니다. 저와 같은 맥락의 생각을 가진 분들도 있었고, 구글 검색을 하는 키워드 위주로 적극적인 사용을 하시는 분들도 있었습니다. 저는 단지, 생성형 AI는 빠른 시간안에 구현과 문제 해결을 도와주기 때문에 지양하려는 마음이 있었지만, 그것을 해치지 않으면서, 시간을 아끼는 효율적으로 학습에 사용할 수도 있겠다고 느꼈습니다.
문제가 발생한 부분에서 방향을 빠르게 잡는 용도로 사용하거나, 모르는 문법 등을 빠르게 학습하기 위해 사용하는 것은 성장에 도움이 될 수 있겠다고 생각했습니다. 물론 최종 테스트에서는 사용할 수 없으니, 그냥 안된다고 사용하는 것이 아니라 이것 또한 근거를 가지고 도구로 활용한다면, 의존도를 줄이고, 더욱 효율적인 성장을 할 수 있겠다고 생각했고, 근거를 가지고 다음 미션을 위한 학습에 사용해 보려고 합니다.
매일 기록
매일 학습 내용을 기록하는 이유는 두 가지입니다.
- 스스로 잘하고 있는지 확인하기 위해서
- 왜 내가 이렇게 구현했는지를 명확하게 기억해두기 위해서
단순히 학습한 내용을 기록하는 것이 아니라, 어떤 이유로 그 선택을 했는지를 함께 적어두고, 시간이 지나도 그 의도와 과정을 떠올릴 수 있게 하려고 했습니다.
가독성 및 피드백
저는 다양한 의견을 듣고 배울 기회를 소중히 여기며, 함께 성장하고 싶습니다.
이러한 목표를 가진 저에게는 더 나은 피드백을 받는 것이 중요했습니다. 가는 말이 고와야 오는 말이 곱다는 속담처럼, 제가 작성한 코드의 의도를 명확히 전달해야 더 깊고 유의미한 피드백을 받을 수 있을 것이라 생각했습니다. 이를 위해 PR 페이지에 의도를 작성하거나, 메서드명을 명확하고 통일성 있게 작성하려고 노력했습니다.
이후 프리코스 커뮤니티의 서로 리뷰하기 채널에 홍보하고, 깊고 의미있는 피드백을 주고받을 수 있었습니다.
- 서비스의 역할(객체의 역할), 메서드 분리, 검증 로직의 위치, 테스트 코드, 예외 메시지 등 다양한 지원자의 의견을 듣고 배울 수 있어서 좋았습니다.
돌아보기
좋은 리뷰를 작성하는 일은 생각보다 어렵다는 것을 느꼈습니다.
같은 문제를 다루더라도 지원자마다 접근 방식이나 해결 방법이 달라지기 때문에, 리뷰어가 그 의도를 온전히 파악하지 못할 때도 있는 것 같습니다. 리뷰를 잘 받기 위해서는, 제가 작성한 코드의 의도를 더욱 명확히 표현하는 것이 중요하다는 점을 깨달았습니다. 코드에 대한 설명을 조금 더 신경 써서 남기면, 의도에 대한 깊이 있는 피드백을 받을 가능성이 높아지고, 그로 인해 더 나은 코드로 개선할 기회를 얻을 수 있을 것이라 기대하고 있습니다.
또한, 제가 다른 지원자의 코드를 리뷰할 때도 마찬가지로, 피드백을 명확하고 도움이 되도록 남기는 것이 매우 중요하다는 것을 느꼈습니다. 다른 사람의 PR을 구경하다 보면 "나도 이렇게 배려 넘치는 리뷰를 남기고 싶다"는 생각이 많이 들었습니다. 이를 위해서는 단순히 코드의 오류를 지적하는 데 그치지 않고, 해당 코드의 의도와 설계 방식에 대해 고민하고, 지원자 스스로 학습할 수 있는 환경을 조성하려는 노력이 필요하다는 것을 알게 되었습니다.
특히, 다른 사람의 코드 리뷰를 작성할 때는 코드의 맥락을 충분히 이해하고, 그 코드가 어떤 문제를 해결하려는지, 그리고 왜 그렇게 구현했는지를 고려하여 일관적인 피드백을 제공하는 것이 중요하다고 생각합니다. 그 과정에서 저 역시 새로운 시각을 배우고 성장할 기회가 있다는 점이 있기 때문입니다. 앞으로는 더욱 주도적으로 리뷰에 참여하여, 서로의 발전에 기여할 수 있는 유의미한 피드백을 남기는 것이 목표입니다. 다만, 너무 많은 지원자들과 코드 리뷰를 주고받으면 시간이 꽤 많이 소요되기 때문에 인원 수에 제한을 두는 방법도 좋을 것 같습니다.
결국, 좋은 리뷰를 남기기 위해서는 단순한 코드 확인을 넘어서서 문제 해결 과정과 의도를 이해하는 것이 필수적이며, 더 나은 피드백을 주고받는 경험이 지원자 모두의 성장에 큰 도움이 될 것이라 생각합니다.
함께 리뷰를 주고받은 분들께 감사합니다!
