2026년을 향한 추천 LLM 코딩 워크플로우

 

My LLM coding workflow going into 2026

 

Addy Osmani (Google 엔지니어)의 AI 코딩 베스트 프랙티스 정리

---

핵심 메시지

AI 코딩 도구는 "버튼만 누르면 마법처럼 되는" 경험이 아니다. LLM을 효과적으로 활용하려면 명확한 방향 제시, 충분한 컨텍스트, 철저한 감독이 필요하다.

Anthropic에서는 엔지니어들이 Claude Code를 너무 많이 사용해서 Claude Code의 코드 90%가 Claude Code 자체로 작성되고 있다.

---

1. 명확한 계획부터 세우기 (코드 전에 스펙)

막연한 프롬프트로 시작하지 말 것.

• AI와 함께 상세한 요구사항 브레인스토밍 진행
• AI에게 "내가 무엇을 빠뜨렸는지 질문해달라"고 요청
• 최종적으로 spec.md 작성: 요구사항, 아키텍처, 데이터 모델, 테스트 전략 포함
• 그 다음 프로젝트 계획(plan.md) 생성: 구현을 논리적인 작은 단계로 분해

Les Orchard의 표현: "15분 안에 워터폴" — 빠른 구조화된 계획 단계가 이후 코딩을 훨씬 수월하게 만든다.

---

2. 작업을 작은 반복 단위로 쪼개기

한 번에 거대한 결과물을 요청하지 말 것.

• 프로젝트를 반복적인 단계/티켓으로 나누고 하나씩 처리
• "1단계부터 구현해보자" → 코드 작성 → 테스트 → 2단계로 이동
• 한 번에 너무 많이 요청하면 "10명의 개발자가 서로 대화 없이 작업한 것 같은" 엉망진창 결과물

TDD(테스트 주도 개발)와 자연스럽게 연결됨 — 각 단계마다 테스트 생성

---

3. 충분한 컨텍스트와 가이드 제공

LLM은 제공받는 컨텍스트만큼만 똑똑하다.

제공해야 할 것들:

• 수정할 코드, 프로젝트 제약사항, 알려진 함정
• API 문서, README
• 고수준 목표와 불변 조건
• 피해야 할 접근법에 대한 경고

유용한 도구들:

• gitingest, repo2txt: 코드베이스를 텍스트로 덤프
• Context7 MCP: 컨텍스트 자동 패킹
• Claude Skills: 반복되는 프롬프팅을 재사용 가능한 모듈로 패키징

LLM은 **리터럴리스트(문자 그대로 해석)**다 — 상세하고 맥락적인 지시를 제공하라.

---

4. 적절한 모델 선택 (필요시 여러 모델 사용)

모든 LLM이 동일하지 않다.

• 각 모델은 고유한 "성격"이 있음
• 한 모델이 막히면 다른 모델로 시도
• 같은 프롬프트를 Claude → Gemini로 복사해서 비교 가능
• "모델 뮤지컬 체어": 모델의 맹점을 피하는 전략

저자는 요즘 Gemini를 많이 사용 — 상호작용이 더 자연스럽고 첫 시도에 이해하는 경우가 많음

---

5. SDLC 전반에서 AI 코딩 활용

CLI 도구:

• Claude Code: 프로젝트 디렉토리에서 직접 대화, 파일 읽기, 테스트 실행
• OpenAI Codex CLI
• Google Gemini CLI

비동기 에이전트:

• Jules, GitHub Copilot Agent: 클라우드 VM에서 리포지토리 클론하고 백그라운드에서 작업 → PR 생성

중요한 점:

AI 에이전트가 전체 기능을 무인으로 완벽하게 코딩하는 단계는 아직 아니다.

감독된 방식으로 사용 — 각 단계를 지켜보며 필요시 개입

---

6. 휴먼 인 더 루프 유지 — 검증, 테스트, 리뷰

AI는 그럴듯해 보이는 코드를 기꺼이 생성하지만, 품질 책임은 당신에게 있다.

