[회고록] 우아한테크코스 5기 - 프리코스를 마치고

https://www.woowahan.com/
배달의 민족 운영사인 우아한 형제들에서 운영하는 개발자 양성 프로젝트, 우아한 테크코스에 지원하게 되었다.

지원 동기

대학교 4학년 졸업을 앞 둔 시점,
국비 교육에서 프로젝트를 진행하며, 취업이 점차 다가온다는 것을 느낀 나는, 취업을 위해 코딩 테스트 준비를 하기 시작했다. 하지만 코딩 테스트를 준비할수록, 내가 원하는 기업에 갈 수 있을지 너무나도 불투명해졌다.

 

마냥 프로젝트와 코테 준비로 바쁘던 중, 아는 형의 추천으로 우아한 테크코스를 접하게 되었고, 나를 좋은 개발자로 성장시켜 줄 수 있는 부트캠프라는 확신이 들자 지원하게 되었다.

 

지원서

지원할 당시에는 코딩만 잘 하면 된다는 생각이 컸어서, 지원서에 많은 신경을 쓰지 않았던 것 같다.

하지만 지금 다시 생각해 본다면, 지원서만큼 나를 잘 나타낼 수 있는 것이 없다.

 

만약 이후 기수에 도전하시는 분이라면, 지원서를 전략적으로 잘 작성해서 제출하시길 권장한다.

 

 

1. 프로그래밍 학습 과정

학습 과정에는 글자 수를 다 채우려 노력하지 않았고, 간략하게 내가 어떤 과정을 겪어 왔는 지를 나열했다.

고등학생 때 코딩 학원을 다닌 경험부터,

대학교 컴퓨터 공학을 전공한 이야기와 다니고 있던 국비 교육 이야기로 마무리 지었다.

 

이 부분은 간략한 경험 확인 과정이라 생각된다.

 

2. 프로그래머가 되려는 이유

이 부분에는 내가 개발자가 되려는 이유로 가득 채웠다. 언제부터 이 꿈을 갖고 있었고, 왜 프로그래머가 되려고 하는지를 중심으로 이야기를 풀어나갔다.

 

3. 마음이 끌리는 무엇인가에 긴 시간 동안 몰입해 본 경험

내가 가장 후회되는 부분이다. 1년 이상 오랫동안 했던 것을 작성해야 하는데, 딱히 떠오르는 부분이 없어서 학과 졸업작품을 주제로 이야기를 풀어나갔다.

 

하지만 지금 생각해 보면, 굳이 SW 부분이 아니어도 된다고 했기 때문에, 오히려 SW가 아닌 부분으로 작성하는 것이 더 도움이 될 것 같다. 예를 들자면, 나는 초등학교 때부터 중학교 때까지 큐브를 좋아했어서 수집하기도 하고, 공식을 외우는 것에 시간을 투자하기도 했었는데. 이 경험을 썼으면 어땠을까 후회가 된다.

 

 

4. 우아한테크코스에 참여하려는 이유

가장 중요한 부분이라고 생각한다. 이 부분에는 내가 왜 우테코가 필요한지. 내가 어느 부분이 부족해서, 그것을 우테코에서 어떻게 채우고 싶은지를 위주로 작성하면 좋을 것 같다.

 

 

 

 

프리코스 과정

이번 기수인 5기 부터는 프로코스를 진행한 후, 최종 코딩테스트를 하도록 변경되었다.

프리코스는 총 4주간 일주일마다 미션이 주어지고, 깃허브에서 Pull Request를 통해 미션을 제출하는 방식으로 진행되었다. 물론 미션을 제출할 때마다, 소감문도 같이 작성해서 제출하여야 했다.

 

나는 주차가 진행될 수 록 소감문의 중요성을 깨달아서, 잘 쓰려고 노력했지만.

처음부터 구조적으로 일관성 있게 잘 쓰는 것도 중요할 것이라 생각한다.

 

 

아래부터는 내가 프리코스를 진행하면서, 어떤 것이 어려웠고 무슨 공부를 하며 진행했는 지를 적어 보았다.

 

1주차 프리코스 <온보딩>

1주 차 프로코스 미션의 제목은 <온보딩>이었다.

온보딩(onboarding)

영어로어로 '배에 탄다'는 뜻으로
신규 직원이 조직에 수월히 적응할 수 있도록 업무에 필요한 지식이나 기술 등을 안내·교육하는 과정을 뜻한다.

 

첫 주차 미션 명을 보고 나니, 열정이 불타오르게 되었다.

