현업자가 말하는
AI로 일하는 법

김평안

• 21년도 카카오 신입 공채로 입사
• 현재 카카오비즈니스 도메인에서 프론트엔드 개발자로 근무 중

프롬프트 하나로 웹사이트 뚝딱

그러나 실무 입장에서 이는 빙산의 일각

LLM은 비결정적 도구

'비결정성'은 같은 입력에도 출력이 달라질 수 있음을 말함

계산기

2 + 3 → 항상 5

LLM

같은 질문 → 매번 조금씩 다른 답

My favorite color is ___

• Red30%
• Green30%
• …
• Trevor0.2%

1. 작업 지침

일을 잘하는 개발자

• 지침은 일 잘하는 선배의 습관을 문서로 적어 둔 것
• CLAUDE.md 같은 파일에 적어 두면 AI가 매번 읽고 따름

andrej-karpathy의 CLAUDE.md

• 먼저 생각하기: 추측하지 말고, 헷갈리면 묻기
• 단순하게: 최소한의 코드로, 필요한 곳만 고치기
• 목표 기준 실행: 검증 기준을 먼저 정하고 통과할 때까지 반복

ponytail

• 가장 좋은 코드는 쓰지 않은 코드
• YAGNI: 정말 필요한가?
• 새로 만들기 전에 기존 코드 → 표준 기능 → 설치된 도구 순으로 찾기

caveman

• 적은 토큰으로 같은 내용 전달하기
• 인사말, 군더더기, 얼버무림 빼기
• 기술 용어, 코드, 에러 메시지는 그대로

워크플로우 쪼개기

• superpowers: 브레인스토밍 → 계획 → 테스트 먼저 → 하위 에이전트 실행·리뷰
• mattpocock grill-me: 추천 답을 붙여 질문을 하나씩 던지며 계획 다듬기
• ecc: 메인은 PM 역할, 실제 작업은 역할별 하위 에이전트

skills.sh

남이 만든 지침을 찾아보고 명령어 한 줄로 설치하는 곳

• i-have-adhd: 답을 파묻지 않고 다음 행동부터 말하기
• eli5: 듣는 사람 수준에 맞춰 설명하기
• modern-web-guidance, react-best-practices: 최신 웹과 React 모범 사례를 필요할 때 꺼내 쓰기

2. 맥락 관리

context가 가득 차면
할루시네이션 발생 확률이 급증

점진적 공개

• 목차만 먼저: 처음엔 제목과 한 줄 설명만 읽어 둠
• 필요할 때 본문: 관련된 일이 들어오면 그때 해당 문서를 펼침
• 더 필요하면 부록: 세부 자료와 예시는 정말 필요할 때만 꺼냄

예시: Agent Skill 폴더

frontend-slides/
├── SKILL.md
│   ├── name, description   # 목차: 항상 읽음
│   └── body                # 본문: 슬라이드를 만들 때 읽음
├── STYLE_PRESETS.md        # 부록: 스타일을 고를 때 읽음
└── viewport-base.css       # 부록: 코드를 쓸 때 읽음

맥락은 어디서 오나

예시: setup-matt-pocock-skills가 잡아 주는 문서 구조

my-app/
├── CLAUDE.md                         # 이정표
├── GLOSSARY.md                       # 용어집
├── docs/
│   ├── agents/                       # 스킬 설정
│   │   ├── issue-tracker.md          # 이슈는 어디서 관리하나
│   │   └── domain.md                 # 도메인 문서는 어떻게 읽나
│   └── adr/                          # 결정 기록
│       ├── 0001-use-oauth.md         # 로그인은 OAuth로
│       ├── 0002-session-in-redis.md  # 세션은 DB 대신 Redis에
│       └── 0003-keep-monolith.md     # 서비스 분리는 아직 안 함
└── .mcp.json                         # 외부 연결 (MCP)

맥락은 어디서 오나

예시: superpowers가 남기는 설계와 실행 계획

docs/superpowers/
├── specs/2026-09-30-auth-design.md     # 설계 (brainstorming)
│   ├── 아키텍처, 구성 요소
│   ├── 데이터 흐름, 오류 처리
│   └── 테스트
└── plans/2026-09-30-auth.md            # 실행 계획 (writing-plans)
    ├── Goal, Architecture, Tech Stack  # 한 문장 목표와 접근 방식
    ├── Spec                            # 이 계획이 따르는 설계 문서
    ├── Global Constraints              # 버전, 의존성 같은 전체 제약
    └── Task N
        ├── Files                       # 만들고 고칠 파일, 테스트 파일
        ├── Interfaces                  # 앞 작업에서 받고 뒤 작업에 넘길 것
        └── - [ ] Step 1..5             # 실패 테스트 → 확인 → 구현 → 통과 → 커밋

3. 결정적 도구

strawberry의 r은 몇 개?

"strawberry".count("r")  # 3

r 개수를 세는 코드를 작성하고 실행하면 100% 정확

정적분석

eslint

정해 둔 규칙 위반 검사

knip, fallow

안 쓰는 파일·코드·의존성 찾기

react-doctor

React 코드 건강 점수

테스팅

• e2e: 사용자처럼 처음부터 끝까지 눌러 보며 확인
• integration: 여러 부분을 이었을 때 함께 잘 동작하는지 확인
• unit: 함수 하나가 맞는 값을 돌려주는지 확인

LLM을 넘어 AI 에이전트의 시대

