▲

2026년을 대비한 나의 LLM 코딩 워크플로우

 (addyosmani.com)
33P by neo 16시간전 | ★ favorite | 댓글 1개
  • AI 코딩 어시스턴트가 2025년을 거치며 실전 개발의 핵심 도구로 자리 잡았고, 효과적인 활용을 위해서는 구조화된 워크플로우와 인간의 책임 있는 개입이 필수
  • 코드 생성을 바로 요청하기보다 명확한 스펙과 계획 수립을 선행하고, 이를 기반으로 단계별 구현을 진행하는 방식이 품질과 생산성을 동시에 높임
  • 작업을 작은 단위로 분해하고 충분한 맥락과 제약을 제공할수록 LLM의 오류와 일관성 문제를 크게 줄일 수 있음
  • 단일 모델에 의존하지 않고 여러 LLM과 도구를 목적에 맞게 선택하며, 개발 전 주기에 걸쳐 AI를 보조적으로 활용하는 흐름이 확산 중
  • 최종적으로 테스트, 리뷰, 버전 관리를 통해 인간이 통제권을 유지할 때 AI는 강력한 생산성 증폭기로 작동함

개요

  • 2025년을 거치며 AI 코딩 어시스턴트가 실제 제품 코드 작성에 대규모로 활용되기 시작함
  • Anthropic 엔지니어들은 Claude Code를 적극 도입해 현재 Claude Code 코드의 약 90%를 Claude Code 자체가 작성하는 수준에 도달
  • LLM을 프로그래밍에 활용하는 것은 버튼 한 번으로 되는 마법이 아니며, 새로운 패턴 학습과 비판적 사고가 필수
  • AI를 공격적으로 활용하되 생산된 소프트웨어에 대한 책임은 개발자 본인이 져야 함
  • 핵심은 LLM을 자율적 판단자가 아닌 명확한 방향, 컨텍스트, 감독이 필요한 강력한 페어 프로그래머로 대하는 것

명확한 계획으로 시작하기 (스펙 먼저, 코드는 나중에)

  • LLM에게 막연한 요청을 던지지 말고, 문제 정의와 솔루션 계획부터 시작해야 함
  • 새 프로젝트의 경우 아이디어를 설명하고 LLM에게 반복적으로 질문하도록 요청해 요구사항과 엣지 케이스를 구체화
  • 최종적으로 요구사항, 아키텍처 결정, 데이터 모델, 테스트 전략을 포함한 spec.md로 정리
  • 스펙을 추론 가능한 모델에 입력해 구현을 논리적이고 작은 태스크 단위로 분할한 프로젝트 플랜 생성
  • Les Orchard 표현대로 "15분 만에 워터폴" 방식으로 빠른 구조화된 계획 단계를 거치면 이후 코딩이 훨씬 원활해짐
  • 명확한 스펙과 플랜이 있으면 인간과 LLM 모두 무엇을 왜 만드는지 정확히 인지하고 재작업과 낭비되는 사이클 방지

작업을 작고 반복적인 청크로 분할

  • LLM에 한 번에 거대한 출력을 요구하지 않고, 프로젝트를 반복 가능한 단계·티켓 단위로 쪼개 순차 처리
    • 예: “플랜의 Step 1 구현” 같은 단위로 프롬프트를 주고, 코딩 후 테스트를 거쳐 Step 2로 이동하는 흐름 정착
  • 한 번에 너무 많은 범위를 던지면 모델이 꼬이거나 뒤죽박죽 결과물을 내고, 수습 비용이 급증함
  • 앱의 큰 덩어리를 통째로 생성하게 했더니 일관성 붕괴와 중복 코드가 쌓였고, “대화 없이 10명이 만든 것 같다”는 평가도 나
  • 각 반복에서 이미 구축된 컨텍스트를 이어받아 점진적으로 추가하며, TDD(테스트 주도 개발) 접근법과도 잘 맞음
  • 일부 코딩 에이전트 도구는 이 청크 워크플로우를 명시적으로 지원하며, 프롬프트 플랜 파일을 생성해 순차 실행 가능

