어쩌다 지원했나요?
프로젝트 경험은 많지만, 기초가 부실한 개발자 == 나
자바 개발자로 취업하고 싶은데 자바를 잘 다루지 못한다는게 늘 마음에 걸렸다. 자바 연습하는데엔 우테코 프리코스만한게 없다는 이야기를 종종 들었는데, 그 와중에 지인들 중 지원하는 사람이 많았기에 그렇게 지원하게 됐다.
시작은 가벼운 마음이 컸다.
인생 경험 자소서에 녹이기
지원 동기
분명 자바 공부나 해보자는 가벼운 마음이었지만, 지원서만큼은 공들여 썼다. 마침 기업 자소서를 쓰고 있던 시기였고, 어차피 써야 할 이야기들이라 항목을 뽑아내는 일도 어렵지 않았다.
다만, 우테코는 기업이나 동아리 자소서에 비해 문항 수는 적은데 글자 수 제한은 넉넉했다. 그래서 한 문항 안에서 ‘서사 있는 사람’처럼 보이기 위해 최대한 나를 잘 포장하려고 애썼던 것 같다.
사실 나는 사학과에서 시작해 복수전공과 전과를 거쳐 어렵게 전공자가 된 케이스다. 20대 초반 내 진로는 말 그대로 풍파를 많이 맞았기에, "왜 역사 공부하던 놈이 개발을 하게 됐냐?"는 질문에 설득력 있게 답하는 것이 중요하다고 생각했다.
대학교만 6년을 다닌 사람으로서, 이에 대해 할 말은 꽤 많았다.
그래서 지원 동기와 어떤 프로그래머가 되고 싶은지는 결국 내 인생 서사를 쭉 늘어놓는 방식으로 풀어냈다.
오랜 시간 몰입했던 경험
오랜 시간 몰입했던 경험은 생각나는게 여러개 있었는데, 그중에서 가장 오래 해온 일기쓰기를 썼다.
일기 쓰는게 무슨 몰입이냐 싶겠지만, 일기는 나를 P형 인간에서 J형 인간으로 바꿔준 고마운 친구다. 일기를 쓰기 시작하면서 15kg 다이어트도 성공하고 몇 번의 수석도 해보는 긍정적인 경험을 했는데, 그런 과정이 어떻게 이뤄졌는지를 썼다.
문장력이 뛰어나진 않아 글이 다소 밋밋했을지 몰라도, 단순한 습관 이야기로 끝내지 않기 위해 일기 쓰기와 회고를 메타인지와 연결지으려 노력했다. 우테코 설명회에서 메타인지를 중요하게 언급했던 게 기억에 남았기 때문이다.
증빙 자료에는 내가 실제로 썼던 일기 내용 중 일부를 발췌해 사진과 함께 주석을 달아 첨부했다. 단순한 ‘경험담’이 아니라, 꾸준함이 어떤 성장을 이끌 수 있는지 보여주고 싶었다.
프리코스 목표
프리코스를 시작하면서 이루고 싶은 목표는 여러 가지였지만, 그중 가장 큰 목표는 자바 실력 향상이었다. 다만 이를 단순히 "자바 공부를 열심히 하겠다"고 적기보다는, 실제로 지인들과 함께 스터디를 계획하고 있었기 때문에, 지원 동기와 자연스럽게 연결되도록 ‘협동’이라는 키워드에 초점을 맞췄다.
스터디에서는 클린코드와 코드리뷰를 중심 주제로 삼고, 서로의 코드를 리뷰하고 개선점을 나누는 방식으로 운영할 계획이었다. 혼자 성장하는 것보다 함께 성장하는 환경을 만들고 싶었다. 그 흐름 속에서 클린코드와 코드리뷰에 능동적으로 참여하는 사람이 되고자 했다.
프리코스 마지막 문항은 이 스터디 계획서를 바탕으로 작성했다. 이미 구조를 잡아 두었기에, 빠르게 풀어낼 수 있었다.
동기부여가 된 프리코스
프리코스는 디스코드와 우테코 지원페이지를 통해 진행됐다.
일단 지원하기만 하면 모두에게 프리코스에 참여할 기회를 준다니, 우테코에 가장 큰 호감을 느낀 부분이었다.
애플리케이션을 예쁘게 만들 자신은 없지만, 주어진 기능을 잘 돌아가게 만들 자신은 있었기 때문에 프리코스는 과제 중심으로 적극적으로 참여하고자 했다.
어벤저스터디
우테코에 지원한 학교 내 지인들과 함께 작은 규모의 스터디를 계획했다.
그러다가 스터디원 중 한명이 외부 인원도 받으면 코드리뷰가 더 다양해질 것 같다는 의견을 주었고, 스터디원을 추가로 모집하게 됐다.
초기 스터디원은 나를 포함하여 3명이었지만, 2주차가 시작할때 쯤 스터디원은 총 7명이 됐다.
인원이 많아지다보니 다양한 사람들을 볼 수 있었는데, 신기하게도 스터디원들 모두가 개발을 잘 했다. 나 혼자만 감자고 다른 사람들은 전부다 은둔고수처럼 느껴졌다.
스터디 방식은 노션을 통한 데일리 회고 공유, 주 1회 대면 코드 리뷰로 진행됐다.
데일리회고는 말 그대로 매일 하루를 회고하는거였다.
회고 구성은 매일 잘한 점, 아쉬운 점, 개선할 점 세가지의 항목을 하나 이상 작성하면서 하루를 피드백하는 방식이었다.
노션으로 진행했기 때문에 가끔 내 회고를 보고 다른 분들이 궁금한 점이나 의견을 댓글로 남겨주시기도 했다. 이런 댓글을 통한 토론을 통해 한번 더 생각해볼 수 있었던게 회고에서 가장 좋았던 것 같다.
주 1회 대면 코드 리뷰는 점차 개선되었다.
처음에는 리뷰 방식이 정립되지 않아, 각자 자신의 코드를 단순히 설명하는 식으로 진행됐다. 그러다 보니 눈에 띄는 부분에만 피드백이 집중되었고, 결국 발표처럼 흘러가면서 "제대로 리뷰가 되고 있는 걸까?" 하는 의문이 들었다.
서로의 코드를 전부 이해하기도 어렵다 보니, “이런 방식도 있네요, 신기하네요~” 같은 피상적인 반응밖에 주고받지 못했다.
그래서 2주차부터는 형식을 바꾸기로 했다. 대면 스터디 전에 미리 PR을 통해 서로의 코드를 리뷰하고, 스터디 시간에는 코드에 달린 코멘트를 중심으로 토론하는 방식으로 전환했다.
이 변화는 꽤 효과적이었다. 각자의 코드를 사전에 살펴보며 충분히 고민할 수 있었고, 토론의 밀도도 훨씬 높아졌다. 스터디원들 모두 디테일에 강하고, 구현에 앞서 깊이 고민하는 사람들이었다. 그래서 스터디는 한 번 시작하면 짧게는 2시간, 길게는 4시간까지 이어지기도 했다. 그만큼 배울 점이 많았다.
가장 기억에 남는 토론은 ‘왜 일급 컬렉션을 사용해야 하는가?’에 대한 주제였다. 대부분 일급 컬렉션을 사용하는 것이 좋다고 보았지만, 각자가 생각하는 이유가 달랐다. 서로의 이유를 설명하고, 그에 맞는 구현 방식을 비교해보는 과정이 특히 흥미로웠다.
사실 나는 일급 컬렉션을 꼭 공부하겠다고 데일리 회고에 적어두고 계속 미루고 있었는데, 이 토론 이후 다음 날 급하게 공부했다. 😅
1주차
첫번째 미션은 덧셈만 가능한 계산기를 만드는 미션이었다. 커스텀 구분자를 추가할 수 있다는 특이사항이 있었는데, 파싱은 C언어로 자주 해봤기 때문에 C언어로 개발했던 스타일 그대로 코드를 작성했다.
사실 객체지향에 대해서 고민을 많이 안 했기 때문에 처음에는 하나의 클래스 안에 코드를 쭉 써내려갔다.
그러다 제출하기 직전에 좀 아닌가...? 싶어져서 클래스를 분리하기 시작했다.
그러나 생각없이 써내려간 코드는 뒤늦게 쪼갠다고 책임에 맞게 분리해내기 어려웠고, 클린코드는 아예 고려하지도 못한채로 이렇게 되어버린 메서드를 제출하게 된다.
public List<Integer> parse(String removedString, List<String> separator) {
List<Integer> operand = new ArrayList<>();
String tmpOperand = "";
for (int i = 0; i < removedString.length(); i++) {
int separatorLength = isSeparator(removedString.substring(i), separator);
if (separatorLength != -1) {
if (!tmpOperand.equals("")) {
operand.add(Integer.parseInt(tmpOperand));
tmpOperand = "";
}
i += separatorLength - 1;
} else if (Character.isDigit(removedString.charAt(i))) {
tmpOperand += removedString.charAt(i);
} else {
throw new IllegalArgumentException("등록되지 않은 구분자가 포함되어 있습니다.");
}
}
if (!tmpOperand.equals("")) {
operand.add(Integer.parseInt(tmpOperand));
}
return operand;
}제출할 때까지만 해도 나름 클래스도 분리했으니 이정도면 잘 짠 코드라고 생각했다. (진심으로)
그러나 매주 진행되는 과제 피드백과 코드 리뷰를 통해 1주차 코드가 아주 잘못됐음을 깨달았다.
https://github.com/woowacourse-precourse/java-calculator-7/pull/477
MVC에 대해 더 고민해보고 코드를 짜면 좋을 것 같다는 피드백을 많이 받았다.
이 리뷰에는 model에 부여한 책임이 작다는 피드백이 달렸는데, 사실 MVC 각각의 책임이 뭔지도 잘 몰랐다. 그냥 스프링부트에서 흔히 쓰던 개발 방식을 적용했을 뿐이었다.
‘역할’과 ‘책임’이라는 단어는 익숙했지만, 그때는 단순히 의미에 맞게 쓰는 정도로만 이해하고 있었다.
그런데 프리코스를 진행하면서 다양한 코드 리뷰를 접하다 보니, 이 단어들이 거의 빠짐없이 반복해서 등장한다는 걸 느꼈다. 단순한 기술 용어가 아니라, 객체지향에서 어떤 보편적인 철학처럼 쓰이는 말이 아닐까 하는 생각이 들었다.
그러자 문득 예전에 읽었던 객체지향의 사실과 오해라는 책이 떠올랐다. 그 책에서도 ‘역할’, ‘책임’, ‘협력’ 같은 단어들이 반복적으로 등장했었다. 그제야 내가 그 의미를 깊이 이해하지 못하고 그냥 넘겼다는 걸 깨달았다.
코드 리뷰에서 만난 사람들은 대부분 SOLID 원칙에 기반해 객체를 설계하고 있었다. 그들의 코드는 각 객체가 명확한 책임을 가지고 있었고, 변경에 유연하게 대응할 수 있도록 구조화되어 있었다. 반면, 내 코드는 그럴듯한 외형만 갖춘, 구조적 완성도는 부족한 코드였다. 비교가 될수록 내 코드가 허술하게 느껴졌고, 리뷰를 받으면서도 “사실 잘 이해 못한 채 작성했다”는 말만 되풀이했던 것 같다.
하루 종일 리뷰를 곱씹으며 반성하던 그 시점부터, ‘자바를 잘하고 싶다’는 목표는 곧 ‘객체지향을 이해하고 잘 설계할 수 있어야 한다’는 다짐으로 바뀌었다.
2주차
2주차 스터디에서는 1주차 미션에 대한 공통 피드백을 공유받았다.
그중에서도 가장 인상 깊었던 건 ‘클래스나 메서드명만으로도 의도가 명확히 드러나야 한다’는 점이었다.
또한, 공백이나 주석, 스페이스 같은 사소한 요소들 역시 클린코드에 큰 영향을 준다는 사실도 새롭게 배웠다.
1주차 미션에서는 다른 사람들이 많이 쓰는 MVC 패턴을 나도 모방하듯 적용했었다. 구조의 의도나 책임에 대해 깊이 고민하지 않고 단순히 따라 하기 급급했던 것 같다.
하지만 2주차부터는 각 레이어가 어떤 책임을 가져야 하는지에 대해 훨씬 더 의식하며 개발을 진행했다.
그래서 2주차 자동차 경주 미션에서는 다음과 같은 기준을 가지고 코드를 작성하려고 노력했다.
- 패키지와 클래스의 이름이 중복되지 않도록, 의도가 잘 드러나도록 네이밍하기
- else 사용 지양하기
- 인덴트 깊이 3단계를 넘기지 않기
- 한 메서드는 최대 15줄 이내로 제한하기
- 헬퍼 메서드 도입을 통해 메서드의 책임 분리 고려하기
- 변수 이름의 단수/복수를 문맥에 맞게 구분해서 사용하기
- 코드의 책임이 적절히 분리되어 있는지 스스로 점검하기
이러한 기준은 1주차 코드 리뷰에서 받은 피드백과 공통 피드백을 종합하여 정리한 것이다.
2주차 미션은 그 피드백을 실제 코드에 적용해보는 첫 번째 시도였고, 클린코드에 대한 감각을 키우기 위해 더욱 신경 쓰며 개발했던 시간이었다.
https://github.com/woowacourse-precourse/java-racingcar-7/pull/1050
하지만 여전히 역할 분리에는 미숙한 점이 많았다.
각 클래스가 어떤 책임을 가져야 하는지 고민했지만, 실제로 구현한 코드에서는 여전히 책임이 섞여 있는 경우가 종종 있었다.
2주차부터는 단위 테스트 코드 작성도 함께 시작했다.
처음 접하는 테스트는 신선하면서도 동시에 낯설고 위화감이 컸다. 테스트 코드는 본문을 검증하기 위한 도구인데, 테스트를 위해 오히려 본문 코드를 수정해야 하는 상황이 자주 발생했기 때문이다.
예를 들어,
- private으로 선언해둔 메서드를 테스트를 위해 public으로 수정해야 했고,
- 실제 본문에서는 사용되지 않지만 테스트를 위해 생성자나 getter를 추가하는 일도 빈번했다.
이러한 점이 내게는 주객전도로 느껴졌고, 테스트 코드에 대한 고민이 시작된 계기가 됐다.
3주차에 작성한 소감문을 백업해두었는데, 그 글에서도 단위 테스트에 대한 아쉬움과 혼란이 그대로 드러나 있다.
테스트 코드를 제대로 작성하기 위해 어떤 구조가 되어야 하는가, 그 방향에 대해 더 깊이 고민하게 된 시간이었다.
한가지 뿌듯했던 점은 테스트커버리지를 높게 유지할 수 있었던 점이다. 테스트코드를 작성하면서 개발을 진행하다보니 내 코드에 확신이 생겨서 좋았다. 게다가 중간에 코드 수정이 빈번했는데도 테스트에 통과하기만 하면 내가 세운 일정 선은 넘은 느낌이었기에 귀찮은 확인 과정을 생략하고 개발에만 몰두할 수 있었다.
2주차 미션은 MVC패턴에 익숙해지고 테스트코드를 유용하게 써봤다는 점에서 배워간게 많았다.
3주차
3주차 미션인 로또 과제에서는 2주차에 느꼈던 테스트의 위화감을 해결해보고자 TDD를 도입했다.
당시 스터디원 중 한 분이 이미 프로젝트를 TDD 방식으로 진행하고 계셔서, 그분께 많은 조언을 얻을 수 있었다.
그 중 인상 깊었던 조언은,
도메인 설계부터 시작해서, 메인 로직에 집중하고 인터페이스는 후순위로 미루라. 그러면 테스트 대상인 비즈니스 로직이 나중에 크게 바뀌지 않는다.
는 이야기였다.
그 조언을 바탕으로 먼저 로직 중심의 설계를 진행한 뒤, 점진적으로 TDD 방식으로 개발을 이어갔다.
하지만 테스트 코드 작성조차 아직 미숙한 상태에서 TDD까지 도입하려다 보니, 예상보다 훨씬 많은 시간이 소요되었다.
또한 이 시점에 공통 피드백과 코드 리뷰를 통해 일급 컬렉션의 필요성을 본격적으로 깨닫게 되었다.
로또 미션처럼 도메인과 상태가 복잡하게 얽힌 미션일수록, 컬렉션에 대한 책임을 위임할 수 있는 구조가 필요하다는 사실을 체감했다.
그래서 3주차는 아래와 같은 목표를 세웠다.
- TDD를 통해 각 클래스의 기능 분리를 명확히 한다.
- 각 클래스가 명확한 하나의 큰 기능을 수행하도록 한다.
- 가독성 좋은 코드를 작성한다.
- ENUM을 통해 중복되는 값을 관리한다.
- 인덴트 깊이 2 이내로 작성한다.
- 한 메서드가 15줄을 넘지 않는다.
- 클래스, 메서드, 변수명의 의미를 확실히 한다.
- 의도치 않은 외부 조작을 막는다.
https://github.com/woowacourse-precourse/java-lotto-7/pull/757
3주차 미션은 TDD도입을 통해 설계 방식에 변화를 줬고, 실제로 유의미한 결과를 냈다는 점에서 의미있는 주차였다. 물론 본문에 사용하지 않는 생성자나 getter를 완전히 없앨수는 없었지만, 데이터 조작을 막는 선에서는 이정도는 허용하기로 했다. ㅎ
4주차
대망의 4주차 과제는 편의점이었다.
https://github.com/ppparkta/java-convenience-store-7-ppparkta/pull/1
4주차 미션은 가장 어렵고 치열했던 과제였다.
3주차처럼 TDD를 기반으로 개발을 시작했지만, 개발 시간이 턱없이 부족했다.
그동안은 항상 마감 하루 전에는 여유롭게 제출했는데, 이번엔 마감 10분 전에 겨우 제출할 수 있었다.
요구사항을 파악하고 전체 구조를 설계하는 데에만 거의 3일이 소요됐다.
실제 구현은 학교 수업까지 빠져가며 진행했지만, 며칠을 꼬박 새워서야 겨우 마무리할 수 있었다.
3주차까지는 ChatGPT의 도움 없이 스스로 구현했지만, 이번 4주차에는 시간이 너무 촉박해서 일부 로직은 GPT가 제안해준 코드를 거의 그대로 제출하기도 했다.
그런 선택이 어쩔 수 없다는 건 알면서도, 제출 후엔 한동안 마음이 무겁고 심란했다.
그 후
4주차 미션이 끝나고 1차 발표까지 몇 주의 시간이 비었다.
4주차 PR 링크 타고 들어가보면 눈치챌 수 있듯이, 4주차 이후 리뷰부터는 스터디 인원이 확 줄었다.
주차별로 스터디 인원이 조금씩 빠지더니 어느덧 나를 포함해 세명밖에 남지 않았다. 그러나 남은 분들이 다들 열심히, 또 깊게 생각하는 분들이셨기 때문에 이분들과 토론하면서 여전히 배워갈 점이 많았다.
스터디 운영하면서 운영방식에 대해 배운 점도 있고, 스터디 자체로 얻어가는 것도 있었기 때문에 스터디는 다시 생각해봐도 잘 한 선택이었다.
스터디에서는 매주 하나의 최종 코딩테스트 문제를 풀면서 1차 합격을 대비하기로 했다.
나는 4주차 과제를 마친 이후로 의기소침해 있었는데, 예전 기수 최종 코딩테스트 문제를 풀다보니 자신감을 되찾을 수 있었다.
5기와 6기의 문제가 생각보다 쉬웠기 때문이었다. 주어진 5시간 중 2~3시간만 투자하면 구현을 완성할 수 있었고 그 이후에 테스트코드를 추가하거나 리팩토링을 하는 등 유지보수하면 5시간을 알차게 쓸 수 있었다.
그러나...
인턴 합격
1차 발표를 앞두고, 학교 연계를 통해 지원했던 IT 기업의 인턴십에 합격하게 됐다.
면접을 보러 갈 때만 해도 그저 경험이라 생각했기에, 설마 했는데,
그 회사는 굳이 없던 자리를 만들어서 나를 뽑아주었다.
면접은 판교에서 진행됐다.
준비 과정에서 면접을 도와주셨던 주니어 개발자 분과 짧게 상담할 기회도 있었는데,
그 분 덕분에 앞으로 어떤 공부를 해야 할지, 인턴을 하게 되면 어떤 일들을 맡게 될지
조금은 감을 잡을 수 있었다.
그 분 말씀대로라면, 2025년은 눈코 뜰 새 없이 바쁜 한 해가 될 거라고 했다.
하지만 요즘 취업 시장 분위기를 생각하면, 그게 어쩌면 당연한 일일지도 모른다.
솔직히 말해, 우테코 1차 합격은 지원자 수를 생각하면 가능성이 낮다고 생각했다.
그래서 이미 합격한 회사에서 인턴을 시작하는 것이 현실적인 선택이라 판단했다.
그렇게 해서, 1차 발표를 일주일 앞둔 시점에서 함께 달려온 우테코 스터디를 마무리하게 되었다.
1차 합격
졸업전시회, 기말고사 준비로 정신없을 때 쯤 1차 결과가 나왔다.
결과는...엥?
저 왜 합격이에요?
스터디를 하면서 늘 느꼈다. 나보다 개발을 잘하고, 열정도 넘치는 분들이 정말 많았다.
나는 열정은 많았지만, 개발을 잘하진 않았다. 그냥... 열심히 하는 감자일 뿐이었다.
그래서 자연스레 1차에서 떨어질 거라 생각했다. 실력이 부족하다는 자각이 있었고, 한편으론 좋은 동료들을 직접 봐왔기에 더더욱 그렇게 생각했다.
그런데도 합격 통보를 받았다.
아직도 잘 모르겠다. 어떤 점을 좋게 봐주셨는지. 어쩌면, 부족한 실력에도 끝까지 놓지 않았던 진심을 봐주신 걸까?
하지만 하나는 분명했다. 이왕 이렇게 기회를 주셨다면, 후회하지 않을 사람으로 성장해보고 싶다.
최종 코테 당일
그래서 최종 코딩테스트를 열심히 준비해갔냐고 한다면… 그건 아니었다.
번아웃이 와버렸다.
팀 프로젝트에서 받는 대인관계 스트레스와 앞으로의 진로에 대한 걱정 때문에 아무것도 손에 잡히지 않았고, 그냥 아무것도 하지 않은 채 하루하루가 흘러갔다.
이대로 가다가는 후회밖에 남지 않을 거라는 생각이 들었고,
시험 전날에야 겨우 4기 최종 코딩테스트 문제였던 페어매칭 문제만 풀어본 채로 시험장에 갔다.
페어매칭 문제를 5시간 안에 끝내지 못하고 인터페이스만 조금 만져봤을 뿐이라 자신감이 많이 떨어졌다. 그래도 1차에 붙었으니 신나는 마음으로, 스터디 함께 했던 분과 시험 당일 만나 가볍게 이야기를 나눴다.
시험장에 들어서자 그냥 웃음만 났다. 문제를 다 풀 거라는 기대는 하지 않았고, 그저 교육장이 예뻐서 사진만 잔뜩 찍었다.
시험보는 자리는 고정이었다. 다들 좁은 테이블에 세명씩 앉다보니 불편해보였는데, 나는 운 좋게도 가장 마지막 자리에 배정돼서 테이블을 혼자 사용할 수 있었다.
시험장은 누가봐도 우테코 교육장처럼 보였다.
최종 코딩테스트
오후 1시가 되어 시험이 시작됐다.
우테코 교육장의 출석부 시스템을 만드는 과제가 나왔다.
인터페이스 형식이 4주차 페어매칭 문제와 비슷하다는 감상을 했고, 전날 잠깐이라도 문제를 풀어봤음에 감사해지기 시작했다.
전날 만든 인터페이스를 거의 그대로 가지고 와서 인터페이스부터 빠르게 만들었다. 시험 준비하면서 느꼈던건, 도메인 설계에 지나치게 집중하다보면 문제를 제 시간 안에 풀지 못한다는 점이었다.
그래서 매번 부실한 인터페이스를 만들게 됐고, 일단 돌아가는 쓰레기를 만드려면 적어도 최종 시험에서만큼은 도메인 설계보단 인터페이스 구현부터 끝내는게 맞다는 생각을 했다.
그렇게 시험이 시작되고 한시간 반만에 간단한 설계와 기본적인 인터페이스를 구현해낼 수 있었다. 전날 풀어본 문제가 많은 도움이 됐다.
기능 구현
기능 구현은 그냥 저냥 무난하게 진행됐다.
시험 중간에 학장님이 들어오셔서 돌아가는 쓰레기를 만들어야 한다. 도메인 구현하다가 인터페이스 연결 못하는 사람들이 많다. 이런 얘기를 해주셨다.
그래서 그때부터는 클린코드는 버려두고 else 범벅인 코드를 작성했다.
함정
4주차 미션이었던 편의점에서도 테스트코드 내에 숨은 요구사항이 있었다. 이번 최종 미션에서도 비슷한 숨은 요구사항이 존재했다. 그러나 시험장에서는 그런 요구사항을 바로 파악하지 못했고, 테스트를 돌려보고 나서야 뭔가가 있음을 알 수 있었다.
부랴부랴 기존 교육생 초기화 코드에 요구사항에 맞게 기능을 추가했는데, 이미 시간은 종료까지 30분 정도만을 남겨놓고 있었다. 다행히 마지막 테스트코드를 통과할 수 있었지만, 테스트코드에는 없는 4번 기능에 대한 요구사항이 남아있었다.
포기하고 소감문에 집중할까 하다가, 그렇게 하면 시험장을 나서고 후회할거라는 생각이 들었고, 결국 소감문은 5분컷으로 미리 작성한 뒤에 남은 모든 시간을 4번 기능 구현에 쏟았다.
약 20분 남짓한 시간동안 기능을 구현하는건 불가능할거라고 생각했지만, 정렬에 대한 요구사항을 완전히 포기하니 그냥 기존에 만들었던 메서드 몇 개만 가져다 쓰면 끝날 정도로 간단히 구현이 가능했고, 그렇게 시험 종료 2분 전에 4번 기능까지 구현을 완료하게 됐다.
그러나 기능 구현을 하면서 테스트코드 통과를 위한 수정때문에 특정 케이스에서 np가 터질거란 것을 직감했고, 시험이 끝난 후에 혼자 터미널에서 이것저것 테스트해보면서 내 예감이 사실이었음을 알게 됐다.
후기
아쉬움이 전혀 없는 코드를 작성하지는 못했다.
테스트코드도 작성하지 못했고, 클린코드와는 거리가 멀었으며, 요구사항도 많이 놓쳤다… 특히 NP터진 게 가장 치명적이었다.
그럼에도 시험장을 나서면서 기분은 정말 좋았다.
시간 안에 애플리케이션의 핵심 기능을 모두 구현했다는 점에서 스스로가 대견했다.
정렬 같은 세부 요구사항은 구현 후 유지보수 과정에서 추가할 수 있는 부분이라, ‘실전이었다면 일정 맞추는 개발자가 된 셈’이라고 스스로 위안 삼았다. 지금 생각해보면 꽤 뻔뻔한 변명이긴 하다. ㅋㅋ
그래도 이런 마음가짐 덕분에 시험이 끝난 후 가족과 연인에게 기쁜 마음으로 소식을 전할 수 있었다.
결과
1차 발표날에도 약속된 시간에서 한참 지난 뒤에 메일이 왔다.
최종 발표 메일은 무려 3시간이나 지나서 도착했다.
어렴풋이 문제가 어려웠고, 테스트도 다 맞추지 못한 사람이 많을거라고 예상했다. 그래서 np터진 쓰레기 코드가 아쉽지만 결국 우테코에는 붙지 않을까 했다. 그러나 3시간 동안 도착하지 않는 메일에 마음졸이면서 혹시나 내가 테스트를 다 통과하고도 탈락하는걸까? 내 코드가 그렇게 별로였나? 하는 생각을 했다.
뭐라도 하지 않으면 이 시간이 느리게 흘러갈 것 같아서 게임을 하다가 메일이 도착했다. 6시였다.
결과는 진짜... 붙었다.
합격 발표를 받자마자 산학협력 인턴은 포기했다.
최종발표 결과를 보며, 부끄럽지만 친한 동생이 최근 나에게 해준 말이 맴돌았다. 언니를 보면 준비된 사람에게 기회가 온다는걸 실감해.
누군가 나를 좋게 봐준 만큼 더 멋진 모습으로 보답하고 싶다.
