전통적 코딩과 에이전틱 코딩의 차이 — 플로우 상태의 문제

AI 요약

코딩의 즐거움은 단순히 많은 코드를 만들어내는 데서 오지 않고, 문제를 이해하고 작은 결정을 반복하면서 해결 과정에 깊이 관여하는 데서 오기도 합니다. 이 글은 AI coding agent를 활용하는 agentic coding이 코드 생산량은 늘려주지만, 개발자가 문제와 계속 연결되어 있다는 감각과 flow state를 약화할 수 있다고 설명합니다. AI를 거부하자는 주장이 아니라, AI에 일을 넘기는 방식과 개발자가 결과를 검토하는 흐름을 다시 설계하자는 제안입니다.

■ 전통적 코딩이 만드는 촘촘한 피드백 루프

수동으로 코딩할 때는 보통 생각하고, 작성하고, 실행하고, 관찰하고, 조정하는 루프를 반복합니다. 기능을 구현하면서 어떤 파일을 바꿔야 하는지, 데이터가 애플리케이션 안에서 어떻게 이동하는지, 사용자가 폼을 제출했을 때 어떤 일이 일어나야 하는지를 차례로 판단합니다. 충분한 코드를 작성해 실행한 뒤에는 성공했는지, 오류가 발생했는지, 동작은 하지만 의도와 다른지 확인할 수 있습니다.

각 결과는 바로 다음 결정을 위한 재료가 됩니다. 이 과정이 수십 번 반복되면 계획·코딩·테스트 사이를 의식적으로 오가는 느낌이 줄고, 눈앞의 문제를 계속 해결하는 상태에 가까워집니다. 빌드가 오래 걸리거나 문서를 따라가다 다른 자료로 빠지는 일, 막혀서 진전하지 못하는 일도 있지만, 작업 자체가 다음 결정을 요구한다는 점은 유지됩니다. 글에서는 어려운 기능을 완성했을 때의 만족감이 결과뿐 아니라 그 과정에서 경험한 작은 판단과 돌파에서 나온다고 설명합니다.

■ 에이전틱 코딩에서 발생하는 대기와 컨텍스트 전환

agentic coding에서는 계획을 세운 뒤 기능을 설명하고 에이전트에게 구현을 맡깁니다. 그러면 개발자는 작업이 끝날 때까지 기다려야 합니다. 에이전트가 처리하는 동안 이메일을 확인하거나 다른 탭을 열거나 다른 프로젝트로 이동하기 쉽습니다. 데스크톱 도구에서는 프로젝트 A의 에이전트가 실행되는 동안 프로젝트 B에 프롬프트를 보내고, 다시 프로젝트 C의 작업을 시작하는 흐름도 가능합니다.

처음에는 여러 에이전트가 동시에 일하고, 과거에 며칠 걸리던 일이 몇 분 안에 진행되는 것처럼 보여 강력한 능력을 얻은 느낌을 줄 수 있습니다. 그러나 프로젝트 A가 끝났을 때는 자신이 무엇을 요청했는지, 어떤 결과를 기대했는지, 애플리케이션의 어느 부분이 영향을 받는지 다시 기억해야 합니다. 이후 변경 사항을 검토하고 결과를 테스트한 뒤 수정 프롬프트를 보내는 동안 프로젝트 C가 끝날 수도 있습니다.

이렇게 되면 한 가지 어려운 문제를 두 시간 동안 붙들고 해결하는 대신, 여러 문제에서 어디까지 진행했는지를 반복해서 복원하는 데 시간을 쓰게 됩니다. 글에 제시된 시각 자료의 색깔별 행은 이러한 분산된 주의를 표현한 것이며, 생산성을 측정한 데이터는 아닙니다. 핵심은 작업이 계속 진행되고 있어도 개발자가 어느 한 작업에 완전히 정착하지 못할 수 있다는 점입니다.

■ 주의력과 코드 소유권의 변화

각 프로젝트를 다시 시작하려면 현재 기능, 관련 파일, 해결되지 않은 질문, 지금의 결정에 이르게 된 이유를 다시 머릿속에 올려야 합니다. 파일을 재독해하고, 특정 접근 방식을 선택한 이유를 잊고, 이전 결정과 충돌하는 변경을 놓칠 수 있습니다. 각각은 큰 문제처럼 보이지 않을 수 있지만, 반복되면 전체 작업이 피로해집니다. 또한 개발자는 합리적인 중단 지점에 도달해서가 아니라 에이전트가 끝났다는 알림을 보고 작업을 전환하게 됩니다.

글은 ownership의 상실도 지적합니다. 에이전트가 코드를 작성했다고 해서 개발자가 아무것도 하지 않은 것은 아닙니다. 아이디어를 내고, 작업을 계획하고, 에이전트를 지시하고, 결과를 받아들일 수 있는지 판단하는 일은 모두 개발자의 기여입니다. 다만 맡기는 작업이 커질수록 구현 과정의 결정 중 개발자가 직접 관여하지 않는 부분이 많아집니다.

예를 들어 인증 기능을 한 번에 맡기면 사용자 모델, 유효성 검사, 오류 처리, 세션 관리, 인터페이스의 반응 방식에 관한 선택이 하나의 큰 diff로 나타날 수 있습니다. 결과를 검토할 수는 있지만, 각 결정이 어떻게 형성되었는지를 따라가지 않았다면 변경이 필요할 때 그 가정이 코드의 어디에 놓여 있는지 알기 어려울 수 있습니다. 애플리케이션 전체를 one-shot으로 생성하면 겉보기에는 그럴듯하지만 개발자가 거의 이해하지 못하는 코드베이스가 될 수 있다는 설명도 이어집니다.

