우아한테크코스 8기 최종 코딩테스트 회고

들어가며

감사하게도 우아한테크코스 프리코스를 마친 이후 1차 합격을 하여, 최종 코딩테스트를 응시할 기회를 얻었다.

이 날을 간절히 바랐고, 실제로 이 날을 맞이한 만큼

결과보다도 내가 어떤 생각을 바탕으로 판단과 결정을 내렸는지 되짚어보고 싶었다.

문제를 어떻게 해석했는지, 시간 압박 속에서 어떤 결정을 내렸는지,

그리고 그 결정이 나에게 어떤 영향을 끼쳤는지를 정리하지 않으면 금세 잊혀질 것 같았다.

따라서 최종 코딩테스트 준비 과정, 시험 당일의 판단과 선택, 그리고 이후의 회고를 차례대로 정리하며

앞으로의 나를 발전시키는 데 참고하고자 한다ㅎㅎ

 

최종 코딩테스트 준비

오픈 미션이 끝나고, 일주일 후부터 최종 코딩테스트 준비를 시작했다.

1차 합격 결과가 나오기 전이었지만, 만약 합격했을 경우 시험 당일까지 약 2주 동안 만족할 만큼 준비를 못할 것 같았기 때문에 미리 시작했다.

합격하든 못하든 공부한 건 언젠가 빛을 발휘하기 때문에!!!!

1차 발표 전까지는 일주일에 미션 2개 씩, 발표 이후에는 매일 4시간 타임어택으로 풀면서 감을 익히려 노력했다.

4시간동안 노트북 한 대로 AI 도움 없이 문제를 풀었고, 문제를 푼 이후 KPT 회고를 통해 부족한 점을 보완해갔다.

 

https://github.com/Jiihyun/wooteco8th/pulls

GitHub - Jiihyun/wooteco8th: 우테코 8기 최종 코테 준비

 

목표

코딩테스트를 준비하며 세운 최종 목표는 ‘요구사항에 있는 기능들을 재활용 가능한 쓰레기로 구현하기’였다.

우선 요구사항 위주로 리팩토링이 가능할 정도의 코드를 빠르게 작성하고, 이후 시간이 남으면 리팩토링과 테스트 코드를 챙기는 것이다.

 

처음에는 프리코스에서 배운 객체지향 개념을 최대한 녹여내고, 예외 처리까지 완벽한 코드를 작성하는 것을 목표로 삼았다.
설계 단계부터 객체 간 책임과 의존성을 고민하며, 이상적인 구조를 만드는 데 집중했다.

하지만 설계를 깊게 가져갈수록 시간이 빠르게 소모되었고,
요구사항에 포함되지 않은 예외 처리까지 모두 챙기다 보니 4시간 안에 구현을 마치지 못하는 경우가 많았다.

객체지향적인 구조를 고민하며 캡슐화와 의존성을 신경 쓸수록 4시간이라는 제한 시간은 생각보다 훨씬 촉박하게 느껴졌다.

 

실제 시험 환경에서는 긴장감으로 인해 평소보다 사고 속도가 느려질 수도 있고,
소감문 작성 시간이나 예상치 못한 상황에 대비할 여유도 필요했다.
결국 4시간 안에 주어진 테스트를 통과시키는 것 자체가 가장 우선적인 목표가 될 수밖에 없었다.

이 경험을 통해, 이상적인 코드보다 제한된 시간 안에서의 선택과 판단이 더 중요하다는 사실을 체감하게 되었다.

실제 현업에서도 내 능력과 별개로 마감 일정이나 여러 제약으로 인해 코드를 이상적으로 작성하지 못하는 상황이 종종 있다고 들었는데,

이번 코딩 테스트를 준비하며 그 말의 의미를 조금은 이해할 수 있었다.

 

이후에는 미션을 진행할 때 4시간 동안 각 단계에 얼마나 시간을 사용하는지 기록하며 문제를 풀었고,
미션이 끝난 뒤에는 그 시간을 다시 되돌아보며 전략을 하나씩 수정해 나갔다.

