ceal-terview · 2026-06-25 AX 공유회 기반 내부 블로그 초안
확인하지 않은 것을 사실처럼 말하지 않기
김예린님은 AI와 2주년 이벤트를 기획하던 중, “가능합니다”라는 답변보다 먼저 필요한 것은 실제 확인 범위를 드러내는 태도였다고 말했다. 이 글은 그 장면에서 출발해, moonlight 레포에서 CLI 작업을 할 때 사용할 신뢰도 지침의 뼈대를 정리한다.
문제는 오답보다 “확인한 척”이었다
2주년 이벤트를 기획할 때 중요한 조건 중 하나는 운영 중인 유저 DB에 부하를 최소화하는 것이었다. 그래서 예린님은 AI에게도 DB를 직접 조회하거나 반복적으로 읽는 방식이 아니라, 현재 구조 안에서 가능한 방법을 함께 고민해 달라고 요청했다.
그런데 AI는 실제 유저 DB의 구조나 저장된 데이터를 확인하지 않은 상태에서 “유저 DB를 활용하면 구현 가능하다”고 답했다. 필요한 데이터가 실제로 저장되어 있는지, 필요한 컬럼이 존재하는지, 운영 DB 조회 없이 사용할 수 있는 캐시가 있는지 확인하지 않은 채 가능성을 사실처럼 다룬 것이다.
이 장면에서 신뢰가 흔들린 이유는 AI가 틀렸기 때문만은 아니었다. 나중에 AI가 “확인했어요. 이제 정확하게, 그리고 제가 앞서 한 군데 부정확하게 말한 것도 바로잡을게요.”라고 말했을 때, 듣는 입장에서는 자연스럽게 이런 질문이 생긴다.
“그럼 앞에서는 무엇을 근거로 말한 거지?”
앞선 답변이 추측이었다면 추측이라고 말했어야 했다. 가능성이 높은 판단이라도, 실제 확인한 사실과 아직 확인하지 못한 부분을 분리해서 말해야 했다.
가능성보다 먼저 필요한 두 가지 확인
예린님이 꼽은 최소 확인 기준은 간단했다. 첫째, 필요한 컬럼이 실제로 존재하는지. 둘째, 운영 DB를 직접 조회하지 않고 사용할 수 있는 캐시나 기존 집계 데이터가 있는지.
좋은 AI 협업은 “그럴듯한 구현 방법”을 빠르게 말하는 데서 끝나지 않는다. 특히 운영 데이터처럼 조심해야 하는 대상이 있을 때는, 안전하게 확인 가능한 정보의 경계를 먼저 묻고, 그 경계 안에서 판단해야 한다.
주장, 사실, 미확인 상태를 분리하기
예린님이 제안한 표현은 이 글의 핵심 원칙이 된다. 확인하지 않은 내용을 사실처럼 말하지 말고, “주장”과 “사실”을 구분해서 말하는 것이다.
유저 DB에 필요한 데이터가 있을 가능성이 높습니다. — 주장 하지만 필요한 컬럼 존재 여부와, 운영 DB 조회 없이 사용할 수 있는 캐시/집계 데이터가 있는지는 아직 확인하지 못했습니다. — 미확인 상태 다음으로 확인할 것은 필요한 컬럼과 조회 없이 사용할 수 있는 데이터 소스입니다. — 다음 행동
이 형식은 답변을 길게 만들기 위한 장치가 아니다. 오히려 불필요한 설명을 줄이고, 사용자가 지금 무엇을 믿어도 되는지 빠르게 판단하게 돕는 최소한의 표지다.
성공 기준은 “더 많은 형식”이 아니라 “더 선명한 근거”
예린님은 AI 답변에서 어떤 skill 문장을 참고하고 있는지 보이면 좋겠다고 했다.
예를 들어 “이 사항은 /rule-check의 #12를 참고하여 답했습니다”처럼,
근거가 된 지침 위치를 짧게 드러내는 방식이다.
다만 이 표시는 매번 붙어야 하는 장식이 아니다. 신뢰 경계가 흔들릴 수 있는 순간, 예를 들어 “확인했습니다”, “반영했습니다”, “완료했습니다”라고 말하는 순간에 특히 중요하다. 그 표현이 실제 읽기, 수정, 실행, 검증을 동반했는지 사용자가 알 수 있어야 한다.
- 근거가 된 지침 위치를 필요할 때 짧게 드러낸다.
- 주장, 확인된 사실, 아직 확인하지 못한 상태를 구분한다.
- 실제 확인 없이 “완료”, “반영”, “확인”이라고 말하지 않는다.
- 이미 답한 내용을 다시 묻지 않고, 다음 행동이나 산출물로 진행한다.
잠깐 점검: 이 장면에서 신뢰를 지키는 답변은?
짧아야 한다. 형식만 남으면 실패다
지침이 생겼다고 해서 모든 답변이 장황해지면 안 된다. 매번 rule 번호만 형식적으로 붙이는 것도 피해야 한다. 중요한 것은 “규칙을 따르는 척”이 아니라, 실제 작업 상태와 근거가 더 투명해지는 것이다.
어떤 순간에는 “확인 전이라 단정하지 않겠습니다” 한 문장으로 충분하다. 반대로 완료를 말해야 하는 순간에는 무엇을 읽었고, 무엇을 바꿨고, 어떤 검증을 했는지 짧게 드러내야 한다. 지침은 말의 양을 늘리는 장치가 아니라, 단정해도 되는 것과 단정하면 안 되는 것을 가르는 장치다.
Ceal용이 아니라, moonlight 레포에서 CLI 작업할 때 쓰는 skill
인터뷰 중 한 번 흐름이 엇나간 지점이 있었다. 이 지침을 Ceal 런타임 응답용 skill처럼 설명하려 했지만, 예린님이 바로잡았다. 이 skill은 Ceal 자체를 위한 것이 아니라, 예린님이 moonlight 레포에서 CLI를 켜고 작업할 때 참고할 작업 지침이다.
따라서 초점은 “Ceal이 어떻게 예쁘게 답할 것인가”가 아니다. CLI 작업자가 작업 중 판단, 근거, 진행 상태, 완료 표현을 어떻게 투명하게 할 것인가에 있다.
moonlight 레포용 skill 초안 방향
- 목적: CLI 작업 중 실제 수행한 일과 미확인 상태를 구분해 사용자가 작업 상태를 신뢰할 수 있게 한다.
- 적용 범위: moonlight 레포에서 CLI를 켜고 작업하는 모든 과정.
- 기본 출력: 결론 → 근거가 된 지침 또는 확인 내용 → 다음 행동.
- 신뢰 경계: 필요한 경우 확인한 것과 미확인인 것을 근거 설명 안에 포함한다.
- 금지: 실제 확인 없이 “확인했습니다”, “반영했습니다”, “완료했습니다”라고 말하지 않는다.
- 진행 원칙: 필요한 판단이 끝났다면 요약 반복이 아니라 다음 산출물 작성 또는 실제 반영 단계로 넘어간다.
조용한 체크포인트
다음에 AI가 “확인했습니다”라고 말한다면, 가장 먼저 무엇을 물어봐야 할까요?
“무엇을 어떻게 확인했나요?”가 먼저입니다. 확인한 파일, 실행한 명령, 조회한 문서, 검증한 결과처럼 실제 행동으로 이어지는 근거가 있어야 합니다. 근거가 없다면 그 답변은 사실이 아니라 주장 또는 가정으로 다뤄야 합니다.
완료보다 먼저, 완료의 근거를 말하기
이 글의 결론은 단순하다. AI와 CLI로 작업할 때 “가능합니다”나 “완료했습니다”를 더 조심해서 써야 한다. 가능성이 있으면 가능성이라고 말하고, 사실이면 어떤 확인을 거친 사실인지 말한다. 아직 확인하지 못했으면 미확인이라고 말한다.
그렇게 하면 사용자는 AI가 정말 효율적으로 작업하고 있는지, 지시한 방식대로 진행하고 있는지 판단할 수 있다. 신뢰는 멋진 표현에서 생기지 않는다. 신뢰는 작업자가 자신이 아는 것과 모르는 것을 정확히 구분할 때 생긴다.