Anthropic Academy AI Fluency 사내 기술세션 [4]

개요#

이번 세션에서는 일부러 프롬프트를 조금 틀리게 넣어봤다. 기능 스펙 하나를 빼고 돌려본 것이다.

그랬더니 실제로는 막혀 있는 기능이 가능한 것처럼 소개 문구에 들어갔다. 문장 자체는 자연스러웠고, 그래서 오히려 더 위험했다. 얼핏 보면 그냥 넘어갈 수 있는 결과였기 때문이다.

이 지점에서 느낀 건, AI 활용에서 중요한 건 좋은 결과를 뽑아내는 능력만이 아니라 그 결과를 어디서 걸러낼지 판단하는 능력이라는 점이었다. 이번 글에서 다루는 Discernment와 Diligence는 결국 그 얘기다.

Discernment (판별) 심화#

1편에서 Discernment의 세 가지 하위 역량을 정리했었습니다.

Product Discernment — 결과물의 정확성, 적절성 평가
Process Discernment — AI가 어떤 논리로 결과를 냈는지 검토
Performance Discernment — AI의 소통 방식이 효과적이었는지 평가

막상 이 파트에 들어오면, 앞에서 배운 걸 실제로 어디에 써먹을지 감이 좀 더 선명해집니다.

Product Discernment: 결과물을 의심하기#

말 그대로 AI가 내놓은 결과물을 곧이곧대로 받지 않고 한 번 의심해보는 단계입니다.

쉬워 보이는데, 1편에서 다뤘던 "아는 주제 vs 모르는 주제" 실험을 떠올려보면 만만치 않습니다. Spring의 DispatcherServlet 동작 과정이면 바로 "이건 아닌데?" 할 수 있는데, 모르는 프레임워크에서는 AI가 deprecated된 API를 자신 있게 알려줘도 그대로 따라가게 됩니다.

강의에서 제시하는 방법은 세 가지였는데, 써보니 다 이유가 있었습니다.

사실 확인 습관화 — AI가 구체적인 수치, 날짜, 이름을 언급하면 원본 출처에서 확인합니다. 특히 "~에 따르면", "연구에 의하면" 같은 표현 뒤에 나오는 내용은 Hallucination 가능성이 높습니다.

교차 검증 — 같은 질문을 다르게 물어보거나, 다른 소스에서 확인합니다. Text-to-SQL 프로젝트에서 Claude가 생성한 SQL을 항상 실제 DB에서 돌려본 건 Product Discernment였습니다. 코드가 "그럴듯해 보이는 것"과 "실제로 동작하는 것"은 다릅니다.

부분별 검증 — 긴 결과물을 통째로 보지 말고, 섹션별로 나눠서 검증합니다. 기획 문서를 Claude한테 뽑았을 때, 요구사항 파트는 맞는데 기술 스펙 파트에서 Hallucination이 섞여있는 경우가 있었습니다. 전체를 한 번에 "OK" 하면 이걸 놓칩니다.

Process Discernment: 논리를 검토하기#

이건 결과만 보지 말고, 거기까지 가는 과정도 같이 보자는 이야기입니다.

3편에서 다룬 "Think First" 기법이 여기서 빛을 발합니다. AI한테 사고 과정을 먼저 보여달라고 하면, 결과뿐 아니라 과정까지 검토할 수 있습니다.

"이 SQL을 왜 이렇게 짰어?"라고 물어보면 Claude가 논리를 설명해주는데, 거기서 "아 이 조인 조건이 잘못됐구나"를 잡을 수 있습니다. 결과만 보면 쿼리가 돌아가니까 맞는 것 같은데, 과정을 보면 잘못된 가정 위에 세워진 경우가 있습니다.

세션에서 이걸 실습할 때, 같은 프롬프트를 두 번 돌려서 결과가 다르게 나오는 경우를 보여줬습니다. "왜 다르게 나왔지?"를 추적하다 보면 AI의 추론 과정에서 갈라지는 지점이 보입니다. 이게 Process Discernment입니다.

Performance Discernment: 소통 방식을 평가하기#

"답이 맞느냐"만 보는 게 아니라 "답이 제대로 전달되느냐"까지 같이 보는 단계입니다. 정확하지만 너무 장황한 답, 반대로 짧지만 핵심이 빠진 답을 구분하는 쪽에 가깝습니다.

세션에서 기획자분이 좋은 예시를 줬습니다. Claude한테 기능 명세를 요청했는데, 기술적으로는 정확한 답이 나왔지만 개발자가 아닌 기획자가 읽기에는 너무 기술적이었다고. 답의 정확성(Product)은 OK인데 소통 방식(Performance)이 대상에 안 맞았던 겁니다. 이럴 때 Performance Description을 수정해서 다시 요청하면 되는데, 이게 바로 Description-Discernment 루프입니다.