온보딩 미션은 총 7개의 미션으로 구성이 되어 있었고, 별다른 요구사항이 보이지 않았다.

프리코스를 진행 하기 전, 진행했던 코딩테스트 방식과 비슷해 보였다. 문제들의 난이도도, 프로그래머스 2단계 정도의 수준으로 보였고, 적당한 시간 투자로 풀 수 있다고 생각이 들었으나, 바로 풀지 않고 오랫동안 어떻게 풀 지 생각을 해 보았다.

 

처음 해보는 미션인 만큼 너무나도 조심스러웠다. 심지어,

제공된 미션에서 파도타기로 다른 기수 미션의 제출 제약을 보고는, 나도 모르게 적용해야 겠다고 생각했던 적이 있다.

예를 들어, depth 2를 넘기지 말라는 문구와, 함수 하나가 하나의 기능만 하게 하라는 등의 제약 사항을 보았어서, 1주 차부터 적용하려고 노력했었다.

문제를 풀기 시작한 것은, 커밋 컨벤션과 인텔리J의 사용법을 익히고 나서야 시작했다. 이 때는 요구사항을 무조건 적으로 다 지켜야 된다는 생각에 수도 없이 정독하면서 풀었던 기억이 난다.

문제를 풀면서 가장 고전했던 문제는 문제 난이도가 어려웠던 6번과 7번 문제가 아닌, 2번 문제였다.

 

2번은 간단한 중복제거 문제로, 프로그래머스에서 비슷한 문제를 풀어본 기억이 있어, 바로 스택으로 접근하여 문제를 해결하였다. 하지만 미션 참가자들을 관리하는 슬랙 커뮤니티에 올라온 뜻밖의 글이 나를 고민의 늪으로 밀어버렸다.

 

바로 'apppa' 를 중복제거 하였을 시,
'apppa' > 'apa'
'apppa' > 'aa' > ' '

위와 아래 중, 어느것이 정답이냐는 글이었다.

당연히 프로그래머스로 문제를 접해본 나는 첫 번째의 경우로 해결을 하였으나, 사람들의 의견이 분분하였고, 그들에게 설득당해 버렸다.

 

나는 프로그래머스 문제를 접했다는 이유로, 생각이 제한이 되어 있어서, 두 번째 방식으로 풀 생각을 해보지도 않았었다.

하지만 댓글들의 말들이 충분히 설득력 있었고, 미션 진행 방식에  "기능 요구 사항에 기재되지 않은 내용은 스스로 판단하여 구현한다."라는 부분이 있어서 혼자 생각하는 시간을 갖게 되었다.

 

결국 나는 2번 방식으로 풀기로 결정을 하여 2번 방식으로 미션을 해결을 하였다.


1주 차 미션의 경우, 커밋도 최대한 깔끔하게 보이면 좋다는 생각이 있었기 때문에, 모든 문제를 해결하고 부분적으로 커밋을 진행하였다.

하지만 3,4주 차 미션을 진행하며, 코치님들이 보고 싶으신 것은 내가 어떻게 코딩을 했는지의 <과정>이었다는 것을 깨닫게 되었으며, 미션을 마친 지금은 이렇게 커밋한 것이 내가 가장 후회하는 부분이 되었다.

 

olrlobt 1주 차 미션 보기 : branch olrlobt
https://github.com/olrlobt/java-onboarding/tree/olrlobt

GitHub - olrlobt/java-onboarding: 온보딩 미션을 진행하는 저장소

2주 차 프리코스 <숫자야구>

2주차 미션 제목은 <숫자야구>였다.

숫자야구의 경우, 초등학교 때 숫자야구로 학교를 재패했었기 때문에 자신 있었다.

2주 차 요구사항을 보고 나서는, "1주 차 때 안 지켜도 될 것을 지킨 것이구나!"라는 깨달음과, "미리 해봤으니 쉽겠는데?"라는 생각이 같이 들었다. 그리고 이번 미션에서는 클래스는 나누어 풀어야 조금 더 좋은 코드가 될 것이라는 느낌이 들었다.

 

나는 지난 주차와 마찬가지로, 추가 요구사항과 문제를 수도 없이 읽었다. 역시 문제를 풀기 시작한 것은 2 ~ 3일이 지난 후의 시점이다.

난 이 2 ~ 3일 동안의 기간 동안 머릿속으로 어떻게 문제를 풀어야 좋은 풀이가 될 수 있을까 고민을 하였고, 클래스를 잘 나누면 되겠다는 생각에 클래스 나누는 방법을 무작정 검색하면서 시작을 하였다.

 

