우아한테크코스 최종 코딩테스트 준비: 프리코스 코드를 현장에서 다시 구현하기

우아한테크코스 최종 코딩테스트 준비는 기출을 외우기보다 프리코스에서 훈련한 문제 유형을 다시 설계하고 구현하는 연습이 중심입니다. 현재 지원 안내는 AI 시대에 맞게 과정을 개편 중이며 9기 선발 안내를 2026년 11월 중 발표한다고 적습니다. 기존 FAQ의 프리코스·최종 테스트 설명을 9기 확정 규칙으로 옮기지 말고, 새 공고와 본인의 안내를 따로 확인하세요. 먼저 Test-Driven Pair Programming: Grow a Java Set Class from Unit Tests로 한 번 풀어 보고, 이 글의 점검 절차로 풀이를 다시 검증하세요.

공식 사실: 우아한테크코스 FAQ는 선발 과정이 프리코스와 최종 테스트로 구성되고, 온라인 코딩테스트 없이 프리코스를 진행한다고 설명합니다. FAQ는 최종 테스트 유형이 프리코스와 같고 유사 난이도이며 오프라인 진행이 기본이라고 안내합니다. 모집 공고의 일정은 별도의 해당 기수 자료로 확인해야 합니다. 후보자 보고: 동일 회차의 독립된 후보자 보고는 수집하지 않았습니다. 추론: 프리코스 제출 코드를 재현 가능한 규칙으로 요약하고, 제한 시간 안에 요구사항·설계·테스트를 다시 구성하는 연습이 공식 안내와 가장 직접적으로 맞닿는다.

FAQ와 모집 일정은 서로 다른 근거 (Current notice vs FAQ)

현재 지원 안내에는 9기 선발 안내를 2026년 11월 중 이 홈페이지에서 발표한다는 공지가 있습니다. 동시에 기존 FAQ는 프리코스와 최종 테스트, 트랙별 언어를 설명합니다. 두 문서가 같은 시점의 새 선발 규칙이라고 가정하지 마세요. 새 과정이 발표되면 지원 구조·기간·허용 자료가 무엇인지 새 공고에서 다시 확인해야 합니다.

후보자 보고: 이번 글은 특정 기수 지원자의 독립된 경험 보고를 수집하지 않았습니다. 추론: 공식 FAQ가 말하는 유형과 유사 난이도라는 경계를 기준으로 프리코스 문제를 다시 설계하는 것이, 확인되지 않은 “실제 기출” 목록을 따라가는 것보다 안전합니다.

프리코스 문제를 학습 노트로 압축 (Rule summary)

각 미션에서 입력 조건, 주요 도메인 규칙, 클래스 경계, 예외 처리, 테스트를 한 장으로 요약합니다. 코드 전체를 외우지 말고 “왜 이 객체가 이 규칙을 책임지는가”, “어떤 테스트가 잘못된 결과를 잡았는가”, “변경을 쉽게 하기 위해 무엇을 분리했는가”를 적으세요. 기존 저장소를 볼 수 없는 조건으로 모의 연습해 보면 무엇을 이해하고 무엇을 파일에서 복사해 왔는지 구분할 수 있습니다. 실제 시험의 저장소·IDE·자료 사용 규칙은 본인의 안내에서 확인해야 합니다.

프리코스 제출본에서 가장 복잡했던 미션을 다시 고릅니다. README와 테스트 결과를 먼저 읽고, 요구사항만 남긴 뒤 처음부터 작게 구현해 보세요. 구현 전에는 클래스의 책임과 함수 시그니처를 세우고, 첫 테스트가 통과한 뒤 다음 동작으로 넓혀갑니다.

첫 10분은 문제 계약과 작업 순서 (Mock contract)

새 과제를 받으면 입력·출력, 성공 조건, 오류·빈 값, 동률 처리, 제약을 체크합니다. 모호한 요구사항은 질문하거나 보수적인 가정을 쓰고, 그 가정이 답을 바꾸는지 확인합니다. 다음에 핵심 기능과 위험도가 높은 경계를 분리해 작업 순서를 정합니다.

