에이전트 기반 코딩 (Agentic Coding) 수준 높이기

우리가 전통적인 코딩에서 에이전트 기반 코딩 (Agentic Coding)으로 이동함에 따라, 실질적인 학습 곡선이 존재합니다. 코드 품질을 진정으로 높이고 에이전트 기반 경험으로부터 최상의 결과를 얻으려면, 우리는 우리의 프로세스와 사고방식을 바꿔야 합니다.

레벨 1 - 바이브 코딩 (Vibe coding)

레벨 1은 우리 모두가 시작하는 단계로, 요청 사항을 붙여넣고 AI가 그 요청을 구현하도록 내버려 두며, 작동하기만 한다면 그 코드가 아마 괜찮을 것이라고 받아들이는 단계입니다.

이 방식은 한 줄짜리 변경 사항이나 기타 매우 작은 변경 사항에는 효과적일 수 있지만, 더 큰 규모에서는 작동하지 않습니다.

최종 결과물은 종종 다루기 힘들거나, 이해하기 어렵고, 보안 문제나 버그로 가득 찬 코드가 되곤 합니다.

또한 우리가 흔히 "AI가 작성했어"라고 말하게 되는 단계이기도 합니다.

이러한 관점에서 벗어나는 것이 여러분이 할 수 있는 첫 번째 단계의 업그레이드입니다. AI가 작성하는 것이라고 생각하는 것을 멈추고, 도구의 도움을 받아 당신이 작성하는 것이라고 생각하십시오.

궁극적으로, 당신의 감독 하에 AI가 작성하는 코드에 대한 책임은 당신에게 있으며, 무언가 잘못되었을 때 "하지만 AI가 작성했어요"라는 말은 결코 용납될 수 있는 이유가 될 수 없습니다.

레벨 2 - 프롬프팅 (Prompting)

프롬프팅 (Prompting)은 다소 오해의 소지가 있는 단계입니다. AI에게 더 많은 작업 재료를 제공하기 때문에 상당한 업그레이드처럼 느껴지며, 결과물도 눈에 띄게 좋아지기 때문입니다. 작고 제한된 변경 사항의 경우, 이것만으로도 정말 충분할 수 있습니다.

하지만 함정은 AI가 여전히 아키텍처 설계 (Architecting)를 수행하고 있다는 점입니다. 당신이 직접 코드를 작성할 때는 항상 다음 단계, 놓친 단계, 그리고 이것이 기존의 것과 어떻게 어우러지는지를 생각하며 앞을 내다봅니다. 프롬프팅은 이러한 역학 관계를 바꾸지 못하며, 단지 AI가 스스로 결정을 내리는 동안 사용할 재료를 더 많이 제공할 뿐입니다.

그 결과는 무엇일까요? 단독으로는 완벽하게 유효하지만, 의도한 작업에 맞지 않거나 작성 중인 코드베이스(codebase)에 어울리지 않는 코드가 생성됩니다. 그리고 코드가 그럴듯해 보이기 때문에, 이를 놓치기가 쉽습니다.

레벨 3 - 계획 (Planning)

레벨 3은 에이전트 기반 코딩 (Agentic Coding)을 위한 최소한의 요구 사항이어야 합니다. 이 단계에서 개발자는 방관자에서 설계자 (architect)로 거듭납니다.

AI와 함께 요청 사항을 계획하고, 코드가 작성되기 전에 실제로 그 계획을 읽어보는 것입니다. 계획이 기존의 코드 표준을 준수하고 있습니까? 계획이 실제로 작업을 해결합니까? AI가 개발자로 하여금 AI가 작업을 올바른 방향으로 수행하고 있음을 알 수 있게 도와주는 좋은 후속 질문 (follow up clarifying questions)을 던지고 있습니까?

계획 모드 (planning mode)에 시간을 할애하는 것의 중요성은 아무리 강조해도 지나치지 않습니다. 이는 품질이 낮은 코드, 작업에 맞지 않는 코드, 누락된 보안 조치 등에 대한 방어책이 됩니다.

이 계획 단계 동안, AI가 작업을 더 잘 이해하기 위해 가설 (assumptions)을 확인하고 있는지, 아니면 단순히 가설을 세우고 있으며 더 나은 질문을 던질 수 있도록 약간의 자극이 필요한 상태인지를 고려하십시오.

본질적으로, 여러분은 코드 한 줄이 작성되기 전에 사고 과정을 검토하는 것이며, 이는 나중에 대규모 코드 차이 (code diff)를 코드 리뷰 (code review)하려고 노력하는 것보다 훨씬 쉽습니다. 계획이 적절히 검토되고 확인되어 합의된 후에만 AI가 코드를 구축하도록 허용하십시오.

레벨 4 - 완전한 설계자 (Full Architect)

레벨 4는 레벨 3에 프로세스를 도입하여 확장합니다. 사람이 코드를 확인하기 전에, 코드가 작성된 후 AI의 자기 검증 (self verification) 프로세스를 추가하는 것입니다.

