AI를 활용한 유지보수 가능한 코드 작성 완전 가이드

게시 2026/01/16

By BLUEBUG

89 분읽는 시간

ArjanCodes의 철학과 Claude Code 실전 방법론

들어가며: AI 시대 개발자의 진짜 가치

2026년 현재, AI 코딩 도구는 더 이상 선택사항이 아닌 필수가 되었습니다. GitHub Copilot 사용자는 2천만 명을 돌파했고, 구글의 신규 프로덕션 코드 중 25%가 AI로 작성되며, 이 비율은 2026년 말까지 50%에 달할 것으로 예상됩니다. 그러나 이러한 통계 뒤에는 중요한 진실이 숨어 있습니다. AI가 생성한 코드 중 실제로 개발자들이 받아들이는 비율은 약 30%에 불과하며, 나머지 70%는 폐기되거나 대폭 수정됩니다.

더 심각한 문제는 코드 품질의 저하입니다. GitClear의 2024년 연구에 따르면 AI 보조 코딩이 도입된 이후 코드 중복은 4배 증가했고, 개발자들은 코드를 재사용하거나 리팩토링하는 대신 복사-붙여넣기를 더 많이 사용하고 있습니다. 이는 기술 부채의 급격한 증가를 의미하며, 장기적으로는 소프트웨어의 유지보수성을 크게 떨어뜨립니다.

그렇다면 AI 시대에 개발자의 진짜 가치는 무엇일까요? ArjanCodes는 명확한 답을 제시합니다. 미래의 개발자는 코드를 직접 타이핑하는 속도가 아니라, AI에게 올바른 설계 원칙을 지시하고 시스템을 견고하게 구조화하는 능력에서 그 가치가 결정됩니다. 좋은 설계를 아는 사람이 AI를 활용할 때 그렇지 못한 사람보다 10배 더 빠르게, 그리고 10배 더 유지보수 가능한 결과물을 낼 수 있습니다.

이 문서는 ArjanCodes의 “The Right Way to Use AI for Writing Maintainable Code” 영상에서 제시된 핵심 원칙들과 2026년 최신 Claude Code 개발 방법론을 통합하여, AI 시대에 진정으로 가치 있는 개발자가 되기 위한 실전 가이드를 제공합니다.

제1부: AI 코딩의 근본적인 패러다임 전환

1.1 사고방식의 전환: 속도에서 설계로

많은 개발자들이 AI 코딩 도구를 접하면서 가장 먼저 느끼는 것은 속도입니다. “10분 만에 작동하는 앱을 만들었다”는 성취감은 강력하지만 위험합니다. ArjanCodes는 이러한 접근 방식의 문제점을 명확히 지적합니다. 단순히 작동하는 코드를 빠르게 생성하는 것에만 집중하면, 장기적으로 복잡성 관리에 실패하게 됩니다.

좋은 설계의 핵심은 시스템의 복잡도를 낮추는 것입니다. 복잡도가 낮을수록 AI는 코드의 맥락을 더 잘 이해할 수 있고, 결과적으로 더 나은 코드를 생성합니다. 이는 선순환 구조를 만듭니다. 잘 설계된 시스템에서 AI는 더 정확한 제안을 하고, 이는 다시 시스템의 품질을 높입니다. 반대로 잘못 설계된 시스템에서는 AI가 맥락을 제대로 파악하지 못해 부적절한 코드를 생성하고, 이는 복잡도를 더욱 증가시키는 악순환을 초래합니다.

2026년 현재, 가장 성공적인 AI 코딩 사례들을 분석해보면 공통점이 있습니다. 이들은 모두 AI를 단순한 코드 생성기가 아닌 설계 파트너로 활용합니다. Claude Code의 창시자인 Boris Cherny는 Anthropic 내부에서 항상 Plan Mode를 먼저 사용하여 AI와 함께 설계를 완성한 후에야 코드 작성으로 넘어간다고 강조합니다. 이러한 접근 방식은 개발 시간이 더 걸리는 것처럼 보이지만, 전체 개발 수명주기를 고려하면 훨씬 더 효율적입니다.

1.2 AI의 첫 번째 결과물과 그 한계

ArjanCodes의 영상에서 제시된 사례는 AI 코딩의 현실을 잘 보여줍니다. AI에게 애니메이션 시스템을 구축하라고 요청했을 때, 처음에 생성된 코드는 기술적으로는 작동했습니다. 화면에 도형이 나타나고 움직였습니다. 그러나 코드의 구조는 엉망이었습니다. 모든 기능이 하나의 거대한 Animator 클래스에 몰려 있었고, 이동, 회전, 크기 조절 등의 로직이 거대한 if-else 문으로 묶여 있었습니다.

이러한 구조의 문제점은 명확합니다. 새로운 애니메이션 효과를 추가하려면 기존 코드를 수정해야 하므로 개방-폐쇄 원칙을 위반합니다. 각 기능이 서로 강하게 결합되어 있어 한 부분의 변경이 예상치 못한 부작용을 일으킬 수 있습니다. 테스트하기도 어렵습니다. 거대한 클래스를 통째로 테스트해야 하므로 단위 테스트의 이점을 얻을 수 없습니다.

여기서 중요한 교훈은 “작동한다”와 “잘 설계되었다”는 전혀 다른 개념이라는 것입니다. AI는 작동하는 코드를 만드는 데는 매우 능숙하지만, 좋은 설계는 여전히 인간 개발자의 영역입니다. 2026년 현재, Claude Opus 4.5나 GPT-5 같은 최신 모델들도 이 한계를 완전히 극복하지 못했습니다. 이들은 코드를 생성하는 텍스트 생성기일 뿐, 소프트웨어 아키텍처를 깊이 이해하는 시스템이 아니기 때문입니다.

1.3 반복적 협업의 힘

ArjanCodes가 강조하는 핵심 원칙 중 하나는 AI와의 반복적 협업입니다. AI의 첫 번째 결과물에 만족하지 않고, 디자인 패턴을 적용하여 코드의 구조를 개선하도록 계속 지시하는 것입니다. 애니메이션 시스템 예제에서 Arjan은 AI에게 커맨드 패턴을 적용하라고 지시했습니다. 그 결과 각 애니메이션 동작이 독립적인 클래스로 분리되었고, 모든 클래스가 AnimationStep이라는 공통 인터페이스를 따르게 되었습니다.

이러한 개선을 통해 코드는 진정으로 확장 가능해졌습니다. 새로운 애니메이션 효과를 추가하려면 새로운 클래스를 만들기만 하면 되고, 기존 코드를 전혀 수정할 필요가 없습니다. 각 클래스가 명확한 책임을 가지므로 테스트와 디버깅이 훨씬 쉬워집니다. 코드를 읽는 사람도 시스템의 구조를 쉽게 이해할 수 있습니다.

그러나 이 과정에서 새로운 문제가 발생했습니다. 순환 참조 문제였습니다. 애니메이션 단계가 애니메이터를 알고, 애니메이터가 단계를 아는 상황이 발생했습니다. Arjan은 AI에게 질문을 던졌습니다. “단계를 애니메이터로부터 독립시킬 방법이 없을까요?” 이 질문을 통해 AI는 더 나은 설계를 제안했습니다. 애니메이션 단계는 도형의 데이터만 수정하고, 구체적인 실행 로직은 분리되었습니다.