■ 작은 handoff와 의미 있는 checkpoint

글에서 제안하는 방법은 기능 전체를 한 번에 맡기지 않고, 개발자가 의미 있게 검토할 수 있는 크기로 작업을 나누는 것입니다. 인증 시스템 전체를 만들라고 요청하는 대신 먼저 user model을 만들게 하고, 애플리케이션에 필요한 필드가 맞는지 확인합니다. 그다음 registration endpoint를 요청하고, 해당 변경을 테스트하고 검토한 뒤 다음 단계로 넘어갑니다.

작은 요청은 구현을 이해하고 방향을 수정할 기회를 만듭니다. 적절한 작업 크기는 프로젝트와 개발자의 경험에 따라 달라집니다. 익숙한 코드베이스에서 일하는 숙련된 개발자는 완성된 기능을 맡길 수 있지만, 스택을 배우는 사람은 더 작은 단계가 필요할 수 있습니다. 중요한 기준은 결과가 중요한 결정을 이해할 수 있는 크기인지입니다. 결과가 너무 커서 핵심 결정을 파악할 수 없다면 handoff가 지나치게 컸다는 뜻입니다.

“build authentication”보다 “이 user model을 사용해 registration endpoint를 만들어 달라”는 요청이 소프트웨어 구조와 더 직접적으로 연결됩니다. 개발자는 애플리케이션이 무엇을 필요로 하는지, 구성 요소들이 어떻게 맞물리는지를 계속 생각할 수 있습니다. 따라서 models, routes, endpoints, components, data flow 같은 기본 개념을 이해하는 일이 여전히 중요합니다. 그래야 유용한 질문을 만들고 잘못된 구현을 알아볼 수 있습니다.

■ 작업이 끝날 때까지 같은 문제를 유지하기

에이전트가 처리하는 동안 즉시 무관한 프로젝트로 이동하지 않는 것도 방법으로 제시합니다. 같은 프로젝트의 주변 코드를 읽거나, edge case를 생각하거나, 테스트를 준비하거나, 현재 작업이 계획과 맞는지 확인할 수 있습니다. 에이전트가 생성하는 모든 줄을 지켜볼 필요는 없지만, 결과가 도착했을 때 무엇을 했는지 이해할 수 있을 정도로 문제를 머릿속에 유지하는 것이 목적입니다.

에이전트가 완료되면 다음 프로젝트로 넘어가기 전에 diff를 확인하고 동작을 테스트합니다. 요청한 문제를 해결했는지, 관련 없는 파일을 바꾸지 않았는지, 기존 코드에 맞는 구현인지, 에이전트에게 자신의 애플리케이션을 다시 설명해 달라고 하지 않아도 유지보수할 수 있을 만큼 결정을 이해하는지 확인합니다. 복잡한 작업을 쌓아두면 코드는 작성되더라도 검증과 이해의 작업은 사라지지 않고 나중에 더 큰 복원 작업으로 돌아옵니다.

글은 parallel agents 자체를 반대하지 않습니다. 같은 프로젝트의 연관된 부분을 조사하거나, 계획된 checkpoint에서 검토할 수 있는 작업이라면 여러 에이전트가 유용할 수 있습니다. 문제는 서로 무관한 세 프로젝트가 하루 종일 주의를 나누어 갖는 상황입니다. 중요한 것은 에이전트의 절대적인 수보다 그 작업이 개발자에게 요구하는 주의의 형태입니다. 여러 에이전트가 하나의 명확한 목표에 기여하는 경우는 관리할 수 있지만, 서로 다른 애플리케이션에서 동시에 작업하면 무관한 결정 사이를 계속 전환하게 될 수 있습니다.

■ AI Blueprint와 목표로 삼는 협업 방식

작성자는 이러한 생각을 실천하기 위한 오픈소스 AI coding workflow framework인 AI Blueprint를 만들었다고 소개합니다. 이 프레임워크는 한 번에 하나의 기능을 계획하고 구현하도록 에이전트에 구조를 제공하며, specs, project context, completed history를 코드 옆의 읽을 수 있는 파일로 유지합니다. 다만 특정 설정을 그대로 사용할 필요는 없으며, 중요한 부분은 개발자가 계속 관여할 수 있는 checkpoint를 선택하는 데 있다고 설명합니다.

궁극적으로 지향하는 방식은 많은 탭을 열어 최대한 많은 코드를 동시에 생성하는 것보다, 빠른 pair programmer와 함께 일하는 흐름에 가깝습니다. 에이전트가 구현의 상당 부분을 담당하더라도 개발자는 결정과 피드백에 참여합니다. 이렇게 하면 raw code의 양은 줄어들 수 있지만, 생성된 코드의 양만으로 좋은 결과를 판단할 수는 없습니다. 결과가 동작하는지, 무엇을 만들었는지 이해하는지, 나중에 직접 변경할 수 있는지가 더 중요하다는 주장입니다.

글의 결론은 AI를 덜 쓰라는 것이 아니라 handoff의 크기를 바꾸라는 제안입니다. 이해할 수 있는 checkpoint를 선택하고, 에이전트가 작업하는 동안 같은 프로젝트의 문제를 유지하며, 이동하기 전에 결과를 검토하고 테스트합니다. 그렇게 하면 수동 코딩과 완전히 같은 만족감을 얻지는 못하더라도, 큰 작업을 넘긴 뒤 이해하기 어려운 변경 사항 더미와 마주하는 것보다는 프로젝트의 구조와 결정에 가까이 남을 수 있습니다.

원문: dev.to / 번역·요약: Trawling