우아한테크캠프 7기 및 우형 최종 탈락 후기

들어가기에 앞서

본 게시글은 올해 6월 21일부터 8월 30일까지 이루어진 우아한테크캠프 7기에 참여하며 제가 경험한 것, 배운 것에 대한 기록입니다. 우아한형제들 최종 면접에서 탈락한 후기도 짧게 다룰 예정입니다. 다만, 비밀유지서약서를 작성했기 때문에 면접 질문이나 상세한 절차는 다루지 않고 개인적인 감상정도만 다룰 생각입니다.

이하의 기록은 회고의 성격을 가지지만 우아한테크캠프에서 어떤 것을 경험하는지 궁금하신 분들이 읽을 수도 있다는 생각하에 작성한 글입니다. 다만, 기수에 따라 교육 내용이 변경될 수도 있습니다.

우아한테크캠프

소켓 프로그래밍 과제 수행

우아한테크캠프 전체 10주 중 초반 7주는 Java, JSP 과제를 수행했습니다. 이 과제들 중 가장 기억에 남는 것은 3주 동안 진행한 소켓 프로그래밍 과제가 아니었나 생각합니다. 스프링 프레임워크나 서블릿을 이용하지 않고 네트워크 통신을 구현하는 것이 처음이기도 했고 다른 동료들을 보면서 가장 많이 배울 수 있는 시간이었습니다.

과제 기간 동안에는 매주 2회 랜덤 매칭을 통해 3~4인의 스쿼드로 코드 리뷰를 진행했습니다. 다만 Github PR을 올린 코드에 대해 코멘트를 달면서 진행하는 것은 아닙니다. 일정 시간동안 각자 돌아가면서 자신의 코드를 설명하고 다른 동료들은 '이 부분이 좋았다.', '이 부분은 이렇게 고치면 좋을 것 같다.' 의견을 달아주는 형식으로 진행했습니다.

자연스럽게 다른 분들의 코드를 접하는 기회가 생겼고 각자의 개성같은 것을 엿볼 수 있었습니다. 누군가는 톰캣의 구조를 깊게 파고들었습니다. 또 누군가는 객체 컨테이너를 만들었습니다. 저희에게 주어진 요구사항은 분명 HTTP 통신을 구현하기, 로그인 구현하기와 같이 단순한 것 뿐이었는데 몇몇 동료들은 그것 이상의 무언가를 만들고 있었습니다.

<출처: 무한도전 술래잡기 특집>

다른 사람들이 그정도 하는데 거기에 질 수는 없었습니다. 아주 간단한 객체 컨테이너라면 어떻게든 만들 수 있었습니다. configuration에 해당하는 클래스를 직접 의존한다거나, 빈 객체를 생성할 때 필요한 의존성은 반드시 먼저 만들어져 있어야 한다는 아주 작?은 문제가 있기는 했습니다만 리플렉션과 어노테이션을 잘 써서 만들 수는 있었습니다.

단, 과제를 진행하면서 가장 중요한 것은 일정 안에 요구사항을 만족시키는 것이었습니다. 코치님 역시 일정에 대한 이야기를 종종 하셨고 당시 일간 회고 때도 항상 그 부분을 가장 많이 신경썼던 것 같습니다. 앞서 말했듯이 저희에게 주어진 요구사항 어디에도 구조적인 부분은 없었기에 주어진 기간 안에서 무리하지 않는 선에서만 챙겼습니다.

미니 세미나 참여

우아한테크캠프의 프로젝트 최종 데모를 발표하는 마지막 주를 제외하고 9주 동안 매주 금요일 2명의 교육생이 미니 세미나를 진행했습니다. 주제는 자유 주제였습니다. 지식도 좋고, 경험도 좋고, 개발과 전혀 상관없는 이야기도 가능했습니다. 그래서인지 마지막 미니 세미나의 제목은 무려 '다이어트 비벖'이었습니다.

서로 다른 지식과 경험을 가지고 있는 개발자 27명 앞에서 무언가를 발표할 수 있는 기회가 쉽게 오는 것은 아니었습니다. 때문에 저 역시 미니 세미나를 참여했습니다. 주제를 결정하는 것은 어렵지 않았습니다. 제가 진행한 미니 세미나의 제목은 '테스트 더블'이었습니다. 좋은 테스트를 작성하기 위한 고민을 계속 가지고 있었고 캠프 참여 직전에 진행했던 프로젝트에서 이것저것 실험을 해보기도 했었기에 발표거리 삼기에 딱 좋은 내용이었습니다.

미니 세미나 내용으로 삼을 만한 것은 충분했지만 문제는 제가 무언가를 발표한다는 것에 썩 익숙한 사람은 아니었습니다. 그래서인지 PPT를 만들고, 스크립트를 만들고, 다듬고, 다듬고, 다듬고, 다듬고....를 계속 반복했던 기억이 납니다. 그래도 어떻게든 미니 세미나를 잘 진행했습니다.