이 사례는 AI 코딩의 본질을 보여줍니다. AI는 강력한 코드 생성 능력을 가지고 있지만, 올바른 방향으로 이끄는 것은 개발자의 몫입니다. 개발자는 AI에게 “무엇을 할지”뿐만 아니라 “어떻게 할지”도 가르쳐야 합니다. 이는 단순한 프롬프트 엔지니어링을 넘어서는 것으로, 소프트웨어 설계 원칙에 대한 깊은 이해를 요구합니다.

제2부: 설계 원칙과 AI의 통합

2.1 도메인 책임의 명확한 분리

ArjanCodes 영상에서 가장 중요한 교훈 중 하나는 도메인 책임의 분리입니다. AI는 처음에 렌더링 로직과 애니메이션 로직을 섞어 놓았습니다. 화면에 도형을 그리는 코드와 도형을 움직이는 코드가 같은 클래스에 존재했습니다. 이는 단일 책임 원칙을 위반하는 전형적인 사례입니다.

Arjan은 AI에게 명확한 지시를 내렸습니다. “렌더러는 도형 객체를 몰라야 합니다. 단순히 점의 위치와 색상 정보만 받아야 합니다.” 이 지시의 핵심은 고수준의 비즈니스 로직과 저수준의 구현 세부사항을 분리하는 것입니다. 애니메이션은 고수준의 로직입니다. “이 도형을 오른쪽으로 100픽셀 이동시켜라”는 비즈니스 요구사항입니다. 반면 그래픽 렌더링은 저수준의 구현입니다. “이 픽셀들을 화면의 특정 위치에 그려라”는 기술적 세부사항입니다.

이러한 분리는 여러 이점을 제공합니다. 첫째, 렌더링 엔진을 바꾸더라도 애니메이션 로직은 그대로 유지할 수 있습니다. OpenGL에서 Vulkan으로 전환하거나, 브라우저 캔버스에서 WebGPU로 이동할 때 애니메이션 코드를 수정할 필요가 없습니다. 둘째, 각 레이어를 독립적으로 테스트할 수 있습니다. 애니메이션 로직은 실제 렌더링 없이 도형의 위치 변화만 검증하면 되고, 렌더러는 주어진 좌표에 올바르게 그리기만 하면 됩니다.

2026년 현재 Claude Code를 사용하는 개발자들도 같은 원칙을 적용하고 있습니다. Boris Cherny는 Anthropic에서 각 팀이 CLAUDE.md 파일에 아키텍처 가이드라인을 문서화하도록 권장합니다. 이 파일에는 “프론트엔드는 API 구현 세부사항을 몰라야 한다”, “데이터베이스 로직은 서비스 레이어에서 캡슐화한다” 같은 원칙들이 명시됩니다. AI는 이러한 원칙을 읽고 이를 준수하는 코드를 생성합니다.

2.2 추상화와 의존성 제거

순환 참조 문제는 AI가 생성한 코드에서 자주 발생하는 문제입니다. 두 모듈이 서로를 참조하면 시스템의 결합도가 높아지고, 변경이 어려워지며, 테스트가 복잡해집니다. ArjanCodes 영상에서는 이 문제를 해결하는 과정을 상세히 보여줍니다.

Arjan은 AI에게 질문 형태로 지시했습니다. “단계를 애니메이터로부터 독립시킬 방법이 없을까요?” 이는 중요한 접근 방식입니다. 단순히 “순환 참조를 제거해라”라고 명령하는 대신, AI가 스스로 해결책을 찾도록 유도한 것입니다. AI는 애니메이션 단계가 도형의 데이터만 수정하고, 애니메이터는 이러한 단계들을 순서대로 실행하는 구조를 제안했습니다.

이 해결책의 핵심은 의존성 역전 원칙입니다. 고수준 모듈인 애니메이터가 저수준 모듈인 구체적인 애니메이션 단계에 의존하는 대신, 둘 다 추상화인 AnimationStep 인터페이스에 의존합니다. 이를 통해 새로운 애니메이션 효과를 추가하거나 기존 효과를 수정할 때 애니메이터 코드를 건드릴 필요가 없어집니다.

Claude Code를 사용할 때도 같은 원칙을 적용할 수 있습니다. 2026년 베스트 프랙티스에 따르면, 개발자는 Claude에게 구체적인 구현보다는 인터페이스와 추상화를 먼저 정의하도록 요청해야 합니다. 예를 들어 “사용자 인증 시스템을 만들어라”라고 요청하기 전에, “인증 시스템의 핵심 인터페이스를 정의해라. 어떤 메서드들이 필요하고, 각 메서드는 무엇을 받고 무엇을 반환하는가?”라고 물어봅니다.

2.3 디자인 패턴의 전략적 활용

ArjanCodes는 커맨드 패턴을 애니메이션 시스템에 적용했습니다. 이는 단순히 코드를 정리하는 것 이상의 의미가 있습니다. 디자인 패턴은 검증된 솔루션의 청사진입니다. 수십 년간 소프트웨어 엔지니어링 커뮤니티가 축적한 지혜의 결정체입니다.

커맨드 패턴을 적용함으로써 각 애니메이션 동작이 독립적인 객체가 되었습니다. Move, Rotate, Scale은 모두 AnimationStep 인터페이스를 구현하는 별도 클래스입니다. 이는 여러 이점을 제공합니다. 첫째, 새로운 애니메이션 효과를 추가할 때 기존 코드를 수정하지 않아도 됩니다. Fade나 Bounce 같은 새 클래스를 만들기만 하면 됩니다. 둘째, 각 애니메이션을 독립적으로 테스트할 수 있습니다. 셋째, 애니메이션을 조합하거나 순서를 바꾸기가 쉽습니다.

2026년 현재 AI 코딩 도구들은 디자인 패턴에 대한 이해가 크게 향상되었습니다. Claude Opus 4.5는 GoF 디자인 패턴뿐만 아니라 현대적인 패턴들도 잘 알고 있습니다. 그러나 어떤 패턴을 언제 적용할지는 여전히 개발자가 결정해야 합니다. AI는 패턴의 구현은 완벽하게 할 수 있지만, 현재 문제에 어떤 패턴이 가장 적합한지 판단하는 것은 개발자의 경험과 직관이 필요한 영역입니다.

실전에서는 다음과 같은 접근이 효과적입니다. 먼저 Claude에게 현재 설계의 문제점을 설명하고, 어떤 디자인 패턴이 적합할지 제안하도록 합니다. Claude는 여러 옵션을 제시할 것입니다. 개발자는 각 옵션의 장단점을 평가하고 가장 적합한 것을 선택합니다. 그런 다음 Claude에게 선택한 패턴을 구현하도록 지시합니다. 이 과정에서 개발자는 AI의 지식을 활용하면서도 최종 결정권을 유지합니다.

2.4 알고리즘 버그와 도메인 지식

ArjanCodes 영상에서 가장 흥미로운 부분 중 하나는 AI가 범한 알고리즘 오류입니다. 애니메이션 좌표를 계산할 때 AI는 ‘누적 변형’ 방식을 사용했습니다. 매 프레임마다 이전 위치에 변화량을 더하는 방식이었습니다. 이는 이론적으로는 맞지만 실제로는 부동소수점 오차가 누적되어 도형이 점점 화면 밖으로 날아가는 문제가 발생했습니다.

