우아한테크코스 6기

4주차 미션 [크리스마스 프로모션] 회고록

스키(ski) 2023. 11. 15. 21:16

이번주차를 끝으로 길기도,짧기도했던 4주간의 프리코스 과정이 마무리되었다.

 

4주차 미션코드 깃허브

https://github.com/shin5774/java-christmas-6-shin5774

 

 

마지막도 신나게 코드리뷰 달려봅시다!

(근데 private 레포는 어캐 리뷰하지...?)

 

주차 시작전 (0~2일차/코드리뷰)

0일차

이번에도 여느때와 다름없이 바로 코드리뷰를 시작하였다. 3주차는 본인 기준에서 만족스럽지 않은 결과였기에 여러사람들의 코드를 보는것이 더 중요하다고 여겨졌다! 그러면서 한편으로는 내 코드에 얼마나 많은 사랑의손길(?)들이 쌓일지 벌써 기대(?)되었다.

 

3주차 코드리뷰를 앞둔 본인의 현 상황

 

역시나 역시나 역시나..

늘 세상에는 코드를 잘 짜는 사람은 넘쳐나고 거기에 나는 언제나 해당되지 않았다.

이번에는 다른사람들의 코드리뷰를 보면서 정보를 흡수(?)하기로 했다.

 

1일차

이 날도 이웃인 프리코스 참가 파티와 서로 코드리뷰를 진행하였다.

역시 저번주부터 느낀 오프라인 코드리뷰의 장점인 실시간 의견 교환이 이번주에도 빛을 발했다!

실시간으로 여러 코드를 보면서 생각나는 것을 바로 이야기하면 이에 대해 서로의 의견을 이야기하고 그 이야기에 다시 의견을 내고.. 이런 느낌으로 꼬리에 꼬리를 무는(꼬꼬무) 의견들을 이어감으로서 최고는 아닐지라도 최선의 해답을 향해 나아갈수 있었다.

 

(그리고 부끄러웠던 내 코드를 보고 잘 짠거 같다고 해줘서 솔직히 고마웠다.. ㅎㅎ)

 

그렇게 서로의 코드리뷰를 하면 1일차가 순삭나게 된다.

 

2일차

 

이번 주차에는 마지막 주차다 보니 후회없이 미션을 진행하고 싶었다. 그래서 다른 사람들의 장점들을 전부 흡수해서 이번 미션에 쏟아보고 싶어졌다. 따라서 2일차까지는 본인과 다른사람들의 코드리뷰를 보면서 제시된 의견들중에서 새로운점이나 배울만한점등등을 기록했다.

 

그리고 그 기록들을 하나씩 읽어보면서 상세하게 찾아보기 시작했다.

 

코드리뷰에서 기록한 정보들중 일부

 

이런식으로 하나씩 상세하게 찾아보면서 정보들을 정리했다.

 

 

주차를 진행하면서

4주차 미션은 크리스마스 프로모션 미션이었다. 여태까지의 우테코 프리코스에서 나온적이 없는 완전 새로운 미션이였다. (코치님들 말로는 아주 어려울 거라던...)

 

미션의 난이도는 앞선 3주간의 미션을 가볍게 뛰어넘는 문제였던것 같았다.

미션의 기능들부터 제한사항 등등이 매우 꼼꼼하게 작성되어 있었고, 각 기능간의 상호작용이 매우 긴밀하게 이루어져 있기에 기능분리를 상당히 잘 해야할것이라고 생각하였다. 

(다른것보다 기능분리가 제일x25 어려웠다..) 

 

늘 그렇듯 이번주차도 큰 목표를 하나 잡았다.

 

이번주차는 '여태까지 배운 모든것을 녹여보자!' 라는 타이틀을 잡고 가기로 했다.

 

마지막 주차이고, 프리코스를 진행하면서 학습한것을 이번주차에 전체적으로 쏟아붓기로 했다.

그리고 다른분들이 주신 영감들도 전부 참고하여 이른바 내 현재 실력의 '최종품'을 보여주고 싶었다.

 

세부적인 목표로는 1.프리코스간 해결하지 못한 의문점을 해결해보자! 2.다른 분들의 영감을 최대한 활용해보자! 3. 기본을 준수하자! 이렇게 3개의 소목표를 가지고 주차를 진행했다.

 

1. 프리코스 동안의 의문점! 여기서 마무리다!

 

