JIN.PROC // v3.1
~/ / AI 활용법 / 2026-04-29-ai-guide-14-response-protocol

[AI 활용법 14] 응답 프로토콜과 작업 보고 형식

모호하면 묻는다. 복잡하면 계획→승인→진행. 끝나면 한 자리 같은 형식으로 보고

DATE 2026.04.29 UPDATED 2026.04.29 READ ~ 4 MIN WORDS 626

시리즈 14편(완결). LLM의 응답 품질 만큼 중요한 게 응답 형식 이다. 같은 결과도 어떻게 보고하느냐 에 따라 다음 작업이 달라진다.

요청 해석 — 모호하면 묻는다

LLM의 첫 결정: 들어온 요청이 명확한가, 모호한가.

명확함의 신호 모호함의 신호
구체적 입출력 명시 “잘 만들어 줘”
영향 파일/모듈 지정 “어디든”
완료 기준 분명 “쓸 만하게”
하나의 변경 단위 여러 의도가 섞임

모호하면 즉시 시작하지 않고 가장 짧은 질문을 한다. 3개 이하의 질문으로 핵심을 좁힌 뒤 시작.

사용자: "이 페이지 좀 다듬어 줘"
AI:   다음 셋만 짧게 확인할게요:
       1) 다듬는 단위는 _시각 디자인_ vs _코드 구조_ 중 어디?
       2) 모바일 대응도 함께 봐야 하나요?
       3) 변경 범위는 이 파일만? 컴포넌트까지?

명확하면 즉시 착수

질문을 남발 하지 않는다. 명확한 요청에 추가 질문을 던지면 느려지고 짜증난다. 다음 패턴은 좋은 디폴트:

  • 단순 요청 → 즉시 실행, 한 줄 결과 보고
  • 중간 복잡도 → 계획 한 단락 → 즉시 실행
  • 고복잡도 → 계획 → 승인 → 실행

계획 → 승인 → 진행

복잡한 작업은 시작 전에 계획을 공유 한다. 사용자가 다른 방향 을 원하면 아직 코드를 안 만졌으니 비용이 0.

좋은 계획의 5요소:

  1. 목표 — 무엇을 달성
  2. 단계 — 순서가 있는 N개의 작업
  3. 영향 범위 — 어떤 파일/모듈
  4. 리스크 — 알려진 함정
  5. 완료 기준 — 어떻게 다 됐다 고 부르는가
[계획]
목표: OAuth 로그인을 PKCE 흐름으로 전환
단계:
  1. authcode flow 호출부 → PKCE generator 추가
  2. 서버 측 검증: code_challenge_method=S256
  3. 단위 테스트 + e2e 1건
  4. README 환경변수 섹션 갱신
영향: src/auth/*, tests/auth/*, README.md
리스크: 기존 implicit flow 클라이언트가 있으면 deprecation 경로 필요
완료 기준: PKCE e2e 통과 + 단위 90%+

승인을 받은 에만 코드 변경.

중간 보고 — 계획 변경

진행하다가 계획에 없던 결정 이 필요하면, 즉시 보고:

중간 보고: 위 단계 2 진행 중,
src/auth/legacy.py가 implicit flow를 직접 사용 중인 것을 발견.
다음 옵션:
  A) 이 파일도 같은 PR에 포함 — 범위 확대
  B) 별도 PR — 이 PR은 신규 PKCE만
어느 쪽으로 갈까요?

LLM이 혼자 결정 하는 게 아니라 드러내고 묻는다. 이 패턴 하나가 PR 리뷰의 80% 를 사전에 해결.

작업 보고 형식 — 6개 항목

작업이 끝났을 때, 다음 6개를 같은 자리에 항상:

1. 무엇을 했는가
   - 변경 파일 N개, 커밋 X개 (해시)
2. 무엇을 하지 않았는가 / 남은 작업
   - 의도적으로 미뤄둔 것
3. 가정·한계
   - mock 여부, 검증 여부
4. README 갱신 여부
   - O/X + 이유
5. 다음 권장 행동
   - 후속 PR, 리뷰 포인트, 검증 절차
6. 기록 위치
   - Obsidian 경로, 커밋 해시, ADR 링크

이 형식이 고정 되면, 사용자가 필요한 정보를 어디서 찾을지 알게 된다. 응답이 매번 다른 구조면 매번 다시 찾아 야 한다.

과도한 꾸밈 지양

LLM은 수사 를 잘 만든다. 응답이 길수록 잘한 것처럼 느껴지는 함정. 다음을 막자:

  • ❌ “훌륭한 질문입니다”, “정말 좋은 접근이에요” (의미 없는 칭찬)
  • ❌ 매 답변에 이모지 5개
  • ❌ “결론적으로 / 요약하면” 류 결론을 3번 반복
  • ❌ “이 부분이 매우 중요합니다” — 코드를 보고 판단하게 두자

핵심 중심, 간결하게. 응답이 짧아도 할 일을 했다 면 좋은 응답.

침묵하지 말 것

반대로 아무 보고도 없이 끝내지도 마라. 작업이 끝났는데 무엇을 했는지 안 보이면 사용자가 다시 물어야 한다. 할 일 했고, 위 6개로 보고 끝.

응답 형식의 예시 — 길이별

짧은 답 (단순 요청):

변경: src/utils.py에 lower() 추가. 테스트 통과.

중간 답 (한 PR):

변경: 3 files, 1 commit (a1b2c3d).
- src/auth/pkce.py 추가
- src/auth/__init__.py 등록
- tests/auth/test_pkce.py: 5 tests, all pass
README: 환경변수 섹션 갱신.
다음: implicit flow deprecation은 별도 PR.

긴 답 (복잡한 일): 위 6개 항목 모두 + 단계별 진행 + 발견된 이슈 + 후속 권장.

한 줄 요약

응답의 품질 만큼 형식 이 중요하다. 모호하면 질문, 복잡하면 계획, 끝나면 6항목 보고.


이전 편: AI 활용법 13 — Tool 사용 전략

AI 활용법 시리즈 진행 (14편)

  1. 정직성
  2. 컨텍스트 관리
  3. 자율모드
  4. 가드레일
  5. Git 워크플로우
  6. ADR
  7. 모듈화 임계값
  8. 성능 예산
  9. UI의 5가지 상태
  10. 모바일 퍼스트 + 접근성
  11. 보안과 시크릿 관리
  12. 문서화 3계층
  13. Tool 사용 전략
  14. 응답 프로토콜