Arjan은 AI에게 문제를 설명했지만 AI는 스스로 해결하지 못했습니다. 결국 Arjan이 직접 개입하여 올바른 접근법을 가르쳐야 했습니다. “기준점을 저장하고, 현재 시간에 따라 목표 위치를 계산하는 방식으로 바꿔야 합니다. 이렇게 하면 오차가 누적되지 않습니다.”

이 사례는 AI의 근본적인 한계를 보여줍니다. AI는 텍스트 패턴을 학습한 시스템입니다. 수학적, 물리적 원리를 진정으로 이해하는 것이 아니라 훈련 데이터에서 본 패턴을 재현할 뿐입니다. 따라서 미묘한 수치적 안정성 문제나 엣지 케이스는 놓칠 수 있습니다.

2026년 현재도 이 문제는 여전히 존재합니다. Claude Opus 4.5나 GPT-5는 놀라운 추론 능력을 가지고 있지만, 도메인 특화된 수학적 문제에서는 여전히 실수를 범할 수 있습니다. 따라서 개발자는 AI가 생성한 알고리즘을 항상 검증해야 합니다. 특히 수치 계산, 동시성 처리, 메모리 관리 같은 민감한 영역에서는 더욱 주의가 필요합니다.

실전 팁으로, Claude Code를 사용할 때는 알고리즘이 포함된 코드에 대해 항상 단위 테스트를 먼저 작성하도록 요청하세요. “이 정렬 알고리즘을 구현하기 전에, 예상 입력과 출력을 정의하는 테스트를 작성해주세요”라고 지시합니다. 그런 다음 TDD 방식으로 구현을 진행하면, 알고리즘의 정확성을 지속적으로 검증할 수 있습니다.

제3부: Claude Code 실전 개발 방법론

3.1 CLAUDE.md: AI의 프로젝트 뇌

Claude Code 개발 방법론에서 가장 중요한 요소는 CLAUDE.md 파일입니다. 이는 Claude가 자동으로 읽어 프로젝트 컨텍스트를 이해하는 특별한 문서입니다. 2026년 베스트 프랙티스에 따르면, 이 파일은 프로젝트의 “영구적인 뇌”로 기능해야 합니다.

효과적인 CLAUDE.md는 다음 내용을 포함합니다. 첫째, 아키텍처 개요입니다. “프론트엔드는 React 18 + TypeScript + Vite를 사용하고, 백엔드는 Node.js + Express + PostgreSQL을 사용한다” 같은 기술 스택 정보입니다. 둘째, 코드 스타일 가이드라인입니다. “함수형 컴포넌트와 훅만 사용한다”, “named export를 default export보다 선호한다”, “Tailwind 유틸리티 클래스만 사용한다” 같은 규칙들입니다.

셋째, 핵심 파일 위치입니다. “유틸리티는 /src/utils/에 있고, API 엔드포인트는 /src/api/endpoints/에 있으며, 타입 정의는 /src/types/에 있다” 같은 디렉토리 구조 설명입니다. 넷째, 주요 명령어입니다. “개발 서버는 npm run dev, 테스트는 npm run test, 빌드는 npm run build로 실행한다” 같은 정보입니다.

Anthropic 내부에서는 각 팀이 실수와 학습 내용을 CLAUDE.md에 계속 추가합니다. Boris Cherny는 동료의 PR에 @.claude 태그를 달아 중요한 통찰을 문서화합니다. 그의 팀의 CLAUDE.md는 현재 2,500토큰 정도이며, 이는 프로젝트가 성숙할수록 계속 성장합니다. 이 문서는 단순한 README가 아닙니다. AI가 매 세션마다 읽고 따라야 하는 살아있는 가이드라인입니다.

실전에서는 프로젝트 시작 시 /init 명령어로 CLAUDE.md를 자동 생성할 수 있습니다. Claude는 코드베이스를 분석하여 초기 문서를 만들어줍니다. 그런 다음 개발자가 이를 검토하고 프로젝트별 규칙을 추가합니다. 30분 정도 투자하여 좋은 CLAUDE.md를 만들면, 그 후 수개월 동안 생산성 향상의 혜택을 받을 수 있습니다.

3.2 Plan Mode: 코딩 전 설계의 중요성

ArjanCodes가 강조한 “설계 우선” 철학은 Claude Code의 Plan Mode에서 구체화됩니다. Boris Cherny는 항상 Plan Mode를 먼저 사용한다고 강조합니다. “PR을 작성하는 것이 목표라면, Plan Mode를 사용하여 Claude와 계획을 완성할 때까지 반복합니다. 계획이 마음에 들면 auto-edit 모드로 전환하고, Claude는 보통 한 번에 완성합니다. 좋은 계획이 정말 중요합니다!”

Plan Mode는 Shift+Tab 키를 두 번 눌러 활성화됩니다. 이 모드에서 Claude는 파일을 실제로 수정할 수 없는 “아키텍트 모드”로 전환됩니다. 관찰하고, 분석하고, 계획할 수는 있지만 실행은 할 수 없습니다. 이는 의도적인 제약입니다. 코드를 작성하기 전에 충분히 생각하도록 강제하는 것입니다.

Plan Mode에서 Claude는 일관된 형식으로 응답합니다. 이는 AI의 출력이 너무 장황하거나 일관성이 없는 문제를 해결합니다. 개발자는 계획을 검토하고, 필요하면 수정을 요청하고, 만족할 때까지 반복합니다. 계획이 확정되면 일반 모드로 전환하여 실제 구현을 시작합니다.

2026년 베스트 프랙티스는 다음과 같은 3단계 워크플로우를 제안합니다. 첫 번째, 연구 단계입니다. Claude에게 문제를 설명하고 관련 파일을 읽도록 합니다. “우리 인증 시스템을 분석하고 OAuth 통합을 위해 어떤 변경이 필요한지 조사해주세요.” 두 번째, 계획 단계입니다. Claude가 상세한 구현 계획을 작성하도록 합니다. “5단계로 나눈 구현 계획을 작성해주세요. 각 단계에서 어떤 파일을 수정하고, 어떤 테스트를 추가할지 명시해주세요.”

세 번째, 구현 단계입니다. 계획을 승인한 후 auto-edit 모드로 전환하여 Claude가 코드를 작성하도록 합니다. 이 3단계 접근은 AI가 바로 코드를 작성하는 것을 방지합니다. 1-2단계 없이 바로 코딩으로 넘어가면 Claude는 충분한 맥락 이해 없이 코드를 생성하고, 결과물의 품질이 떨어집니다.

3.3 TDD와 AI의 강력한 조합

ArjanCodes는 명시적이지는 않지만 테스트 주도 개발의 원칙을 따릅니다. 먼저 기대하는 동작을 정의하고, 그에 맞춰 코드를 개선하는 방식입니다. Claude Code에서는 이를 더 체계적으로 적용할 수 있습니다.