프리코스를 진행하면서 여러 의문점들이 발생했고 그럴때마다 다양한 사람들의 의견들을 참고했다. 

(이런 고민들의 대부분은 나만 하는게 아니라더라..)

 

이런 과정에서 대부분의 의문점들은 해결이 되지만 아직 해결하지 못하고 애매모호한 의문점들도 남아있었다.

그 중에서 가장 본인의 의문을 가지게 만든건 바로 이것이었다!

 

 DTO(Data Transfer Object)에 Validate 로직이 들어가도 되는걸까?

 

 

이 의문은 프리코스 1주차때부터 본인을 계속해서 따라다닌 아주 지겨운 놈이다!

물론 매 주차마다 그 당시의 해결책을 냈다.

처음에는 '생성자에 validate 로직이 들어가는 건 괜찮지 않을까?' 라는 생각으로 진행하였고

그 다음에는 'DTO는 getter/setter를 제외한 로직이 들어가면 안되니까 이를 생성하기 전에 처리하자!' 라는 생각으로

DTO 객체 생성을 하는 클래스 (본인의 코드에서는 대표적으로 InputView 였다)가 값의 validate를 처리하고 이를 통과한 값을 DTO에 넣는 식으로 진행했다.

 

하지만 이렇게 'Validate 로직이 View에 있는것이 과연 View의 역할에 적합한가?'라는 의문이 들었다. 

이런 의문이 들때마다 찾는곳은 바로 디스코드의 토론 하기 채널!

아니나 다를까 이에 대한 많은 의견들을 이미 나누고 있었다.

 

모두가 한마음 한뜻으로 고민하는 열정적인 곳

 

 

각자의 의견들이 다양했고, 전부 일리가 있는 말이어서 '어느것이 맞다!' 라고 딱 정하기 어려웠다. 그렇게 이번에는 인터넷에서 정보를 찾아보기로 했고 한 사이트를 발견하게 되었다.

 

https://creampuffy.tistory.com/188#DTO%EB%8A%94%20%ED%83%9D%EB%B0%B0%EC%83%81%EC%9E%90%EB%8B%A4-1

 

📦 DTO는 택배상자 (Bean Validation 검증은 누가 하나?)

팀 프로젝트 중 DTO 사용 관련 논의가 있었습니다. DTO 내에 getter이외의 로직을 담지 않는 게 어떨지 제안하는 과정에서 제가 생각하는 DTO에 대한 정의를 이야기해보았습니다. 이와 관련해 다시

creampuffy.tistory.com

 

해당 글쓴이는 DTO에는 getter/setter 로직만이 들어가야한다고 주장하면서 DTO를 택배상자에 비유했다.

 

현실에서 택배상자가 스스로 내부의 물품에 대해 검증을 하지는 않는다는점에서 DTO에는 검증로직이 없어야 하는게 옳고 이를 검증하는 것은 택배상자를 싸는 사람, 즉 DTO를 호출하는 쪽에서 검증하는게 맞다고 하는 주장이었다.

 

 

'그럼 앞에서 언급한 View에 넣는다는 말과 동일한거 아니냐?'

 

 

맞다고 볼수있다! 하지만 나는 View에 validate로직을 넣는것이 그렇게 좋다고 생각하는 편이 아니었고, 어떻게 해야 이를 해결할수 있을지 고민하던중 한 코드리뷰에서 Mapper 클래스를 이용한 것을 보았다.

 

이를 보자마자 이걸 이 문제에 적용하면 되겠구나 했다!

 

간단하게 말하자면 View에서 Mapper의 메서드를 호출한다. Mapper의 메서드는 입력값의 검증을 하고 이후 해당 값을 DTO로 변환시켜주고 이를 반환해주는 로직을 가진다. 이를 통해 View에는 실질적으로 Validate로직이 들어가지 않고 Mapper에 책임을 넘기는 느낌이 된다!

 

이런 방식을 이번 미션에 적용하였고 결과적으로 해당 파트에서는 책임의 분리가 잘 일어났다고 생각하였다.

 

 

2. 좋은것은 같이 쓰는게 좋은게 아닐까?! (물론 확실히 알고서)

매 주차마다 코드리뷰를 하면서 느끼는 것은 '내가 떠올리지 못한것을 떠올리고 반영하였더니 코드가 더 말끔해졌다'라는 것이었다.

