[우테코]실수 많았던 우테코 최종 코딩 테스트 후기

 

📝 1차 심사 합격

먼저 이번 프리코스는 많은 시간을 투자하며 고민해본 시간이 된 것 같습니다.

오픈 미션 도전을 통해 많은 문제들을 직면 했기 때문입니다. 

quddaz/Stockify: 가상 주식 투자 시뮬레이터 Stockify

GitHub - quddaz/Stockify: 가상 주식 투자 시뮬레이터 Stockify

(프리티어 끝나서 배포는 하지 않았습니다... 돈이 업성요)

 

그래서 프리코스에서 많은 것을 얻어가 만족하고 있었고 합격 예감 또한 들었지만 불안감은 많았어요.

통과 이메일을 딱 3시에 받았는데 그 때 감정은 정말 행복했습니다. 

 

 

📝 최종 코테 준비하기 

최종 코딩 테스트 준비는 이전 기수 합격자 후기 조사로 시작했습니다.

• 어떻게 준비하면 좋은지
• 어떤 유형의 문제가 나오는지
• 합격 기준은 무엇인지

이를 바탕으로 저만의 개발 템플릿을 준비했고,
이전 기수 문제들을 모두 직접 풀어보았습니다.

준비하며 세운 목표

1. 제한 시간 내 모든 기능 구현
2. 객체지향 원칙을 지키며 개발

풀어본 문제:

• 6기: 야구, 온콜, 로또, 크리스마스
• 7기: 편의점, 출석
• 4기: 페어프로그래밍

 

 

📝 최종 코테 

 

최종 코딩 테스트는 그전 기수와 다른 방식으로 진행되었습니다.

• 시험 시간 : 13시 ~ 17시(4시간)
• 회고 작성 : 17시 ~ 18시(1시간)

이전 기수와 다른 점은 문제가 4시간 구현으로 바뀌었고 도전 과제가 추가되었습니다. 

도전 과제는 리팩토링과 기능 확장 중에서 골라야합니다.

📝구현

기본 구현은 약 1시간 20분 만에 마쳤습니다.
이미 한 번 풀어본 유형이었고, 난이도도 높지 않았기 때문입니다.

quddaz/java-planetlotto-8 at quddaz

GitHub - quddaz/java-planetlotto-8

 

📌 내가 한 선택

1. MVC 패턴을 사용하지 않았습니다. 그 이유는 다음과 같아요.

• 우테코의 문제는 단방향 프로세스에 해당하며 화면 전환 및 상태 관리 프로세스가 적다.
• 그렇기에 Controller와 Service의 역할이 비슷해지는 상황이 나와 책임이 유사해진다.
• Service를 이용하는 것보다 Domain의 상호작용이 더 유효하고 객체지향적이다.

2. 방어적인 복사를 활용했습니다.

• 외부에서 전달받은 컬렉션을 그대로 사용하지 않고, 방어적 복사를 통해 객체의 내부 상태가 외부에 의해 변경되지 않도록 구현했습니다.
• DTO를 활용하는 방식도 고려했지만, 결과 출력 메소드의 인자가 Map으로 고정되어 있었기 때문에 DTO를 도입하기보다는 도메인 내부에서 필요한 형태의 Map을 생성하여 방어적으로 반환하는 방식을 선택했습니다.

3. Stream과 for을 혼합하여 사용했습니다.

• 프리코스를 진행하기 저는 Stream을 사용했습니다. 더 세련되고 간단했기 때문입니다.
• 프리코스를 진행하면서 항상 Stream이 가독성이 있는 것은 아니라는 생각이 들어 구현 전에 생각하며 둘을 혼합하여 사용했습니다.

4. Service를 사용하지 않기에 객체들의 역할을 더 고려했습니다.

• 객체들의 상호작용을 철저히 하려면 객체들의 역할을 염두하고 기능을 구현할 필요가 있었습니다.
• 이 객체는 어떤 역할을 위해 있는가를 계속 생각하며 계산 결과가 필요한데 어느 객체에서 리턴하지? 와 같은 물음을 혼자 주고받았습니다

 

📝도전 과제

리팩토링은 기본적으로 해야한다고 생각하여 선택하지 않았고 기능확장쪽으로 생각했습니다.

그래서 단발성인 해당 프로그램의 기록을 남겨보자는 생각으로 파일 시스템을 만들었습니다.

 

회고글(도전 미션 관련)

저의 도전 과제는 이전 기록 불러오기입니다. 행성 로또 문제는 단발성 프로그램에 가깝습니다. 즉 한번 사용하면 상태가 남지 않는다는 것입니다. 저는 기록 또한 재미라고 생각하기에 로또 결과를 기록으로 남기면 어떨까? 라는 생각에서 주제를 정하게 되었습니다. 기존에 없었던 자바 파일 읽기와 쓰기 기능을 추가해야 했고 파싱 기능도 필요했습니다. 아쉬운 점은 아직도 단발성 프로그램에 가깝다는 것입니다. 초기 기획은 `마지막에 다시 하시겠습니까? (Y/N)`를 추가하여 무한 루프가 가능하게 하고 싶었습니다. 그러나 기존 프로세스 중에 무언가를 추가하면 안 되는 것과 새로운 Input이 들어오면 안 되기에 파일 시스템만 추가했습니다.

