⚙️ Tech

Advanced Claude Code Patterns That Move the Needle - AgenticLab1

Jaenoo

Jan 14, 20262m ago

Created by

Jaenoo

Created at

Jan 14, 2026 7:32 PM

2025년의 LLM 코딩은..

2025년 LLM 코딩은 더 이상 "프롬프트 좀 잘 쓰면 된다"의 문제가 아닙니다. 지금 생산성 격차는 모델 IQ가 아니라 운영 능력(Agentic harness + context engineering + deterministic validation)에서 벌어집니다.

Claude Code를 "도우미"로 쓰면, 그 순간부터 당신은 모델의 기분·컨텍스트 부패·환각·루프에 끌려다닙니다. 반대로 Claude를 공동 개발자(Co-Dev)로 쓰려면, 인간이 해야 할 일은 명확해집니다.

특히 대규모 코드베이스에서 실패하지 않으려면,

•

실패를 데이터로 만들고(로그)

•

안전과 품질을 결정론으로 고정하고(훅/테스트/게이트)

•

컨텍스트를 예산처럼 관리하고(위생/리셋/핸드오프)

•

작업을 그래프로 쪼개 오케스트레이션한다(/commands + subagents + routing)

이 4가지를 동시에 갖춰야 합니다.

아래 슬라이드별 각각의 설명을 적는 형태로 포스팅 하겠습니다.

PPT

Google NoteBook LM으로 PPT를 제작하였습니다.

이 덱의 핵심은 "Claude를 잘 쓰는 법"이 아닙니다.

Claude가 일을 '망치지 못하게' 만드는 법입니다.

LLM 코딩은 확률 시스템이고, 확률 시스템을 생산 라인에 올리려면 운영체계(guardrails + feedback + context control)가 필요합니다. 이 덱은 그 운영체계를 만드는 패턴만 다룹니다.

시스템을 만들면, 모델이 흔들려도 결과는 흔들리지 않습니다.

Karpathy 인용은 감정 과잉이 아닙니다.

지금 개발자는 기존 레이어(언어/프레임워크/인프라) 위에 새 레이어 하나를 추가로 마스터해야 합니다.

Agents, prompts, contexts, memory, tools, permissions, workflows… 이 레이어는 "사용법"이 아니라 "설계 대상"입니다.

그리고 여기서 뒤처지는 이유는 뻔합니다. 다들 모델을 도구로만 써서 그렇습니다. 도구는 '내가 클릭'하면 끝이지만, 에이전트는 내가 설계하지 않으면 사고가 납니다. 이 덱은 그 설계 문서입니다.

불편한 진실부터

박고 갑니다. LLM이 만든 똥코드의 상당수는 사용자 과실입니다.

왜냐? 모델은 상수고, 변수는 당신의 입력(프롬프트/컨텍스트/하네스)이니까.

프롬프트가 모호하면, 모델은 "가장 그럴듯한" 걸 만듭니다(=환각 포함)

컨텍스트를 막 집어넣으면, 모델은 중요 신호를 잃습니다(=context rot)

검증/가드레일이 없으면, 실수는 그냥 통과합니다(=사고)

이 프레임을 받아들이면, 문제 해결이 시작됩니다.

모델 탓은 끝이고, 운영 설계가 시작입니다.

여기가 사실상 전체 덱의 설계도(Operating System)입니다. 실전에서 바늘을 움직이는 패턴은 네 가지 축으로 수렴합니다.

Feedback Loop: 실패/성공을 기록해 내가 실력을 쌓는 구조(/log_error, /log_success).

Determinism & Safety: 위험/품질을 확률에 맡기지 않고 결정론적으로 차단(hooks, tests, 스크립트).

Context Economy: 컨텍스트를 무한 저장이 아니라 예산으로 관리(CLAUDE.md 절제, JIT 주입, /clear).

Orchestration: 복잡한 일을 작은 작업으로 쪼개 병렬/순차로 조율(/commands, subagents, model routing, validation gates).

이 4기둥이 중요한 이유는, 어느 하나만 잘해도 금방 한계가 오기 때문입니다. 예를 들어 프롬프트가 좋아도 검증이 없으면 사고가 나고, 오케스트레이션을 해도 컨텍스트가 썩으면 품질이 무너집니다.

앞으로의 슬라이드는 이 4기둥을 각각 "바로 쓸 수 있는 패턴"으로 내려줍니다.