Anthropic가 권장하는 TDD 워크플로우는 다음과 같습니다. 첫째, Claude에게 예상 입출력 쌍을 기반으로 테스트를 작성하도록 요청합니다. “사용자가 잘못된 이메일 형식을 입력하면 ‘유효한 이메일을 입력하세요’ 에러가 반환되어야 합니다. 이를 검증하는 테스트를 작성해주세요.” 둘째, TDD를 하고 있다는 것을 명시적으로 알립니다. “우리는 TDD를 하고 있습니다. 아직 존재하지 않는 기능에 대해서도 목 구현을 만들지 마세요.”

셋째, Claude에게 테스트를 실행하고 실패를 확인하도록 합니다. “테스트를 실행하고 실패하는지 확인해주세요. 이 단계에서는 어떤 구현 코드도 작성하지 마세요.” 넷째, 테스트가 통과할 때까지 최소한의 구현을 추가하도록 합니다. 다섯째, 테스트가 통과하면 코드를 리팩토링하여 품질을 높입니다.

이 접근법은 여러 이점을 제공합니다. 테스트가 먼저 작성되므로 요구사항이 명확해집니다. AI는 테스트를 통과하는 최소한의 코드를 작성하므로 불필요한 복잡성이 줄어듭니다. 각 변경 후 테스트를 실행하여 회귀를 즉시 발견할 수 있습니다. 리팩토링 시 테스트가 안전망 역할을 합니다.

실제 사례를 보면, Boris Cherny는 claude.ai/code에 배포하는 모든 변경사항을 Claude Chrome 확장 프로그램으로 테스트합니다. Claude가 브라우저를 열고 UI를 테스트하며, 코드가 작동하고 UX가 좋을 때까지 반복합니다. 이는 완전히 자동화된 엔드투엔드 테스트로, AI가 QA 역할도 수행하는 것입니다.

3.4 병렬 세션과 작업 관리

Boris Cherny의 워크플로우에서 주목할 점은 병렬 세션 활용입니다. 그는 MacBook 터미널에서 5개, Anthropic 웹사이트에서 5-10개, 총 10-15개의 Claude 세션을 동시에 실행합니다. 각 세션은 서로 다른 작업을 처리하며, 충돌을 피하기 위해 각각 자체 git checkout을 사용합니다.

이 접근법은 여러 면에서 효율적입니다. 첫째, 컨텍스트 오염을 방지합니다. 각 세션이 단일 목적을 가지므로 서로 다른 관심사가 섞이지 않습니다. 둘째, 블로킹을 줄입니다. 한 세션이 긴 작업을 수행하는 동안 다른 세션으로 작업을 계속할 수 있습니다. 셋째, 실험을 장려합니다. 새로운 접근법을 시도할 별도 세션을 만들고, 실패하면 간단히 폐기할 수 있습니다.

Cherny는 세션의 10-20%를 예상치 못한 시나리오로 인해 포기한다고 말합니다. 이는 문제가 아니라 장점입니다. 빠르게 실험하고 효과가 없으면 빠르게 포기하는 것은 소프트웨어 개발의 건전한 접근법입니다. 한 세션에 집착하여 계속 수정하는 것보다 새로운 세션으로 다시 시작하는 것이 종종 더 빠릅니다.

실전에서는 세션을 다음과 같이 구조화할 수 있습니다. 메인 개발 세션은 현재 작업 중인 주요 기능에 집중합니다. 리팩토링 세션은 코드 품질 개선을 담당합니다. 버그 수정 세션은 발견된 이슈를 처리합니다. 문서화 세션은 README와 주석 업데이트를 담당합니다. 테스트 세션은 누락된 테스트를 추가합니다.

각 세션은 명확한 목표를 가지고 시작해야 합니다. “이 세션의 목표는 사용자 프로필 API를 구현하는 것입니다”라고 Claude에게 명시합니다. 목표를 달성하면 세션을 종료하고 변경사항을 커밋합니다. 이는 작업을 관리 가능한 단위로 나누고, 진행 상황을 명확히 추적하는 데 도움이 됩니다.

3.5 서브에이전트와 특화된 작업

Claude Code는 서브에이전트 기능을 제공합니다. 이는 특정 작업을 위한 전문화된 AI 인스턴스를 만드는 것입니다. 예를 들어 디버깅만 담당하는 에이전트, 보안 검토만 하는 에이전트, 성능 최적화만 하는 에이전트를 만들 수 있습니다.

디버거 에이전트의 시스템 프롬프트는 다음과 같을 수 있습니다. “당신은 디버거 에이전트입니다. 오직 버그를 식별하고 수정하는 것만 합니다. 스타일 제안, 리팩토링, 새 기능 추가는 하지 마세요. 버그를 찾으면 근본 원인을 설명하고 최소한의 수정으로 해결하세요.”

보안 검토 에이전트는 이렇게 설정할 수 있습니다. “코드를 오직 보안 취약점만을 위해 검토하세요. SQL 인젝션, XSS, 인증 결함, 데이터 노출, 안전하지 않은 의존성을 찾으세요. 심각도 등급과 수정 방법을 제공하세요. 스타일 제안은 하지 마세요.”

서브에이전트의 이점은 컨텍스트 관리입니다. 복잡한 작업을 여러 전문화된 단계로 나누면 각 단계는 필요한 정보만 집중할 수 있습니다. 또한 재사용성이 높아집니다. 같은 디버거 에이전트를 여러 프로젝트에서 사용할 수 있습니다.

그러나 서브에이전트에는 단점도 있습니다. 2026년 실무자들의 피드백에 따르면, 서브에이전트는 컨텍스트를 게이트키핑할 수 있습니다. 테스팅 서브에이전트를 만들면 메인 에이전트는 테스트 컨텍스트를 잃어버립니다. 변경사항에 대해 전체적으로 추론할 수 없게 되고, 테스트 방법을 알기 위해 서브에이전트를 호출해야 합니다.

또한 서브에이전트는 경직된 인간 워크플로우를 강제할 수 있습니다. AI에게 “먼저 계획하고, 그 다음 구현하고, 마지막에 테스트해라”라고 지시하는 것은 인간의 작업 방식입니다. 그러나 AI는 이러한 순차적 접근보다 더 유연한 방식이 더 효과적일 수 있습니다.

따라서 2026년 베스트 프랙티스는 서브에이전트를 신중하게 사용하는 것입니다. 명확하게 독립적인 작업에만 사용하세요. 예를 들어 문서 생성, 번역, 특정 도메인의 분석 같은 것입니다. 메인 개발 흐름에 필수적인 작업은 메인 에이전트가 직접 처리하도록 하세요.

3.6 이미지와 비주얼 컨텍스트 활용

ArjanCodes는 영상에서 직접 언급하지 않았지만, Claude Code의 강력한 기능 중 하나는 이미지 처리입니다. 2026년 Claude Opus 4.5는 뛰어난 비전 능력을 갖추고 있어, 스크린샷, 디자인 목업, 다이어그램을 코드로 변환할 수 있습니다.

실전 활용법을 보면, macOS에서는 cmd+ctrl+shift+4로 스크린샷을 클립보드에 복사한 후 ctrl+v로 Claude에 붙여넣을 수 있습니다. (주의: 일반적인 mac 붙여넣기인 cmd+v가 아닙니다) 디자인 목업을 드래그 앤 드롭하여 UI 구현의 참조로 사용할 수 있습니다. 차트나 그래프를 공유하여 데이터 분석과 디버깅에 활용할 수 있습니다.