완벽한 구현에 집착하기보다, 주어진 시간 안에서 무엇을 우선해야 하는지를 스스로 판단하는 데 집중했고
4시간 이내에 테스트를 통과하기 위한 감각을 점점 익혀나갈 수 있었다.

 

개선한 점

1. 요구사항 분석 방식 개선

이전에는 요구사항을 빠르게 훑은 뒤 설계 없이 기능 목록만 작성하고 구현에 들어가는 경우가 많았다.

이로 인해 요구사항을 정확히 이해하지 못해 놓친 기능이나, 출력에 필요한 상태 값을 저장해 두는 것을 놓쳐 구현 후반에 로직을 크게 수정해야 하는 문제가 반복되었다.

이를 개선하기 위해 요구사항을 읽을 때 실행 예시를 그냥 읽는 것이 아니라,

직접 계산해보며 어떤 값이 필요할지 분석하기 시작했다.

또한 기능 목록을 작성할 때 출력에 필요한 값과 저장해야 할 상태를 함께 정리했고, 재입력 여부나 검증 시점처럼 헷갈리기 쉬운 조건들은 체크박스로 명시했다.
그 결과 구현 도중 요구사항을 다시 해석하느라 시간을 소모하는 일이 크게 줄었다.

 

2. 테스트 코드 활용 방식 개선

초기에는 테스트 코드를 구현이 끝난 뒤 결과를 검증하는 용도로만 사용했다.

이 때문에 입력 흐름이나 검증 타이밍을 잘못 이해해 NoSuchElementException과 같은 오류를 뒤늦게 마주하는 경우가 많았다.

또한 구현한 기능 알고리즘이 테스트 코드에서 짜여진 방식과 달라 결과는 같지만 테스트가 틀리는 경우도 발생하였다.

이후에는 구현 전에 ApplicationTest를 먼저 읽고, 테스트가 기대하는 입력 단위와 흐름을 파악하는 방식으로 접근했다.

테스트 코드를 일종의 설계 힌트로 활용하면서, “어떤 순서로 기능을 구현해야 하는지”, “어느 단계에서 재입력이 필요한지”를 파악할 수 있었다.
이 방식 덕분에 구현 이후 테스트를 단번에 통과하는 비율이 늘어났다.

 

3. 디버깅 접근 방식 개선

문제가 발생했을 때 원인을 정확히 파악하지 못한 채 추측으로 코드를 수정하는 경우가 잦았다.

특히 입력 흐름이나 알고리즘이 복잡한 기능에서는 이러한 방식이 오히려 버그를 늘리고 버그 고치는 시간을 크게 증가시켰다.

이를 개선하기 위해 막히는 경우에는 추측에 의존해 코드를 수정하기보다, 반드시 디버깅을 통해 실제 값의 흐름을 먼저 확인하는 것을 원칙으로 삼았다.

예상과 다른 지점을 눈으로 확인한 뒤 수정하도록 습관을 바꾸면서, 불필요한 수정과 되돌리기를 줄일 수 있었고 문제 해결 속도도 빨라졌다.

 

4. NsTest 라이브러리 활용

초기에는 테스트 코드 작성을, 구현이 끝난 이후 시간이 남으면 작성하는 선택 사항으로 여겼다.

이로 인해 리팩토링 과정에서 기존 기능이 깨지는지 확신하기 어려웠고, 변경에 소극적이 되는 경우가 많았다.

이후에는 JUnit이나 Assertions를 활용해야지만 테스트코드를 작성할 수 있다는 사고를 바꿨다.

구현 완료 후 시간이 남으면 우아한테크코스 라이브러리인 NsTest를 통해 바로 통합 테스트를 작성하거나, 여러 테스트 케이스를 메모장에 기록해두는 방식으로 접근을 바꾸었다(콘솔에 복사해서 실행시킬 수 있게).