광범위한 컨텍스트와 가이던스 제공

  • LLM은 주어진 컨텍스트의 범위만큼만 성능을 발휘하므로, 관련 코드·문서·제약 조건을 충분히 제공해야 함
  • Claude는 Projects 모드에서 전체 GitHub 레포를 컨텍스트로 불러올 수 있고, Cursor·Copilot 같은 IDE 어시스턴트는 열린 파일을 자동으로 포함
  • 브레인 덤프 방식으로 모델이 알아야 할 정보를 사전에 전달하는 것이 효과적이며, 고수준 목표·바람직한 해법 예시·피해야 할 접근 방식까지 포함
  • gitingest나 repo2txt 같은 도구를 활용해 코드베이스의 필요한 부분을 텍스트 파일로 덤프해 LLM에 제공 가능
  • Claude Skills는 반복 프롬프팅에 의존하던 방식을 넘어, 지시·스크립트·도메인 전문성을 내구적이고 재사용 가능한 모듈로 묶는 접근
    • 커뮤니티에서 큐레이션된 Skills 컬렉션 도 있음
    • frontend-design 스킬은 LLM이 생성한 UI에 흔한 보라색 위주의 디자인 미학을 교정해주기도 함
  • 프롬프트 내부에 코멘트와 규칙을 직접 포함해 AI를 안내하면 효과가 큼
    • 예: “여기 X의 현재 구현이 있다. 이를 Y로 확장하되 Z는 깨뜨리지 말 것”
  • LLM은 지시를 문자 그대로 따르는 리터럴한 특성을 가지므로, 상세하고 맥락이 분명한 지시를 제공할수록 환각과 엉뚱한 제안 감소

적절한 모델 선택 (필요시 여러 모델 활용)

  • 모든 코딩 LLM이 같은 수준은 아니며, 태스크 성격에 맞는 모델이나 서비스를 의도적으로 선택하는 것이 중요
  • 경우에 따라 두 개 이상의 LLM을 병렬로 사용해, 동일한 문제에 대한 서로 다른 접근을 교차 검증하는 방식이 효과적
  • 각 모델은 고유한 성향과 강점을 가지므로, 한 모델이 막히거나 평범한 결과를 내면 다른 모델로 전환하는 판단 필요
  • 동일한 프롬프트를 다른 서비스에 그대로 옮겨 테스트하는 ‘모델 뮤지컬 체어’ 방식으로 특정 모델의 맹점 회피 가능
  • 가능하다면 최신 프로 티어 모델을 사용하는 편이 품질 면에서 확실한 이점 제공
  • 장시간 협업을 전제로 할 경우, AI 페어 프로그래머의 "바이브" - 응답 톤과 상호작용 감각이 본인과 맞는지도 중요한 선택 기준

AI 코딩을 전체 라이프사이클에 걸쳐 활용

  • 커맨드 라인 환경에서 Claude Code, OpenAI Codex CLI, Google Gemini CLI 같은 AI 에이전트가 등장해, 프로젝트 디렉토리 안에서 파일 읽기·테스트 실행·다단계 수정 작업 수행 가능
  • Google의 Jules, GitHub의 Copilot Agent는 레포를 클라우드 VM에 복제해 작업한 뒤 PR을 여는 비동기 코딩 에이전트로 활용
  • 이러한 도구들은 완전하지 않으며, 한계를 이해한 상태에서 사용하는 것이 필수
    • 보일러플레이트 생성, 반복 변경 적용, 자동 테스트 실행 같은 기계적 작업에서는 큰 가속 효과를 보이지만, 여전히 인간의 가이던스가 품질을 좌우
  • 에이전트 사용 시 초기 단계에서 플랜이나 투두 리스트를 함께 제공하면 정확한 작업 순서 인식에 큰 도움
  • AI 에이전트가 기능 전체를 무인으로 구현해 완벽한 결과를 내는 단계는 아직 아님, 감독형 사용이 현실적인 접근
  • Conductor 같은 오케스트레이션 도구를 활용해 여러 에이전트를 병렬로 돌리며, 서로 다른 기능을 동시에 처리하는 실험이 진행 중