이는 특히 프론트엔드 개발에서 유용합니다. 디자이너가 제공한 Figma 목업 스크린샷을 Claude에게 보여주고 “이 디자인을 React 컴포넌트로 구현해주세요. Tailwind CSS를 사용하고, 반응형이어야 합니다”라고 요청하면, Claude는 놀라울 정도로 정확한 구현을 제공합니다.

또한 에러 메시지 스크린샷도 유용합니다. 복잡한 스택 트레이스를 복사-붙여넣기하는 대신 스크린샷을 찍어 Claude에게 보여주면, Claude는 이미지에서 텍스트를 읽고 문제를 분석합니다. 브라우저의 네트워크 탭이나 개발자 도구 스크린샷도 디버깅에 도움이 됩니다.

심지어 손으로 그린 스케치도 작동합니다. 화이트보드에 시스템 아키텍처를 그리고 사진을 찍어 Claude에게 보여주면, Claude는 다이어그램을 이해하고 그에 맞는 코드 구조를 제안할 수 있습니다. 이는 팀 회의에서 나온 아이디어를 빠르게 프로토타입하는 데 특히 유용합니다.

3.7 MCP 서버와 도구 확장

2026년 Claude Code 생태계의 중요한 발전은 Model Context Protocol (MCP) 서버입니다. MCP는 Claude가 외부 도구와 데이터 소스에 접근할 수 있게 하는 표준화된 방식입니다. 이를 통해 Claude는 단순한 코드 생성기에서 자율적인 개발 에이전트로 진화합니다.

MCP 서버의 예를 보면, 데이터베이스 MCP는 Claude가 직접 데이터베이스 스키마를 조회하고 쿼리를 실행할 수 있게 합니다. “users 테이블의 구조를 보고, 최근 가입한 사용자 10명을 조회하는 API를 만들어주세요”라고 요청하면 Claude는 실제 스키마를 확인하고 정확한 쿼리를 작성합니다.

Slack MCP는 Claude가 팀 커뮤니케이션에 통합됩니다. “어제 엔지니어링 채널에서 논의된 API 변경사항을 구현해주세요”라고 하면 Claude는 Slack에서 관련 대화를 찾아 요구사항을 파악하고 구현합니다.

GitHub MCP는 이슈와 PR 관리를 자동화합니다. “이슈 #123을 읽고, 테스트와 함께 구현한 후 PR을 생성해주세요”라고 요청하면 Claude는 전체 워크플로우를 처리합니다.

그러나 2026년 커뮤니티 피드백에 따르면, MCP는 만능 해결책이 아닙니다. 많은 개발자들은 MCP 대신 간단한 CLI 도구를 선호합니다. 그 이유는 투명성입니다. CLI는 정확히 무엇을 하는지 명확하지만, MCP 서버는 블랙박스처럼 느껴질 수 있습니다. 또한 디버깅이 쉽습니다. CLI는 --verbose 플래그로 쉽게 디버그할 수 있지만 MCP는 더 복잡합니다.

베스트 프랙티스는 균형 잡힌 접근입니다. 자주 사용하고 잘 정의된 작업에는 MCP를 사용하세요. 예를 들어 표준 데이터베이스 작업이나 일반적인 API 호출입니다. 프로젝트별 특수한 작업에는 간단한 bash 스크립트나 CLI를 만드세요. 이는 더 빠르고 이해하기 쉽습니다.

제4부: 코드 품질과 유지보수성

4.1 타입 시스템의 전략적 활용

ArjanCodes는 영상에서 타입 힌트의 중요성을 강조합니다. Python의 타입 어노테이션은 단순히 문서화를 위한 것이 아닙니다. AI가 코드의 의도를 이해하는 데 결정적인 역할을 합니다. 함수가 List[AnimationStep]을 받는다고 명시하면, AI는 이 리스트에 어떤 객체가 들어갈 수 있는지 정확히 알 수 있습니다.

2026년 현재 Claude Opus 4.5는 타입 시스템을 매우 잘 이해합니다. TypeScript, Python, Rust 같은 언어에서 타입을 활용하여 더 안전한 코드를 생성합니다. 개발자는 이를 전략적으로 활용해야 합니다.

첫째, 인터페이스를 먼저 정의하세요. 구현을 작성하기 전에 “이 서비스의 퍼블릭 인터페이스를 타입으로 정의해주세요”라고 요청합니다. Claude는 메서드 시그니처, 파라미터 타입, 리턴 타입을 정의합니다. 이는 구현의 청사진 역할을 합니다.

둘째, 제네릭을 적극 활용하세요. “이 리스트 처리 함수를 제네릭으로 만들어 모든 타입의 리스트에서 작동하도록 해주세요”라고 요청하면 Claude는 타입 안전성을 유지하면서도 재사용 가능한 코드를 만듭니다.

셋째, 타입 가드를 사용하세요. TypeScript에서는 런타임 타입 체크가 필요한 경우가 많습니다. “이 API 응답의 타입 가드를 작성해주세요. 예상하지 못한 형식이 오면 에러를 던져야 합니다”라고 지시하면 Claude는 견고한 검증 로직을 만듭니다.

실전 예제를 보면, Anthropic 팀은 CLAUDE.md에 타입 정책을 명시합니다. “모든 퍼블릭 함수는 타입 어노테이션을 가져야 한다”, “any 타입 사용을 피하고 unknown을 선호한다”, “외부 API 응답은 반드시 타입 검증을 거쳐야 한다” 같은 규칙들입니다.

4.2 최신 언어 기능과 관례

ArjanCodes는 최신 Python 문법 사용을 강조합니다. 구식 관례 대신 현대적인 접근을 따르는 것이 중요합니다. 2026년 Claude는 각 언어의 최신 베스트 프랙티스를 잘 알고 있지만, 때로는 명시적인 지시가 필요합니다.

Python에서는 다음을 요청할 수 있습니다. “Python 3.12 기능을 사용하세요. match-case 문, 구조적 패턴 매칭, 타입 가드를 활용하세요.” TypeScript에서는 “TypeScript 5.3 기능을 사용하세요. satisfies 연산자, const 타입 파라미터를 활용하세요.” Rust에서는 “Rust 2024 edition을 사용하세요. async/await, 에러 핸들링에 ? 연산자를 사용하세요.”

언어별 관례도 중요합니다. Python에서는 “PEP 8을 따르세요. snake_case 명명, 79자 줄 길이 제한을 준수하세요.” JavaScript에서는 “Airbnb 스타일 가이드를 따르세요. const를 선호하고, 화살표 함수를 사용하세요.” Go에서는 “gofmt 형식을 따르세요. 에러는 항상 명시적으로 처리하세요.”

CLAUDE.md에 이러한 규칙을 명시하면 Claude는 일관된 스타일로 코드를 생성합니다. “이 프로젝트는 Prettier와 ESLint를 사용합니다. .prettierrc와 .eslintrc 설정을 따르세요”라고 문서화하면, Claude는 자동으로 프로젝트 설정을 읽고 준수합니다.

4.3 의존성 주입과 결합도 낮추기