통합 테스트코드 작성을 통해 리팩토링 시 빠르게 피드백을 받을 수 있었고, 코드 개선을 보다 과감하게 시도할 수 있었다.

 

5. 자료구조 선택 기준 정립

이전에는 익숙한 List 위주로 자료구조를 선택하다 보니, 저장한 값 조회 로직이 복잡해지는 경우가 많았다.

특히 페어 매칭이나 출석 미션에서 특정한 조건을 가진 값들을 조회하거나, 그 값의 상태 갱신할 때 코드가 불필요하게 길어졌다.

문제를 반복해서 풀면서 상태 저장이 필요하며, 조건에 따라 값들을 조회하는 경우에는 key 기반 접근이 편리하다는 것을 깨달았다.

따라서 “중복이 허용되는가”, “조회가 잦은가”, “key 기반 접근이 편리한가” 등을 기준으로 자료구조를 선택하도록 나만의 기준을 세웠다.
그 결과 상태 저장이 필요한 경우에는 Map을 적극 활용했고, 중복이 필요 없는 경우에는 Set을 고려하는 등

상황에 맞는 자료구조를 선택할 수 있게 되었다.

이는 코드의 가독성과 수정 용이성을 개선하는 데 도움이 되었다.

 

▪️ Map 활용

https://github.com/Jiihyun/wooteco8th/pull/11/files#diff-5deef5ca5c71e35619dd0b5601a3781415022465387b3e1650af20ef90bbebab

페어매칭 타임어택2 by Jiihyun · Pull Request #11 · Jiihyun/wooteco8th

 

 

▪️ Set 활용

https://github.com/Jiihyun/wooteco8th/pull/8/files#diff-55fb9dfb1803a3e21bdbd238f89465af042b98bd1303a1ad280eaf22003b6002

페어매칭 타임어택 by Jiihyun · Pull Request #8 · Jiihyun/wooteco8th

 

객체 지향

객체지향적으로 구현하는 연습을 완전히 내려놓지는 않았다.

프리코스 기간 동안 객체지향적으로 사고하고 구현하는 연습을 꾸준히 했고,

최종 코딩테스트에서도 테스트 통과 이후 리팩토링을 막힘 없이 하기 위해서도 결국 객체지향에 대한 이해가 많이 필요하다고 느꼈기에

프리코스가 끝난 이후에도 관련 공부를 이어갔다.

 

타임 어택 이후 코드를 다시 살펴보며 스스로 개선 여지가 있다고 느꼈지만 방향이 바로 떠오르지 않는 경우에는

 AI에게 의견을 묻거나, 다른 분들의 레포지토리를 참고하며 다양한 구현 방식을 살펴보았다.

그 과정에서 더 읽기 쉬운 코드나 책임이 명확하게 분리된 구조를 발견하면, 이를 내 코드에 적용해 보며 리팩토링을 진행했다.

 

시뮬레이션 하기

 

 

시험장에서 5시간을 어떻게 활용할지 크게 세 단계로 나누어 시뮬레이션을 반복했다.

타임 어택을 할 때마다 부족한 부분을 보완하며 점차 흐름을 다듬었고, 시험 하루 전에 나만의 루틴을 완성할 수 있었다.

시간을 최대한 아끼기 위해 자주 사용하는 코드 패턴은 인텔리제이에 Live Template으로 등록해 두었고, 소감문 역시 미리 작성해 두었다.

이를 통해 시험 당일 예상치 못한 상황이나 시간 부족에 대한 부담감을 줄이기 위해 많은 준비를 했다.

이러한 과정을 거쳐 최종 코딩 테스트에 임하기 위한 준비를 마칠 수 있었다.

 

최종 코딩테스트 당일

당일에 폭설예보가 있었기에 버스가 막힐까봐 10시보다 살짝 이르게 나왔지만,

눈이 전혀 오지 않아 11시도 안되어 잠실에 도착한 나는

코딩 테스트 장소 근처 투썸에서 시험 중 발생할 여러 상황에 대해 시뮬레이션하며 긴장감을 낮추려 노력했다.

