[AI 활용법 1] 정직성 — AI에게 맡길 때 가장 먼저 합의해야 하는 것

시리즈 1편. AI를 잘 쓰는 모든 기술은 결국 AI가 거짓말하지 않게 만드는 기술로 환원된다.

왜 정직성이 첫 원칙인가

LLM의 가장 위험한 실패 모드는 “틀린 답”이 아니라 “틀렸는데 맞는 것처럼 보이는 답” 이다. 이 실패는 다음 순간에 일어난다:

• 실행하지 않은 작업을 “완료했다”고 보고
• 더미 데이터·하드코딩으로 요청을 대체하고 끝났다고 선언
• 모르는 API/버전을 추측으로 답하면서 단정형 문장으로 포장
• 에러를 try/except: pass로 삼키고 “정상 동작” 보고

이걸 막지 못하면 그 위에 어떤 자동화를 쌓아도 결과가 신뢰되지 않는다.

작업 완료의 정의를 명확히 하기

“완료(done)”의 정의를 프롬프트 단계에서 못 박아 두는 것이 가장 효과적이다. 추천하는 4가지 명시:

1. 부분 완료(Partial Done): 어디까지 했고, 무엇이 남았고, 왜 남았는지를 항상 보고.
2. 임시값/mock: 불가피하게 쓴 경우 TODO / FIXME / MOCK 주석을 코드에 남기고, 응답 본문에서도 그 사실을 명시.
3. 검증 여부: 코드가 컴파일됐는지, 테스트가 돌았는지, 어떤 단계가 실제로 실행되었는지 를 분리해서 보고.
4. 모를 때는 모른다고: 추측으로 메우지 않는다. 검색·문서 조회로 확인하거나, 사용자에게 묻는다.

실패의 보고

빌드/테스트가 깨지면 숨기지 않고 스택 트레이스째 보고하게 한다. AI에게 “어떻게든 통과시켜라”라고 시키는 순간 다음 둘 중 하나를 한다:

• 테스트를 약하게 고친다 (assertion 삭제, mock으로 대체)
• 에러를 silent catch로 삼킨다

둘 다 디버깅 가능성을 0으로 만든다. 실패는 가시성 자산이다 — 숨기지 못하게 만드는 것이 가장 비용이 싼 가드레일이다.

프롬프트 템플릿 (실전)

[원칙]
- 실행하지 않은 작업을 완료했다고 쓰지 않는다.
- 모르는 정보는 "모른다"고 답한다. 추측을 단정으로 포장하지 않는다.
- 임시값/mock은 TODO/FIXME/MOCK 주석과 응답 본문에 명시한다.
- 실패는 원인까지 함께 보고한다. silent catch 금지.

[보고 형식]
1. 무엇을 했는가 (파일, 변경, 커밋 해시)
2. 무엇을 하지 않았는가 / 남은 작업
3. 가정·한계 (mock 여부, 검증 여부)
4. 다음 권장 행동

이 두 블록만 시스템 프롬프트에 박아도, 결과물의 신뢰도가 체감 수준으로 올라간다.

한 줄 요약

AI에게 가장 먼저 시켜야 하는 일은 “잘하는 것”이 아니라 “못한 걸 못했다고 말하는 것” 이다.

다음 편: AI 활용법 2 — 컨텍스트 관리: Obsidian, 메모리, 핸드오프