패턴 1의 핵심은 단순합니다: "블랙박스를 학습 가능한 시스템으로 바꿔라."

Agentic coding은 결과가 정성적이고(좋다/나쁘다), 과정은 보이지 않으며(블랙박스), 같은 입력도 결과가 바뀝니다(비결정성). 이 상태에서 "감"으로만 개선하려고 하면 실력이 잘 늘지 않습니다.

그래서 이 패턴은 "문제가 생기는 순간"을 데이터로 만드는 루프를 제안합니다.

무엇이 문제였는지(환각/오해/루프/안티패턴/지시 무시 등)

그 문제를 만든 트리거 프롬프트 원문은 무엇인지(요약 금지)

내 입력의 어떤 지점이 원인이었는지(프롬프트/컨텍스트/하네스)

다음부터 재발 방지를 위해 무엇을 바꿀지(규칙/훅/게이트/템플릿)

이게 쌓이면 인터넷에서 본 '팁'이 아니라, 내 작업 환경에서 진짜 작동하는 패턴이 만들어집니다.

여기서부터 게임이 바뀝니다.

/command를 "프롬프트 저장"으로 쓰는 순간 당신은 아마추어입니다.

/command는 로컬 업무 앱입니다. CLI 툴처럼 입력을 받고, 단계가 있고, 산출물이 있고, 실패 처리가 있어야 합니다.

그리고 중요한 차이: 결정론

skill: "써라" 해도 모델이 무시할 수 있음.

/command: 호출하면 무조건 실행됨.

그래서 구조는 이렇게 고정: 지식은 skill에, 실행은 /command에. 이게 Agentic OS의 기본 전술입니다.

복잡한 자동화에서 중요한 건 "LLM을 많이 호출하는가"가 아니라, 워크플로우가 DAG로 설계됐는가입니다.

이 슬라이드는 병렬/순차/게이트/라우팅이 다 들어간 전형적인 "실전형 파이프라인"입니다.

•

병렬: 서로 의존 없으면 동시에 돌려라(속도)

•

순차: 자원/GPU/의존 있으면 순서대로 돌려라(안정성)

•

게이트: 다음 단계로 넘기기 전에 결정론으로 검증해라(Playwright/테스트)

•

라우팅: 창의적 판단 vs 정밀 작업은 모델을 분리해라

•

결정론 작업은 LLM에 맡기지 마라(FFmpeg/Python이 더 싸고 더 정확함)

대규모 레포도 똑같습니다. "분석 병렬 + 수정 병렬 + 통합 순차 + 테스트 게이트"로 굴려야 실패를 줄입니다.

Hooks는 선택이 아니라 보험입니다. 모델은 실수합니다.

중요포인트는 "실수하냐"가 아니라 실수를 어디서 막을 거냐입니다.

dangerously-skip-permissions 같은 설정은 생산성을 미친 듯이 올릴 수 있지만, 그만큼 사고 가능성도 올립니다. 그러면 답은 하나입니다. 훅으로 못 하게 만들어라.

•

rm -rf 같은 파괴 명령 차단

•

시크릿 출력 차단

•

prod 배포/접근 차단

•

위험 패턴은 사전에 거절 + 안전한 대안 제시(dry-run 등)

프롬프트로 "하지 마"는 소원입니다. 훅은 규칙입니다. 실전은 규칙이 이깁니다.

컨텍스트는 저장공간이 아닙니다.

성능을 갉아먹는 비용입니다.

대화가 길어질수록 "모델이 멍청해진다"는 느낌? 그거 착각이 아니라 context rot입니다. 불필요한 토큰이 모델의 주의를 희석시키고, 중요한 요구가 묻힙니다.

여기서 가장 큰 범인은 CLAUDE.md입니다. 글로벌 CLAUDE.md에 규칙을 쌓아두면, 당신은 매 세션 시작부터 성능을 깎고 들어갑니다.

정답은 잔인할 정도로 단순합니다.

•

글로벌은 최소

•

프로젝트별로 분리

•

필요한 것만 제때(JIT) 주입

'많이 알려주면 더 잘하겠지'는 환상입니다. 필요한 것만이 실전입니다.

컨텍스트 관리는 "정리정돈"이 아니라 리소스 매니지먼트입니다.

autocompact를 켜두면, 어느 순간 맥락이 날아가고도 왜 그런지 모릅니다. 그 상태에서 디버깅은 지옥입니다. 통제권을 가져오세요.

•

autocompact 끄기(내가 원할 때만 압축)

