Prompting (수정중)
FDE 세션 'Prompting' 편이 개념(지시형 vs 제안 요청형)이라면, 여기선 4개 실세션 대화를 따라가며 그 패턴이 어떻게 굴렀는지 본다.
1. 케이스 A: "어떻게 해야 할까" (위임형, 전면 채택)
사용자는 방법을 정하지 않고 목표만 줬다.
USER >>> golden 프로젝트에 최신 standarda template 을 적용하고 싶은데 어떻게 해야 할까
Claude 는 바로 실행하지 않았다.
- 방향부터 교정: 사용자가 떠올렸을
/sync-template이 반대 방향(프로젝트→템플릿)임을 짚었다. - diff 전수조사: 공통 파일 차이를 전부 떠봤다.
- 위험도 등급화: A(안전·고가치) ~ D(공통 Django 앱, User 모델 필드 충돌로 위험, 권장 안 함)로 묶어 선택지로 제시했다.
사용자는 A+B+C(D 제외)를 골랐고, 반영 중 B 는 golden 이 더 최신이라 건너뛰었다. 한 번 통한 흐름은 재사용 자산으로 승격됐다(기존 프로젝트에 템플릿을 반영하는 스킬 신설 → ES05L01).
교훈: "어떻게 해야 할까" 한 줄이 방향 교정 → 전수조사 → 등급화 → 실행 → 재사용 스킬로 굴렀다. 해결책을 미리 정했다면(예: "공통 파일 다 복사해줘") D 등급을 덮어 운영 DB 가 깨졌을 것이다.
2. 케이스 B: "너는 어떻게 생각하니" (데이터 첨부형, self-correction)
사용자가 자기 해결책(풀 위키 + 룰 문서)을 들고 의견을 물었다. 문제 + 재현 예시 + 자기 가설 + 참고 자산을 모두 줬다.
Claude 는 코드로 원인을 재현하고, 방향엔 동의하되 역할을 분리해 제안했다. 결정적 장면은 사용자가 "풀 위키로 가자"고 지시했을 때다.
ASSISTANT >>> 핵심 데이터가 나왔고 설계를 바꿉니다.
엔티티 메모리 총합 51행(전 조직), 조직당 평균 17행(~3.3KB). 이미 전부 통째로 주입 중입니다.
50행 데이터에 새 모델 + 임베딩 인덱스 + 룩업 머신을 짓는 건 과설계입니다.
사용자가 "경량과 풀 위키의 차이가 뭐냐"고 되물었고, Claude 는 정직한 트레이드오프로 답했다. 생성 풍부함은 결국 LLM 에 주입되는 텍스트의 양이라 경량+로도 동등하며, 그래프·편집 UI 가 별도 목적일 때만 풀 위키가 값어치가 있다고 갈랐다. 사용자는 "경량+ 쪽인 것 같다"로 결론지었다.
교훈: 자기 가설이 있어도 "만들어줘"가 아니라 "이 방향 어때?"로 열었기에, Claude 가 데이터(51행)를 근거로 더 작은 답을 밀어붙일 수 있었다.
3. 케이스 C: "어떤 방식이 좋을지 제안해줘" (조사 후 범위 축소, 배포까지)
USER >>> 사용자가 생성된 회의록을 직접 편집하는 기능, 어떤 방식으로 구현하면 좋을지 제안해줄래
Claude 는 처음부터 설계하지 않고 현재 코드를 먼저 읽었다.
- 발견: 저장 백엔드(
PATCH .../minutes/)와 부분 편집 선례가 이미 있어 "80% 완성" 상태. - 제안: 선택지를 늘어놓는 대신 단일 추천안(편집 모드 토글, raw 마크다운) + 결정해야 할 3가지(버전 일관성·포맷 깨짐·동시성).
사용자가 "백로그 기록 → /develop 구현 → /release 배포"로 마무리를 명시해 프로덕션까지 갔다.
구현 중 Claude 는 요청에 없던 개선(저장 로직 공통화, 낙관적 동시성 가드)까지 넣었다.
교훈 둘: (1) "제안해줘"는 Claude 를 먼저 조사하게 만든다. 추측이 아니라 코드를 읽어 범위가 줄었다. (2) 마지막 한마디("배포해야지")가 결과를 끝맺는다. 안 하면 working tree 에 남는다.
4. 케이스 D: "안전하게 관리할 수 있을까" (프레임 뒤집기, 전면 채택)
USER >>> 카드 번호를 서버에서 안전하게 관리할 수 있을까? 제안해줘
Claude 는 계획 전에 스펙 숫자를 실제 데이터로 대조하고, "안전하게 관리 = 잘 암호화해 저장"이라는 암묵적 프레임을 뒤집었다.
ASSISTANT >>> 핵심: 전체 PAN 은 애초에 필요가 없다.
분류 로직이 쓰는 건 뒤 4자리뿐. 들어오자마자 last4 로 줄이면(truncate-at-ingestion)
전체 PAN 을 저장하지 않아 PCI-DSS 스코프 밖으로 나간다. 가장 안전한 PAN 은 저장하지 않는 PAN.
5단계(P0~P4) 전부 실행, E2E 에서 16자리 PAN 0건·자동분류 정답일치 100% 로 스펙을 재현했다.
교훈: 사용자는 "어떻게 안전하게 저장하지"를 물었지만 Claude 는 "저장 안 하면 된다"로 답했다. 제안 요청형은 질문 자체를 더 나은 질문으로 바꿀 여지를 준다.
5. 패턴 정리
두 갈래의 제안 요청형:
| 위임형 (A·C·D) | 데이터 첨부형 (B) | |
|---|---|---|
| 사용자가 가진 것 | 문제·제약·목표 | 문제 + 데이터 + 자기 가설 |
| 전형적 발화 | "어떻게 해야 할까", "제안해줘" | "이렇게 하면 어떨까, 너는 어떻게 생각하니" |
| Claude 의 여지 | 구조(등급·계층·단계)를 세움 | 가설을 데이터로 반박/축소 |
좋은 제안을 받은 4세션에서 Claude 가 공통으로 한 5가지:
- 먼저 조사하고 제안한다. 추측이 아니라 코드·데이터를 읽고 근거를 만든다.
- 가정·프레임을 뒤집는다. B(과설계), C(이미 80%), D(저장 안 하면 됨), A(방향이 반대).
- 선택지를 구조화한다. 등급(A)·계층(B)·단계(D)·단일추천+결정포인트(C).
- 정직한 트레이드오프를 말한다. B 에서 경량+와 풀 위키의 차이를 솔직히 갈랐다.
- 중복·위험을 먼저 경고한다. A(D 등급 위험), B(기존 pending 과 겹침).
6. 그래서 프롬프트를 줄 때
- 해결책이 안 보이거나 내 방법이 최선인지 모르면, 지시하지 말고 "어떻게 하면 좋을지 제안해줘"로 연다.
- 데이터·스펙·예시가 있으면 같이 준다. 제안 품질은 조사 가능 여부에 달렸다(D 의 통찰은 데이터에서 나왔다).
- 자기 가설이 있어도 "만들어줘"가 아니라 "이 방향 어때?"로 묻는다. 틀렸을 때 되돌릴 길이 열린다(B).
- 마지막에 마무리를 명시한다. "제안해줘"로 시작했으면 끝에 "구현·배포까지"를 붙인다(C).
마무리
- 핵심 정리: 제안 요청형은 위임형(A·C·D)과 데이터 첨부형(B)으로 갈린다. 어느 쪽이든 해결책을 미리 못 박지 않았기에 Claude 가 조사·프레임 전환·구조화로 더 낫거나 더 작은 답을 끼워 넣었다.
- 주의 사항: (1) 확신 없는 해결책을 지시형으로 던지지 않는다. (2) "제안해줘"로 끝내지 말고 마무리(구현·배포)를 시킨다.
- 다음 시간: 합의한 해결책을 실제로 굴리는 /develop 한 사이클.