"몰입과 방향" 우아한테크코스 5기 최종 탈락 회고

이 글은 5기 우.테.코  벡엔드 파트  선발과정에 참여를 했다가 최종에서 떨어진 사람의 회고글이다.

 

당시 벡엔드 파트 지원은 2000명 정도 였으며 최종 코테는 약 200 명의 사람들이 응시를 했다.

 

결론 , 그래도 좋았다.

 

최종에서 탈락을 하여 ,당시에는 정말 절망적이고 우울했지만 시간이 흐른 지금은 떨어진 것에 대하여 연연하지 않아졌다.

정말 많은 것을 배웠고 앞으로 개발자로 성장을 하는데 추구해야하는 방향을 정하는 경험이 되었다.

 

프리코스를 진행하는 기간동안 스타트업 프로젝트 ,학교 수업,싱가폴 단기 연수 등 챙길 것들이 많았지만 노트북을 들고 다니면서 시간이 날때마다 비행기, 버스, 새벽 싱가폴의 호텔 로비 등 시간,장소를 가리지 않고 과제를 함과 동시에 좋은 코드와 구조는 무엇일까 고민하는 것이 재미 있었고, "몰입"을 하는 경험 자체가 너무 즐거웠다. 추가로  oop 에 관하여 공부할 방향을 정한 소중한 경험이 되었다.

 

당시의 내 상황은 벡엔드 개발을 시작한지 6개월(대학교 3-2 재학중)이였으며 개발을 시작한지는 1년 정도 였다.  실제 개발에 집중한 시간은 학교를 다니는 시간 및 대학생 스타트업 일 등을 제외하면 정말 짧은 기간이었다.

 

프리코스 시작전에는 자바 객체 생성의 기본이 생성자라는 것을 까먹을 정도로 기본기가 부족했으며, 4주차에는 싱가폴 단기 연수를 진행 하면서 코드의 품질이 떨어지는 것을 느겼다.

( 4주차에 인터페이스 라는 것을 처음 사용해본 경험을 했다라는 사실이 당시에 내가 엄청난 코린이라는 것을 증명해준다.)

 

그래도, 최종까지 볼 수 있었던 이유는  "모든 제출"을 했고 "모든 테스트 케이스"를 통과를 했다 라는 사실이 가장 컸던것 같다.

 

(아니면 새벽 2시부터 5시까지의 커밋 기록을 좋게 봐주신 것 일지도,,)

 

돌아보면 최종에서 떨어진 이유는 다음과 같은 것 같은 것 같다.

 

1. 최종 코테에서 구현을 완성하지 못했다.

- 시작전에도 일단은 돌아가는 쓰래기를 만들라고 했지만, 나는 그러한 돌아가는 쓰래기 조차 완성을 하지 못했다.

 

당시 긴장을 하는 상황과 부족한 준비로 스스로에 대한 불신과 불안으로 집중을 못한 것이 가장 컸다.

 

만약 최종을 준비하시는 분이라면 꼭 연습을 하고 가길 바란다.

( 추가로 만약 옆자리에 시작부터 기계식 키보드를 뚜드리는 참가자가 있다면 ,시작과 동시에 근처 회의실로 옮기는 것을 추천한다.) 

 

2. 프리코스 기간동안 객체지향적인 코드에 관하여 고민을 하지 못 했다.

 

- 객체지향의 사실과 오해라는 책을 우.테.코 프리코스가 끝나고 추천을 받았는데 책을 다 읽은 후의 나의 프리코스 과제 코드에서 나는 객체지향 프로그래밍을 한게 아니라 그저 자바라는 언어로 원하는 결과만 출력을 했다라는 사실을 뒤늦게 깨달아 버렸다.

 

캡슐화를 한다라고 했지만, 접근자와 수정자만있는 클라스들과 그러한 이유로 응집도가 떨어지고 결합도가 높은 중앙 집중적인 코드들이 많았다.

 

도메인 모델 패턴, 에그리거트 패턴, mvc 패턴의 대한 이해도가 없이 그럴듯 하게 작성한 코드들이 정말 많았다.

 

 

프리코스 기간동안 느끼거나 배운 것들이 정말 많았지만 그 중 인상깊었던 경험은 다음과 같았다.

 

1.커뮤니티가 큰게 도움이 많이 된다.

 

GDSC-HUFS (한국외대 구글 학생 개발 동아리)를 하면서 커뮤니티의 소중함을 느꼈지만, 프리코스 기간 동안  질문을 읽는 것 만으로 새로운것들을 배우고 있었다. 

 

for 문과 lambda 함수의 성능 차이를 지표로 객관적인 수치를 이용하여 비교를 하면서 서로 대화를 주고 받는걸 보면서 단순하게 자바의 버전의 따른 lambda 함수의 성능이 좋아졌다 라는 객관적적인 사실을 넘어 얼만큼 깊게 들어갈 수 있나를 보여주는 참여자분들의 대화를 보고 감명을 받았다.

 

 