•

컨텍스트 상태줄 넣기(예: 55%) → 리셋 타이밍을 의식화

•

/clear를 더 자주 → "참고로 기억해줘"는 곧 썩는다

길게 끌고 가는 게 실력이 아닙니다. 깨끗하게 끊는 게 실력입니다.

서브에이전트는 "편의 기능"이 아니라 품질 전략입니다.

한 에이전트에게 모든 걸 시키면 컨텍스트가 엉키고, 목표가 흐려지고, 결국 사고가 납니다. 일을 잘게 쪼개서 병렬로 던지면, 각 에이전트는 좁은 범위에서 집중하고 결과가 안정화됩니다.

하지만 함정이 하나 있습니다. 환각 전염.

Agent A가 틀린 걸 내뱉고 Agent B가 그걸 믿으면, 체인이 통째로 오염됩니다. 그래서 운영 규칙은 무조건 포함해야 합니다.

•

산출물 포맷 고정(경로/JSON/섹션)

•

상호 검증(Agent X validates Agent Y) 또는 결정론 테스트

•

가능하면 실행 모니터링(대시보드)으로 가시성 확보

"서브에이전트를 많이"가 아니라, 많이 쓰되 검증하라가 핵심입니다.

툴스택은 가벼워야 합니다. 도구를 늘리면 능력이 느는 게 아니라, 컨텍스트가 무거워져서 모델이 더 흔들릴 수 있습니다.

그래서 이 덱은 "필수만 남기는" Lean Stack을 권합니다.

•

최신 문서 접근(Context7 같은 축): 학습 데이터는 항상 늦습니다. 최신 스펙은 외부에서 가져와야 합니다.

•

브라우저 자동화(Dev Browser/Playwright): UI/콘솔/스크린샷 기반 검증은 말로 설명하는 것보다 싸고 정확합니다.

다시 말하지만, 에이전트 코딩은 "똑똑함"보다 검증/최신성/결정론이 승부처입니다.

프롬프트 엔지니어링의 병목은 창의력이 아니라 속도와 일관성입니다. 매번 구조화 프롬프트를 손으로 만들면, 그 순간부터 생산성이 무너집니다.

그래서 해법은 "프롬프트를 쓰지 말고 컴파일하라"입니다.

•

거친 요구(음성/메모)를 던짐

•

모델이 질문으로 요구를 정제(누락/엣지/제약)

•

모델이 구조화된 최종 프롬프트로 재작성(성공 기준/금지 사항/테스트 포함)

최소 버전은 이 한 줄입니다:

"코딩하기 전에, 내가 놓친 요구사항을 찾기 위한 질문 7개만 먼저 해줘."

이게 진짜 바늘을 움직입니다. 재작업이 줄고, 첫 시도 품질이 올라갑니다.

치트시트는 '요약'이 아니라 반사 신경을 만드는 도구입니다.

실전에서 필요한 건 "아 그거 어디 있었지?"가 아니라, 상황이 오면 즉시 행동이 나오는 자동화입니다.

이상한 출력/환각 → /log_error로 사건화 → 되감기

컨텍스트 뭉개짐 → /clear + CLAUDE.md 다이어트

버그 수정 후 대화 오염 → 대화만 되감기

루프/폭주 → 코드+대화 체크포인트 복귀

고위험 구간 → hooks/테스트 게이트 추가

병렬 가능 → 서브에이전트 분해 + 검증

이 표를 레포 루트나 팀 위키 첫 화면에 박아두면, Agentic Coding이 개인기에서 팀 운영 표준으로 바뀝니다.

마무리는 실행 계획입니다.

OS는 한 번에 깔면 실패합니다. 순서대로 깔아야 합니다.

Today: /log_error부터 설치. 실패를 데이터로 바꾸지 못하면, 어떤 개선도 반복되지 않습니다. 그리고 CLAUDE.md 다이어트로 컨텍스트 예산을 확보하세요.

This Week: /command 1개를 "업무 앱"으로 만들고, 검증 게이트를 1개라도 붙이세요. /handoff 템플릿으로 세션 전환 비용도 줄이세요.

30 Days: hooks로 안전을 결정론화하고, 서브에이전트 병렬+검증을 표준으로 굳히세요. 성공 로그를 플레이북으로 승격하면 팀 전체 생산성이 튑니다.

결국 이 모든 건 한 문장으로 끝납니다.

"확률을 운영하지 마라. 시스템을 운영해라."