검색 결과, MVC 모델에 관하여 아주 아주 얕게 알게 되었고, 해당 지식을 바탕으로 코딩을 진행하였다.

나의 2주 차의 코드를 보면, 정말 MVC를 얕게 아는 정도로, M. V. C 느낌으로 구현을 해 놓았다.

 

지금 보면 조금은 부끄러운 구성이긴 하지만, 당시에는 나름 괜찮은 구성이라고 생각했었다.

미션을 진행하면서 가장 난처했던 부분은, 랜덤함수를 테스트하는 부분이었다. 어떤 식으로 랜덤함수를 테스트해야 하는지 몰랐던 나는, 한 검색 결과를 보게 되었는데, 글의 결론에는 <객체를 객체스럽게 사용하도록 리팩터링 해라.>라는 말과 함께 예시가 적혀 있었다.

 

 

 

해당 예시를 바탕으로 리팩토링을 진행하여, 객체를 객체답게 사용하려 노력하였고, 객체 자체가 로직에 포함되도록 구성하였다.

 

객체를 객체스럽게 사용하라
https://tecoble.techcourse.co.kr/post/2020-04-28-ask-instead-of-getter/

getter를 사용하는 대신 객체에 메시지를 보내자

PR 제출 이후에는 다른 분들의 코드를 찾아보는 시간을 가졌었다.
이때, PR에서 수도 없이 분리를 해 놓으신 분의 코드를 보게 되었는데, 이게 옳은 것인가?라는 생각이 머릿속을 헤집어 놓았다.

왜냐하면 나는 이 숫자야구 코드의 경우, 그렇게 복잡한 코드가 아니기 때문에, 과도한 분리는 오히려 독이 된다고 생각했다. 깔끔하게 컨트롤러, 뷰, 모델만 있어도 되는 규모의 코드라고 생각했다. 나는 이 의문점을 갖고 2주 차를 마치게 되었고, 3주 차, 4주 차를 지나가면서 점차 머릿속이 정리되었다.

olrlobt 2주 차 미션 보기 : branch olrlobt
https://github.com/olrlobt/java-baseball/tree/olrlobt

GitHub - olrlobt/java-baseball: 숫자 야구 게임 미션을 진행하는 저장소

 

3주 차 프리코스 <로또>

3주차 미션 제목은 <로또>였다.

미션은 주어진 Lotto 클래스를 활용하여 구현을 하여야 했으며, 생소하였던 ENUM 또한 사용하여야 했다.

 

3주 차 미션 역시 시작하기에 앞서, 문제를 읽고 이해하는 시간을 가졌으며, 생소했던 ENUM과 도메인로직 단위테스트에 관하여 검색해보며 시작했다. 그리고, 지난 미션에서 부족했던 MVC에 관한 얕은 지식을 조금이라도 더 깊게 만들고 시작하였다.

 

 

2주 차 때와 변화된 패키지 구조의 모습이이다.
내가 이해한 MVC 모델의 구조는, 가장 중요한 Model(Domain)과 Controller, View를 중심으로 구성되며, 나머지 부분은 필요에 따라 생성된다고 이해했다.

 

특히 Domain에 해당하는 부분에는 비즈니스 로직이 포함된 객체 클래스를 담았고, Service에는 객체에서 수행하지 않는 비즈니스 로직을 담았으며, Util에는 로직에 포함되지 않는다고 생각되는 작업 (변환, 파싱, 검증 등)의 작업을 넣었다.

 

미션 완료 후에도, 계속 어느 패키지에 있어야 할지 고민이 되는 것을 보니, 공부가 부족하다는 느낌이 들었다. MVC모델에 관련해서는 블로그 포스팅만 봐서는 이해가 부족할 것 같으니, 남는 시간에 강의를 찾아보면서 공부해 보아야겠다.

 

미션 도중 재밌었던 부분은, Stream을 사용하는 부분이었다. 이 전 미션에서는 Stream에 관한 지식이 없어서 사용을 못하였었다. 하지만, 지난 미션의 PR리뷰를 많이 찾아보니, 많은 제출자 분들께서 Stream을 사용하시는 모습을 볼 수 있었고, 나도 사용하고 싶은 마음에 Stream을 찾아보았다.

 