Simon Willison: LLM 페어 프로그래머를 **"과신하고 실수하기 쉬운 존재"**로 생각하라.

실천 사항:

• AI 생성 코드를 주니어 개발자의 코드처럼 취급 — 읽고, 실행하고, 테스트
• 워크플로우에 테스트를 엮어 넣기
• 두 번째 AI 세션을 열어 첫 번째 AI 코드를 리뷰하게 하기
• Chrome DevTools MCP 활용: AI에게 브라우저가 보는 것을 직접 보게 함

경고 사례:

테스트 없이 AI에만 의존했더니 "중복 로직, 불일치하는 메서드명, 일관성 없는 아키텍처" 발생 → 고통스러운 리팩토링

---

7. 자주 커밋하고 버전 관리를 안전망으로

잦은 커밋은 세이브 포인트다.

• 각 작은 작업 후 git commit
• AI 다음 제안이 문제를 일으키면 최근 체크포인트로 롤백
• 커밋을 **"게임의 세이브 포인트"**처럼 취급

고급 워크플로우:

• git worktree 사용: 각 AI 작업을 자체 샌드박스 브랜치에서 진행
• 여러 AI 세션을 같은 리포지토리에서 간섭 없이 병렬 실행

설명할 수 없는 코드는 절대 커밋하지 말 것.

---

8. 규칙과 예시로 AI 행동 커스터마이징

AI의 기본 스타일을 그대로 받아들일 필요 없다.

설정 방법:

• CLAUDE.md 또는 GEMINI.md 파일 생성
• 프로세스 규칙과 선호사항 포함: 린트 규칙, 코딩 스타일, 피해야 할 함수 등
• 커스텀 인스트럭션/시스템 프롬프트 활용

강력한 기법:

• 인라인 예시 제공: 원하는 출력 형식이나 접근법 보여주기
• 규칙 추가: "확신이 없으면 지어내지 말고 명확히 질문해달라"

조금의 사전 튜닝이 훨씬 나은 결과물을 만든다.

---

9. 테스트와 자동화를 힘의 배수로

CI/CD, 린터, 코드 리뷰 봇을 활용하라.

왜 중요한가:

• 모든 커밋/PR에 자동 테스트 실행
• 실패 로그를 AI에게 피드백: "통합 테스트가 XYZ로 실패했어, 디버깅하자"
• 린터 출력을 프롬프트에 포함

선순환 구조:

AI가 코드 작성 → 자동화 도구가 문제 발견 → AI가 수정 → 반복

테스트 없이는 AI가 "다 괜찮아!"라고 태평하게 가정할 수 있지만, 실제로는 여러 가지를 망가뜨렸을 수 있다.

---

10. 지속적으로 배우고 적응하기

AI 코딩 세션을 학습 기회로 삼아라.

AI가 당신의 기술을 증폭시킨다:

• 탄탄한 기초가 있으면 AI가 생산성을 배수로 증폭
• 기초가 없으면 AI가 혼란을 증폭

저자의 경험:

• AI 코드를 리뷰하면서 새로운 이디엄과 솔루션을 접함
• AI 실수를 디버깅하면서 언어와 문제 도메인 이해가 깊어짐
• AI를 리서치 어시스턴트로 활용: 라이브러리 비교, 트레이드오프 열거

숙련된 개발자 + AI 조합이 둘 중 하나만 있는 것보다 훨씬 강력하다.

---

결론

핵심 교훈:

1. AI 자동화가 아닌 AI 증강 소프트웨어 엔지니어링
2. 클래식한 소프트웨어 엔지니어링 규율이 여전히 (더욱) 중요
3. 휴먼 엔지니어가 쇼의 감독으로 남아야 함

AI 코딩 어시스턴트는 놀라운 **힘의 배수(force multiplier)**지만, 인간 엔지니어가 여전히 쇼의 감독이다.

---

추천 리소스

• 저자의 신간: AI-Assisted Engineering (O'Reilly)
• 관련 글: "The AI-Native Software Engineer", "Vibe Coding is Not an Excuse for Low-Quality Work"