정도현 - 로보코 수석 컨설턴트

이 포스팅은 Armin Ronacher의 블로그 글 「Agentic Coding Recommendations」(에이전틱 코딩 권장사항)을 토대로 작성되었다.

서문

며칠 전 개발자 커뮤니티 Geek News에서 Armin Ronacher의 블로그 글 「Agentic Coding Recommendations」(에이전틱 코딩 권장사항)을 접하고 적잖은 충격을 받았다. 글의 저자인 Armin은 윈래 Flask 웹 프레임워크 창시자로 유명한데, 그의 바이브 코딩에 대한 통찰은 Roboco 가 지향하는 방향과도 맞닿아 있었기 때문이다. 이번 포스팅에서는 이제 막 Claude Code, Cursor, Windsurf 같은 도구를 접하는 바이브 코딩 입문자들을 위해, Armin의 글에 담긴 핵심 내용을 쉽게 풀어 설명하고자 한다.

에이전틱 코딩이란 무엇인가?

Armin이 말하는 에이전틱 코딩 (Agentic Coding) 이란, 코딩 작업의 많은 부분을 AI 에이전트에게 위임하는 개발 방식이다. 여기서 에이전트란 개발자의 지시를 받아 스스로 작업을 수행하는 자율 프로그램을 의미한다. 여기서는 사람처럼 코딩 업무를 도와주는 AI 프로그램을 가리키며, 파일 편집, 명령 실행, 웹 검색 등 개발 관련 작업을 대리인(agent) 처럼 처리한다.

일반적인 AI 코딩 도우미(예: Github Copilot 자동 완성, ChatGPT를 이용한 코드 생성)보다 한 걸음 더 나아가, 에이전트에게 하나의 작업 목표를 할당하면 그 에이전트가 알아서 필요한 일련의 작업들을 수행하도록 하는 것이다.

에이전틱 코딩은 안드레아 카르파티(Andrej Karpathy)에 의해 바이브 코딩이라는 용어가 제안되기 전까지 AI 주도 개발에 대한 가장 유력한 용어였고 현재도 바이브 코딩이라는 용어와 더불어 많이 사용되고 있다. 이 글에서는 원저자의 의지를 존중해 바이브 코딩이라는 용어 대신 에이전틱 코딩으로 용어를 통일한다.

쉽게 말해, 사람 개발자가 “프로젝트 X의 버그를 고쳐줘”라고 자연어로 지시하면, 에이전트가 해당 코드베이스를 파악하고, 코드를 수정하고, 테스트를 실행해 결과까지 내놓는 흐름이다. 이 과정에서 개발자는 세부 단계마다 간섭하지 않고 결과가 나올 때까지 기다리는 것이 특징이다.

이러한 접근법에서는 기존에 우리가 쓰던 IDE(통합 개발 환경)의 역할도 크게 줄어든다. Armin의 경우 에이전트가 코딩 대부분을 처리하므로, 그는 마지막 손질 정도만 텍스트 편집기(Vim 같은 도구)로 하고 있다. 그만큼 에이전트가 주도적으로 코딩 과정을 맡는 것이 에이전틱 코딩의 모습이다.

그렇다면 왜 에이전틱 코딩이 필요한가? 우선, 잘 활용하면 개발 생산성을 비약적으로 높일 수 있기 때문이다. 사람 개발자가 많은 시간을 소모하는 반복 작업(예: 코드 리팩토링, 여러 파일에 걸친 수정, 긴 문서나 코드베이스 파악)을 에이전트가 대신 해준다면, 개발자는 더 창의적이고 중요한 문제에 집중할 수 있다. 실제로 Armin은 “에이전트를 개발 프로세스에 통합하면 상당한 생산성 향상을 얻을 수 있다.”고 강조한다. 또한 이러한 방식은 빠르게 발전 중인 AI 기술의 최신 잠재력을 개발에 접목하는 길이기도 하다.