ArjanCodes 영상에서 의존성 주입이 어떻게 코드의 결합도를 낮추는지 보여줍니다. 애니메이션 렌더러를 하드코딩하는 대신 생성자를 통해 주입받으면, 테스트 시 목 렌더러를 사용할 수 있고, 나중에 다른 렌더러로 쉽게 교체할 수 있습니다.

Claude Code에서 의존성 주입을 구현할 때는 명시적으로 요청해야 합니다. “이 서비스가 데이터베이스를 직접 생성하지 말고 생성자에서 주입받도록 리팩토링해주세요. 이렇게 하면 테스트에서 목 데이터베이스를 사용할 수 있습니다.”

의존성 주입 컨테이너를 사용하는 프로젝트에서는 더 구체적으로 지시할 수 있습니다. “이 클래스를 NestJS의 의존성 주입 시스템에 등록해주세요. @Injectable 데코레이터를 사용하고, providers 배열에 추가하세요.”

Python에서는 “이 함수가 환경 변수를 직접 읽지 말고 의존성으로 받도록 해주세요. 이렇게 하면 테스트에서 다른 설정을 주입할 수 있습니다”라고 요청할 수 있습니다.

의존성 주입의 이점은 테스트 용이성만이 아닙니다. 코드가 더 모듈화되고 재사용 가능해집니다. 각 컴포넌트가 독립적으로 발전할 수 있습니다. 시스템의 다른 부분을 건드리지 않고 특정 구현을 교체할 수 있습니다.

4.4 리팩토링: 작동하는 코드를 좋은 코드로

ArjanCodes의 전체 영상은 사실상 리팩토링 과정입니다. 작동하는 코드에서 시작하여 점진적으로 개선해 나갑니다. 이는 AI 코딩에서 권장되는 접근법입니다. 한 번에 완벽한 코드를 만들려고 하지 말고, 반복적으로 개선하세요.

Claude Code에서 효과적인 리팩토링 워크플로우는 다음과 같습니다. 첫째, 현재 상태를 파악합니다. “이 파일의 코드 스멜과 개선 기회를 분석해주세요.” Claude는 긴 메서드, 중복 코드, 높은 결합도 같은 문제를 식별합니다.

둘째, 우선순위를 정합니다. “가장 중요한 3가지 개선사항을 제안하고, 각각의 이유를 설명해주세요.” 모든 것을 한 번에 리팩토링하려 하지 마세요. 가장 큰 가치를 제공하는 것부터 시작합니다.

셋째, 테스트로 보호합니다. “리팩토링 전에 이 클래스의 현재 동작을 보장하는 테스트를 작성해주세요.” 리팩토링은 기능을 변경하지 않아야 하므로 테스트가 안전망 역할을 합니다.

넷째, 작은 단계로 진행합니다. “먼저 이 긴 메서드를 여러 작은 메서드로 분리해주세요. 각 단계 후 테스트를 실행하세요.” 큰 변경을 한 번에 하면 무엇이 잘못되었는지 찾기 어렵습니다. 작은 단계는 각 변경의 영향을 명확히 합니다.

다섯째, 검증하고 커밋합니다. 각 리팩토링 단계 후 테스트를 실행하고, 통과하면 커밋합니다. 이렇게 하면 문제가 발생했을 때 쉽게 되돌릴 수 있습니다.

제5부: 실전 워크플로우와 팁

5.1 Boris Cherny의 8단계 워크플로우

Claude Code 창시자인 Boris Cherny의 실전 워크플로우는 2026년 베스트 프랙티스의 정수입니다. 그의 접근법을 단계별로 살펴보겠습니다.

1단계: 모델 선택과 환경 설정 Cherny는 모든 코딩 작업에 Opus 4.5를 사용합니다. Sonnet보다 느리지만 품질과 신뢰성을 우선시합니다. “속도보다 정확성이 중요합니다. Opus의 높은 품질은 재작업 시간을 줄여 결국 더 빠릅니다.”

환경 변수 설정도 중요합니다. ANTHROPIC_API_KEY를 엔터프라이즈 키로 설정하여 사용량 기반 과금을 활용합니다. MCP_TOOL_TIMEOUT과 BASH_MAX_TIMEOUT_MS를 늘려 복잡한 명령도 처리할 수 있게 합니다.

2단계: 터미널 기반 세팅 Cherny는 VS Code 같은 무거운 IDE 대신 경량 터미널 환경을 선호합니다. Ghosty 같은 도구로 여러 터미널을 효율적으로 관리합니다. 이는 시스템 자원을 절약하고 주의 산만을 줄입니다.

3단계: CLAUDE.md 준비 각 프로젝트의 CLAUDE.md에 실수와 학습 내용을 지속적으로 추가합니다. PR 리뷰에서 발견한 통찰을 @.claude 태그로 표시하여 문서화합니다. 이는 팀 전체의 지식을 축적하는 메커니즘입니다.

4단계: Plan Mode로 시작 어떤 코딩 작업이든 Plan Mode로 시작합니다. 계획이 만족스러울 때까지 반복하고, 그 후에야 구현 모드로 전환합니다. “좋은 계획 없이 코딩을 시작하면 나중에 더 많은 시간을 낭비합니다.”

5단계: 병렬 세션 활용 10-15개의 세션을 동시에 운영하며, 각각 독립적인 git checkout을 사용합니다. CLI에서 세션을 &로 백그라운드로 시작하고, --teleport로 원격과 로컬 간 이동합니다.

6단계: 커스텀 명령어와 서브에이전트 반복적인 워크플로우를 슬래시 명령어로 자동화합니다. /commit, /pr, /simplify, /verify 같은 명령어가 일상적인 작업을 처리합니다.

7단계: 자동화된 검증 모든 변경사항을 Claude Chrome 확장으로 자동 테스트합니다. AI가 브라우저를 제어하여 UI를 테스트하고, 문제를 발견하면 반복합니다. “코드 리뷰 시점에 코드는 이미 좋은 상태여야 합니다.”

8단계: 지속적인 학습과 문서화 각 PR에서 배운 내용을 CLAUDE.md에 추가합니다. 실수는 미래의 가이드라인이 되고, 성공한 패턴은 표준이 됩니다. 이는 팀의 집단 지능을 지속적으로 향상시킵니다.

5.2 프롬프트 작성의 기술

좋은 프롬프트는 좋은 코드의 전제조건입니다. 2026년 베스트 프랙티스에 따르면 효과적인 프롬프트는 다음 특징을 가집니다.

명확성과 구체성 나쁜 예: “사용자 인증을 만들어줘” 좋은 예: “JWT 기반 사용자 인증 시스템을 만들어주세요. /auth/login 엔드포인트는 이메일과 비밀번호를 받아 토큰을 반환합니다. /auth/verify는 토큰의 유효성을 검증합니다. bcrypt로 비밀번호를 해싱하고, 토큰은 24시간 유효합니다.”

파일 참조 탭 완성을 사용하여 구체적인 파일을 참조하세요. “src/auth/login.ts와 src/middleware/auth.ts를 수정하여…” Claude는 정확한 파일을 알면 더 정확한 코드를 생성합니다.

외부 컨텍스트 제공 URL을 직접 붙여넣어 문서를 참조하세요. “https://docs.example.com/api 의 API 스펙을 읽고 그에 맞는 클라이언트를 구현해주세요.” Claude는 URL을 fetch하여 최신 정보를 얻습니다.

