전체 내역

·study·2026.08.06·5 min read·조회수318

Anthropic AI Fluency 수강 후기, 4D 프레임워크를 개발 업무에 대입해 보기

AI를 매일 쓰면서도 요령만 쌓이는 것 같아 AI Fluency 과정을 들었습니다. 위임, 설명, 분별, 성실이라는 네 가지 역량을 프론트엔드 개발 업무에 하나씩 대입해 봤습니다.

프론트엔드 개발자의 AI 기초· 1 / 3펼치기
  1. 1. Anthropic AI Fluency 수강 후기, 4D 프레임워크를 개발 업무에 대입해 보기
  2. 2. LLM 관리자 화면을 만들다가 공부한 토큰, 컨텍스트, 임베딩, RAG
  3. 3. 매일 쓰는 Claude Code가 궁금해서 들은 허깅페이스 AI 에이전트 과정

AI를 업무에 꽤 많이 쓰고 있습니다. 코드도, 문서도, 기획도요. 그런데 어느 순간 이런 생각이 들었습니다. 내가 아는 건 전부 써 보면서 익힌 요령인데, 이게 맞는 방향인지는 잘 모르겠다는 생각이요.

그래서 원리부터 다시 보자는 마음으로 AI 관련 과정을 차례로 듣기 시작했습니다. 첫 번째가 Anthropic의 AI Fluency였습니다. 이 글에서는 이 과정의 중심인 4D 프레임워크를 정리하고, 제 업무에 하나씩 대입해 본 내용을 공유합니다.

1. 4D가 뭔가요

이 과정은 특정 도구 사용법을 가르치지 않습니다. 대신 AI와 효과적이고, 효율적이고, 윤리적이고, 안전하게 일하기 위한 네 가지 역량을 이야기합니다. 영어 앞 글자를 따서 4D라고 부릅니다.

Delegation(위임)은 무엇을 AI에게 맡기고 무엇을 내가 할지 정하는 역량입니다. Description(설명)은 원하는 걸 AI가 이해하도록 명확하게 전달하는 역량이고, Discernment(분별)는 AI가 내놓은 결과와 과정을 비판적으로 평가하는 역량입니다. 마지막 Diligence(성실)는 결과에 책임지고 투명하게 쓰는 태도를 말합니다.

처음 들었을 때는 너무 당연한 이야기 같았습니다. 그런데 하나씩 제 일에 대입해 보니 생각보다 못 하고 있는 게 많았습니다.

2. Delegation: 맡기지 않을 일을 정하는 것도 위임입니다

위임은 "AI를 쓸까 말까"가 아니라 "일을 어떻게 나눌까"의 문제라고 합니다. 과정에서는 세 가지를 같이 보라고 하는데, 목표와 필요한 결과물이 무엇인지(문제 인식), 지금 쓰는 AI가 뭘 잘하고 못하는지(플랫폼 인식), 그리고 그걸 바탕으로 사람과 AI 사이에 일을 어떻게 나눌지(작업 위임)입니다.

제 일에 대입해 보면 이렇습니다. 공통 컴포넌트를 쓰는 화면 구현은 AI가 쓰고 저는 계획을 승인하고 결과를 검토합니다. 디자인 토큰이나 컴포넌트 규칙은 제가 정하고, AI에게는 초안이나 빠진 부분 점검을 맡깁니다. 사업수행계획서는 AI가 예전 제출본 구조를 재사용해서 초안을 쓰고, 저는 사실관계를 검수합니다.

그리고 발주처와 범위를 협의하는 일은 맡기지 않습니다. 이게 제일 중요한 줄이었습니다. 무엇을 맡기지 않을지 정하는 것도 위임이라는 말이 오래 남았습니다.

3. Description: 결과물, 과정, 태도를 나눠서 설명하기

AI에게 원하는 걸 설명하는 역량입니다. 과정에서는 이걸 다시 셋으로 나눕니다. 무엇을 만들지(결과물), 어떻게 접근할지(과정), 어떤 태도로 협업할지(성능)입니다.

개발에서는 이게 곧 프롬프트이자 CLAUDE.md입니다. 예전에 제가 쓰던 프롬프트와 지금 쓰는 프롬프트를 비교해 보면 차이가 보입니다.

예전:  대시보드 만들어 줘.
 
지금:  /dashboard 화면을 만들어 줘.
       - 결과물: 상단 KPI 카드 4개 + 최근 업무 테이블. docs/components.md의 Card, Table을 쓴다.
       - 과정: 먼저 필요한 API와 컴포넌트 목록을 보여 주고, 승인하면 구현한다.
       - 태도: 모르는 API 응답 형태는 추측하지 말고 물어본다.

세 번째 줄, 태도에 대한 설명은 과정을 듣기 전에는 거의 안 썼습니다. 그런데 "모르면 물어봐"라는 한 줄을 넣은 뒤로 AI가 API 응답을 마음대로 지어내는 일이 확실히 줄었습니다.

4. Discernment: 분별을 사람 감에만 맡기면 지칩니다

AI의 결과를 그대로 받아들이지 않고 평가하는 역량입니다. Description과 짝을 이룹니다. 결과물이 정확하고 적절한지, 추론 과정에 비약은 없는지, 협업 방식이 기대에 맞았는지를 봅니다.

솔직히 개발에서 이걸 매번 제 눈으로만 하면 금방 지칩니다. 그래서 분별의 상당 부분을 기계적인 검증으로 옮겼습니다. typecheck, e2e 테스트, 스크린샷 비교가 결과물 분별을 대신하고, 저는 구조와 의도를 봅니다. 이 이야기는 품질 게이트 글에 따로 정리해 뒀습니다.

5. Diligence: 마지막 책임은 결국 사람에게 있습니다

결과에 대한 책임입니다. 어떤 AI를 어떻게 쓸지 신중하게 고르는 것, AI를 썼다는 사실을 필요한 사람에게 알리는 것, 내보내는 결과물을 검증하고 책임지는 것까지 포함합니다.

공공 사업 문서를 AI로 초안 작성할 때 특히 이 부분을 의식하게 됐습니다. 수치나 기관명, 일정은 반드시 원본과 대조합니다. 최종 제출물에 대한 책임은 AI가 아니라 작성자인 저에게 있으니까요. 이 블로그 첫 화면 캐릭터도 AI로 만들었는데, 그 사실과 과정을 시리즈 글로 공개한 것도 같은 이유입니다.

마치며

4D를 배우고 나서 가장 달라진 건, AI 결과가 마음에 안 들 때 원인을 나눠서 생각하게 됐다는 점입니다. 애초에 맡기면 안 되는 일을 맡긴 건지(위임), 맥락을 충분히 안 준 건지(설명), 검토 없이 받아들인 건지(분별). 원인이 보이면 고치는 방법도 분명해지더라고요.

AI를 많이 쓰는데 뭔가 정리가 안 되는 느낌이라면, 이 과정을 한번 들어 보시길 권합니다. 분량이 길지 않고, 듣고 나면 자기 작업 방식을 돌아보게 됩니다.

Comments (0)