2.제한사항의 대한 처리

- 제한 사항의 대한 Validation 의 처리를 할지 말지 ?

case1 제한사항은 100% 지켜서 들어 온다라는 가정에서 -> 예외처리를하면 오버 프로그래밍이 될 수 있어 비용 효율의 문제가 된다 . 

case2. 제한사항은 그래도 validation을 하자 .

 

요구사항이 프리코스에 참여하는 참여자들 사이에서도 해석이 달라지는 것을 볼 수가 있었는데, 돌아 보면 정답이 없는 문제였지만

개발자의 요구사항 및 제한 사항의 대한 해석, 근거 그리고 대응등을 볼 수 있는 부분이였던 것 같다.

 

3. 갓텔리제이 이용

커뮤니티의 이야기를 보고 method 의 호출을 부정문으로 하면 메서드 이름에 경고를 보낸다라는 사실을 알았다. 

 

2주차를 넘어서는 시점에서는 구글 자바 컨벤션을 따라야했고(컨벤션이라는 것을 처음 알았다.), 나의 경우는 pdf 로 다운을 받아서 학교 가는길에 중요한 부분들은 외워서 당연하게 여겨질정도 익혔지만, 인텔리제이의 플러그인을 이용하여 자동으로 줄 맞춤을  적용하시는 분들을 봤다. 

 

4.TestCode 

스프링에 관련한 인터넷강의를 듣고 테스트코드를 따라하는 것을 미리 익혔었는데 그 경험이 다행히 우테코 1 일차에 테스트 코드를 작성하고 실행하는 것들에 큰 도움이 되었다.

 

프리코스를 하는 동안 단위 테스트를 작성하여 빠르게 내가 작성한 코드의 피드백을 스스로 받을 수 가 있고 이후 리펙토링을 하는데 있어 큰 보험이 되었다.

 

4 주차의 인터페이스와 테스트 코드를 같이 받았을때는 어떻게 사용하는지 당황했던 기억이 난다.

 

인터페이스와 테스트코드가 기능 구현에 관련하여 다른이에게 설계도를 넘겨주는 것과 같은 효과를 만드는것 직접 체험을 했다. 

주어진 인터페이스를 구현하는 클라스를 만듬과 동시에 , 단위 테스트 코드도 돌아가게 만드는 작업이 신입에게 작업을 전달할때 이런식으로도 할 수 있겠다라는 생각이 들었다.

 

+당시에는 몰랐지만, 객체지향의 사실과 오해 책에서 설계를 하는 방식에 인터페이스를 우선적으로 구현해 보라는 이야기와 그러기 위해서는 메서드를 정의 할수 있는 테스트코드를 짜야 한다라는 내용이 생각이난다. SOLID 의 OCP 를 지키면서 개발을 하는 방향이 아닐까 싶다.

 

5. 요구 사항 분석 및 기능 구현 리스트 작성 

API 설계를 할때 프론트 팀과 협업 하여 요구사항 명세서를 작성하고 api 작성을 들어갔는데 , 알고리즘코테에서도 사용 할 지 몰랐다.

 

2일차 당시의 목표는 요구사항 리스트를 기반한 기능 구현 리스트의 내용 변경 없이 한번에 구현 하는것이였다.

요구 사항 이라는 것이  프로젝트 경험상 수시로 바뀌면 상당히 생산성이 떨어지는 것을 느꼈던 기억이 있다 . 

 

-> 2주차 시작전 피드백에서 기능구현 리스트는 언제든 변할 수 있다 라는 것을 받아들이고 문서를 수정하면서 작업을 하라 내용을 받았다.

이도 당시에는 몰랐지만,  데이터 기반의 설계가 아닌 책임 기반의 변경사항의 유연한 설계가 필요하다라고 생각이 든다.

오늘의 기능을 충실하게 실행을 하지만 내일의 변경사항을 적용할 수 있는 설계를 해야한다.

 

감상)

추가로 우테코 프리코스 4주차때 싱가폴 구글 퍼시픽에서 일하시는 한국분과 만나서 이야기를 했었는데 , 우테코 프리코스에서 다루는 내용들을 전부 구글 페이 팀에서도 다룬다라는 이야기를 간접적으로 들었을때 , 지난 기간 동안의 학교 수업과 다른 인턴 지원을 어느 정도 내려놓고 했던 고생과 고민, 우아한 테크 프리코스에 모든것을 거는 경험이 헛 된 것이 절대 아니다 라는 판단에 스스로가 감동을 받았다. 본인의 성장을 느끼는 시점이었지만 약간의 불안과 올바른 길을 걷겠다라는 판단이 맞았다라는 것을 외부의 요인으로 알았을때 성취감을 다시 한번 느끼는 경험이었다.