코드리뷰를 할때마다 늘 새로운 관점의 코드를 다양하게 보게되고 이를 통해 본인이 놓치고 있던것이나 몰랐던 것을 알수 있게되는 계기가 되었다.

 

3주차에서 얻을수 있던점은 바로 함수형 인터페이스와 제네릭의 활용이었다.

 

'로또 미션' 중에는 당첨개수와 보너스 번호에 따른 등수 판단 기능이 들어가야 했다.

본인의 경우는 각 등수별로 당첨개수와 보너스번호를 Enum의 인자로 놓고 이 전체를 stream으로 돌면서 등수를 찾아냈다.

 

하지만 어떤분의 코드를 보니 이를 람다식과 함수형 인터페이스를 사용하여 심플하게 구현한것을 발견하였다. 이를 보고 상당히 큰 영감을 얻을수 있었다. 

 

또한 오류발생시 재입력기능은 본인은 반복문을 사용하여 구현하였는데 어떤 분이 제네릭과 상속을 이용해서 구현한것을 보고 상당한 충격을 먹었다.

내가 대체 뭘 본걸까 하는 표정 (그정도로 신세계 였다는거지..)

 

어찌보면 상속의 목적은 공통된 기능을 상속하여 코드의 재사용을 방지하는 것이라고 생각한다.

그렇기에 이 오류발생시 재입력기능 역시 여러곳에서 사용되는데 이를 상속을 통해 묶어주는 발상이 나를 상당히 놀라게했다. 거기에 제네릭을 통해서 상속을 더욱 유연하게 만든것이 상당히 인상적이었다.

 

그래서 이번미션에서 나는 '공통된 기능을 최대한 묶어보자!'라는 목표를 가지고 진행하였고 결과적으로 공통기능들을 최대한 묶어 확장성을 추구하게 되었다.

 

3. 기본은 괜히 기본()이 아니다!

본인은 2주차 이후로 항상 조심하는 것이 하나 있다.

 

 

"배보다 배꼽이 커지도록 하지 말자"

 

 

여러가지를 배우다보니 지식이 많아지고 이 지식에 매몰되는 경우가 생겼다.

즉, 기본적인 기능분리,클래스분리도 제대로 못하는데 패턴이니, 전략이니 개발방법론이니 이런 부수적인것들을 적용하려고만 하다보니 코드가 더욱 이상해지는 결과를 나아내는 경우가 많이 있었고 실제로 본인도 2주차 과정에서 한번 겪었었다. 

 

이번 미션에서의 본인의 목표인 배운것을 모두 녹여내려다 보니 정작 기본적인 분리도 못할수 있다고 생각하였고, 모든것을 적용하더라도 기능분리 하나만은 충실하게 지키자고 생각하였다.

 

결과적으로는 어느정도 지켰다고 생각하지만 코드리뷰를 하면서 보니 부족한점이 생각보다 많았다.

(사실 이번주만 그런게 아니라 매 주차마다 부족한점은 늘 생겨난다.)

 

거기에 기본적인것을 준수하지 못한점도 몇가지 보였다. 정작 어려운 방법론이나 스킬등은 적용을 해놓고 기본적인것도 못하니 너무 부끄러웠다. (마치 백엔드 스프링을 하는데 기초적인것도 못하는데 여러가지를 붙여넣는 느낌)

 

이를 통해 항상 기본을 중심 토대로 잡고 가지를 뻗어 가듯이 코드에 녹여내야겠다고 생각했다.

 

 

주차 반성점 및 개선사항

이번주차는 모든것을 적용해보는 과정에서 많은것을 느꼈던것 같다

 

1. 남들과의 과한 비교는 본인을 힘들게 만든다.

이전까지는 코드리뷰를 통해 다른 분들의 코드를 보면서 일종의 의지가 생겼다. 

 

"나도 열심히 하면 저분들을 따라갈수 있지 않을까? 이번주도 최선을 다해보자!"

 

이런식으로 일종의 자극을 받아서 프리코스를 열심히 할수있게 하는 원동력이 되어주었다.

하지만 4주간의 코드리뷰를 진행하면서 이 간격이 좁아지는 느낌이 전혀 들지 않았다.

내가 다가가면 그분들도 멀어지고, 이렇게 반복되다 보니 상대적으로 내가 정체되어 있는것 같다는 느낌이 들었다.

 

