---
name: cofa-build
description: "Cofa 과제의 필수 기능을 구현하거나 기존 코드의 오류를 재현·수정한다. 기존 API 계약과 실행법을 유지하며 작은 변경을 검증할 때 사용한다."
---

# 핵심 흐름부터 완성하기

제출 확정 전용이다. 확정 후에는 질문 준비 대기 중에도 이 스킬과 AI 작업을 중단한다.

먼저 현재 코드·제공 데이터·요구사항과 남은 시간을 확인한다. 기존 프로젝트의 실행법, 의존성, 테스트 구조를 유지할 수 있으면 유지한다. 스택 교체나 새 프레임워크는 현재 문제를 해결하는 이득이 설치·통합 비용보다 클 때만 고려한다.

**기존 서비스·API·스크립트의 오류 수정이면 먼저 [기존 프로젝트 수정 절차](references/existing-project.md)를 읽는다.** 변경 전 재현, 유지할 계약, 실패를 잡는 회귀 테스트, 최소 수정, 수정 후 정상·실패 검증을 연결한다. 새 프로젝트에만 맞는 구현 순서를 강제하지 않는다.

## 구현 단위

**입력 → 핵심 처리 → 사용자에게 필요한 출력 → 확인 가능한 결과**가 이어지는 작은 흐름을 먼저 완성한다. 필요한 것은 실제 동작이며, 고정된 예시 출력으로 성공처럼 보이게 만들지 않는다. 샘플이나 모의 데이터는 표시하고 실제 입력 경로와 구분한다.

과제에 따라 검증 단위를 바꾼다.

| 유형 | 먼저 끝낼 흐름 | 확인 방법의 예 |
| --- | --- | --- |
| 기존 코드·API 수정 | 기존 실패 재현 → 원인 확인 → 최소 수정 → 같은 검사 | 재현 사례가 수정 후 통과하고 관련 정상 동작·API 계약이 유지됨 |
| 데이터·분석 | 파일 읽기 → 정제 → 핵심 지표 → 해석 | 작은 수작업 표와 합계·분모·단위 대조 |
| 알고리즘·자동화 | 입력 → 처리 → 요구 형식 출력 | 정상·경계·실패 입력과 기대 결과 비교 |
| 서비스·화면 | 실제 입력 → 처리·저장 → 결과 확인 | 핵심 동작을 사용자가 직접 수행하고 새로고침 후 상태 확인 |
| 문서·의사결정 | 근거 → 대안 비교 → 선택 → 실행안 | 각 결론의 자료 위치·가정·한계 확인 |

첫 흐름이 동작한 뒤 필수조건을 넓힌다. 추가 기능은 필수 요구 충족, 오류 가능성 감소, 핵심 결과의 전달 중 어느 것에 기여하는지 판단한다. 시간이 부족하면 장식·새 연결·새 추상화보다 누락된 필수조건과 잘못된 결과를 고친다.

첫 구현 뒤에는 실제 요구·참가자 피드백과 비교해 가장 큰 남은 문제를 골라 **수정 → 관련 검증 → 기존 동작 확인**을 이어간다. 화면·설명이 마음에 들지 않는다는 피드백도 관찰 가능한 기준으로 바꾸며, 유지할 기능·계산·데이터 형식은 보존한다. 같은 대화에서 이미 맡긴 수정은 계속 진행한다. 합의한 기준이 충족되고 새 개선 근거가 없거나 참가자가 정한 개선 중단 시각이면 새 변경을 멈추고 최종 검사·문서·저장으로 전환한다. 실패나 미검증을 완료로 표현하지 않는다.

## AI에 맡기고 확인하기

작업 요청에는 목적, 수정 범위, 제약, 완료 확인법을 준다. 긴 설계 설명을 반복 생성하지 말고 파일과 실행 결과로 진행 상태를 확인한다. 병렬 작업을 쓸 수 있는 제공 환경이라면 같은 파일을 동시에 수정하지 않는 독립 작업에만 한정한다. 병렬 실행이 허용된 기능인지 불명확하면 단일 세션으로 진행한다.

병렬 작업을 실제로 쓴다면 수정 파일의 담당을 구분하고 한 곳에서 통합한다. 각 작업의 성공만으로 전체 성공을 선언하지 않고 통합된 파일에서 관련 검사를 실행한다.

중요한 선택을 할 때는 선택 이유·포기한 대안·관련 요구사항을 짧게 남긴다. AI가 제안한 코드를 그대로 이해했다고 주장하지 않는다. 구현한 주요 분기와 한계를 참가자가 설명할 수 있도록 변경 후 짧게 해설한다. 테스트 결과나 성능 수치는 실제 실행한 관찰만 기록한다.