마지막으로, 에이전틱 코딩은 단순히 “코드를 더 빨리 쓰는 것”에 그치지 않는다. 궁극적으로는 더 나은 품질의 코드를 작성하고, 유지보수성과 안정성을 높이는 것을 목표로 한다. Armin은 몇 달 전만 해도 형편없던 AI 코드 출력물이 이제는 상당히 개선되었다면서, 앞으로도 발전을 거듭할 것이라고 말한다. 따라서 이 글의 뒷부분에서 살펴볼 Claude Code와 같은 도구를 잘 활용하면, 초보 개발자도 점차 “AI 에이전트와 협업하는 개발자”로 성장할 수 있을 것이다.

Armin이 제안하는 에이전틱 코딩 핵심 원칙

Armin Ronacher는 자신의 글에서 에이전틱 코딩을 효과적으로 활용하기 위한 조언을 다수 제시했다. 프로그래밍 기초 정도를 아는 독자도 이해할 수 있도록, 그의 주요 권장사항을 하나씩 풀어 설명하겠다:

  1. 간단하고 안정적인 언어 선택: 에이전트가 다룰 언어를 고를 수 있다면 가능한 한 단순한 언어를 택하라고 Armin은 권한다. 그는 새로운 백엔드 프로젝트의 경우 Go 언어를 강력 추천했는데, 그 이유는 명확하다. Go는 문법이 단순하고 예측 가능해서 에이전트(LLM)가 실수할 여지가 적으며, 테스트 실행도 자동으로 한 번에 잘 동작하기 때문이다. 예를 들어 Go에서는 go test 명령으로 필요한 테스트를 한꺼번에 돌릴 수 있다. 에이전트가 테스트 대상 선정에 혼란을 겪지 않는다. 또한 Go 생태계는 변화가 느리고 하위 호환성이 좋아서, AI가 낡은 예제 코드를 생성할 위험이 적다. 반면 Python처럼 마법(magic)이 많은 동적 언어는 에이전트가 숨은 동작을 오해하거나, 실행 환경 문제로 시행착오를 겪기 쉽다고 한다. 따라서 언어 자체가 단순하고 환경 변화가 적을수록 에이전트가 더 안정적으로 코드를 다룰 수 있다.

  2. 에이전트 친화적 개발 도구 세팅: 언어만큼이나 개발 도구(tool)를 어떻게 꾸리는지도 중요하다. Armin의 조언은 “도구는 무엇이든 될 수 있지만, 반드시 빠르고 명확하게 동작해야 한다.”는 것이다. 에이전트가 여러분의 환경에서 bash 명령어, 빌드 도구, 테스트 러너 등을 실행할 텐데, 반응이 느리거나 출력이 불필요하게 장황한 도구는 피해야 한다. 예를 들어 Armin은 자신의 프로젝트에 Makefile을 활용해 자주 쓰는 명령을 정리해두었다. make dev로 개발 서버를 띄우고, make tail-log로 로그를 보는 식이다. 중요한 것은 에이전트가 이런 도구를 사용할 때 오류가 나면 즉각 알려주고(logging), 중복 실행을 막는 등의 보호장치도 필요하다는 점이다. 실제 사례로, Armin은 프로세스 관리 도구를 수정하여 이미 서버가 실행 중이면 두 번째로 띄우지 못하게 하고, 그 대신 “이미 실행 중”이라는 에러를 명확히 출력하게 만들었다. 덕분에 에이전트가 make dev를 실행했을 때 서버가 이미 돌아가는지 판단하고, 바로 로그를 살펴보는 다음 단계로 넘어갈 수 있었다.