예제 제공 입출력 예제를 명시하세요. “입력이 {email: ‘user@example.com’, password: ‘12345’}일 때 출력은 {token: ‘jwt…’, expiresIn: 86400}이어야 합니다.”

제약 조건 명시 “Express와 TypeScript를 사용하세요. class-validator로 입력을 검증하고, class-transformer로 DTO를 변환하세요. 에러는 HTTP 상태 코드와 함께 JSON으로 반환하세요.”

5.3 /rewind와 실수 복구

Claude Code의 /rewind 명령어는 실수를 안전하게 되돌리는 강력한 도구입니다. AI가 잘못된 방향으로 가거나 예상치 못한 변경을 했을 때, 마지막 안전한 상태로 돌아갈 수 있습니다.

사용 시나리오를 보면, Claude가 리팩토링 중 의도치 않게 기능을 변경했을 때 /rewind로 이전 상태로 돌아갑니다. 병합 충돌이 복잡하게 발생했을 때 rewind 후 다른 접근으로 시도합니다. 실험적인 변경이 효과가 없을 때 빠르게 포기하고 다시 시작합니다.

Rewind는 git checkout과 다릅니다. Git은 커밋된 변경만 되돌리지만 rewind는 Claude 세션 내의 모든 변경을 추적합니다. 따라서 아직 커밋하지 않은 여러 단계의 작업도 되돌릴 수 있습니다.

베스트 프랙티스는 중요한 변경 전에 명시적인 체크포인트를 만드는 것입니다. “지금 상태를 저장해주세요. 다음 리팩토링이 문제가 있으면 여기로 돌아올 것입니다.” Claude는 이를 기억하고, 필요시 정확히 그 지점으로 되돌릴 수 있습니다.

5.4 효율적인 컨텍스트 관리

AI의 컨텍스트 윈도우는 유한합니다. Claude Opus 4.5는 200,000 토큰의 컨텍스트를 가지지만, 이를 효율적으로 사용해야 합니다. 불필요한 정보로 가득 차면 중요한 것을 놓칠 수 있습니다.

새 대화 시작하기 복잡한 작업이 완료되면 /clear로 새 대화를 시작하세요. 이전 컨텍스트의 잔여물이 새 작업을 방해하는 것을 방지합니다. Boris Cherny는 각 PR마다 새 세션을 시작한다고 합니다.

관련 파일만 포함하기 프로젝트 전체를 컨텍스트에 넣지 마세요. 작업과 직접 관련된 파일만 참조하세요. “src/auth/ 디렉토리만 분석해주세요”가 “전체 프로젝트를 분석해주세요”보다 효과적입니다.

문서는 선택적으로 모든 API 문서를 한 번에 제공하지 마세요. 필요한 부분만 URL로 참조하세요. “이 엔드포인트의 스펙은 docs.example.com/api/users#create에 있습니다.”

주기적인 정리 대화가 길어지면 Claude에게 요약을 요청하세요. “지금까지 우리가 한 변경사항을 요약하고, 다음 단계를 명확히 해주세요.” 이는 컨텍스트를 정리하고 다음 작업에 집중하게 합니다.

5.5 지속적인 품질 관리

ArjanCodes가 강조하듯이, AI가 생성한 코드는 항상 검토가 필요합니다. 2026년에도 75%의 개발자가 AI 코드를 병합 전에 수동으로 검토한다고 합니다. 이는 필수적입니다.

코드 리뷰 체크리스트 Claude가 코드를 생성한 후 다음을 확인하세요. 기능이 요구사항을 정확히 충족하는가? 엣지 케이스가 처리되는가? 에러 핸들링이 적절한가? 보안 취약점이 없는가? 성능 이슈가 없는가? 테스트가 충분한가? 문서화가 되어 있는가?

자동화된 검증 린터와 포매터를 CI/CD에 통합하세요. Prettier, ESLint, pylint 같은 도구가 스타일 문제를 자동으로 잡습니다. 타입 체커(TypeScript, mypy)를 실행하여 타입 안전성을 검증합니다. 테스트 커버리지를 추적하여 충분한 테스트가 있는지 확인합니다.

정기적인 리팩토링 기술 부채가 쌓이기 전에 정기적으로 리팩토링하세요. 매 스프린트 말에 “이번 주 추가된 코드 중 리팩토링이 필요한 부분을 식별해주세요”라고 Claude에게 요청합니다. 작은 개선을 지속적으로 하는 것이 나중에 큰 리팩토링을 하는 것보다 효율적입니다.

제6부: 미래를 위한 준비

6.1 AI 시대 개발자의 핵심 역량

ArjanCodes가 제시한 미래상은 명확합니다. 앞으로 개발자의 가치는 다음 세 가지에서 결정됩니다.

설계 원칙의 이해 SOLID 원칙, 디자인 패턴, 아키텍처 스타일을 깊이 이해하고 AI에게 올바르게 지시할 수 있어야 합니다. 단순히 “코드를 짜라”가 아니라 “이 구조로, 이 원칙을 따르며 짜라”고 말할 수 있어야 합니다.

책임의 분리 시스템을 적절한 모듈로 나누고, 각 부분의 경계를 명확히 정의하는 능력입니다. 어떤 로직이 어디에 속하는지, 어떤 모듈이 무엇을 알아야 하는지 결정하는 것은 여전히 인간의 영역입니다.

유지보수성 최우선 10배 빠른 속도로 코드를 짜더라도, 그 코드를 계속 확장할 수 없다면 무의미합니다. 6개월 후에도 이해하고 수정할 수 있는 코드를 만드는 것이 진짜 실력입니다.

2026년 현재 이러한 역량의 중요성은 더욱 커졌습니다. AI가 코드 생성은 더 잘하지만, 좋은 설계를 아는 개발자가 AI를 활용할 때 진정한 시너지가 발생합니다. Stack Overflow 2025 조사에 따르면, AI 역량을 가진 신입 개발자는 전통적인 신입보다 50-100% 높은 연봉을 받습니다. 그러나 이는 단순히 AI 도구를 사용할 줄 안다는 것이 아니라, AI를 전략적으로 활용하여 더 나은 소프트웨어를 만들 수 있다는 것을 의미합니다.

6.2 계속 학습하기: 변화하는 환경 적응

AI 코딩 도구는 빠르게 진화하고 있습니다. 2026년 1월 현재도 새로운 모델과 도구가 계속 출시됩니다. Claude Opus 4.5, GPT-5, Gemini 3.0 등은 이전 버전보다 훨씬 뛰어난 능력을 보입니다. 개발자는 이러한 변화를 따라가야 합니다.

최신 모델 실험하기 새 모델이 출시되면 실제 프로젝트에서 테스트하세요. 벤치마크 점수만 보지 말고 여러분의 실제 작업에서 어떻게 작동하는지 확인하세요. 각 모델의 강점과 약점을 파악하세요. Opus는 복잡한 추론에, Sonnet은 빠른 반복에 더 좋을 수 있습니다.

커뮤니티 참여 Reddit의 r/ClaudeAI, r/ChatGPT 같은 커뮤니티에서 다른 개발자들의 경험을 배우세요. Twitter/X에서 @AnthropicAI, @OpenAI 같은 공식 계정을 팔로우하세요. GitHub에서 오픈소스 AI 도구들을 살펴보고 기여하세요.