구입금액을 입력해 주세요.
1000

2개를 구매했습니다.
[8, 11, 13, 21, 22]
[1, 3, 6, 14, 22]

지난 주 당첨 번호를 입력해 주세요.
1,2,3,4,5
보너스 번호를 입력해 주세요.
10

당첨 통계
---
5개 일치 (100,000,000원) - 0개
4개 일치, 보너스 번호 일치 (10,000,000원) - 0개
4개 일치 (1,500,000원) - 0개
3개 일치, 보너스 번호 일치 (500,000원) - 0개
2개 일치, 보너스 번호 일치 (5,000원) - 1개
0개 일치 (0원) - 1개

============기록============
라운드	구매	1등	2등	3등	4등	5등
1라운드	3개	1개	1개	1개	0개	0개
2라운드	2개	0개	0개	0개	0개	1개
3라운드	2개	0개	0개	0개	0개	1개
4라운드	2개	0개	0개	0개	0개	1개

 

 

 

📝 회고 작성

회고는 따로 준비하지 않았습니다. 

그래서 1시간동안 솔직하게 적었습니다. 그래서 글이 가독성이 있지는 않았습니다.

대신 솔직하고 제가 중요하게 생각한 것을 남김없이 적었습니다.

사실 제일 어려웠던 것은 변수, 메소드명 네이밍이였습니다. 이번 최종 코딩 테스트에서 AI를 못 쓴다고 했을 때 제일 걱정하던 것입니다. 

이런식으로 작성한 것 같아요. 

다른 분들은 회고 문 템플릿은 준비해 가는 것이 좋을 거 같습니다. 

 

 

📝 실수들...

최종 코딩 테스트가 끝나고 집에서 제가 구현한 것을 점검했습니다. 

많은 실수들이 나왔어요

 

1. 많은 예외 케이스 놓침

위 코드는 구매 금액을 입력하고 몇개를 가져올 지 반환하는 쿼리입니다.

그러나 음수 금액에 대한 검증을 하지 않았어요.

 

또한 로또 번호의 1~30 범위 검증을 하지 않았습니다. 그 이외에는 전부했는데 말이죠.. 긴장했다 하더라도 하면 안되는 실수였습니다.

 

2. 매직 넘버

파일에서 읽어올 때와 파일에 저장할 때 사용하는 파서 로직에서 매직 넘버를 사용했습니다.

당시에는 OutputView의 출력 형식이 고정되어 있고, 결과 또한 Map<Integer, Integer> 형태로 관리되고 있었기 때문에,
출력 로직과 동일한 규칙(0은 미당첨, 1~5는 등수)을 유지하는 것이 일관성 측면에서 더 적절하다고 판단했습니다.

 

하지만 구현 이후 다시 돌아보니, 현재 요구사항을 만족하는 것뿐만 아니라
확장과 리팩토링이 쉬운 코드를 만드는 것이 더 중요하다는 점을 놓쳤다고 느꼈습니다.
이러한 맥락에서 매직 넘버를 그대로 사용하는 대신,
상수나 enum을 통해 의미를 드러내는 방식이 더 적절했을 것이라 생각하게 되었습니다.

 

3. 회고 준비 안함

회고 준비를 안한 것도 실수라고 할 수 있을거 같아요.

1시간안에 저가 담고 싶었던 모든 것을 쓰는 건 무리가 있었습니다. 문법도 맞지않고 가독성도 좋지 못했어요.

솔직함은 들어있지만요.

 

 

📝마치며..

근 1년 중에서 우테코에 투자했던 3달을 제일 열심히 살았던 것 같습니다.

공부했던 것을 다시 상기하고 도전하면서 활기찬 하루하루 였습니다. 

 

정말 열심히 준비하였습니다. 그러나 모든 능력을 보여주지 못한 것 같아 아쉽습니다.  현재의 저는 휴식기를 가지고 있습니다. 그 동안 길어지는 취준으로 인해 마음고생도 많이 했고 자책도 많이했습니다. 내가 실력이 없나?, 나의 학습 방법이 잘못되었는가?, 나는 똑똑하지 않구나.. 등등 입니다.

그래서 점점 공부 의욕도 적어지는 느낌이였어요. 그럼에도 우테코를 통해 다시 한 번 ‘나는 여전히 프로그래밍을 좋아하는 사람이구나’ 라는 확신을 얻을 수 있었습니다.

3개월동안 매일매일 몰입하는 경험 감사합니다.

 

 

합격했다!! 합격!!!