예를 들어 주문 합계를 계산하는 과제가 주어진다고 가정하면, 할인 전 금액, 할인 대상, 반올림 시점, 취소 상품 포함 여부가 모두 결과를 바꿉니다. 이것은 교육용 합성 예시이지 우아한테크코스 과제에 관한 보고가 아닙니다. 규칙을 테스트 이름으로 먼저 옮기면 구현의 우선순위를 설명하기 쉬워집니다.

예약 규칙을 새 저장소에서 다시 구현하는 예 (Reservation exercise)

이 글의 독립 미션을 한 가지 정합니다. 하루의 예약 슬롯은 18:00, 19:00 두 개이고 한 슬롯에는 이름 하나만 저장합니다. 이름은 양끝 공백을 제거한 뒤 비어 있으면 거절합니다. 이미 예약한 슬롯이나 허용하지 않은 시간은 오류이며, 실패 전에 기존 예약을 부분 변경해서는 안 됩니다. 실제 프리코스나 최종 테스트 문제를 복제한 예제가 아닙니다.

먼저 테스트 이름을 성공하면 새 상태 반환, 같은 슬롯 재예약 거절, 잘못된 시간 거절, 빈 이름 거절, 실패 후 기존 상태 유지로 적습니다. 입력 정규화, 규칙 판단, 상태 생성, 출력 문자열을 분리할 이유가 여기서 나옵니다. 다음 JavaScript 함수는 프론트엔드 언어로 연습하는 예시이며 9기 사용 언어를 보장하지 않습니다.

function reserve(bookings, rawName, rawSlot) {
  const name = rawName.trim(), slot = rawSlot.trim();
  if (!name) throw new Error('empty name');
  if (!['18:00', '19:00'].includes(slot)) {
    throw new Error('unknown slot');
  }
  if (bookings.has(slot)) throw new Error('slot occupied');
  const next = new Map(bookings);
  next.set(slot, name);
  return next;
}

빈 Map에서 reserve(empty,' A ','18:00')는 18:00 → A를 담은 새 Map을 반환하고 empty는 그대로입니다. 그 반환값으로 B,18:00을 예약하면 오류가 나며 여전히 A가 남아야 합니다. B,20:00도 거절하지만 이유는 중복이 아니라 허용 시간입니다. 두 거절을 같은 테스트로 합치면 어떤 규칙이 깨졌는지 알기 어렵습니다. 로컬 Node 검산은 정상 저장·입력 정규화·중복 거절·잘못된 시간·빈 이름과 원본 보존을 확인하며 공식 시험 환경을 실행한 결과가 아닙니다.

변경 요구를 하나 넣어 봅시다. 이제 같은 사람의 여러 슬롯 예약을 금지한다면 기존의 슬롯 기준 중복 검사만으로는 충분하지 않습니다. 현재 이름 목록을 검사하는 규칙과 A,19:00 거절 테스트를 추가해야 합니다. 반대로 동일 이름이 다른 사람일 수도 있는 서비스라면 이름을 식별자로 삼는 계약 자체를 바꿔야 합니다. 객체나 함수 수를 늘리는 것보다 어떤 규칙이 어느 입력을 구별하는지 설명하는 일이 먼저입니다.

현장에서 다시 만들 코드의 범위 (Incremental rebuild)

완성된 대형 구조를 한 번에 복원하려 하지 마세요. 가장 작은 실행 가능한 핵심을 구현하고, 테스트를 돌린 다음 다음 요구사항을 추가합니다. 도메인 로직과 입력·출력, 예외 정책을 분리하면 규칙이 바뀔 때 수정 지점이 명확해집니다. 다만 시험의 실제 제출 환경이 제공하는 구조나 제한을 먼저 읽어야 합니다.

클린 코드라는 이름만으로 계층을 과도하게 만들 필요는 없습니다. 객체 수가 늘어도 각 객체가 서로의 상태를 중복 소유하면 변경은 더 어려워집니다. 공개 과정의 백엔드·프론트엔드 커리큘럼에서 설명하는 테스트, 리팩터링, 협업 학습을 자신의 미션 코드와 연결하고, 실제로 필요한 설계만 남기세요.

테스트를 통과시키고 경계에서 다시 읽기 (Boundary tests)