베스트 프랙티스 공유 여러분만의 워크플로우가 효과적이라면 블로그 포스트나 GitHub repo로 공유하세요. 다른 사람의 피드백을 받고 개선하세요. Boris Cherny처럼 트위터에서 자신의 방법론을 공유하면, 커뮤니티가 더 나은 아이디어를 제안할 수 있습니다.

실험적 태도 유지 새로운 접근법을 두려워하지 마세요. Cherny가 세션의 10-20%를 포기한다고 했듯이, 실패는 학습의 일부입니다. 무엇이 효과가 있고 없는지 발견하는 유일한 방법은 시도하는 것입니다.

6.3 윤리적 고려사항

AI 코딩이 보편화되면서 윤리적 질문들이 등장합니다. 개발자는 이를 진지하게 고려해야 합니다.

코드 소유권과 책임 AI가 생성한 코드라도 최종 책임은 개발자에게 있습니다. 보안 취약점, 성능 문제, 버그는 모두 여러분의 책임입니다. “AI가 만들었으니까”는 변명이 될 수 없습니다. 따라서 AI 코드를 철저히 검토하고 이해해야 합니다.

데이터 프라이버시 회사의 민감한 코드나 데이터를 AI 도구에 입력할 때 주의하세요. 많은 도구가 입력을 훈련에 사용할 수 있습니다. 엔터프라이즈 라이선스를 사용하거나, 온프레미스 솔루션을 고려하세요. Anthropic의 Bedrock 통합이나 Google의 Vertex AI가 이러한 우려를 해결합니다.

일자리와 직업의 미래 MIT Technology Review의 2025년 연구에 따르면 22-25세 소프트웨어 개발자 고용이 20% 감소했습니다. 이는 AI의 영향으로 보입니다. 그러나 이는 개발자가 필요 없다는 것이 아니라, 필요한 개발자의 유형이 변하고 있다는 것입니다. 코드를 타이핑하는 것보다 설계, 아키텍처, 시스템 사고가 더 중요해집니다.

6.4 2026년 이후: 에이전틱 코딩의 미래

2026년은 에이전틱 코딩의 원년이라 할 수 있습니다. AI가 단순히 코드를 제안하는 것을 넘어 자율적으로 복잡한 작업을 수행하는 에이전트로 진화하고 있습니다.

완전 자율 개발 Devin, GitHub Copilot Workspace 같은 도구들은 고수준 명세에서 완전한 애플리케이션을 만들어냅니다. “전자상거래 사이트를 만들어라”라고 하면 데이터베이스 설계부터 프론트엔드 구현까지 모두 처리합니다. 개발자의 역할은 점점 더 제품 관리자와 아키텍트에 가까워집니다.

멀티 에이전트 협업 미래에는 여러 AI 에이전트가 협업할 것입니다. 하나는 백엔드를, 다른 하나는 프론트엔드를, 또 다른 하나는 테스트를 담당합니다. 개발자는 이러한 에이전트들을 조율하는 오케스트라 지휘자 역할을 합니다.

지속적인 코드 진화 AI가 코드베이스를 지속적으로 모니터링하고 개선합니다. 성능 병목을 발견하면 자동으로 최적화를 제안합니다. 보안 취약점이 발견되면 패치를 생성합니다. 새로운 라이브러리 버전이 나오면 자동으로 업그레이드합니다.

자연어 프로그래밍 코드를 직접 작성하는 것이 아니라 자연어로 의도를 표현하는 것이 주가 될 수 있습니다. “사용자가 비밀번호를 3번 틀리면 30분간 계정을 잠그고 관리자에게 이메일을 보내라”고 말하면 이것이 곧 코드가 됩니다.

그러나 이 모든 미래에도 ArjanCodes의 핵심 메시지는 유효합니다. 좋은 설계를 아는 사람이 AI를 활용할 때 진정한 힘이 발휘됩니다. AI가 아무리 발전해도, 무엇을 만들지, 어떻게 구조화할지, 어떤 트레이드오프를 할지는 여전히 인간이 결정해야 합니다.

결론: AI 시대의 진짜 개발자 되기

이 문서는 ArjanCodes의 “유지보수 가능한 코드를 위한 AI 활용법”과 2026년 최신 Claude Code 개발 방법론을 통합하여 실전 가이드를 제공했습니다. 핵심 교훈을 정리하면 다음과 같습니다.

패러다임 전환이 필요합니다. 속도보다 설계를, 작동하는 코드보다 유지보수 가능한 코드를 우선시하세요. AI는 빠르게 코드를 생성하지만, 좋은 구조는 여전히 인간이 설계해야 합니다.

반복적 협업이 핵심입니다. AI의 첫 번째 결과에 만족하지 말고, 디자인 패턴과 원칙을 적용하여 계속 개선하세요. Plan Mode를 활용하여 코딩 전에 충분히 설계하세요.

도메인 지식이 차별화 요소입니다. AI는 텍스트 패턴을 학습했을 뿐 진정한 이해는 없습니다. 수학적, 물리적, 비즈니스적 맥락을 제공하는 것은 개발자의 몫입니다.

체계적인 워크플로우가 생산성을 결정합니다. CLAUDE.md로 프로젝트 컨텍스트를 관리하고, TDD로 품질을 보장하며, 병렬 세션으로 효율을 높이세요. Boris Cherny의 8단계 워크플로우는 검증된 접근법입니다.

지속적인 학습이 경쟁력입니다. AI 도구는 빠르게 진화합니다. 최신 모델을 실험하고, 커뮤니티에 참여하며, 자신만의 베스트 프랙티스를 개발하세요.

2026년 현재, AI는 개발자를 대체하는 것이 아니라 증강하고 있습니다. 좋은 설계를 아는 개발자는 AI를 활용하여 10배 더 생산적이 될 수 있습니다. 그렇지 못한 개발자는 AI가 생성한 기술 부채에 묻힐 수 있습니다.

ArjanCodes가 보여준 것처럼, AI 시대의 진짜 개발자는 코드를 빠르게 타이핑하는 사람이 아닙니다. 시스템을 설계하고, AI를 전략적으로 활용하며, 장기적으로 유지보수 가능한 소프트웨어를 만드는 사람입니다. 이것이 AI와 함께 성장하는 개발자의 모습입니다.

이 문서가 여러분의 AI 코딩 여정에 실질적인 도움이 되기를 바랍니다. 좋은 설계와 AI의 힘을 결합하여 놀라운 소프트웨어를 만드세요!

참고 자료

ArjanCodes: “The Right Way to Use AI for Writing Maintainable Code” (https://www.youtube.com/watch?v=8Pi6vGRlp1c)
Anthropic: Claude Code Best Practices (https://www.anthropic.com/engineering/claude-code-best-practices)
Boris Cherny의 워크플로우 (InfoQ, 2026년 1월)
AI-Generated Code Statistics 2026 (NetCorp Software Development)
MIT Technology Review: “AI coding is now everywhere” (2025년 12월)
Faros AI: Best AI Coding Agents for 2026 (2026년 1월)

문서 작성일: 2026-01-16

AI, Material

AI Material claude-code TDD sub-agents parallel-sessions MCP Claude.write