Description-Discernment 루프 실전#

1편에서 루프 개념을 한 번 봤다면, 여기서는 그걸 실제로 굴려보는 파트라고 보면 됩니다.

graph TD
    A[프롬프트 작성<br/>Description] -->|실행| B[AI 결과물]
    B -->|Product 검토| C{정확한가?}
    C -->|No| D[맥락/제약 수정]
    D --> A
    C -->|Yes| E{논리가 맞는가?}
    E -->|No| F[단계/순서 수정]
    F --> A
    E -->|Yes| G{톤이 맞는가?}
    G -->|No| H[역할/태도 수정]
    H --> A
    G -->|Yes| I[완료]
    
    style A fill:#1e3a5f,stroke:#3b82f6
    style I fill:#1e5f3a,stroke:#34d399

루프를 의식적으로 돌리기#

여기서 핵심은 결과가 마음에 안 들 때 그냥 "별로다"로 끝내지 않는 겁니다. 뭐가 안 맞는지 Discernment의 세 가지로 나눠서 보는 쪽이 훨씬 낫습니다.

결과가 틀림 → Product Discernment 실패 → 맥락이나 제약(Product Description)을 수정
논리가 이상함 → Process Discernment 실패 → 단계나 순서(Process Description)를 수정
톤이 안 맞음 → Performance Discernment 실패 → 역할이나 태도(Performance Description)를 수정

이렇게 보면 Discernment가 "프롬프트의 어디를 손봐야 하는지"를 짚어주는 역할을 합니다. 예전처럼 "뭔가 안 맞는데 뭘 고쳐야 하지?" 하고 막막해지는 순간이 확 줄어듭니다.

루프에서 빠져나오는 타이밍#

1편에서 "루프를 의식하면 빠져나올 타이밍도 보인다"고 했는데, 구체적인 기준이 필요합니다.

막상 루프를 몇 번 돌리다 보면 이런 신호가 보입니다:

같은 종류의 피드백이 반복될 때 — 정확성을 고치려고 맥락을 계속 추가하는데 나아지지 않으면, 프롬프트 문제가 아니라 AI의 한계일 수 있습니다. 이때는 작업을 더 잘게 쪼개거나(Delegation 재설계), 사람이 직접 해야 합니다.
점수가 수렴할 때 — Langfuse 점수가 4.5 → 4.5 → 4.6 → 4.5 이렇게 진동하면, 프롬프트 수준에서 할 수 있는 건 다 한 겁니다.
투입 대비 개선이 미미할 때 — 프롬프트를 2배로 길게 만들었는데 점수가 0.1 올랐다면, 그 노력 대비 효과가 너무 적습니다.

Text-to-SQL에서 SQL 정확도가 70%에서 안 올라갔던 경험이 정확히 이겁니다. 프롬프트 루프를 3바퀴 넘게 돌렸는데 안 올라가서, 결국 RAG 메타데이터 품질을 올리는 쪽으로 방향을 틀었습니다. 루프를 빠져나오는 판단이 없었으면 프롬프트만 계속 만지고 있었을 겁니다.

세션 실습: 루프 실전#

세션에서는 의도적으로 "루프를 돌려야 하는 상황"을 만들었습니다.

공통 과제 프롬프트의 기능 스펙에서 핵심 정보를 하나 빼고 돌린 겁니다. "민감 데이터 검색 제외" 조건을 빼놨더니, AI가 "급여 조회도 자연어로 가능합니다"라는 문구를 생성했습니다. 실제로는 불가능한 기능인데 소개 문구에 들어간 거죠.

여기서 동료들한테 "이 결과물의 어디가 문제인지, 그리고 프롬프트의 어디를 고쳐야 하는지"를 분석하게 했습니다.

대부분 "결과가 틀렸다 → Product Discernment → 기능 스펙이 빠져있었다 → Product Description 수정"으로 정확히 진단했습니다. 4회차쯤 되니까 4D 용어로 문제를 짚는 게 자연스러워진 겁니다.

Diligence (책임) 심화#

1편에서 Diligence를 제일 놓치기 쉬운 영역이라고 했는데, 여기서 그 이유가 좀 더 또렷하게 드러납니다.

Creation Diligence: AI를 선택하는 책임#

모든 AI가 똑같지는 않고, 작업 성격에 따라 어울리는 도구도 다릅니다.

민감한 고객 데이터를 다루는 작업이면 데이터 처리 정책부터 봐야 하고, 코드 생성이면 라이선스도 같이 따져야 합니다. "그냥 아무 데나 넣어보자"가 아니라 "이 작업에 이 도구를 써도 되나?"를 먼저 물어야 한다는 얘기입니다.