휴먼 인 더 루프 유지 - 검증, 테스트, 리뷰 철저히

  • AI는 그럴듯한 코드를 주저 없이 만들어내지만, 품질과 결과에 대한 책임은 전적으로 개발자에게 있음
  • Simon Willison의 표현처럼 LLM 페어 프로그래머는 과신하며 실수하기 쉬운 존재로 인식해야 하며, 버그나 말이 안 되는 코드도 확신에 차서 작성함
  • AI가 생성한 코드 스니펫은 주니어 개발자의 코드처럼 취급해야 하며, 코드를 직접 읽고 실행하고 필요에 따라 테스트 수행
  • 테스트를 워크플로우 안에 자연스럽게 포함시키고, 계획 단계부터 각 단계별 테스트 목록과 테스팅 플랜을 함께 설계
  • Claude Code 같은 도구에는 태스크 구현 후 테스트 스위트 실행을 명시적으로 지시하고, 실패 시 원인 분석과 수정까지 진행
  • 코딩 에이전트를 가장 잘 활용하는 경우는 대부분 탄탄한 테스트 문화를 갖춘 팀과 개인
  • 테스트가 없는 환경에서는 에이전트가 실제로 여러 부분을 깨뜨렸음에도 문제가 없다고 가정하고 넘어갈 위험 존재
  • 자동화 테스트 외에도 코드 리뷰를 필수 단계로 유지, 수동 리뷰와 AI 기반 리뷰를 병행
    • 별도의 AI 세션이나 다른 모델을 활용해, 첫 번째 AI가 작성한 코드를 비평하거나 리뷰하도록 요청
    • 예: Claude가 코드 작성 후 Gemini에게 해당 함수의 오류나 개선 가능성 검토 요청
  • Chrome DevTools MCP를 디버깅과 품질 루프의 핵심 도구로 활용해, 정적 분석과 실제 브라우저 실행 사이의 간극 해소
    • AI 에이전트가 DOM 구조, 성능 트레이스, 콘솔 로그, 네트워크 요청을 직접 관찰하도록 접근 권한 부여
    • 수동으로 맥락을 옮기는 과정 없이 LLM 기반 자동 UI 테스트 수행 가능
    • 실제 런타임 데이터를 바탕으로 버그를 정밀하게 진단하고 수정하는 흐름 가능
  • 급한 프로젝트에서 AI 생성에 과도하게 의존한 결과를 한 개발자는 일관성 없는 엉망이었다고 얘기함
    • 중복 로직, 서로 다른 메서드 이름, 통합되지 않은 아키텍처가 누적
    • 계속 만들어내기만 하고, AI가 엮은 전체 구조를 점검하기 위해 한 걸음 물러서지 않았다고 반성함
    • 결국 대규모 리팩토링과 함께 다시는 무감독 상태로 맡기지 않겠다는 결론에 도달
  • AI 사용량과 무관하게 개발자는 끝까지 책임 있는 엔지니어로 남아야 함
  • 실무적으로는, 코드를 이해한 뒤에만 머지하거나 배포하고, AI가 복잡한 구현을 내놓으면 설명 주석 추가나 더 단순한 형태로의 재작성을 요구

