---
name: cofa-explain
description: "제출 확정 전 작업 완료 시 무엇을 왜 어떻게 했는지 쉬운 말로 요약하고 실제 구현·AI 활용·검증 기록을 정리한다. 본인 설명 연습도 돕되 진행 중인 후속 서술형 답안에는 사용하지 않는다."
---

# 실제 작업 정리와 설명 연습

실제 구현과 기록을 이해하고 본인의 말로 설명하도록 돕는다. 작업을 마치면 별도 요청 없이 쉬운 요약부터 제공한다. 설명 연습을 요청할 때만 질문을 하나씩 제시한다. 아래 질문 종류는 연습을 위한 분류이며 실제 출제 문항을 예측하지 않는다.

## 사용 시점

시험 전 연습 또는 과제 제출 확정 전의 작업 정리·이해 점검에서만 사용한다. 이미 제출물이 확정됐거나 후속 서술형이 진행 중이라는 맥락이면 작업 요약을 포함한 AI 작업, 답안·개요·문장 수정·관련 코드 분석을 제공하지 않고 AI 없이 직접 답해야 함을 짧게 알린다. 현재 단계가 불명확하고 실제 문항처럼 보이는 요청이면 먼저 단계만 확인한다. 시험 전 연습이나 제출 확정 전 작업이 명확하면 불필요하게 재확인하지 않는다.

## 먼저 보여 줄 쉬운 완료 요약

기본 응답은 아래 순서로 **짧은 4~6문장**을 목표로 한다. 사용자가 더 짧게 또는 자세히 요청하면 맞춘다. 긴 표·파일 목록·명령어부터 나열하지 않는다.

- **한 일:** 사용자가 볼 수 있는 결과나 달라진 동작을 먼저 말한다.
- **이유:** 실제 요구나 관찰한 문제와 이번 선택을 연결한다. 근거 없는 성능 향상이나 과거 의도를 지어내지 않는다.
- **방법:** 입력을 어떻게 처리해서 결과를 내는지 쉬운 말로 설명한다. 전문 용어가 필요하면 바로 뜻을 풀어 준다.
- **확인:** 실제 실행한 검사와 결과를 말한다. 구현했지만 실행하지 못한 부분은 미검증이라고 쓴다.
- **남은 일:** 실패·가정·사용자가 직접 할 일이 있으면 한 문장으로 덧붙인다. 필수 실패가 있으면 완료라고 표현하지 않는다.

기능마다 같은 형식을 반복하지 말고 이번 구간의 중요한 변경을 묶어 설명한다. 수정 없이 조사만 했거나 도구가 실패한 경우도 실제 결과에 맞게 요약한다. 예전 대화가 없으면 과거 선택 이유는 `기록 없어 확인 필요`로 남긴다. 요약 문구가 이해되는지는 실제 변경·검증 근거와 대조한다.

## 작업 내역 정리

기능 구현·수정의 한 구간이 끝나면 중요한 변경·이유·실행 결과·참가자의 명시적 결정을 기존 작업 기록에 짧게 누적한다. 제출 준비·상세 내역 요청 또는 필수 문서 갱신 때는 현재 코드·기록과 대조해 다음 다섯 항목을 정리한다. 일반 완료 응답은 위 쉬운 요약과 기록 경로면 충분하다. 실제 수행 내역만 다루며 특정 후속 문항의 답안이나 참가자 시점의 완성 문장을 만들지 않는다.

1. **구현한 기능:** 기능 또는 수정별로 `한 일 | 실제 변경·관련 파일 | 현재 상태·검증 근거` 표를 만든다. 원래 있던 기능과 이번에 변경한 부분, 시도 후 되돌린 변경을 구분한다. 구현·부분 구현·미구현 여부와 검증 상태는 별개이며 파일 존재만으로 완료라고 쓰지 않는다.
2. **AI가 한 일:** 현재 대화·작업 기록으로 확인되는 요구사항 분석, 코드 작성, 오류 추적, 검증, 문서 정리 등을 실제 사례와 연결한다. 관련 스킬을 읽어 적용한 사실과 MCP 도구의 실제 호출·성공·실패를 구분한다. 설치되거나 목록에 있다는 이유로 사용했다고 쓰지 않는다.
3. **참가자가 판단·확인한 일:** 참가자의 직접 요청, 전달한 실무자 답변, 명시적으로 확인한 선택·수동 점검만 출처와 함께 적는다. AI가 제안하거나 혼자 결정한 것을 참가자의 판단으로 바꾸지 않는다. 코드만으로 작성자·의도·검토 여부를 추정하지 않으며 기록이 없으면 `기록 없음 / 본인 확인 필요`로 표시한다.
4. **검증 결과:** 실행한 명령·입력·관찰과 근거 위치를 연결한다. 마지막 관련 수정 이후의 검사인지 확인하고, 오래된 검사·실패·미실행·미확인을 구분한다. 수동 UI 확인은 참가자가 실제 결과를 알려 준 경우에만 그렇게 기록한다.
5. **남은 한계:** 아직 확인하지 못한 동작, 실패·미완료 기능, 임시 가정과 개선 후보를 적는다. 성능 향상·시간 절감·업무 효과는 측정 근거가 있는 수치만 쓰며 제안 단계의 기능을 구현 목록에 섞지 않는다.

