# 민감 내용은 피하고자 하였지만, 우테코 프리코스에 대한 내용이 일부 포함되어 있습니다.
# 문제시 일부 내용이 수정될 수 있습니다.
우아한테크코스 프리코스 (우테코)를 4주 동한 경험하였습니다.
우선 저는 1년의 경험이 있는 주니어 개발자입니다.
따라서 이번 우테코의 선발 대상에서는 제외됩니다.
아쉽게도 개인 사정으로 인해 3주차 미션을 미제출함에 따라 4주차 미션은 경험해 보지 못했습니다.
예전부터 경험해 보고 싶었던 우테코 프리코스를 3주 동안 경험하고, 그 과정에서 느낀 것을 정리하고자 합니다.
목차
0. 지원 이유 및 과정
1. 프리코스 1주차 - 온보딩
2. 프리코스 2주차 - 숫자 야구
3. 프리코스 3주차 - 로또 (미제출)
4. 소감
0. 지원 이유 및 과정
저는 현재 SI/SM 프로젝트에 참여하는 개발자입니다. 운이 좋게 괜찮은 회사에서 개발자로 커리어를 시작하였지만, 개발자로서 프로젝트에 참여하며 접할 수 있는 기회가 크게 제한된다고 느꼈습니다.
물론 현재 회사에서 배우고 얻은 것이 훨씬 큽니다. 단순히 알고리즘 푸는 코드만 짜고, 트래픽 없는 간단한 백엔드 개발만 해 본 저는, 약 1년간의 실무 경험을 통해 (제 입으로 직접 말하기는 그렇지만) 큰 폭으로 성장했음을 체감합니다. 백엔드 개발자로써 디자인 패턴, 객체지향, 데이터베이스, 네트워크 등 여러 분야에 대한 지식의 깊이가 늘었음은 물론, 실무에서 가장 중요한 커뮤니케이션 스킬이 많이 성장하였습니다. 이에 대한 저만의 철학이 생긴 것은 덤입니다.
하지만 개발자라면 주어진 환경에 만족하지 않죠? 더 큰 성장과 경험을 위해, 바라는 것이 많을 수밖에 없습니다.
코드 리뷰, 페어 프로그래밍, 클린 코드, 리팩토링, 테스트 코드. 제가 자발적으로 일부 진행한 부분도 있지만, 주로 현재 프로젝트와는 거리가 먼 키워드들입니다.
그러다 보니 언제부터인가 더 나은 환경에 대한 궁금증이 자라게 되었고, 그쯤에 우아한테크코스를 알게 되었습니다.
1년 동안 경제적 지원도 없이 교육을 받는다니, 취준생에게 메리트가 있을까?
1년 전에 취준생이던 시절의 제가 했던 생각입니다. 당시에는 이어지는 취준생활에 생기는 경제적인 부담이 있었고, 따라서 우테코보다 SSAFY나 SW Maestro 같은 과정이 조금 더 매력적이지 않나 싶었습니다.
하지만 실무를 겪으며, 또 우테코가 어떤 과정인지 조금 더 관심을 가지고 들여다 보니, '이건 내가 바라던 교육과정이다!' 라는 생각이 절로 들었습니다. 일방적인 교육이 아니라, 코드와 기술에 대해 서로 토론하고 피드백을 주고 받을 수 있는 과정이라고 생각했습니다.
그래서 사실, 이번에 우테코를 지원해서 선발된다면 현재 회사를 퇴사할 각오까지 했습니다 (4기 시절엔 경력자도 선발되는 것을 막지 않았습니다).
하지만 올해 우테코는 경력자는 아예 선발 대상에서 제외되죠.
그럼에도 제가 지원한 이유는 명확합니다.
우아한형제들에서 진행하는 교육과정 내에서, 단순히 코드를 작성하는 것 외에 다양한 고민을 해 보고 싶었습니다.
프리코스는 이를 경험하기에 매우 적합한 환경이라고 생각했습니다. GitHub을 통해 참여하고, 코드를 작성할 때도 어떻게 하면 더 클린 코드에 가깝게 작성할 수 있을지 생각하고, 그렇게 고민하면서 생각의 폭을 넓힐 수 있겠다고 생각하였습니다.
다행히 위의 FAQ 내용을 보면, '우아한테크코스 프리코스를 경험하고 싶다면 서류 지원을 하고 프리코스 참여가 가능합니다.'라는 내용이 있습니다. 이것은 바꿔 생각하면, 원한다면 얼마든지 지원해서 프리코스에서 배워가는 것이 있으면 좋겠다는 뜻으로 느껴졌습니다.
그런 이유에서, 자소서의 각 문항에 대해 성심성의껏 작성하여 지원하였습니다. 어차피 저는 선발 대상이 아니며, 그렇다는 것을 자소서에 그대로 적었습니다.
컴퓨터공학 전공 출신이지만 본격적으로 웹 백엔드 개발자로서 노력을 한 기간은 길지 않은 저에게, 하나하나 와닿는 질문들이었습니다. 누군가 제 프리코스 참여 내용과 자소서를 본다면, '이래서 지원했구나' 하고 절로 고개가 끄덕여질 지원자가 되고 싶었고, 그래서 비록 선발 대상이 아닐지라도 매 과정 중 최선을 다 하고 싶었습니다.
지원을 하면 아래와 같은 이메일이 옵니다.
이윽고 모집 기간이 종료되었고, 프리코스에 대한 안내와 함께 프리코스 slack에 초대되었습니다.
이쯤이 한창 배포 때문에 정신없을 때였지만, 새로운 경험을 할 수 있다는 기대감에 늘 두근거렸습니다.
1. 프리코스 1주차 - 온보딩
프리코스 1주차는 2022년 10월 26일에 시작되었습니다.
1주차는 적힌 내용 그대로, 과제 자체가 어렵다기보다는 이후 과정을 위한 환경 설정 및 체험을 위한 미션이었습니다.
GitHub을 통해 소스를 clone 하고, branch를 나누어 작업 내용을 commit 하고, PR을 올립니다.
Java를 통해 주어진 미션을 수행하고, 테스트 코드를 통해 채점해 보며 Java, Junit5에 대한 시야를 넓힙니다.
이것이 모두 추후 프로젝트를 위해 필요한 내용입니다. 동시에 초보자라면 충분히 헤맬 수 있는 내용으로, 약 1주 동안 이를 극복해 가야 하는 숙제라고 생각합니다.
동시에 저도 코드를 작성하며 조금 고민을 했습니다.
'이 코드가 남들이 보기에 합당해 보일까?' '내가 작성한 코드를 한 줄 한 줄 모두 누구에게라도 설명할 수 있을까?'
이런 생각을 하며 코드를 작성하였습니다. 실무에서 기능 구현을 위해 작성하던 때와는 접근하는 방향부터 달랐다고 생각합니다.
'클린 코드' 에 대한 책이나 글을 읽어본 적은 없지만, 여기저기서 본 내용과 더불어 저만의 철학이 있습니다. 작성하는 코드에는 이를 최대한 녹여 내려고 했습니다.
- indent는 2단계 이상 들어가지 않기
- else문 사용하지 않기
- 변수명은 축약하지 않기
- 기능은 최대한 별도의 메소드로 분리하기
- Controller가 단순히 요청을 받고 Service를 호출하며, Service는 Stateless하게 주어진 기능을 수행하듯, 여러 메소드도 각자 이런 역할을 하도록 구분하고자 하였습니다.
- 메소드명은 최대한 직관적으로 작성하기
더불어, 가장 기억에 남는 부분은 '코드로 옮기기 전에 먼저 구현하려는 기능을 문서화하여 정리하는 과정'이었습니다. 평소에도 저는 개발할 때 주석과 문서화를 굉장히 선호합니다. 실무에서도 개발한 내용에 대한 문서화를 진행 과정 중 꼼꼼히 진행하였고, 이에 대해 동료들 및 리더들로부터 칭찬을 받기도 하였습니다. 하지만 이런 문서화 과정이 개발 전에 이루어진 것은 아니고, 대강 어떻게 작성할지 흐름을 종이에 그려본 후, 코드로 이를 옮기고, 옮긴 내용을 구체적으로 문서화 하였습니다.
반면 1주차 프리코스에서는 순서가 약간 바뀌었습니다. 어떻게 작성할지 흐름을 종이에 그리고, 이 내용을 구체적으로 문서화한 후, 마지막 순서로 이를 코드로 옮겼습니다. 물론 코드로 옮기는 중에 구상했던 설계 내용이 바뀌는 경우도 자주 있었지만, 구체적인 내용을 문서화한 후에 개발을 진행하는 것은 개발 목표를 더욱 구체화도록 도와 준다는 느낌을 받았습니다. 그만큼 IDE 앞에서 멍때리는 시간이 줄기도 했고, 코드가 난잡해지거나 산으로 가는 것을 막아 주었다고 생각합니다.
우여곡절 끝에 7개의 문제를 모두 성공적으로 해결한 후, 테스트 코드까지 정상적으로 통과하는 것을 확인하였습니다. 이 테스트 코드가 모든 경우의 수를 확인해 주는 것은 아니지만, 테스트를 전부 통과했다고 생각하니 작성한 코드에 대한 자신감이 생겼습니다.
성공적으로 제출하였고, 테스트 결과도 모두 통과하였습니다. 이렇게 1주차 프리코스가 완료되었습니다.
2. 프리코스 2주차 - 숫자 야구
1주차 프리코스를 성공적으로 제출하고, 11월 2일 수요일에 2주차 미션이 도착하였습니다.
안내 메일에는 1주차에 대한 내용과 전체 피드백, 그리고 2주차 미션에 대한 내용이 담겨 있었습니다.
재미있는 점은 1주차 미션을 정상 제출한 사람에 한해 2주차 미션 메일이 도착한다는 점이었습니다. 앞의 과정을 성공적으로 완수하지 못하면 다음 과정으로 나아갈 수 없다니, 엄격하지만 그만큼 높은 기준으로 교육생들을 대한다는 느낌이 들었습니다.
공통 피드백은 제가 평소에 늘 염두에 두는 내용부터, 미처 생각하지 못한 내용까지 다양했습니다. 그 중에서도 특히 기억에 남는 점을 꼽아 보자면,
- 축약하지 않는다 - 의도를 드러낼 수 있다면 이름이 길어져도 괜찮다.
- 공백도 코딩 컨벤션이다.
- Java에서 제공하는 API를 적극 활용한다 - 메소드를 직접 구현하기 전에, Java에서 제공하는 기능인지 먼저 검색해 본다.
이렇게 세 가지가 되겠습니다.
개발을 하다 보면 별의 별 이상하게 축약된 변수명을 보게 됩니다. 기억에 남는 변수명은 bzcn이었는데, business condition의 축약어였습니다. 이게 무슨 소리지? 한참을 고민하다가, 사업자등록증의 '업태'를 영문으로 옮긴 후 축약한 것임을 깨닫고 경악했던 기억이 납니다.
물론 네 글 자로 줄였으니 보기에는 깔끔해 보일 수 있어도, 변수명을 보고 그 의도를 파악할 수 없으니 코드의 가독성이 굉장히 떨어졌습니다. 만약 businessCondition이라고 썼다면, 내용은 조금 길지라도 변수명만으로 그 의도를 파악할 수 있었겠지요?
또, Java에서 제공하는 API를 적극 활용하라는 점도 유독 와닿았습니다. 저는 보통 제가 이미 알고 있는 C++과 Java의 기본 기능들은 적극 활용하지만, 제가 잘 모르는 내용은 우선 직접 구현하고 봤습니다. 이런 습관이 단순히 알고리즘 문제를 풀 때는 조금의 시간 손해로 이어졌을 뿐이지만, 다 같이 개발하는 환경에서 이렇게 한다면? 불필요한 코드가 점차 쌓이게 될 것임을 알게 되었습니다.
2주차 개발에 앞서, 1주차 때와 마찬가지로 기능 정의를 작성했습니다. 이번에는 README.md에 작성하라는 명확한 지시 사항이 있었기 떄문에, 이를 따라 메소드별로 작성하였습니다.
각 커밋 메세지는 이 글에서 안내한 내용을 따라 영문으로 작성하였습니다. 이전에 경험해 본 적 없는 커밋 메세지 스타일이라 처음에 무척 적응하기 어려웠습니다.
글을 따라 제가 작성한 커밋은 아래와 같이 나눌 수 있습니다.
- docs: 기능에 대한 설계 내용의 문서화를 추가했습니다. 이번 문제의 경우, 문서화 내용을 docs/README.md 파일에 작성했습니다.
- feat: 기능을 메소드 단위로 커밋했습니다. docs 상에서 기능별로 나누어 설계한 내용을 각각 메소드로 구현하였습니다.
- fix: 작성한 기능을 수정할 대 사용했습니다. 먼저 설계 내용을 바꾸고, 그 내용에 따라 실제 기능을 수정하였습니다.
- test: feat에서 작성한 기능을 테스트 하는 테스트 코드를 추가하였습니다.
2주차에서 1주차와 다르게 경험했던 것은 커밋 메세지 작성 컨벤션과 테스트 코드 작성인데요. 그 외에는, 기능을 쪼개어 각각 커밋한 것이나 문서화는 1주차에서 이미 진행했기 때문에 쉽게 적응할 수 있었습니다.
테스트 코드의 경우, 제가 알고 있는 범위 내에서, 각 메소드를 요구 조건에 맞도록 테스트 하고자 했습니다.
어렴풋이 알고 있는 테스트 코드지만, 제가 작성한 내용을 하나하나 검증하는 과정이 정말 너무 즐거웠습니다. 어쩌면 회사에서 테스트 코드를 작성할 때보다도 즐거웠던 것 같네요 ㅎㅎ
업무 중에는 아무래도 훨씬 복잡한 로직을 테스트 하다 보니, 제가 가진 테스트 코드에 대한 지식만으로는 원하는 대로 테스트하기에 조금 어려움이 있었습니다. 숫자 야구는 그보다는 훨씬 간단하니, 테스트하기에도 쉬웠지 않았나 싶네요.
결과적으로 신이 나서 테스트 코드를 쭉쭉 작성했습니다. ApplicationTest 밑에서, 게임종료_후_재시작() 과 예외_테스트()를 제외한 나머지는 전부 제가 작성한 테스트입니다 ㅎㅎ
회사 업무가 바쁘다 보니, 설계를 제외한 기능 구현, 테스트 코드 작성 등은 마지막 날 (11월 8일 화요일)에 전부 작성하여 제출하게 되었습니다. 설계 덕분에, 다행히 실제 구현과 테스트는 오래 걸리지 않았습니다.
성공적으로 제출하면서 2주차를 마무리 하게 되었습니다 ㅎㅎ
3. 프리코스 3주차 - 로또
2주차 미션을 성공적으로 제출하여, 3주차 미션도 전달받게 되었습니다.
공통 피드백을 읽으며 생각해 볼 여지가 몇 가지 있었습니다.
- 기능 목록을 재검토한다
- 구현 순서도 코딩 컨벤션이다
- 함수가 한 가지 기능을 하는지 확인하는 기준을 세운다
저는 보통 무언가 개발을 할 때, 먼저 상세히 설계해 두고, 그것을 바탕으로 코드로 옮기는 것을 좋아합니다. 물론 좋은 방법이지만, 개발을 진행하다 보면 요구 조건 또는 설계가 바뀌는 것은 매우 흔한 일입니다.
2주차 미션을 진행하면서, 저도 중간중간 설계 내용을 수정하게 되었습니다. 미션 요구 조건에 '먼저 설계 내용을 작성하고, 그 다음에 기능 개발을 진행할 것' 이 있었기 때문에, 설계가 자꾸 틀어지는 것에 대한 불안함이 있었습니다. 다행히도 이는 과제에서 의도한 내용이었나 봅니다.
구현 순서도 코딩 컨벤션이라는 내용은, 제가 한 번도 생각해 보지 못한 내용입니다. 보통 흔히 통용되는 순서는 상수, 멤버 변수, 생성자, 메서드 순으로 작성합니다. 이 메서드에도 순서를 정할 수 있을까요? 또는, 이러한 순서를 바꾼다면, 어떤 근거를 기준으로 바꾸게 될까요? 코드를 작성하면서 한 번쯤 생각해 볼 만한 주제인 것 같습니다. 물론 이는 개발을 진행하는 팀 (1인 팀 포함)마다 정하기 나름이고, 팀 내에서 소통의 효율성을 위해서라면 얼마든지 다르게 가져가도 좋다고 생각합니다.
저는 주로 하나의 함수(메소드)는 하나의 기능만을 담당해야 한다고 생각합니다. 특정 요청에 응답하는 메소드는 응답만에 집중해야 하고, 특정 데이터를 저장하는 메소드는 받은 데이터를 저장하는 식으로 말이죠. 설계할 때도 이런 형태를 따르도록 설계하고, 이를 코드로 옮깁니다. 하지만, 확인하는 명확한 기준을 세운다는 점 역시 생각해 본 적 없는 내용이라 유독 와닿았습니다. 제가 작성한 코드는, 누군가 "이 코드가 하나의 기능만을 담당해?" 라고 물어본다면, "그렇다"고 말할 수는 있지만 그에 대한 명확한 기준이 없었거든요. '중복 코드 분리', '메소드 당 줄의 수 제한' 등의 기준을 세운다면 보다 단일 책임 원칙에 부합하는 메소드를 작성할 수 있을 것 같습니다.
이어서 3주차 미션에 대한 얘기입니다. 전반적인 요구 조건도 2주차 때에 비해서 늘어났고, 제약 조건도 추가되었습니다.
클래스 분리, Enum 사용, 도메인 로직에 대한 단위 테스트 작성 등은 기존에 재가 생각해 보지 못한 영역이었습니다. 정확히는, 고민해 본 적은 있으나, 업무 또는 개인 프로젝트에서 개발할 때 실제로 고민해 본 적이 없는 영역이었습니다.
바로 이런 점을 경험하고자 우테코 프리코스에 지원했기 때문에, 이런 과제를 받게 되어 매우 기뻤습니다.
public enum Prize {
FIRST(6, 2000000000),
SECOND(5, 30000000),
THIRD(5, 1500000),
FOURTH(4, 50000),
FIFTH(3, 5000),
NONE(0, 0);
private int hitCount;
private int reward;
Prize(int hitCount, int reward) {
this.hitCount = hitCount;
this.reward = reward;
}
public static Prize getPrize(int hitCount, boolean bonusHit) {
if (hitCount == 5 && !bonusHit) {
return THIRD;
}
if (hitCount < FIFTH.hitCount) {
return NONE;
}
return Arrays.stream(values()).filter(rating -> rating.hitCount == hitCount).findAny()
.orElseThrow(NoSuchElementException::new);
}
}
실제로 제가 로또 당첨 내용을 위해 작성한 Enum입니다. Enum에 대해 어렴풋이 알고는 있었지만, 이를 개발에 적용하기 위해 제대로 고민하고, 구현해 본 적은 이번이 처음인데요. 이렇게 Enum을 잘 작성하면, 그 자체로도 정의서의 역할을 할 수도 있고, 또 Enum 내의 값 외에 다른 값을 넣을 수 없기 때문에 예상치 못한 값이 반영되는 일도 막을 수 있을 것으로 보입니다.
4. 소감
아쉽게도 3주차 미션을 완성하지는 못했습니다. 어떠한 이유에서든 미션 미제출에 대한 변명을 하고 싶지는 않지만, 회사 업무와 개인 사정 등이 겹치며 과제에 집중할 시간이 부족하다 보니 미제출로 남게 되었습니다.
회사 업무에서 고민해 본 적 있는 내용을 보다 명확히 나타내거나, 고민해 본 적 없는 내용을 프리코스를 통해 경험할 수 있어 기뻤습니다. 만약 제가 프리코스에 참여하지 않았다면, 제가 작성한 코드만 보면서 자화자찬하고 있었겠지요. 클린 코드란 무엇인지, 어떻게 하면 더 좋은 설계로 개발을 진행할 수 있을지, 테스트는 어떻게 하면 좋을지 등을 고민하고 시도해 볼 수 있어 너무 즐거운 3주간의 시간이었습니다. 앞으로 제게 주어질 여러 도전의 기회에서, 프리코스를 통해 배운 점들이 도움이 될 것이라 믿습니다.
만약 이 글을 읽고 계신 분이 우테코 지원을 고민 중이신 취준생 또는 업무 외적으로 성장을 이루고 싶은 현직자라면, 우테코에 꼭 지원해 보시길 추천드립니다. 단순히 프리코스만으로도 배워갈 수 있는 내용들이 있고, 우아한테크코스 자체도 현재로써 가장 치열한 양질의 "성장의 기회"를 제공한다고 생각합니다.
댓글