그리고 로그(logging) 자체를 에이전틱 코딩의 핵심 도구로 활용하라고 Armin은 거듭 강조한다. 예를 들어 회원가입 시 인증 이메일을 실제로 보내는 대신 개발 모드에서는 이메일 내용을 콘솔 로그에 찍어두면, 에이전트가 그 로그를 읽어 인증 링크를 자동으로 찾아 클릭할 수 있다. Armin은 자신의 CLAUDE.md 설정 파일에 “디버그 모드에선 이메일이 로그로 출력된다.”는 정보를 넣어 두었고, Claude 에이전트는 이를 참고해 실제로 회원가입부터 인증까지 스스로 완료해냈다. 이렇듯 명확한 로그와 친절한 도구 출력은 에이전트의 눈과 귀가 되어 준다. 우리가 개발할 때 콘솔이나 로그를 보며 문제를 파악하듯, 에이전트도 로그를 통해 상황을 이해하고 다음 행동을 결정하기 때문이다.

  1. 속도와 효율 최적화: 에이전틱 코딩의 병목은 주로 AI 모델 추론 비용과 비효율적인 도구 사용에서 온다. 따라서 응답 속도를 높이고 불필요한 토큰 낭비를 줄이는 것이 중요하다. 위에서 언급한 대로 도구의 신속한 실행이 기본이고, 더 나아가 에이전트가 새로 작성하여 실행하는 코드(“emergent tool”)도 최대한 가볍게 만들어야 한다. 예를 들어, 에이전트가 어떤 작업을 위해 임시 파이썬 스크립트를 작성해 돌린다고 하자. 이때 그 스크립트가 실행되는데 5초가 걸리고, 실행할 때마다 초기화로 1분씩 소모된다면 전체 흐름이 크게 느려진다. Armin은 실제 현업 프로젝트(Sentry)에서 에이전트가 코드를 리로드하는 데 너무 시간이 걸리자, 임시로 “파일 변경을 감지해 자동으로 모듈을 import하고 결과를 로그에 쓰는” 데몬을 만들어 에이전트가 활용하게 했다고 한다. 복잡한 재시작 없이 빠르게 코드를 주입해 실행 결과만 확인하게 한 것이죠. 이러한 창의적인 방식을 통해 가능한 한 실시간에 가깝게 피드백을 주도록 환경을 튜닝하면 에이전트의 작업 효율이 올라간다. 또 로그도 너무 장황하면 토큰을 잡아먹고 속도를 늦추니, 중요한 정보만 담도록 적절한 수준으로 조절하는 것이 좋다고 조언한다.

  2. 안정성과 최소 놀람의 원칙: Armin은 “안정적인 생태계”의 가치를 거듭 언급한다. AI가 코드베이스를 다룰 때 외부 변화가 적은 환경에서 훨씬 실수를 덜 한다. 예를 들어 LLM 에이전트들은 Go나 Flask 같은 오래 검증된 기술 스택을 좋아한다. 반대로 종속성이 급변하는 자바스크립트 생태계처럼 매일 새로운 버전과 라이브러리가 쏟아지는 환경에서는, AI가 며칠 전 코드를 참고해 잘못된 코드를 생성할 위험이 높다. 또한 에이전트는 코드를 작성하며 결정한 이유를 주석으로 남겨두는 등 자기만의 흔적(breadcrumb)을 남기는 경향이 있는데, 우리가 별 생각 없이 의존 라이브러리를 최신 버전으로 올려버리면 그런 주석이나 코드 패턴이 금세 낡은 것이 되어 AI의 사고 흐름에 혼선을 줄 수 있다. 사람도 마찬가지지만, AI는 “어차피 테스트 통과하면 되지 않을까?” 하는 마음으로 손쉽게 업그레이드를 시도할 수 있으므로 특히 주의해야 한다. Armin의 조언은 한마디로: “이전보다 더욱 보수적으로 업그레이드하라”는 것이다. 그리고 새로운 라이브러리를 덜 쓰고 가능하면 직접 코드로 구현하는 편이 낫다고도 말한다. 어차피 에이전트가 빠르게 코드를 뚝딱 만들어줄 수 있으니, 복잡한 의존성을 가져오는 대신 필요한 기능은 직접 작성해서 일관성과 예측 가능성을 유지하라는 뜻이다. 실제로 Armin은 “왜 직접 코드를 써야 하는가”란 제목의 글을 이전에 썼는데, 에이전틱 코딩을 해보니 그 생각이 더 확고해졌다고 한다.

  3. 코드는 최대한 단순하게: “복잡한 코드는 에이전트 환경에서 성능이 안 나온다. 가장 멍청해 보이지만 돌아가는 해결책을 택하라” – Armin이 강조한 문장이다. 에이전트가 코드를 다룰 때는 명료함이 최우선이다. 따라서 개발자는 평소보다 더 직설적이고 단순한 코드 스타일을 추구해야 한다. 예를 들어 복잡한 클래스 상속보다는 길고 구체적인 이름의 함수들을 여러 개 만드는 편이 이해하기 쉽다. 너무 추상적인 패턴이나 매직(Number, Reflection 등)을 남발하면 AI가 맥락을 놓치기 쉽다. Armin은 “평범한 SQL 쿼리를 직접 쓰라”고까지 조언한다. ORM 등을 통해 간접적으로 데이터베이스를 다루기보다, 차라리 에이전트에게 SQL을 쓰게 하면 AI가 로그의 SQL 출력과 자기 코드를 바로 대응시켜 디버깅하기 쉽다. 또한 권한 체크 같은 중요한 로직은 최대한 해당 코드 근처에 두어야 한다. 만약 권한 검사가 설정 파일이나 데코레이터로 숨겨져 있으면, 에이전트가 새로운 기능을 추가할 때 그 부분을 놓쳐 보안 구멍을 만들 우려가 있다. 결국 “단순명료하고 일관된 코드”가 에이전트와 인간 모두에게 좋은 코드라는 뜻이다.

  4. 병렬화(Parallelization) 염두에 두기: 에이전트 혼자서는 아주 빠르지는 않지만, 여러 개를 동시에 돌리면 작업을 병렬 처리하여 효율을 높일 수 있다. 예를 들어 수백 개 파일의 린트 오류를 한 번에 고쳐야 한다면, 한 에이전트가 차례로 처리하는 대신 여러 에이전트를 각기 일부 파일씩 맡기는 식이다. 이를 위해서는 공유 자원(파일시스템, DB 등)의 충돌을 최소화 할 수 있게 프로젝트를 구성해야 한다. 쉽지는 않은 일이지만, Armin은 Docker를 이용한 격리 실행 도구나 CI(지속적 통합) 환경에서 백그라운드 에이전트를 돌리는 등 초기 시도들이 나오고 있다고 소개한다. 현재 자신의 워크플로에는 완벽히 적용하지는 못했지만, 곧 급속히 발전할 분야 라고 전망하니 머지않아 실용화될 가능성이 있다.

  5. 적시에 리팩토링하기: 에이전틱 코딩 환경에서는 리팩토링(refactoring) 의 타이밍이 중요하다. 에이전트는 일정 수준까지는 어지간한 복잡성의 코드도 문제없이 처리한다. 그러나 프로젝트 규모와 복잡도가 한계점을 넘어서면, 에이전트의 맥락 유지 능력에도 한계가 온다. Armin은 예를 들어 “초반에는 프론트엔드에 Tailwind CSS 클래스를 여기저기 막 써가며 에이전트와 빠르게 개발해나갈 수 있지만, 파일 50개에 스타일이 흩어진 시점이 되면 이제 컴포넌트 라이브러리로 구조를 재편할 때”라고 말한다. 그 정도로 코드베이스가 방대해지면 에이전트도 일관성 있는 수정을 하기 어려워, 큰 수정 시 버그가 속출할 수 있다. 따라서 너무 이르게 리팩토링하여 초기 속도를 죽일 필요는 없지만, 또 너무 늦게까지 미루면 에이전트도 수습하기 힘들어지는 시점이 온다는 것이다. 사람이든 AI든 적절한 시점에 코드 구조를 정리해주는 것은 유지보수에 필수적이다. 에이전틱 코딩을 하다 보면 에이전트가 새로운 함수나 파일을 술술 추가해주기 때문에, 어느 순간엔 개발자가 나서서 중복 코드를 모으고 모듈화를 하는 등 대청소를 해줘야 향후 작업이 수월해질 것이다.