자주 커밋하고 버전 관리를 안전망으로 활용

  • 빠르게 대량의 코드를 만들어내는 AI와 작업할수록 더 촘촘한 버전 관리 습관이 필요
  • 작은 태스크를 마치거나 자동 수정이 성공할 때마다 의미가 분명한 메시지로 git 커밋을 남겨, 다음 변경이 문제를 일으켜도 즉시 되돌릴 수 있는 체크포인트 확보
  • 커밋을 게임의 세이브 포인트처럼 취급해, LLM 세션이 엇나가면 언제든 마지막 안정 상태로 복귀
  • 버전 관리는 AI와의 협업에서도 중요한 역할을 하며, 컨텍스트 윈도우 한계로 모든 변경을 기억하지 못하는 상황에서 git 히스토리가 신뢰 가능한 작업 로그가 됨
  • 최근 커밋을 훑어보며 변경 사항을 AI나 스스로에게 빠르게 브리핑 가능
  • git diff나 커밋 로그를 프롬프트에 포함하면, LLM이 새 코드와 이전 상태를 정확히 파악
  • LLM은 diff 해석과 git bisect 같은 도구 활용에 능숙해, 커밋 히스토리를 따라가며 버그 유입 지점을 끈질기게 추적 가능
  • 잘게 나뉜 커밋과 명확한 메시지는 개발 과정을 자연스럽게 기록해 코드 리뷰 시 큰 도움
  • AI 에이전트가 여러 변경을 한 번에 수행했을 때도, 변경이 커밋 단위로 분리돼 있으면 문제를 유발한 지점을 정확히 특정하기 쉬움
  • 브랜치나 worktree를 활용해 AI 실험을 본선 코드와 격리
    • Jesse Vincent에게서 영감을 받은 방식으로, 새 기능이나 서브 프로젝트마다 fresh git worktree 생성
    • 동일 레포에서 여러 AI 코딩 세션을 서로 간섭 없이 병렬로 실행한 뒤 결과를 선택적으로 머지
    • 각 AI 태스크가 자체 샌드박스 브랜치에 있는 것과 같아, 실패한 실험은 폐기해도 main에는 영향 없음
  • 이해하고 설명할 수 없는 코드는 절대 커밋하지 않는 원칙 유지

규칙과 예시로 AI 행동 커스터마이즈

  • AI의 기본 스타일이나 접근 방식을 그대로 받아들이지 않고, 명확한 가이드라인을 주는 것만으로도 출력 품질과 일관성에 큰 영향
  • CLAUDE.md 파일을 주기적으로 관리해 Claude가 따라야 할 프로세스 규칙과 선호도를 명시하고, Gemini CLI 사용 시에도 동일한 방식으로 GEMINI.md 활용
    • 예: 프로젝트 스타일에 맞춰 코드 작성, 린트 규칙 준수, 특정 함수 사용 금지, OOP보다 함수형 스타일 선호 등
    • 세션 시작 시 해당 파일을 Claude에게 제공해 작업 전반을 규약에 맞추는 방식
    • Jesse Vincent에 따르면 이런 접근으로 AI가 원치 않는 방향으로 이탈하거나 낯선 패턴을 도입하는 빈도 감소
  • 별도의 규칙 파일이 없어도 커스텀 인스트럭션이나 시스템 프롬프트를 통해 전반적인 톤과 행동 설정 가능
    • GitHub Copilot과 Cursor 모두 프로젝트 단위로 AI 행동을 전역 설정하는 기능 제공
    • 코딩 스타일을 짧은 문단으로 명시: “4 스페이스 들여쓰기 사용, React에서 화살표 함수 피하기, 설명적인 변수명 사용, 코드는 ESLint를 통과해야 함”
    • Ben Congdon은 Copilot의 커스텀 인스트럭션 기능이 거의 사용되지 않는 현실에 놀랐다고 언급하며, 몇 가지 예시와 선호도를 사전에 주는 것만으로도 팀 관용구에 맞는 코드 출력이 가능하다고 지적
  • 인라인 예시 제공은 특히 강력한 기법
    • 특정 방식의 함수 구현을 원할 경우, 코드베이스에 이미 존재하는 유사한 함수를 먼저 보여주며 “X는 이렇게 구현했으니 Y도 같은 접근을 사용하라”고 안내
    • 주석 스타일을 맞추고 싶다면 직접 한 줄을 작성한 뒤, 그 스타일을 이어가도록 요청
    • 결국 모델을 따를 패턴으로 프라이밍하는 방식이며, LLM은 이런 모방에 매우 강함
  • 커뮤니티에서는 LLM 행동을 다듬기 위한 다양한 룰셋이 공유됨
    • "Big Daddy" 규칙이나 프롬프트에 “환각·기만 금지” 조항을 추가하는 방식
    • AI가 존재하지 않는 코드를 꾸며내거나 과도하게 확신하는 행동을 줄이기 위한 장치
    • 예: “불확실하거나 코드베이스 컨텍스트가 없으면 답을 지어내지 말고 명확화를 요청하라”를 프롬프트 앞부분에 추가해 환각 감소
    • 또 다른 규칙으로 “버그 수정 시 항상 주석으로 이유를 간략히 설명하라”를 두면, AI가 “// Fixed: 스펙에 따라 Z 방지를 위해 X를 Y로 변경” 같은 설명 주석을 함께 남김