(버스 안에서는 멀미할까봐 뭘 하지는 못했고.. 우주소녀-이루리🎶 무한 반복으로 들으면서 합격 기운 모았다,,ㅋㅋㅋㅋ)

12시부터 입실이 가능했어서, 12시에 맞춰 시험장에 도착하였다.

입실하자마자 신분증 검사를 했고, 지정석이었기에 칠판에 붙어있는 내 좌석 위치를 확인했다.

자리가 좁다는 후기는 많이 봤긴 했지만, 실제로 앉아보니 진짜 좁았다.

하나의 긴 테이블에 3명이 앉아야했고, 내 자리는 그중에서도 가운데 자리였다..ㅎㅎ

짐을 최소화한 상태로 방문했음에도 불구하고, 노트북, 마우스, 음료수, 간식, 노트북 앞에 A4용지를 놓으니 자리가 가득 찼다.

적응된 후에는 불편함이 없었지만, 처음 자리에 앉아 세팅을 하기 전까지는 자리가 좁다고 느꼈던 것 같다.

 

자리에 앉은 후에는 와이파이 세팅 등 도착 이후 해야 할 루틴을 수행하였고,,,

코드를 좀 읽어보려했지만 머리가 자꾸 튕겨 내어 그냥 멍 때렸던 것 같다.

그냥 편하게 임하자! 긴장하지 말자! 프리코스 기간동안 스스로 했음만 보여주자! 를 되뇌었다.

아차차 프리코스 기간동안 좋은 말씀 많이해주신 포비님께 싸인도 받았다.

 

이전 시험과는 달라진 점

최종 코딩테스트 안내 시간

1차 합격 메일에서 최종 코딩테스트 안내 사항 설명을 위해 20분 일찍 입실을 권장했는데,

막상 13시까지 아무런 안내가 없어 설명 없이 바로 시험 시작이라 생각했다.

하지만 13시부터 약 20분간 시험 안내를 진행했다.

약간 당황하였지만, 지금 안내 대충 들었다가 나중에 어리버리 하기 싫어서 딴 짓 안하고 열심히 들었다.

 

쉬는 시간

3시부터 쉬는 시간이 10분 주어졌다.

자율이 아니라 모든 인원이 노트북을 덮고 10분간 휴식해야 했다.

이때 포비님이 앞에 나와 코딩 테스트에서 자주하는 실수&시험에 임하는 마음 가짐 등 코딩 테스트 관련 조언을 해주셨다.

이야기를 들으면서 2시간 동안 실수한 거 없는지 돌아보았고, 남은 시간동안 어떻게 시험 볼 건지 계획을 재정비했다.

 

테스트 방식

이전 기수들과는 다르게 도전 과제가 추가되었다.

프리코스 마지막 미션이었던 로또 미션과 유사한 요구 사항이 주어졌고,

요구 사항을 충족한 이후 리팩토링 또는 기능 확장 중 하나를 선택해 추가로 도전하는 방식이었다.

이 때 코드 작성 및 푸쉬는 17시까지인 4시간 동안 가능했고, 이후 1시간은 오직 소감문 작성만 허용됐다.

안내 사항 들으면서 이런 진행 방식은 전혀 예상하지 못했기에,,

타임어택 연습 시간을 타이트하게 잡아두길 정말 잘했다고 느꼈다.

 

나의 판단과 선택

https://github.com/woowacourse-precourse/java-planetlotto-8/pull/40

[행성 로또] 임지현 미션 제출합니다. by Jiihyun · Pull Request #40 · woowacourse-precourse/java-planetlotto-8

 

요구사항 구현 먼저 & 주어진 테스트 코드를 통과하자

우선 연습해 왔던 대로기능 목록을 가장 먼저 작성하였고, 이후 주어진 테스트 통과를 위한 기능을 구현했다.

구현하면서는 3주 차 로또 미션 코드 리뷰에서 받은 피드백을 반영하는데 집중했다.