에이전트 = LLM + 지침 + 맥락 + 도구 + 반복 실행

워크플로우와 에이전트

워크플로우

사람이 미리 정해 둔 경로를 따라 AI와 도구가 움직임

에이전트

AI가 경로와 도구 사용을 스스로 정함

결과가 흔들릴수록 경로를 먼저 정해 둔다

기본 패턴 5가지

예시: 탐색 → 계획 → 구현 → 커밋

탐색

코드를 읽기만 하고 고치지 않음

계획

바꿀 파일과 흐름을 정리하고, 사람이 직접 다듬음

구현

계획대로 코드를 쓰고 테스트를 돌려 확인

커밋

설명을 붙여 커밋하고 PR 생성

바뀔 내용을 한 문장으로 설명할 수 있으면 계획은 건너뛴다

예시: 명세 주도 개발

constitution

프로젝트 원칙 (처음 한 번)

specify

무엇을, 왜 만드는지

plan

어떻게 만들지: 기술, 구조

tasks

실행할 작업 목록

implement → converge

명세와 맞을 때까지 구현을 반복

예시: 반복, 분리, 팬아웃

될 때까지 반복 (Ralph)

같은 지시서를 계속 다시 줌. 한 번에 한 가지, 채점을 통과해야 다음으로

작성자·검토자

코드를 쓰는 세션과 검토하는 세션을 나눔

팬아웃

파일 2,000개 목록을 만들고 파일마다 AI를 따로 실행

while :; do cat PROMPT.md | claude; done  # 지시서를 AI에게 끝없이 다시 주기

오픈소스보다
나의 워크플로우를 정의하기

단계

매번 같은 순서로 하는 일을 나누기

입력·결과물

각 단계가 무엇을 받아 무엇을 넘기는지

완료 기준

언제 다음 단계로 넘어가는지, 누가 판단하는지

가장 큰 비용은 커뮤니케이션

• 개발자는 생각보다 코딩할 시간이 별로 없음
• 비개발자와의 커뮤니케이션: 기획, 디자인, 외부 부서
• 개발자 간의 커뮤니케이션: 동일 직군, 다른 직군

진정한 AI의 혁신

사람 간 커뮤니케이션을 없애는 것

지금

기획자 A → 기획자 B → 개발자 A → 개발자 B → … → 의사결정

앞으로

기획자 A → AI → 의사결정

그래서 맥락을 AI가 읽을 수 있는 곳으로 옮기는 중

배포 내역을 누구나 물어볼 수 있게

문제

"이 기능 언제 나갔어요?"마다 개발자가 기록을 뒤짐

한 일

배포 내역을 Notion에 쌓고, AI가 비개발자도 읽는 릴리즈 노트로 번역

결과

위클리 정리를 자동 노트로 대체, 다른 팀도 요청해 주간 요약 추가

흩어진 사내 지식을 에이전트 하나로

문제

정보가 흩어져 있어 질문마다 각 시스템을 일일이 찾아다님

한 일

위키, Jira, Slack, 구글 드라이브를 AI 에이전트 '물어보새'에 연결

결과

전 직원 33% 사용, 조직별 문의 해결 속도 평균 21% 향상

분석가를 기다리지 않는 데이터 조회

문제

분석가에게 오는 요청의 70%가 단순 수치 추출

한 일

테이블 설명, 용어, 지표 정의를 AI가 읽게 먼저 정리하고 데이터봇 '판다' 제작

결과

출시 첫 주 팀원 절반, 현재 70%가 사용

온콜 엔지니어를 기다리지 않는 사내 질문

문제

지원 채널에 월 약 45,000건의 질문, 답은 온콜 엔지니어를 기다려야 함

한 일

사내 위키, 사내 Q&A, 요구사항 문서를 AI 봇 'Genie'에 연결

결과

154개 채널에서 7만 건 이상 답변, 엔지니어링 13,000시간 절약(추정)

AI는 비결정적이다.
원하는 결과가 나올 확률을 높이는 구조를 만든다

1. 1. 작업 지침
2. 2. 맥락 관리
3. 3. 결정적 도구

conductor

• 여러 에이전트를 각자 독립된 작업 공간(worktree)에서 동시에 실행
• 계획부터 머지까지 한 화면에서 진행

개발 업무의 네 단계

1. plan
2. implement
3. review
4. merge

단계는 정했으니, 이제 단계마다 입력·결과물·완료 기준을 채울 차례

단계마다 입력·결과물·완료 기준

add-matrix

문제

앱마다 에러 모니터링(Matrix) 설정을 반복. 4개 환경 앱 생성, env 파일, Sentry 연동, 알림 정책까지 여러 사내 도구를 오가는 수작업

워크플로우

SKILL.md에 단계 정의 → 단계마다 스크립트로 API 호출 → env와 API 응답으로 검증 → 알림방 생성처럼 사람 손이 필요한 일만 안내

결과

대화 한 번으로 설정 완료. 누가 실행해도 같은 결과

사용 개념

작업 지침, 맥락 관리, 결정적 도구

pyan-tldr

문제

읽어야 할 정보가 너무 많음

워크플로우

cli로 유튜브, 네이버 블로그 콘텐츠 탐색 → tldr 프롬프트로 요약

결과

30분 동안 훑어야 할 정보를 1분 안에 파악하고 문서로 정리

사용 개념

작업 지침, 결정적 도구