세션에서 이 부분을 다룰 때, 실제로 사내에서 "어떤 AI를 어떤 용도로 쓸 수 있는지"에 대한 가이드라인이 없다는 점이 드러났습니다. 고객 데이터를 외부 AI에 넣어도 되는지, 생성된 코드의 라이선스는 어떻게 되는지 — 이런 질문에 명확한 답이 없었습니다. 개인이 알아서 하기엔 한계가 있고, 결국 조직 차원의 가이드라인이 필요한 영역입니다.

Transparency Diligence: AI 기여를 밝히는 책임#

1편에서 "회의에서 Claude가 뽑아준 내용을 내가 조사한 것처럼 발표하면?"이라는 질문을 다뤘습니다.

이번 파트에서는 이 기준을 조금 더 구체적으로 정리해줍니다:

AI가 초안을 잡고 내가 수정한 경우 — "AI 도움을 받아 작성했습니다" 정도면 충분합니다.
AI 결과를 거의 그대로 사용한 경우 — 명시적으로 밝혀야 합니다.
AI를 참고용으로만 쓴 경우 — 굳이 밝힐 필요는 없지만, 물어보면 숨기지 않습니다.

기준이 애매할 수 있는데, 강의에서 주는 간단한 테스트가 있습니다: "동료가 이걸 알면 불편하겠는가?" 불편할 것 같으면 밝히는 게 맞습니다.

세션에서 이 기준을 공유했을 때, "그러면 AI를 쓴 코드는 PR에 밝혀야 하나?"라는 질문이 나왔습니다. 이건 팀마다 다를 수 있는데, 중요한 건 "코드의 책임은 커밋한 사람에게 있다"는 겁니다. AI가 짜든 내가 짜든, 리뷰하고 커밋한 순간 그건 내 코드입니다.

Deployment Diligence: 배포하는 책임#

Discernment랑 겹쳐 보이지만, 차이는 이쪽이 배포 이후까지 포함한다는 점입니다. AI가 만든 코드를 올렸다가 버그가 나면 "AI가 짰어요"는 변명이 안 됩니다.

실무에서 이걸 지키는 방법은 생각보다 단순합니다. 굳이 AI용 별도 프로세스를 만들기보다, 기존 품질 기준을 그대로 적용하면 됩니다. AI가 짠 코드도 똑같이 코드 리뷰를 거치고, AI가 쓴 문서도 똑같이 검수를 거치면 됩니다.

시리즈 전체 회고#

4편에 걸쳐 Anthropic Academy AI Fluency 과정을 정리하고, 사내 기술세션에서 실습한 경험을 기록했습니다.

4D 한 장 정리#

Loading diagram...

세션을 통해 느낀 것#

정리하고 보니 결국 남는 건 꽤 단순했다.

프롬프트를 잘 쓰는 것과, AI 결과물을 믿어도 되는가는 다른 문제였다. 문장이 자연스럽다고 맞는 게 아니고, 그럴듯하다고 바로 배포 가능한 것도 아니다. 결국 사람 쪽에서 검증 기준이 있어야 한다.

Langfuse 점수로 추적해보니 이게 더 선명하게 보였다. 기법을 하나 적용할 때마다 점수는 올라가는데, 그 점수만 보고 안심하면 또 다른 종류의 실수를 놓치게 된다. 그래서 Description이 전반부의 핵심이었다면, 후반부에서는 Discernment와 Diligence가 사실상 브레이크 역할을 한다는 느낌이 들었다.

내가 끝까지 붙잡게 된 것도 딱 그거였다. AI 결과물도 결국 운영 코드나 문서와 같은 기준으로 보고, 같은 책임으로 다뤄야 한다는 것.

강의 이후 바뀐 점#

세션 이후 팀에서 실제로 바뀐 것들:

기획자분이 프로덕트 프롬프트 튜닝할 때 Product/Process/Performance 체크리스트를 쓰기 시작했습니다
"이 결과 맞는 건지 모르겠는데" → "Product Discernment 관점에서 출처를 확인해봐야 할 것 같은데" 로 대화가 바뀌었습니다
AI가 생성한 코드/문서에 대해 "이건 AI로 만든 초안이고, 검토가 필요합니다" 라고 밝히는 문화가 자연스러워졌습니다

거창한 변화는 아닌데, 공통 언어가 생긴 게 가장 큰 수확이었습니다. "이건 Delegation 문제야", "Discernment가 부족했어" — 예전에는 "뭔가 이상한데?" 수준이었던 피드백이, 이제는 어디가 이상한지 짚어서 얘기할 수 있게 되었습니다.

수강 정보#

과정명: AI Fluency: Framework & Foundations
제공: Anthropic Academy
비용: 무료
수료 인증서: 있음
소요 시간: 약 2~3시간 (강의 + 과제)
추천 대상: AI를 실무에 쓰고 있지만 체계적인 프레임워크가 없는 사람

개요#