• 로또 숫자 규칙 관련 중복 검증 해결을 위해 LottoNumber VO 추가
• LottoStore에 몰려있던 여러 책임 분산
  • 구매 금액 관련 PurchaseAmount VO 추가
  • 로또 추첨하는 LottoDrawer 추가

전날에 로또 미션을 다시 한번 풀었던 지라 기억이 생생했고,

로또 미션에서 수익률 계산하는 기능이 최종 테스트에서는 빠졌기에 구현 양이 줄었다.

덕분에 1차 구현 완료 및 테스트 통과는 2시 30분 정도에 해낼 수 있었다.

 

안전한 리팩토링을 위해 통합테스트를 작성하자

20분 동안 통합테스트 4개, 예외 검증 테스트 2개를 작성하였다.

기존에 잘 돌아가던 코드가 리팩토링 이후 안 돌아갈 수 있는 상황을 고려했다.

이때 문제가 발생한 지점을 빠르게 파악할 수 있도록, 그리고 좀 더 과감히 리팩토링을 할 수 있도록 하기 위해

동작을 보장하는 통합 테스트를 작성하였다.

 

어떤 도전을 할까?

리팩토링과 추가 기능 중 선택했어야 했는데,

내게 리팩토링은 새로운 도전이라기보다, 시간이 허락한다면 당연히 수행해야 하는 작업에 가까웠다.

또한 처음부터 어느정도 객체 지향을 지키면서 코드를 작성하였기에

리팩토링만으로 남은 2시간을 알차게 사용하기 힘들 것 같았다.

따라서 리팩토링과 추가 기능 구현 모두 도전하기로 했다!!

'둘 다 할 수 있을까?', '시간이 허락할까?', '리팩토링만 도전하는 안전한 선택을 하는 게 좋나?' 등

여러 의문이 튀어나왔지만 더 깊게 생각 안하고 하고 싶은대로 일단 시작 했다.

겁을 먹고 시도조차 하지 않으면 내가 어디까지 할 수 있는지 결코 알 수가 없고,

나는 내가 생각했던 것보다 더 많은 것을 해낼 수 있는 사람이라는 것을

프리코스 오픈미션을 도전하면서 배웠기 때문이다.

 

리팩토링

처음부터 책임 분리를 위해 클래스도 나누고, 캡슐화 등 객체지향적인 코드를 작성하는 데 신경썼지만,

바로바로 떠오르지 않는 부분은 신경이 쓰여도 표시만 하고 넘어갔었다.

그래서 이부분 위주로 리팩토링을 진행했다.

• 예외메세지 하드코딩 제거
• 게터 사용하지 않아도 되는 부분 캡슐화
• 중복 상수 제거
• 로또 랭킹 계산 하드코딩 제거

당시에는 긴가민가 했지만 추가 기능 구현을 위해 더 붙잡지 않고 넘어갔는데,

집에 와서 다시 회고해 보았을 때 실수한 부분이 한가지 있다,,ㅎ

랭킹 계산하는 부분을 하드코딩에서 알고리즘으로 변경하면서 로직에 오류가 생겼다.

보너스번호를 가지고 있지 않아도 당첨 번호 개수가 같으면 4등, 5등이 당첨되는 것이다..OMG

당시 생각나는 모든 케이스를 작성하였고, 테스트 코드도 전부 통과하니 문제가 없다고 생각했었는데,,

결과적으로는, 내가 작성한 테스트만으로는 모든 경우를 검증하지 못했다.

 

이 로직이 아니라

// 리팩토링 전
private static final List<Rank> NON_REQUIRE_BONUS_NUMBER = Arrays.stream(Rank.values())
            .filter(element -> !element.requireBonusNumber)
            .toList();