신기했던 것은, 문법을 알지 못했을 때의 Stream은 정말 복잡해 보이고, 깔끔한 코드처럼 보이지 못하였었다. 하지만 조금 알고 나니, 코드가 간편해진 것을 많이 느끼고, 활용성 면에서 감탄이 나왔다. 특히 이번 미션이 Stream에 특화되어 있는 미션이라는 생각이 들 정도로 Stream을 많이 사용한 것 같다.

 

반대로 미션에서 가장 어려웠다고 생각되는 부분은, ENUM 부분이었다. 사용한 적이 없기도 하였고, 이해하는데 시간이 필요했으며, 이해를 하고 나서도 미션 어느 부분에 활용해야 하는지 감이 잡히질 않았다. 또한, 로또의 옳은 개수(correct)와 상금(prize)을 연결하고 나서도, 2등과 3등의 correct를 처리하는 부분에서 상당히 애를 먹었던 것 같다. 간단히 if문으로 처리하면 되는 것을 알지만, 조금 더 깔끔한, 클린 한 코드를 원하였기에 이 부분에서 시간을 많이 소비하였던 것 같다.

PR 제출 이후에, 로또라도 한 장 사야 하나 고민을 하게 만드는 미션이었다. 이번 미션 역시 많은 것을 배웠으며, 자바를 자바답게 쓰는 개발자가 되기 위한 첫걸음을 이 미션에서 뗀 것 같은 기분이다.

olrlobt 3주 차 미션 보기 : branch olrlobt
https://github.com/olrlobt/java-lotto/tree/olrlobt

GitHub - olrlobt/java-lotto: 로또 미션을 진행하는 저장소

4주 차 프리코스 <다리 건너기>

4주차 미션 제목은 <다리 건너기>였다.

이 전의 <숫자야구>와 <로또>의 경우는, 지난 차수에서 진행했던 게임으로 알고 있다. 따라서 마지막 미션에는 새로운 게임이 나올 것 같다고 예상했었는데, 예상이 들어맞았다.

 

<다리 건너기> 게임은 오징어게임의 다리 건너기 게임을 모티브로 하고 있었다. 오징어게임을 이미 다 본 나는 미션에 접근하기 쉬웠지만, 역시 요구사항을 꼼꼼히 살펴보았다.

함수(또는 메서드)의 길이가 10라인을 넘어가지 않도록 구현한다.
메서드의 파라미터 개수는 최대 3개까지만 허용한다.
주어진 InputView, OutputView, BridgeGame, BridgeMaker, BridgeRandomNumberGenerator 클래스의 요구사항을 참고하여 구현한다.

 

슬랙을 살펴보니, 첫 번째 요구사항에 관한 곡소리가 많았는데, 나는 공감하지 못했다.

생각해 보면, 지난 3주 차 미션도 10줄을 넘지 않았던 것으로 기억했기 때문이고, 실제로 view 출력문 메서드 1개를 제외하고는 모두 10줄 이내였다.

 

내가 두려웠던 것은 오히려 세 번째 요구사항이었다. 클래스가 주어진 것도 모자라, 각 클래스마다의 요구사항이 따로 붙어 있었다. 역시 최종보스 답다는 생각이 들었다.

 

나는 이 미션을 진행하기에 앞서, 또다시 MVC에 대하여 공부하였다. 저번 주차에 내가 가장 의문이었던 부분이 MVC모델에서의 Service의 역할이었다. 아무리 검색을 해 보아도, Service를 사용하는 역할에는 DB를 접근하기 위한 용도로 밖에 포스팅이 되어있지 않았다.

 

하지만, 어느 한 블로그에서 "Controller에서는 오직 View와 Service만을 호출하며, 로직이 표현되어서는 안 된다."라는 글을 보았고, 이를 적용해 보기로 하였다.

 

나는 보통 코딩을 진행할 때, 컨트롤러는 메서드를 나누지 않은 채 진행을 하는 습관이 있었는데, 코딩을 마치고 리팩토링을 진행하다 보니 큰 문제에 맞닥뜨렸다.

 

바로, BridgeGame은 서비스인가 도메인인가에 관한 문제였다.

BridgeGame 클래스 요구사항에는 다리 건너기 게임을 관리하는 클래스라는 설명이 기본적으로 제공되어 있었는데, 이 멘트 때문에 더 헷갈렸는지도 모르겠다.