테스팅과 자동화를 힘 증폭기로 수용

  • CI/CD, 린터, 코드 리뷰 봇을 적극 활용할수록 AI는 실수를 자동으로 걸러내는 환경에서 가장 잘 작동
  • AI 코딩 비중이 큰 레포일수록 견고한 지속적 통합 환경이 필수
    • 모든 커밋이나 PR마다 자동 테스트 실행, ESLint·Prettier 같은 코드 스타일 검사 강제, 가능하다면 브랜치별 스테이징 배포까지 포함
    • AI가 직접 이를 트리거하고 결과를 평가하도록 구성 가능
    • 예: Jules나 GitHub Copilot Agent가 PR을 열면 CI가 테스트를 실행하고 실패를 보고 → 실패 로그를 AI에 전달해 “통합 테스트가 XYZ에서 실패했다, 함께 디버그하자”로 연결
    • 버그 수정 과정이 빠른 피드백을 동반한 협업 루프로 전환되며, AI가 특히 잘 대응
  • 자동화된 코드 품질 검사도 AI의 방향타 역할 수행
    • 린터 출력을 프롬프트에 그대로 포함해, 린트에 걸린 코드를 작성했을 경우 오류 메시지를 복사해 “이 문제들을 해결하라”고 요청
    • 엄격한 선생님이 AI 어깨 너머에서 지켜보는 효과
    • AI는 테스트 실패나 린터 경고 같은 도구 출력을 인지하면 집요하게 수정 시도
  • AI 코딩 에이전트 자체도 점점 자동화 훅을 내장
    • 일부 에이전트는 모든 테스트가 통과되기 전까지 작업이 “완료”되었다고 인정하지 않음
  • 코드 리뷰 봇(AI든 사람이든)도 추가적인 필터로 활용
    • 리뷰 코멘트를 그대로 개선용 프롬프트로 사용
    • 예: CodeRabbit이나 다른 리뷰어가 “이 함수는 X를 하고 있는데 이상적이지 않다”고 남기면, AI에게 “이 피드백을 반영해 리팩토링할 수 있는가”라고 요청
  • AI와 자동화를 결합하면 선순환 구조가 형성
    • AI가 코드 작성 → 자동화 도구가 문제 포착 → AI가 수정 → 반복, 개발자는 고수준 방향만 감독
    • 극도로 빠른 주니어 개발자의 작업을 지치지 않는 QA 엔지니어가 즉시 검증하는 느낌
    • 단, 이 환경은 개발자가 직접 구축해야 하며, 테스트나 자동화가 없는 프로젝트에서는 AI의 미묘한 버그나 품질 저하가 한참 뒤에 드러날 위험 존재
  • 2026년을 향한 목표 중 하나는 AI 코드 기여 주변의 품질 게이트 강화
    • 더 많은 테스트, 더 많은 모니터링, 필요하다면 AI가 AI를 리뷰하는 구조까지 포함
    • 한 모델이 놓친 문제를 다른 모델이 잡아내는 사례가 실제로 관찰됨