public static Rank of(int matchingCount, boolean hasBonusNumber) {
    if (matchingCount == SECOND.matchingCount && hasBonusNumber) {
        return SECOND;
    }
    if (matchingCount == FOURTH.matchingCount && hasBonusNumber) {
        return FOURTH;
    }
    if (matchingCount == FIFTH.matchingCount && hasBonusNumber) {
        return FIFTH;
    }
    return NON_REQUIRE_BONUS_NUMBER.stream()
            .filter(rank -> rank.matchingCount == matchingCount)
            .findAny()
            .orElse(NONE);
}

// 리팩토링 후
public static Rank of(int matchingCount, boolean hasBonusNumber) {
    if (matchingCount == SECOND.matchingCount && hasBonusNumber) {
        return SECOND;
    }
    return WITHOUT_SECOND.stream()
            .filter(rank -> rank.matchingCount == matchingCount)
            .findAny()
            .orElse(NONE);
}

 

이렇게 작성했어야 했는데!!! 마음이 조급했어서, 더 깊게 생각하지 못했다...

public static Rank of(int matchingCount, boolean hasBonusNumber) {
    return Arrays.stream(values())
            .filter(rank -> rank.matchingCount == matchingCount)
            .filter(rank -> !rank.requireBonusNumber || hasBonusNumber)
            .findFirst()
            .orElse(NONE);
}

 

집에 와서 잘못 수정한 로직을 다시 확인하며
“괜히 욕심을 냈나?”, “차라리 하드코딩을 그대로 두는 게 나았을까?”라는 생각도 들었다.

그럼에도 이번 선택을 완전히 후회하지는 않는다.
실제로 경험해보고, 틀려보고, 부족한 점을 파악했기 때문이다.
이번 경험을 통해 다음에는 같은 실수를 반복하지 않으면 된다!!!

도전한 것 자체에 의미를 두고,앞으로는 알고리즘 생각해 내는 사고를 더 단단히 하기 위해
코딩 테스트 공부도 더 열심히 해보려 한다.

 

추가 기능

리팩토링을 마치고 나니 약 1시간 25분 정도의 시간이 남았고,

약 25분 동안 어떤 기능을 추가할지 생각하며 기능 목록 README를 보완했다.

 

생각해낸 기능은 로또 추첨 이후 당첨된 로또가 한 장도 없는 사람에 한하여 공짜 로또 티켓을 한 장 주는 것이다.

이 때 토스에 있는 로또 기능으로부터 영감받아 로또 번호를 수동 입력과 자동 입력이 가능하도록 기획 했다.

원래 목표는 바로 추첨하여 결과를 알고 싶게 하고 싶었는데, 시간이 부족하여

무료로 받은 다음 주 로또 티켓 한 장에 대한 번호를 알려주는 것으로 추가 기능 도전을 마무리했다.

구입금액을 입력해 주세요.
1000
2개를 구매했습니다.[1, 8, 17, 19, 22]
[5, 6, 16, 21, 29]
지난 주 당첨 번호를 입력해 주세요.
1,2,3,4,5
보너스 번호를 입력해 주세요.
6
당첨 통계
---
5개 일치 (100,000,000원) - 0개
4개 일치, 보너스 번호 일치 (10,000,000원) - 0개
4개 일치 (1,500,000원) - 0개
3개 일치, 보너스 번호 일치 (500,000원) - 0개
2개 일치, 보너스 번호 일치 (5,000원) - 0개
0개 일치 (0원) - 2개
낙첨이므로 공짜 로또를 받을 수 있는 기회를 드리겠습니다.

기능을 번호로 선택하세요.
1. 수동
2. 자동
Q. 필요없음
1
이번 주 당첨 번호를 입력해 주세요.
1,2,3,4,5

응모되셨습니다.
구매 번호: [1, 2, 3, 4, 5]

 

최종 코딩테스트 기출 문제들을 풀면서,
명령어에 따라 기능을 선택하도록 구현하는 방식이 자주 등장했었다.
나는 이 부분이 특히 어려웠는데,
while 문을 언제 빠져나와야 하는지 판단하는 게 늘 헷갈렸기 때문이다.

