우아한테크코스 8기 프리코스 1주차 회고록

이번 가을 우아한테크코스 8기에 지원했다. 이번 주부터 프리코스 주차별 회고를 진행해보려 한다.

 

이미 1주차의 코드리뷰가 진행된 시점이라 다소 늦게 글을 쓰게 되었다.

하지만 오히려 리뷰를 마친 뒤에야 비로소 느낀 점이 많아졌기 때문에, 지금 쓰는 이 회고가 더 의미 있는 기록이 될지도 모르겠다.

요약. 시도하고, 부딪히고, 직접 체감한 다음에 나만의 근거를 만들자.

1주차 과제 - 문자열 덧셈 계산기

과제에 대한 간단한 설명만 짚고 넘어간다.

과제 요구사항은 문자를 연산자로 한 문자열 내부의 숫자를 덧셈하여 출력하는 간단한 어플리케이션이었다.

대신, 입력과정에서 요구된 포멧에 “커스텀 구분자”를 지정할 수 있는 옵션이 있었다.

 

이에 대한, 제출 PR을 첨부한다. PR 바로가기

 

구현 과정에서의 회고

요구사항을 처음 봤을 때는 간단한 어플리케이션이라 구현에 큰 어려움이 없을 거라 생각했다. 하지만, 의기양양했던 나의 밑바닥을 마주할 수 있었던 주차였다고 생각한다. 그 과정을 하나씩 되짚어보려 한다.

 

1. 스프링 프레임워크에 종속된 사고방식

순수 자바 코드로 어플리케이션을 구성하려다 보니 처음부터 많은 고민이 있었다. 스프링 프레임워크에 익숙해 있던 터라, 기본적인 구조조차 스스로 작성하려니 손이 쉽게 나가지 않았다. “레이어별 인스턴스는 어떻게 관리하지?”, “런타임에서 한 번만 초기화되는 객체는 어디서 만들어야 할까?” 이런 질문들 앞에서 막막함을 느꼈다.

 

결국, Spring이 빈을 관리하는 방식을 다시 학습하게 되었고, 프레임워크 내부의 구현 원리를 되짚어보는 좋은 기회가 되었다.

하지만 동시에, 그 과정에서 기본기에 대한 부족함을 뼈저리게 느꼈다.

 

이전에도 “특정 프레임워크에 종속된 학습은 나중에 기술 변화가 있을 때 적응하기 어렵다”는 조언을 여러 번 들었지만, 직접 0부터 만들어보니 그 말의 의미가 확 와닿았다. 원리를 이해하지 못하면, 도구가 바뀌거나 없어졌을 때 적응 과정은 더 고되다는 사실을 몸소 느낀 한 주였다.

 

2. 왜 의심조차 안해봤지?

프리코스의 가장 큰 장점 중 하나는 코드 리뷰라고 생각한다. 다른 사람의 코드를 읽는다는 것은 정말 큰 노력과 시간이 필요한 일인데, 상호간의 리뷰를 통해 성장할 수 있는 이 환경은 정말 흔치 않은 기회라고 생각한다. 그래서, 과제 제출이 끝난 이후 코드 리뷰 활동에 적극적으로 참여하였다.

 

지금까지 총 5분과 코드 리뷰를 주고 받았는데, 정말 뜨끔한 질문들이 많았다.

유틸성 클래스가 인스턴스로 만드는 것과 비교했을 때 어떤 장점이 있는지에 대한 근거가 필요할 것 같아요.
AppConfig의 목적이 따로 있을까요?! LazyLoading의 개념을 혼용해서 사용하고 계신 것 같습니다!

 

 

이 외에도 정곡을 찌르는 질문들이 많았다.

왜 그랬을까 생각해보니, 부끄럽게도 그 부분에서 내가 스스로의 기준을 세우지 않았기 때문이었다.

스프링에서는 싱글톤으로 관리하니까 나도 그냥 그렇게 해야지

상태가 없으면 일단 static으로 두는 게 편하지 않을까?

 

그동안 나는 이렇게 당연하게 여겨진 방식을 아무 의심 없이 따라해왔음을 인지하게 되었다.

 

물론 이미 검증된 구현체를 신뢰하는 건 중요하다. 하지만 이번 경험을 통해, 그 구현체의 선택의 이유를 스스로 추론하고 검증하는 힘이 부족했음을 깨달았다. 지금까지 나의 개발 학습 방식을 돌이켜보면, 이미 알고 있다고 생각하는 것들을 다시 점검해본 적이 거의 없었다.

솔직하게, 이미 생각이 확고해진 방식에 대해서는 보수적으로 해당 의견을 고집하고 다른 방법을 시도조차 해볼 용기가 없었다.

 

이제는 시도해야할 때라고 생각한다. 이번 프리코스 5주 동안의 개인 목표를 아래와 같이 설정한다.

나와 다른 의견이나 방식에, 일단 내 고집을 한번 내려두고 직접 시도해본 뒤 판단하자.

 

앞으로 그 어떤 질문에도, "누가 그렇게 하던데?" , "그 오픈소스는 이렇게 구현했던데?" 라는 식의 대답을 그만두려고 한다. 이런 저런 의견들을 온전히 내가 시도해보고, 내가 직접 느낀 장점과 단점을 비교해보아야 할 시점이라고 생각한다.

 

다음 주차에 적용해 볼 리스트

앞선 회고를 바탕으로 이번주 과제에서의 개인 과제를 정하려고 한다. 코드 리뷰를 바탕으로 반성하게 된 부분들에 대해 정리해보았다.

1. Validator를 유틸성 클래스로 만든 것에서 오는 이점이 무엇인지 고민해보기
   • 인스턴스로 만드는 것과 비교했을때 어떤 차이가 있을까?
   • 싱글톤 클래스는 어떠한가?
   • 이 3가지 방식의 비교를 통해 내가 자신있게 제시할 수 있는 근거 만들기
2. 일급 컬렉션이 주는 단점에 대해서도 알아보자.
   • 만약, 2주차 과제에서 일급 컬렉션을 도입할 수 있는 기회가 된다면, 직접 사용해보고 장단점 비교하기
3. 예외 메시지를 비즈니스 로직에서 지정하는 것과 Enum처리하는 것의 장단점 비교
4. AppConfig 클래스 작성시에, LazyLoading의 개념을 고려해서 작성하기
5. 도메인 객체 내부 값 중, 컬렉션 객체를 넘겨줄 때 변경 가능성을 고려하기
6. 기능 명세서 작성시에 기능 흐름 작성 → 기능 단위 중심으로 분류하여 객체 설계해보기

 

이 부분에 대해서는 다음 회고에서 간단하게 언급해보고자 한다. 만약 내용이 길어진다면 별도의 포스트로 게시해보는 것도 좋을 것 같다.

 

마무리

 

디스코드 커뮤니티와 코드리뷰를 통해 정말 많은 의견을 들은 것 같다. 이 의견을 수용하고 적용하는 것도 나를 위함이며 하나의 용기이다. 내가 가진 고집을 내려두고 바라보도록 노력해보자. 그리고 프리코스가 끝난 이후, 다양한 의견을 유연하게 바라보고, 적용하고, 나만의 근거를 만드는 힘을 길러보자.

다음 과제에서는 앞선 회고 내용을 기반으로 새로운 접근 방식을 긍정적으로 바라보고 검증하려는 시도에 포커싱을 맞추고 진행하고자 한다.  그래도 1주차에 이런 깨달음을 얻은 것에 대해 감사하게 생각하며, 이제 다시 과제를 하러 가야겠다.