"분명 나는 열심히 했고 많은것을 배웠는데 왜 차이가 안좁혀지는거지..? 난 발전을 못하고 있는건가..?"

 

이런 생각이 머리 한구석을 차지하더니 이것이 점차 커져갔고 결국 이번주차에 터져버린것이었다.

프리코스가 끝난 지금에서야 보니 그저 모두가 발전을 하고 있는 상황이었는데 당시에는 너무 '잘해야한다'라는 강박감에 쫓겨서 크게 보지 못했던것 같다.

 

이제는 이런 현상을 보면 예전에 물리시간에 배운 절대속도와 상대속도를 생각하기로 했다.

내가 열심히 했는데 실력차가 좁혀지지 않았다면 그건 그사람도 열심히 하고 있다는것이고 나도 열심히 하고 있다는것이다. 오히려 그 분들의 속도를 따라간것 자체가 상당히 대단한 일이 아닐까?

결국 목적지는 같다. 빨리도착하냐 늦게 도착하냐 차이인것이다. 도착이 확정적 결과라면 오히려 그 과정을 괴로워하는것 보다는 즐기면서 가는게 좋지 않을까?

 

 

우테코 프리코스를 마무리 하면서..

이번 4주는 아마 본인의 개발자 인생에서의 여러 변곡점중 하나일것이라고 생각한다.

대학에 들어와서 프로그래밍이라는것을 처음 배우고 지금까지 약 6년동안 이정도로 개발(이라고 하기에는 작은 미션..)에 몰두한적이 몇 없었던것 같다.

거기에 그 과정에서 지금과 같은 블로그 포스팅이나 오프라인 모각코, 온/오프라인 코드리뷰 등등 여러 새로운 경험을 하고 여러 사람들과 교류 및 의견을 공유하면서 새로운 것을 배워가고, 성장을 하게되고, 그 과정이 즐겁고..(& 힘들고,졸리고,죽을것같고..) 참 말로 표현하기 어려운 감정들이 많이 생겨났다.

 

4주차가 마무리 되자마자 느낀건 뿌듯함도 있지만 공허함도 있었다.

매번 미션이 있고 코드리뷰도 있었는데 이제는 이게 없다니.. 뭔가 내 삶의 일부분이 사라진것 같은 느낌이었습니다. 약간의 섭섭함도 느껴졌다.

(이정도면.. 나는 고통을 즐기는게 아닐까..?) (하지만 끝난날 밤만큼 잠을 푹잔적이 없었다.)

 

우테코의 교육방식을 프리코스를 통해 조금이나마 경험하면서 이렇게나 많은 이야기와 성장이 있었는데 이것을 1년동안 하게 된다면 과연 나는 어떤사람이 되어버리는걸까? 라는 기대감도 생겨났다.(하지만 붙어야만 느낄수 있는 이 감정.)

 

물론 우테코에 붙는다면 정말 좋겠지만.. 만약 떨어지더라도 이번 경험은 본인의 개발자 인생의 큰 기반이 될것이라 의심하지 않는다. 개발자 인생뿐만 아니라 인생을 살아가면서도 이런 몰입경험은 큰 도움이 될것이라고 생각한다.

 

혹시 우테코를 고민하고 있는 개발자 지망생이 있다면 한번쯤은 해보는것도 좋을것이다. 물론 자신과 안맞을수도 있다. 하지만 본인은 우테코를 통해 얻는것이 너무 많았다. 

 

이러한 개발인생의 큰 변곡점을 만들어준 우테코 코치분들에게 다시한번 감사하다는 말을 드리며 4주차, 마지막 회고록을 마무리하려고 한다.

 

(TO BE CONTINUED..?)

 

P.S 아마 결과 발표전까지 최종코테 준비를 오프라인 우테코 인원들과 할것같은데 종종 이런 결과에 대해 포스팅 할지도 모르겠다.

(솔직히 시간만 많으면 막 포스팅하고 싶지만 이번주차는 미션구현만해도 시간이 부족했어서...)

 

 

기타 잡담

1.스터디 리팩토링은 언제하지.. (1주차 코드가 벌써부터 두렵다.. 얼마나 돌아가는 쓰레기를 만들었을까..?)

 

2. 우테코가 끝나니 일종의 번아웃.. 이제 어떤거에 '몰입'해야할까..

 

3.우테코 붙고 싶드아아아아!