동료분이 영상을 찍어주시긴 했지만 막 공유할 정도는 되지 못합니다. 대신 세미나 내용은 제 블로그 게시물인 직접 구현한 스텁으로 이상적인 테스트 작성하기에 모두 정리되어 있습니다.

미니 세미나를 끝내고 캠프의 코치이신 코드스쿼드의 호눅스님께서 피드백을 남겨주시기도 했습니다. '한국 사람들이 분류하는 것을 참 좋아한다. 하지만 너무 엄격하게 용도에 따라 구분할 필요는 없다. 필요에 따라 알맞게 사용하면 된다.'(정확한 내용은 기억하지 못하지만 뉘앙스는 비슷할 겁니다.) 실제로 세미나 내용 중에는 테스트 더블을 엄격한 분류에 따라 적용하려다 보니 프로젝트의 코드가 복잡해졌다는 이야기도 포함되어 있었습니다. 또한, 해당 피드백은 테스트 더블에 대한 것 뿐만 아니라 앞으로 제가 배울 것들에도 적용될 수 있는 내용이기도 했습니다.

미니 세미나를 준비하고, 참여하고, 질문과 피드백을 받은 것은 가치있는 경험이었습니다. 또한, 동료 개발자와 지식과 경험을 공유한다는 예행 연습이기도 했습니다. 이런 자리가 한 번은 있었으면 좋겠다고 생각했기 때문에 코치님께서 미니 세미나 이야기를 꺼내자마자 제 이름부터 적어넣었는데 정말 잘한 선택이었다고 생각합니다.

미니 특강

우아한테크캠프를 진행하며 매주 목요일은 미니 특강을 진행했습니다. 개발과 관련된 하드 스킬보다는 소통 쪽의 소프트 스킬이 주된 내용이었습니다. 직장인의 인간 관계, 테크니컬 라이킹, 우아한현제들 선배 개발자 분들과 함께 하는 네트워킹 데이 등 도움되는 시간이었습니다. 또한, 원래 일정에는 포함되어 있지 않았지만 호눅스님께서 신경써주신 덕분에 오브젝트의 저자이신 조용호님의 객체 지향 특강도 들을 수 있었습니다.

프로젝트

최종 프로젝트는 3주 + a의 기간동안 진행했습니다. 주제는 자유 주제였지만 굉장히 짧은 시간동안 진행하는 만큼 아이디어를 생각할 시간도, 구현을 진행할 시간도 충분하지 않았습니다. 가장 신박했던 아이디어는 캠프 교육생 27명의 합작품 배달의 민족 MSA 구현이 있었지만 시간상의 문제로 재미있는 아이디어 정도로만 남았습니다.

저희 팀 내부에서도 자체적인 서비스 운영을 위한 몇 가지 아이디어가 나왔지만 팀원 모두가 만족하지는 못했습니다. 그렇게 최종적으로 선택한 프로젝트 주제는 티켓팅 서비스였습니다. 단, 저어엉말 최소한의 프로토타입까지만 만든 뒤 동시성 문제가 발생할 수 있는 티켓팅, 티켓팅 서버의 부하를 조절할 대기열 시스템을 핵심 도전과제로 삼기로 결정했습니다.

4명으로 구성된 팀에서 저의 역할은 다른 한 명의 동료와 함께 대기열 시스템을 설계하고 Redis를 활용한 대기열 구현이었습니다. 이후 함께 설계를 진행한 동료의 Java 자료 구조를 이용해 대기열 구현과 성능을 비교, 고부하 상황에서의 성능 검증까지 진행하는 것이 목표였습니다.

짧게 세 줄로 요약하자면 다음과 같은 과정을 거쳤습니다.

1. 실세계의 은행 창구 시스템으로부터 영감을 받아 동료와 함께 대기열 구성요소를 추상화 및 협력 구조 설계
2. Redis를 활용한 대기열 구현 및 Java 자료 구조를 활용한 대기열과 부하 테스트를 통한 성능 비교
3. 부하 테스트 결과에서 응답 시간 스파이크를 발견하여 원인 분석 및 개선 진행
   

최종적으로 테스트 시간 15분, 가상 사용자 2500명, 대기열 API(남은 순서 조회)를 1초 주기로 폴링 시 95%의 요청을 400ms 안에 처리할 수 있음을 검증하였습니다.

세줄로 요약할 수 있긴 하지만 각각을 하나의 게시글로 만들 수 있을 정도의 고민이 있었습니다. 동료와 설계 상의 의견 차이를 조율하기도 하고, 부하 테스트를 위해 쏟아부은 시간도 생각외로 길어지기도 했습니다.