이러한 원칙들은 Armin이 “향후 기술이 변해도 유효할 본질적인 개념”이라고 강조한 부분이다. 실제 툴과 기법은 빠르게 진화하겠지만, 단순성, 안정성, 관찰 가능성(로그 등), 스마트한 병렬화 같은 원칙은 앞으로도 에이전틱 코딩의 성패를 가르는 요소라는 뜻이다. 저희 Roboco 팀도 이러한 통찰에 깊이 공감하며, AI와 함께하는 코딩 문화가 건강하게 정착하기 위해서는 위와 같은 소프트웨어 공학의 기본기 원칙이 더욱 중요해질 것이라 믿는다.

Claude Code 활용 실전 예시

이제 Anthropic 사의 Claude Code라는 도구를 통해 위에서 말한 에이전틱 코딩이 실제로 어떻게 이루어지는지 살펴보겠다. Claude Code는 Armin이 주로 사용하는 명령줄 기반 AI 코딩 에이전트로, 프로젝트 디렉터리에서 터미널 명령어(claude)로 실행된다. 이 에이전트는 코드베이스를 이해하고 파일을 편집하며, 테스트나 빌드 명령을 직접 실행할 수 있다. 또한 Git과 통합되어 git 히스토리 검색이나 커밋, PR 생성까지 도와주는 강력한 도구이다. 아래에 Claude Code를 활용한 몇 가지 상황별 예시를 소개한다.