기능 구현·수정 구간이 끝나면 기존 작업 기록에 이번 변경·AI가 수행한 일·참가자가 명시적으로 결정/확인한 일·관련 파일·검증 상태를 짧게 남긴다. 기존 기능을 이번 성과로 바꾸거나 AI의 선택을 참가자의 판단으로 기록하지 않는다. 되돌린 시도와 최종 구현을 구분해 제출 전 사실 정리에 활용한다.

외부 코드를 일부 참고했다면 출처, 사용한 부분, 변경 사항을 기록한다. 미리 만든 완성 결과물로 제출물을 대체하지 않는다. AI로 작성 가능한 계획·협업 문서도 실제 작업과 일치하게 갱신한다.

## 시간과 실패 처리

### Probe에서 실행·저장하기

- 기존 프로젝트의 실행법을 확인한 뒤 서버를 `0.0.0.0`에 바인딩한다. 실제 실행 포트·경로·참가자가 확인할 핵심 동작을 알려 준다. 참가자는 왼쪽 Browser의 PORT → URL 경로 → 원형 화살표 순서로 연결한다. `3000`을 필수 포트로 가정하지 않는다.
- Codex와 서버용 터미널을 구분하고 서버 탭을 유지한다. CPU/RAM과 본인 프로세스를 확인해 서버·테스트·대형 분석을 중복 실행하지 않는다. 플랫폼 관리·감독 프로세스를 종료하지 않는다.
- AI가 바꾸는 파일을 참가자가 에디터에서 동시에 편집하지 않도록 안내한다. 충돌이면 양쪽을 비교한 뒤 `외부 변경 불러오기`(디스크 내용을 편집기로) 또는 `현재 내용으로 저장`(편집기 내용을 디스크로)을 본인이 선택하게 한다. 무조건 덮어쓰도록 안내하지 않는다.
- 파일 생성 뒤 탐색기 목록이 늦으면 새로고침, 제출 전에는 `저장됨` 확인을 안내한다. 한 영역만 멈추면 화면에 표시된 `이 영역 다시 불러오기`, 터미널 문제는 `다시 연결`을 먼저 검토한다. 전체 새로고침 전에 미저장 여부를 확인한다.

구현·수정 구간을 마칠 때는 별도 요청을 기다리지 않고 **한 일 → 왜 필요한지 → 어떻게 바꿨는지 → 실제 확인 결과·남은 한계**를 쉬운 말로 4~6문장 안팎으로 설명한다. 사용자에게 보이는 동작부터 말하고, 파일명·명령 목록은 필요한 근거만 덧붙인다. 실패·미검증을 완료로 표현하지 않는다.

작업 최대 180분과 실제 남은 시간을 구분한다. 제출 시작을 위한 마지막 10분을 확보하고, 그 전에 핵심 검증과 설명 점검을 끝낼 수 있도록 범위를 줄인다. 이는 준비 키트의 운영 제안이며 공식 세부 배점이나 강제 단계가 아니다.

작업 타이머와 전체 응시 마감은 별개다. 참가자가 알려 준 실제 전체 마감까지 서술형·질문 준비·마지막 업로드 여유도 남긴다. 늦게 시작했을 때 180분 전부를 구현에 배정하지 않는다.

오류는 재현 가능한 가장 작은 입력과 첫 원인부터 추적한다. 한 번에 여러 가설의 수정을 섞지 않는다. 같은 설치·연결 문제가 반복되면 기존 도구나 단순한 구현으로 목표를 달성할 방법을 검토한다. 플랫폼 차단이나 모델 오류는 우회하지 않고 발생 시각과 오류를 문제 신고에 전달하도록 안내한다.

## 응시 환경의 경계

제공된 Codex와 허용 모델만 사용하고, 개인 API 키·외부 모델·Git Push·문제 및 결과물 외부 전송을 사용하지 않는다. UI 확인은 참가자가 플랫폼 Browser에서 직접 수행한다. 이 키트는 Computer Use 금지에 맞춰 Playwright·Selenium·브라우저 MCP 자동 조작을 사용하지 않는 보수적 방식을 택한다. 후속 서술형 단계에 들어가면 AI 작업을 중단한다.

근거: 2026-11-04 재응시판 「1_시험_필수확인사항_브리프」 p.1(시간·제한), 「3_사전_체험_및_응시환경_상세_가이드」 p.2(터미널), p.3(Browser·저장·제출), p.5(자료·모델·복구). 브라우저 테스트 도구별 허용 여부가 별도로 설명된 것은 아니므로 필요하면 사전 체험에서 운영 측에 확인한다.