기본 정상 케이스 외에 빈 컬렉션, 단일 항목, 중복, 최솟값·최댓값, 잘못된 입력, 연속 호출을 확인합니다. 테스트가 실패하면 기대값이 요구사항과 맞는지부터 검토하고, 변경된 코드 주변과 연관 불변식을 함께 봅니다. 통과한 테스트 수를 성능이나 합격 가능성의 대리값으로 설명하지 마세요.

시간이 부족하면 테스트를 모두 제거해 코드를 빨리 쓰는 대신, 핵심 경계 2~3개를 선택해 보호하세요. 마지막 몇 분에는 전체 파일 구조, 미완성 TODO, 임시 출력, 제출 파일과 실행 결과를 확인합니다. 테스트 환경이 제공된다면 실행과 제출을 각각 완료했는지 구분합니다.

언어별 연습은 과정에 맞춰 좁히기 (Track language)

FAQ의 안내에 따라 백엔드 지원자는 Java, 프론트엔드는 JavaScript, Android는 Kotlin을 중심으로 연습합니다. 이것은 현재 FAQ에서 확인되는 일반 안내이고, 실제 회차에서 바뀐 안내가 있으면 공고가 우선입니다. 선택 언어에서 컬렉션 선택, 예외, 문자열 처리, 테스트 실행 방식을 반복해 손에 익히세요.

백엔드는 객체 책임과 도메인 규칙을 작은 테스트로 확인하는 연습을, 프론트엔드는 상태 변화와 입력 검증을 예측 가능한 함수로 분리하는 연습을 할 수 있습니다. Android는 선택한 과제의 언어·도구 요구를 확인해야 합니다. 여기서 말한 연습 포인트는 커리큘럼과 일반 개발 지식을 바탕으로 한 준비 제안이지 시험 출제 보장은 아닙니다.

모의 재구현 기록 (Rebuild evidence)

각 모의 세션에는 사용한 요구사항 요약, 첫 테스트 시각, 기능별 완료 상태, 발견한 반례, 마지막 코드 상태를 기록합니다. 다음번에는 같은 요구사항을 다시 읽고 설계를 바꾸되, 이전 풀이와 차이가 생긴 이유를 설명합니다. 결과물이 비슷해도 선택 이유를 설명하지 못한다면 아직 재현 가능한 이해로 보기 어렵습니다.

친구와 연습할 수 있다면 상대에게 조건 하나를 바꾸게 하세요. 변경이 생겼을 때 어떤 테스트와 객체가 영향을 받는지 먼저 말한 뒤 코드를 고치면, 단순 재현에서 요구사항 적응으로 나아갈 수 있습니다.

공식 안내로 마무리 점검 (Final checks)

지원 트랙, 일정, 최종 테스트 날짜, 장소, 언어, 시험 도구, 허용 자료, 제출 방식은 해당 기수 모집 안내와 응시 공지에서 확인합니다. FAQ의 일반 설명과 과거 모집 페이지를 구분하고, 오래된 날짜는 현재 날짜처럼 쓰지 않습니다. 온라인 연습 환경에서 브라우저·네트워크·실행 버튼이 달라질 수 있으므로 안내에 지정된 방식이 있으면 그 조건으로 연습하세요.

아래 질문은 미션 코드를 설계하고 테스트하는 연습에 활용할 수 있습니다. 공식 기출 또는 합격 예측 자료는 아닙니다.

프리코스 코드를 규칙과 테스트로 변환 (Rule-to-test mapping)

미션 제출물을 다시 볼 때 핵심은 파일을 통째로 외우는 일이 아닙니다. 요구사항 문장을 테스트 이름으로 나누고 정상 흐름, 거절 조건, 경계값을 구분합니다. 각 테스트마다 이 규칙은 어느 함수가 책임지는지, 실패하면 상태가 부분 변경되지 않는지, 같은 입력을 다시 처리해도 결과가 일관적인지 답해 보세요.

수정하기 어려운 코드를 만났다면 과거의 본인을 비난하기보다 변경이 잦은 규칙과 안정적인 세부사항이 어디서 섞였는지 찾습니다. 어떤 테스트가 취약해지는지 확인하고 가장 작은 추출로 개선합니다. 최종 테스트가 특정 설계를 요구한다는 뜻이 아니라, 이해를 확인하는 재구성 연습입니다.