코드 리팩토링 예시

예를 들어, 우리가 processData()라는 함수의 성능 문제를 개선하고 싶다고 해보자. 평소라면 개발자가 해당 함수를 열어 로직을 수정하고, 관련된 부분의 동작을 검증해야한다. Claude Code를 사용하면 이러한 리팩토링 작업을 상당 부분 자동화할 수 있다. 개발자는 자연어로 간단히 지시한다.

processData() 함수를 리팩토링하여 모든 데이터를 한 번에 로드하는 대신 스트리밍을 사용하도록 변경해줘.

프롬프트를 입력하면 Claude Code 에이전트가 알아서 processData 함수가 있는 파일을 열어 코드를 수정하기 시작한다. 예를 들어, 한 번에 모든 데이터를 메모리에 올리던 부분을 스트리밍 방식으로 변경하고, 필요하다면 관련 함수들의 시그니처도 수정할 것이다. Claude Code는 수정 후 자동으로 프로젝트의 테스트를 실행하여 리팩토링이 기존 기능을 깨뜨리지 않았는지 확인한다. 만약 테스트에서 실패가 발생하면, 에이전트가 원인을 분석해 코드를 추가 수정하기도 한다. 모든 테스트가 통과하면 Claude Code는 개발자에게 “리팩토링 완료, 메모리 사용이 크게 줄었다. 모든 기존 테스트도 통과했다.” 같은 요약 결과를 보여줄 것이다. 개발자는 이 변경사항(diff)을 확인하고 만족스럽다면, 곧바로 커밋을 수행할 수도 있다.

문서 요약 예시

에이전트는 코딩뿐 아니라 문서 이해 및 요약 작업에도 쓸모가 있다. 프로젝트에 새로운 개발자가 합류했다고 가정해 보자. 이 개발자가 ARCHITECTURE.md라는 설계 문서를 빠르게 파악해야 할 때, Claude Code에게 요약을 부탁할 수 있다.

docs/ARCHITECTURE.md 내용을 세 줄로요약해줘

Claude Code는 해당 마크다운 문서를 읽고 핵심 내용을 뽑아 요약해준다. 예를 들어 다음과 같은 결과를 출력해 줄 것이다.

- 이 프로젝트는 클라이언트-서버 아키텍처로 구성되어 있으며, 서버는 REST API를 제공한다.
- 사용자 인증과 권한 관리를 위한 모듈이 포함되어 있으며, 역할에 따라 기능 접근이 제한된다.
- 확장성을 위해 메시지 큐와 캐시를 도입하여 향후 증가하는 트래픽에도 대응하도록 설계되었다.