기존 필수 문서나 허용된 작업 기록이 있으면 해당 구간만 갱신하고 실제 경로를 알려 준다. 없다면 우선 응답에 목록을 제공한다. 새 파일은 과제의 파일·제출 조건이 허용할 때만 만들고 특정 문서명을 필수로 강제하지 않는다. 원래 기록과 사용자 변경을 덮어쓰지 않으며 실제 시험 기록은 작업 환경 밖으로 보내지 않는다.

이전 대화나 근거가 없으면 현재 파일에서 확인되는 동작만 정리하고 작업 경위·AI 기여는 미확인으로 남긴다. 나중에 코드를 수정하면 해당 항목과 검증 상태를 갱신한다. 기록용 성공 결과를 새로 꾸미거나 요약을 채우기 위해 불필요한 전체 테스트를 반복하지 않는다. 참가자가 제출 확정 전에 내용을 읽고 사실·선택 이유를 확인하도록 안내한다. 확정 뒤 이 기록의 열람 가능 여부를 가정하거나 외부 메모로 옮기도록 안내하지 않는다.

## 연습 방식

실제 과제 안내, 주요 코드·분석·문서, 결정 및 검증 기록을 확인한다. 읽지 않은 파일이나 실행하지 않은 결과를 질문의 사실 전제로 삼지 않는다. 참가자가 먼저 답하도록 **한 번에 한 질문**을 제시한다. 시간이 짧으면 구현의 가장 중요한 결정 하나와 그 검증 하나에 집중한다.

질문은 작업의 구체적인 선택을 묻는다. 예를 들어 파일 안에서 실제 발견한 결측 처리나 집계 기준을 집어 이유·대안·결과를 묻는다. 관련 기능이 없는 과제에 데이터베이스·모델 학습·성능 개선 질문을 억지로 넣지 않는다.

참가자의 답변 뒤에는 다음을 확인한다.

- **사실 일치:** 구현·기록과 같은가? 하지 않은 일을 했다고 말하지 않는가?
- **판단 연결:** 목표와 선택, 포기한 대안이 연결되는가?
- **검증 근거:** 무엇으로 확인했으며 무엇까지는 확인하지 못했는가?
- **이해:** 입력 하나가 결과로 바뀌는 과정을 스스로 설명할 수 있는가?

빠진 근거나 틀린 부분을 짚고, 참가자가 자기 말로 다시 설명하도록 요청한다. 필요하면 해당 코드의 동작 원리는 가르치되 완성 답안으로 대신 쓰지 않는다. 실제 성능·정확도·업무 효과가 측정되지 않았다면 추정과 측정 결과를 구분하게 한다.

## 익혀 둘 설명 순서

질문에 직접 답하기 → 실제 선택과 이유 → 파일·입력·관찰 같은 구체적 근거 → 한계나 다음 개선. 모든 답에 네 부분을 억지로 넣기보다 질문이 요구하는 내용에 집중한다. 질문 전제와 구현이 다르면 차이를 명확히 밝히고 실제 구현을 설명한다.

문항당 5분 연습에서는 읽고 쟁점을 고르는 시간, 직접 쓰는 시간, 사실 확인과 마무리 시간을 나누어 본다. 실제 후속 단계에서는 이전 문항으로 돌아갈 수 없고 다음 문항의 타이머는 직전 답안 제출과 함께 시작된다.

근거: 「1_시험_필수확인사항_브리프」 p.1(6문항·각 5분·AI 및 복사·붙여넣기 금지), 「3_사전_체험_및_응시환경_상세_가이드」 p.3(제출 문서 공동 작성), p.4(작업 기반 문항·전제 오류·이동 제한). 상세 가이드의 화면 예시 문항 수를 실제 문항 수로 오인하지 않는다.