트랙에 맞는 구현 예제를 선택 (Track practice)

공식 FAQ의 언어 안내를 확인한 뒤 선택 트랙의 기본 도구로 연습합니다. Java 백엔드는 객체 책임과 컬렉션, 예외·테스트 실행을, JavaScript 프론트엔드는 객체·배열 변환과 상태 변화, 테스트를 연습 대상으로 둘 수 있습니다. Kotlin Android는 선택한 언어의 null 처리와 컬렉션, 함수 분리를 점검할 수 있습니다. 이는 학습 제안이지 테스트 출제 예측은 아닙니다.

어떤 트랙이든 첫 테스트를 빠르게 실행하고 점진적으로 기능을 넓히는 흐름은 유용합니다. 그러나 언어 일반 안내와 개인이 예상하는 라이브러리 사용 가능 여부를 섞지 마세요. 실제 테스트 화면과 해당 기수 모집 공지가 허용 도구의 근거입니다.

90분은 연습용 시나리오로만 쓰기 (Mock timebox)

공식 시험 시간이 확인되지 않았으므로 다음 시간 배분은 모의 연습 예시일 뿐입니다. 90분을 잡는다면 처음 10분은 계약과 설계, 다음 50분은 핵심 구현, 20분은 경계 테스트, 마지막 10분은 제출 상태와 설명에 쓸 수 있습니다. 실제 공지가 다르면 공지된 시간에 맞춰야 합니다.

모의 중간에 조건 하나를 바꾸어 보세요. 가격 계산에서 환불 항목을 제외해야 한다면 어떤 테스트와 함수가 영향을 받는지 먼저 설명합니다. 변경된 규칙의 영향 범위를 말한 뒤 수정하면 정답 코드 암기 대신 설계의 경계를 검증하게 됩니다.

제출 직전의 자체 리뷰 (Submission review)

컴파일 또는 테스트 결과, 임시 출력문, 누락된 파일, 미완성 TODO를 확인합니다. 복잡한 메서드 이름이 실제 규칙을 설명하는지, 예외 메시지가 실패 원인과 맞는지, 같은 상태를 여러 객체가 중복 소유하지 않는지도 살핍니다. 마지막에는 제출 안내에서 요구한 형식과 파일을 다시 확인합니다.

통과한 테스트와 아직 검증하지 않은 동작을 구분해 적으세요. 코드가 완벽하다고 주장하기보다 확인 범위를 정확히 설명하면 재현 가능한 검토가 됩니다. 공식 안내에서 제출 방식이나 작업 환경을 특정하면 그 지침이 이 일반 체크보다 우선합니다.

다음 기수 안내를 확인하는 시점 (Next notice)

현재 지원 안내의 9기 발표 예고와 기존 FAQ는 서로 다른 종류의 정보입니다. FAQ의 기존 운영 방식이나 과거 8기 일정은 새 모집의 확정 조건을 대신하지 않습니다. 지원할 때는 모집이 열렸는지, 트랙별 조건과 프리코스 제출 방식, 최종 테스트 장소·시간이 업데이트되었는지 공식 페이지에서 다시 확인합니다.

최종 준비일에는 문제 풀이뿐 아니라 실제 언어의 테스트 실행과 오류 읽기도 연습하세요. 오프라인 기본 원칙에도 예외 가능성이 FAQ에 적혀 있으므로 장소와 방식은 본인에게 전달된 최신 안내로 정합니다.

준비 흐름을 한눈에 보기 (Workflow)

질문으로 연습하고 최신 안내로 조정 (Practice questions)

아래 공식 페이지를 다시 확인한 뒤, 발표된 조건에 맞춰 모의 세션을 조정하세요. 연습 질문은 지원 프로그램의 기출이나 합격을 보장하지 않습니다.

Sources and Further Reading

• 우아한테크코스 공식 FAQ
• 우아한테크코스 현재 지원 안내와 9기 공지 예고
• 우아한테크코스 교육과정

자료 범위: 공식 출처는 공개된 과정·모집 안내를 뒷받침합니다. 후보자 보고는 수집되지 않았고 실습 상황은 교육용 합성 예시입니다. 기수별 일정과 응시 규칙은 최신 공고와 본인에게 전달된 안내로 확인하세요.