지속적 학습과 적응 (AI가 스킬을 증폭)

  • 모든 AI 코딩 세션을 학습의 기회로 다루면, 지식이 늘수록 AI의 도움도 커지는 선순환 형성
  • LLM을 개발에 활용하면서 평소라면 시도하지 않았을 새로운 언어, 프레임워크, 기법에 자연스럽게 노출
  • 탄탄한 소프트웨어 엔지니어링 기초가 있을 때 AI는 생산성을 몇 배로 증폭시키지만, 기초가 부족하면 혼란 역시 함께 증폭
  • 숙련된 개발자들의 공통된 관찰로, LLM은 기존 베스트 프랙티스를 강화하는 성향
    • 명확한 스펙 작성, 잘 갖춰진 테스트, 꾸준한 코드 리뷰가 AI가 개입할수록 더 큰 효과 발휘
  • AI가 보일러플레이트를 처리하는 동안 개발자는 설계·인터페이스·아키텍처 같은 고수준 추상화에 집중할 수 있으나, 이를 위해서는 해당 역량이 선행되어야 함
  • Simon Willison의 지적처럼, 시니어 엔지니어를 만드는 거의 모든 요소—시스템 설계, 복잡성 관리, 자동화와 수작업의 판단—가 이제 AI와 결합될 때 최상의 결과로 이어짐
  • AI 활용은 실제로 엔지니어링 역량 향상을 촉진
    • 계획 단계에서 더 엄격해지고, 아키텍처에 대해 더 의식적으로 사고
    • 매우 빠르지만 다소 순진한 코더인 AI를 관리하는 역할을 수행하며 판단력 강화
  • AI가 능력을 저하시킬 수 있다는 우려에 대해, 제대로 활용하면 오히려 반대 결과
    • AI 코드 리뷰를 통해 새로운 관용구와 해결 방식 학습
    • AI의 실수를 디버깅하며 언어와 문제 도메인에 대한 이해 심화
    • 코드나 수정 이유를 설명하도록 요구해, 후보자를 인터뷰하듯 끊임없이 질문하고 인사이트 확보
    • 라이브러리나 접근법이 불분명할 때 AI를 리서치 어시스턴트로 활용해 옵션과 트레이드오프 비교
  • 큰 흐름에서 AI 도구는 전문성을 증폭
    • 2026년으로 갈수록 일자리를 빼앗길 두려움보다는, 반복적이고 단조로운 작업에서 벗어나 창의적이고 복잡한 문제에 더 많은 시간을 쓰게 될 기대
    • 반대로 탄탄한 기반이 없을 경우, AI가 스테로이드를 맞은 더닝-크루거로 이어질 위험도 존재
  • 조언으로는 기술을 지속적으로 연마하면서 AI로 학습과 생산성을 가속하고, 주기적으로 AI 없이 코딩해 기본기를 날카롭게 유지하는 의도적 균형 필요
  • 결국 개발자와 AI의 조합은 어느 한쪽만 있을 때보다 훨씬 강력하며, 그 조합에서 개발자 쪽이 자신의 역할을 충실히 수행해야 함

결론

  • AI를 개발 워크플로우 전반에 적극 도입했지만, 신중하고 전문가가 주도하는 방식을 유지
  • 지향하는 접근은 AI가 모든 것을 자동화하는 개발이 아니라, “AI-증강 소프트웨어 엔지니어링”
  • 최상의 결과는 AI와의 협업에 고전적인 소프트웨어 엔지니어링 규율을 그대로 적용할 때 도출
  • 설계 후 코딩, 테스트 작성, 버전 관리, 코드 표준 유지처럼 힘들게 쌓아온 모든 실천은 여전히 유효하며, AI가 코드의 절반을 작성하는 상황에서는 오히려 더 중요
  • 도구는 계속 발전하고, 워크플로우 역시 함께 진화할 전망
    • 완전 자율적인 “AI 개발 인턴”이 단순 작업을 더 많이 맡고, 인간은 고수준 문제에 집중
    • 새로운 디버깅 방식과 코드 탐색 패러다임이 등장할 가능성
  • 어떤 변화 속에서도 항상 루프 안에 머무는 태도를 유지
    • AI를 가이드하고, 결과를 검증하며, 그 과정에서 배우고, 책임 있게 생산성을 확장
  • 최종 결론은 명확함: AI 코딩 어시스턴트는 강력한 증폭기이지만, 무대의 디렉터는 끝까지 인간 엔지니어
▲
gracefullight 14시간전  [-]

추상화되면 될 수록 엔지니어링은 중요해지는 것 같습니다.

답변달기