요약된 포인트를 통해 새로 온 개발자는 짧은 시간 안에 시스템 구조를 이해할 수 있다. 이처럼 Claude Code는 프로젝트 코드뿐 아니라 관련 문서까지 맥락을 파악하여 질문에 답변하거나 요약하는 데 활용될 수 있다. 방대한 코드베이스에서 특정 기능이 어디에 구현되어 있는지 물어보거나, 설정 파일들의 역할을 물어보는 등 코드 Q&A 비서로 사용할 수도 있다.

함수 생성 예시

이번에는 새로운 기능을 추가하는 코드 생성 시나리오이다. 가령 우리는 사용자 계정 삭제 시 사전에 권한을 확인하는 로직이 필요하다고 하자. 이를 위해 checkPermissionBeforeDelete()라는 함수를 추가하려 한다면, Claude Code에게 함수를 만들어달라고 요청할 수 있다.

사용자가 삭제 권한이 없을 경우 오류가 발생하도록 하는 checkPermissionBeforeDelete(user) 함수를 생성해줘

이 지시를 받으면 Claude Code는 프로젝트의 코드를 훑어보면서 어떤 권한 체계를 쓰는지 파악할 것이다. 그리고 적절한 위치(예컨대 user_utils.py 파일)에 새로운 함수를 작성한다. 함수 내부에는 user 객체나 ID를 받아 해당 사용자가 삭제 권한이 있는지 검사하고, 없으면 예외를 발생시키는 로직이 포함될 것이다. Claude Code는 코딩 컨벤션을 지키며 (프로젝트가 Django라면 데코레이터를 활용할 수도 있고, 아니면 단순 if-check일 수도 있다) 함수를 생성한다. 작성이 끝나면 스스로 간단한 테스트를 수행하거나, 기존 테스트 코드에 이 함수를 사용하는 부분이 필요한지 제안할 수도 있다. 결국 개발자는 완성된 함수 코드와 에이전트의 설명을 확인하고, 필요하면 약간의 수정이나 주석을 보완한 후 저장하면 된다. 이렇게 새로운 기능 구현도 에이전트와 대화하며 빠르게 진행할 수 있다.

Claude Code와 Git 연계 사용법

Claude Code는 Git과도 밀접하게 통합되어 있다. 버전 관리 작업에도 도움을 준다. 간단한 시나리오를 통해 어떻게 활용할 수 있는지 알아보자.

예시 시나리오: 버그 수정 후 코드를 저장하고 공유하는 과정

  1. 버그 상황 파악: GitHub 이슈로 보고된 버그가 하나 있다. 개발자는 Claude Code에게 “이슈 #37에 설명된 버그를 해결해줘” 라고 지시한다. 에이전트는 GitHub CLI(gh)를 이용해 이슈 내용을 읽거나, 로컬에 받아둔 이슈 설명을 참고하여 어떤 문제인지 이해한다. 그리고 코드베이스에서 해당 버그의 원인을 찾아 수정한다. 예를 들어 null 체크가 빠져 있어서 발생한 버그라면, 조건문을 추가하는 식이다. Claude Code는 수정 후 관련 테스트(gh CLI로 CI 테스트 실행 등)까지 진행해 버그가 해결됐는지 확인한다.

  2. 코드 변경 검토: 버그가 고쳐졌다면, Claude Code는 *“문제를 일으키던 함수에 null 값 검사를 추가했고, 이제 모든 테스트를 통과했습니다”*라고 보고할 것이다. 개발자는 Claude Code가 제시한 코드 변경(diff)를 확인한다. 필요하면 “주석을 좀 더 달아줘” 혹은 *“이 부분 변수명을 더 의미 있게 바꿔줘”*라고 Claude Code에 추가 지시를 내릴 수도 있다. 에이전트는 요청에 따라 코드를 다시 수정해 줄 것이다.

  3. 커밋과 푸시: 수정 결과에 만족하면, 이제 Git 커밋을 할 차례이다. 적절한 커밋 메세지도 수정 내용에 맞춰서 자동으로 생성된다.