일반적으로 (관리 = 컨트롤러)이니, 컨트롤러나 서비스로 쓰라는 말씀이신가?라는 생각이 머릿속을 혼란스럽게 했다. 내 생각에는 아무리 봐도, 도메인으로 적합하다는 생각이 들어 도메인으로 사용하게 되었지만, 도메인으로 사용하면서 컨트롤러를 분리하는 작업을 하다 보니, 서비스를 생성할 수 없게 되어 버렸다. 이미 서비스에서 할 일을 도메인 내부 로직에서 다 처리하고 있었기 때문이다.

 

따라서, 나는 서비스의 필요성과 역할을 또다시 찾기 시작하였고, 앞서 말한 것처럼 DB 접근이나 데이터 가공의 역할을 한다는 검색결과밖에 찾지 못하여, 서비스 없이 미션을 마무리하였다.

 

 

이 부분이 너무나도 찜찜한 부분이었지만, 내 나름의 확신을 갖고 제출하기로 하였다. 소감문도 마무리 짓고 제출을 다 하고 나니, 마지막 미션까지 나름 성공적으로 제출했다는 생각에 뿌듯한 하루를 보냈던 것 같다.

 

1차 합격자 결과 발표를 기다리는 동안, 해야 할 것들이 산더미지만, 쉬어가는 것도 중요하다고 생각한다.

 

olrlobt 4주 차 미션 보기 : branch olrlobt
https://github.com/olrlobt/java-bridge/tree/olrlobt

GitHub - olrlobt/java-bridge

느낀 점

길기도 하고 짧기도 했던, 4주간의 프리코스를 마치며, 4주 동안 정말이지 많은 것을 배웠다.

특히 내가 4주동안 소감문에서만 외쳤던 "자바를 자바답게"라는 멘트는 정말이지 마음에 든다. 프리코스를 진행하는 동안 배웠던, 혹은 스스로 공부했던 모든 코드들은 하나같이 "자바를 자바답게" 쓸 수 있게 나를 성장시켰다고 해도 과언이 아니라 생각한다.

 

앞으로 마주하게 될 프로젝트들도 여기서 배운 모든 것들을 적용하여, 나를 더욱 성장시킬 생각이다.

4주간 이렇게 성장했는데, 우테코의 10개월 과정을 거치면 어떤 엄청난 개발자가 되어 있을까 내심 기대되면서도, 기대가 크면 실망도 크기에 조금만 기대해 보도록 한다.

 

만약, 이 글을 보시는 분께서 우테코 프리코스를 경험해볼까 말까 고민 중이시라면, 무조건 적극적으로 추천한다고 이야기해 주고 싶다. 그만큼 얻어갈 것이 많다고 생각하는 한 달이었다.

 

결과 발표까지 남은 기간 동안은, 현재 국비 프로젝트에서 진행 중인 프로젝트가 2개나 있기에, 여기에 몰두할 생각이다.

이상으로 프리코스 회고록을 마친다.

olrlobt 깃허브
https://github.com/olrlobt

---

탈락 후기 (2023/01/05 추가)

프리코스를 끝내고, 정말 바쁜 날들이 지나갔다. 진행 중이었던 국비 프로젝트 2개부터, 싸피 인터뷰까지 마치고, 국비도 수료하였으며, 대학교 졸업만을 기다리고 있다.

 

지금 생각해 보아도, 프리코스 과정이 도움이 되었다는 생각에는 전혀 변함이 없다.

 

탈락 메일을 받을 때 심정은 그냥 탈락할 것을 알았던 것처럼 덤덤했다.

미션을 진행하면서도 느꼈지만, 지원자만 1500명이고, 지원자가 작성한 코드를 코치님들이 다 볼 수 없을 것이다라는 생각이 들었다. 그렇다면 무슨 기준으로 사람들을 뽑았을까? 내 생각엔 지원서와 소감문의 비중이 크다고 생각한다.

 

지원서 자체가 짧은 편이 아니기 때문에, 그리고 지원자의 정보를 알 수 있는 유일한 길이기 때문에, 지원서를 보고 안 뽑을 사람들을 분류했을 것이라고 생각한다.

 

지원서에 조금 더 신경 써서 제출할걸, 이라는 후회도 조금은 들긴 하지만, 이미 다 끝난 일이고 다른 길을 찾으면 된다.

 

그리고

나에게 우테코 6기를 지원할 것이냐라고 묻는다면, 조금 고민할 것 같다. 프리코스의 4주간의 과정을 다시 반복하였을 때, 떨어졌을 때의 리스크가 너무 크다고 생각한다.

 

지금의 나는 할 수 있는 것을 하고, 차라리 다른 부트캠프를 기다리거나, 취업 준비를 하는 것이 더 도움이 될 것 같다는 생각이다.