그러한 내용들은 제 블로그 [우아한 티켓팅]이라는 이름을 가진 시리즈로 정리하였습니다.

[우아한 티켓팅] 친절한 대기열 시스템 설계하기
[우아한 티켓팅] 대기열 시스템 10,000명 부하 테스트하기
[우아한 티켓팅] 대기열 시스템 응답 시간 스파이크 해결하기

이러저러한 과정을 거쳐 꽤나 만족스러운 결과물과 경험을 할 수 있었지만 아쉬운점도 있었습니다. 저는 대기열 응답 시간 스파이크를 해결하는 과정에서 Grafana 모니터링을 통해 Garbage Collection이 원일일 것이라고 추정하였고 불필요한 객체 생성 로직을 개선하였습니다. 실제로 응답 시간 스파이크 빈도가 줄어들고 성능 역시 상승한 것을 검증하였으나 정확히 어떤 부분이 개선되었는지는 제대로 파악하지 못했습니다.

당시 GC log를 남기기는 했으나 워낙 파일 길이가 길어 어떻게 파악해야 하는지 감도 잡지 못했습니다. 변명을 하자면 마지막 개선에 대한 검증이 최종 데모 하루 전에 이루어져 GC log까지 확인할 시간이 부족하기도 했습니다. 최근에 들어서야 GC log 시각화 방법을 알게 되었고 G1GC 과정 중 Concurrent Marking에 소요된 시간이 4분 30초에서 2분 40초로 개선되었음을 확인했습니다. 다만, G1GC 과정에서 Concurrent Marking이 가지는 의미를 좀 더 명확히 파악하는 등 원인을 명확하게 파악하기 위한 추가 학습이 필요합니다.

이 외에도 예매 좌석 선택 동시성 문제에서 락 방식 간에 성능 차가 크게 발생하지 않았다는 점, 팀원 한 명이 실시간 좌석 갱신을 빠르게 구현했지만 성능이 떨어지는 문제가 있었던 점 등 몇 가지 아쉬운점이 있기도 했습니다. 이런 부분들에 대해서는 가끔 동료들과 원인과 개선점에 대해 이야기하기도 했습니다.

좋았던 점도 있었고, 아쉬운 점도 있었지만 프로젝트는 마무리 되었고 우아한형제들 채용이 시작되었습니다.

우아한형제들 최종 면접 결과를 받아보기까지

앞서 언급한대로 비밀유지서약을 했기 때문에 우아한형제들의 채용 과정, 면접 내용에 대해 알려드릴 수 있는 내용은 없습니다. 마음 졸이는 시간이 이어졌고 여차저차해서 최종 면접까지 진행하였지만 아쉽게도 우아한형제들 개발자의 자리는 다른 동료분이 차지하였습니다.

최종면접을 보면서 후회없이 제 모든 것을 보여주자고 다짐했지만 부족한 부분들이 있었습니다. 면접 결과를 기대하지 않을 것이라 몇번이나 다짐했지만 기대가 되는 것을 막을 수는 없었습니다. 결과를 받아보고 마음을 추스르는 것이 꽤나 어려운 일이었습니다.

우아한형제들 채용 외에 DH 채용도 있었습니다. 저 역시 resume, conver letter, 영문 포트폴리오까지 작성해서 지원했습니다만 저의 회화 능력이 경험과 배경을 설명하기에 충분치 못하다고 판단하여 끝까지 진행하지는 않았습니다. 지원한 동료 중 몇 분은 최종면접까지 보시고 결과를 기다리는 중으로 알고 있습니다. 만일 우아한테크캠프, 우아한테크코스에 참여하실 계획이 있으신 분들은 반드시 영어 회화 능력을 기를 것을 추천드립니다.

끝으로

다시 한 번 달려보자고 마음을 추스르던 차에 면접을 봤던 회사 중 한 곳에서 입사 제의가 왔습니다. 과거에 한 번 면접에서 탈락한 적 있던 회사였으나 면접 경험이 좋았기에 다시 도전한 곳이었습니다. 개인적으로 가고 싶었던 회사였던 덕분에 어지러웠던 마음을 다잡을 수 있었습니다.

짧은 기간이었지만 많은 것을 배웠습니다. 과제를 수행하면서도 어떤 동료는 돌아다니면서 자유롭게 잡담을 했습니다. 지금 뭘 하고 있는지, 이건 어떤 식으로 해결했는지, 안 피곤하냐고 묻기도 했습니다. 어떤 동료는 호기심이 뛰어났습니다. 코치님의 수업시간에 자료 조사를 할 때면 이건 왜 이렇게 작동하는지, 내부는 어떻게 되어있을지 계속해서 파고드는 모습이 인상 깊었습니다. 그런 모습들을 보고 배울 수 있다는 것은 귀중한 기회였습니다.