그래서 이 유형을 의식적으로 많이 연습해 왔다.
비록 이번 최종 코딩테스트 요구사항에는 명령어 처리가 포함되어 있지 않았지만,
스스로 기능을 확장하는 과정에서
과거에 연습해 두었던 이 방식이 자연스럽게 떠올랐다.

그 덕분에 기능을 '수동/자동/필요없음' 을 선택할 수 있는 편리한 형태로 확장할 수 있었고,
“연습해 둔 것이 결국 이렇게 쓰이는구나”라는 생각에 뿌듯함을 느꼈다.

 

추가 기능에서도 잘못된 입력은 재입력처리하고 싶었는데, 시간 부족으로 하지 못했다.

단순히 재입력 메서드를 람다로 감싸주기만 하면 되었는데,,끄헝

기능을 구현하고 리드미를 업데이트하니 시간이 이미 4시 57분이었고,

손을 덜덜 떨며 재입력 가능하게끔 코드를 작성했지만 5시가 되어 끝내 푸쉬는 못한 채 최종 테스트를 마무리 했다.

 

소감문 작성

5시부터 1시간동안 소감문을 작성하였다.

소감문 작성 시간이 부족할 것을 대비해 미리 글을 준비해 왔지만, 실제로는 1시간이라는 비교적 넉넉한 시간이 주어졌다.

또한 소감문에는 가이드라인이 있었다. 최종 코딩 테스트를 치르며 어떤 도전을 했는지, 그 과정에서 무엇을 느꼈는지에 대한 질문들이 제시되었다.

 

내가 미리 준비해 온 글은 최종 코딩 테스트를 어떻게 준비했는지, 그리고 프리코스를 진행하며 무엇을 느꼈는지에 초점이 맞춰져 있었다.
그래서 실제 소감문을 작성하는 순간에는, 사전에 준비한 내용이 생각보다 크게 도움이 되지는 못했다.

또한 도전 이유와 도전 소감 등 ‘도전’ 자체에 대한 이야기를 쓰기 위해 도입부부터 차근차근 빌드업을 하다 보니,

글을 계속 다듬는 데 시간을 많이 썼다.
그 결과, 핵심이 되는 도전과 관련된 경험과 생각을 충분히 구체적으로 풀어내지 못한 채 마무리하게 된 점이 가장 아쉽다.

코딩 연습뿐만 아니라, 글로 생각을 정리하는 연습도 더 필요하다는 것을 느꼈다.

 

마치며

준비한 걸 다 보여주기 위해 최선을 다해 시험에 임했지만, 실수도 했고, 소감문에 나의 이야기를 잘 담지 못한 것 같아 아쉬움이 남는다.

하지만 6시가 되기까지 단 1분도 낭비하지 않고 프리코스에서 배운 모든 것을 쏟아낸 것 같아 후회는 없다!!

또한 잡생각 할 틈 없이 코딩에만 몰두하며, 주변을 의식하지 못할 정도로 집중하는 경험을 하였기에 오래 기억에 남을 것 같다.

내가 할 수 있는 일은 모두 마쳤다. 
약 3개월간의 과정 속에서 나의 열정과 간절함이 잘 전해졌기를 바란다🥹

 

프리코스 덕분에 매주 회고를 통해 내게 필요한 방향을 스스로 정하고 주도적으로 학습하는 방법을 배울 수 있었다.

누군가 정답을 알려주기보다, 스스로 고민하고 선택하며 배워갈 수 있었던 이 경험은 앞으로의 개발 학습에서도 오래 남을 자산이 될 것 같다.

짧은 6주라는 시간 동안에도 이러한 변화를 경험할 수 있었던 만큼, 10개월 동안 몰입한다면 얼마나 더 깊이 성장할 수 있을지를 기대하며 우아한테크코스에서의 시간을 더욱 간절히 바라게 되었다.

결과를 기다리며 아무것도 손에 잘 잡히지 않지만, 할 일 하면서 남은 기간 동안 차분히 기다려야지,,

다들 정말 고생 많으셨습니다!