예를 들면 에이전트는 git commit 명령을 실행하여 현재 변경사항을 ‘Fix null pointer bug in processData function’라는 메시지로 커밋 할 수 있을것이다. 마찬가지로 git push 명령도 에이전트를 통해 실행시킬 수 있다. 즉, 코드 수정부터 커밋/푸시까지 하나의 흐름으로 에이전트가 보조해주는 것이다.

  1. Pull Request 생성: GitHub에 코드를 반영하려면 PR(Pull Request)을 만들어한다. Claude Code는 GitHub CLI(gh)를 사용할 수 있기 때문에, 다음처럼 지시하면:
버그 수정 브랜치를 메인 브랜치와 병합하기 위해 PR을 생성해줘.

에이전트는 gh pr create 등의 명령을 알아서 호출하여, 적당한 제목 및 내용과 함께 현재 버그픽스 브랜치의 PR을 생성한다. 이어서 PR 본문에 이슈 번호를 연결하거나 변경사항 요약을 작성해줄 수도 있다. 결과적으로 개발자는 웹 인터페이스를 일일이 열어 클릭하지 않아도 터미널 안에서 자연어로 PR까지 생성해버릴 수 있는 것이다.

이러한 Git 연계 활용은 팀 협업에도 유용하다. 예를 들어 Merge Conflict(병합 충돌)이 발생했을 때 Claude Code에게 해결을 맡길 수도 있다. *“생성된 충돌을 자동으로 고쳐줘”*라고 하면, 에이전트가 충돌 표시(««, ====, »»)를 찾아 가장 그럴듯한 방식으로 합치는 시도를 한다. 끝나면 *“충돌을 해결했고, 코드가 정상 컴파일된다.”*라고 알려줄 것이다.

또한 여러 개발자가 동시에 작업하는 대규모 프로젝트라면, 에이전트를 병렬로 활용해 여러 개의 이슈를 동시에 처리하고 각각 별도 브랜치에 커밋하게 할 수도 있다. 예컨대 한 에이전트는 기능 A를 개발하고, 다른 에이전트는 버그 B를 수정하게 한 뒤, 두 결과물을 각각 PR로 올려 코드리뷰를 받는 식이다. 이처럼 Claude Code와 Git의 결합은 코딩->테스트->커밋->PR로 이어지는 개발 사이클을 상당 부분 자동화해 준다.

(참고로, Claude Code를 처음 사용할 때는 중요한 시스템 변경을 수반하는 명령들을 안전장치로 묻는 경우가 있다. 예를 들어 파일 삭제나 대형 커밋 같은 동작에는 사용자의 허가를 구하는데, Armin처럼 고급 사용자는 –dangerously-skip-permissions 옵션으로 일일이 허용을 누르는 과정을 생략하기도 한다. 하지만 초보자라면 기본 설정대로 두어 에이전트의 모든 행동을 눈으로 확인하며 진행하는 것을 권장한다.)

마무리: 초보 개발자를 위한 현실적 조언