계획을 더욱 세분화하십시오. 단순히 계획을 만드는 대신, 작고 관리 가능한 부분으로 나뉜 계획 (수직적 슬라이싱, vertical slicing)을 만들고, AI가 각 슬라이스를 진행할 때마다 체크할 수 있는 하위 작업 (sub tasks)을 생성하십시오. 이는 AI에게 구축을 위한 훌륭한 참조 자료를 제공하며, 더 이상 가설이 존재하지 않게 됩니다. AI는 작업을 어떻게 구축해야 하는지 정확히 알게 될 것입니다.

이렇게 빌드(build)를 나누면 더 점진적인 코드 리뷰 (code reviews)가 가능해집니다. 5개의 슬라이스(slice)가 모두 완료되었을 때보다 슬라이스 1에서 문제를 찾아내는 것이 더 쉽습니다. 문제를 조기에 발견한다는 것은 너무 멀리 가기 전에 계획을 조정할 수 있음을 의미합니다.

개발자가 확인하기 전에 AI가 자신의 코드를 스스로 리뷰하게 하는 것은, 진행 과정에서 개발자의 뇌에 과부하를 주지 않으면서도 명백한 실수들을 잡아낼 수 있는 아주 좋은 방법입니다. 이것이 인간의 코드 리뷰 (human code review)를 대체하는 것은 아니지만, 인간의 코드 리뷰를 도와줍니다.

높게 목표를 잡으세요

여러분의 에이전트 기반 (agentic) 여정이 어느 단계에 있든, 다음 단계로 나아가기 위해 노력하십시오. 이는 여러분의 개발자 여정과 다르지 않습니다. 우리는 아주 적은 것을 아는 상태에서 시작하여, 많은 실수를 저지르며, 코드 품질을 높이는 것을 목표로 합니다.

에이전트 기반 코딩 (agentic coding)도 마찬가지입니다. 우리는 작성된 코드에 대해 책임을 지며, 더 나은, 더 일관된 코드를 제공하기 위해 새로운 것을 배우는 것이 목표입니다.

이는 계획 (planning) 단계를 개선하거나, 검증 (verification) 단계를 개선하거나, 혹은 양질의 코드를 생산하는 데 필요한 도구를 제공하기 위해 커스텀 스킬 (custom skills)을 구축하는 단계로 나아가는 방식이 될 수 있습니다.

AI가 실수로부터 배우게 하세요

AI가 저지른 실수가 단 한 줄뿐이고 직접 고치기 쉽다는 이유로, 다시 예전처럼 손으로 직접 코딩하는 방식으로 돌아가기는 매우 쉽습니다. 하지만 장기적으로 볼 때, 그렇게 수정하는 것은 스스로에게 도움이 되지 않습니다. AI는 자신의 실수로부터 배웁니다. 실수로부터 얻은 교훈은 특정 이슈를 장기적으로 기록하기 위해 MD 파일에 저장할 수 있습니다. 또한 쉽게 회상할 수 있도록 메모리 (memories)에 기록될 수도 있습니다.

만약 개발자가 직접 손으로 문제를 해결한다면, 이는 학습의 기회를 놓치는 것입니다. 직접 수정하면 단기적으로는 시간을 절약할 수 있습니다. AI가 수정하게 하는 것보다 직접 수정하는 것이 종종 더 빠를 수도 있습니다. 하지만 AI는 그 실수에 대해 배우고 조정하기 전까지는 계속해서 그 실수를 반복할 것입니다.

마치며

전통적인 코딩에서 에이전트 기반 코딩 (Agentic Coding)으로의 전환을 협상하는 과정은 간단하지 않습니다. 코더 (Coder)에서 아키텍트 (Architect)로 전환함에 따라 직접 코드를 작성할 때 느끼던 만족감이 사라지며, 이는 개발자들에게 고통스러운 과정이 될 수 있습니다. 이러한 전환을 헤쳐 나가는 것은 하룻밤 사이에 이루어지지 않습니다.

사고방식을 개발자에서 아키텍트로 전환하고 나면, 여전히 자랑스러워할 만한 것들이 있다는 사실을 깨닫게 됩니다. 그것은 이전과는 다른 종류의 자부심이지만, 그 과정에서 진정으로 흥분되는 요소들을 발견하게 될 것입니다.

아키텍트가 된다는 것은 본인이 직접 손으로 작성할 수 있는 지식의 한계에 갇히지 않고, 무엇이 가능한지에 대해 훨씬 더 넓은 시야를 갖게 된다는 것을 의미합니다. 이제는 특정 문제를 해결하기 위한 솔루션을 구축하는 것과, 이전보다 훨씬 더 빠르게 결과를 확인하는 것에 더 집중하게 됩니다. 개발자로서의 기술은 다른 프로그래밍 언어로도 전이되며, AI 프로세스 또한 어떤 언어로 작성하든 마찬가지입니다.

우리가 처음 코딩을 시작했을 당시에는 존재하지 않았던 CSS, JS 및 모든 기술들을 배워야 했던 것처럼, 2026년의 개발자에게 AI를 배우는 것은 필수적인 부분입니다. 도구를 배우지 않는다면, 결국 뒤처지게 될 것입니다.