에이전틱 코딩과 Claude Code의 세계는 처음 접하면 다소 낯설고 복잡하게 느껴질 수 있다. 하지만 차근차근 접근하면 초보 개발자도 충분히 활용할 수 있는 도구이며, 오히려 학습과 성장에 큰 도움이 될 수 있다. 마지막으로, 초보자가 Claude Code를 활용해 에이전틱 코딩 역량을 키우기 위한 현실적 조언을 정리하며 글을 마치겠다.

    1. 작은 것부터 시작하라: 처음에는 Claude Code에게 너무 복잡한 전체 프로젝트를 맡기기보다, 작은 작업 단위로 시도해보라. 예를 들어 “이 함수에 주석 달아줘” 또는 “간단한 유닛 테스트 만들어줘” 같은 요청으로 시작하면 좋다. 이렇게 성공과 실패를 경험하며 에이전트의 능력과 한계를 파악해보라.
    1. 결과는 항상 검토하라: Claude Code가 아무리 똑똑해도, 생성한 코드나 수정사항을 사람 개발자가 검토하는 단계는 필수적이다. 에이전트는 가끔 엉뚱한 수정이나 사소한 버그를 남길 수 있으므로, 초보자라도 출력물을 꼼꼼히 읽어보고 테스트를 더 돌려보는 습관을 가지세요. 마치 선배 개발자의 코드를 리뷰하듯 에이전트 코드를 대하면, 잘못된 부분을 발견하고 배우는 기회로 삼을 수 있다.
    1. 실험하고 튜닝하라: 앞서 소개한 CLAUDE.md 같은 설정 파일이나 프로젝트의 Makefile, 스크립트 도구 등을 활용해, 에이전트가 더 잘 일하도록 환경을 튜닝해보라. 예를 들어 자주 쓰는 명령을 CLAUDE.md에 적어두거나, 프로젝트의 규칙(코딩 스타일, 브랜치 전략 등)을 기록해 두면 Claude Code가 이를 기억하고 따르게 할 수 있다. 이러한 환경 개선은 곧 개발자 본인의 작업 효율과도 직결되므로 일석이조이다.
    1. 최신 정보를 놓치지 말 것: Armin이 강조했듯 이 분야의 변화 속도는 매우 빠르다. Claude Code 자체도 계속 업데이트되고 있고, 비슷한 대안 도구(예: OpenAI Codex, Cursor 등)도 빠르게 업데이트 되고 있다. 초보 개발자라도 시간을 내어 관련 뉴스와 커뮤니티를 확인하고, 새로운 기능이나 모범 사례(best practice)를 익혀두면 큰 도움이 된다. 예컨대 Claude Code에 병렬작업 에이전트 기능이 추가되었다는 소식을 접했다면, 바로 시도해보며 경험을 늘려보기 바란다.
    1. 기본기는 중요하다: 마지막으로, 에이전틱 코딩이 만능은 아니라는 점을 명심해야 한다. AI가 많은 걸 도와주지만, 그렇다고 해서 프로그래밍의 기본 원리나 자료구조, 알고리즘에 대한 공부를 소홀히 하면 안 된다. 오히려 이런 지식을 탄탄히 할수록 에이전트를 더 잘 부릴 수 있게 된다. 어떤 문제를 해결해야 할지, 어떤 방향의 수정이 필요한지는 결국 개발자의 판단이 필요하며, 그래야 올바른 지시를 에이전트에게 내릴 수 있다. 또한 기본기가 있다면 에이전트가 만들어낸 결과를 분석하여 옳고 그름을 판단할 수 있다.

Armin Ronacher의 경험담에서 볼 수 있듯이, AI 에이전트와 협업하는 코딩은 개발자의 역할을 완전히 대체하기보다는 한층 증폭시켜주는 도구에 가깝다. 초보 개발자도 주눅 들 필요 없이, 작은 프로젝트라도 직접 Claude Code를 설치해 시도해보라. 처음에는 다소 어색하지만, 에이전트를 마치 또 다른 팀원이나 페어 프로그래머라고 생각하고 대화를 이어가 보라. 어느새 반복 작업은 척척 처리되고, 여러분은 더 큰 그림에 집중하며 성장하고 있는 자신을 발견하게 될 것이다.

마지막으로, 두려워하지 말고 적응력 있게 배우기를 권한다. Armin 역시 “오늘의 워크플로가 내일은 완전히 달라질 수 있다.”고 말하지만, 그 핵심 원칙들은 꾸준히 통용될 것이라고 했다. 단순함, 안정성, 가시성 등의 원칙을 가슴에 새기고, 새 시대의 개발 흐름을 즐겨보라. AI와 사람이 힘을 합쳐 더 나은 코드를 짜는 에이전틱 코딩의 세계에 오신 것을 환영하며, 행복한 바이브 코딩이 되길 바란다!

Armin Ronacher의 유튜브 라이브코딩 영상