수년 동안 인공지능은 에디터 옆에서 당신과 함께하며 다음에 올 내용을 추측해 왔습니다. 당신이 한 줄을 쓰면, 다음 줄을 제안했습니다. 하지만 아키텍처, 디버깅, 구문은 여전히 당신의 몫이었습니다. 이제 그 시대는 끝났습니다.

우리는 의도 기반 개발(Intent-Driven Development)의 시대로 나아가고 있습니다. 이제 루프나 조건문을 직접 타이핑하지 않습니다. 대신 필요한 결과를 설명합니다. 에이전트가 그 목표를 흡수하여 단계를 계획하고, 코드를 작성하고, 테스트를 실행하며, 당신이 결과를 확인하기도 전에 스스로 오류를 수정합니다. 키보드는 더 이상 주요 도구가 아닙니다. 명확한 사고가 그 자리를 대신합니다.

한 줄씩 코딩하는 시대의 종말

기존의 워크플로우는 모든 의도를 컴파일러가 이해할 수 있는 특정 언어로 번역해야만 했습니다. 머릿속에 비즈니스 요구사항을 담은 뒤, 이를 함수, 임포트, 에러 처리, 테스트 케이스로 수동으로 나누어야 했습니다. 의도 기반 개발은 이러한 번역 계층을 무너뜨립니다.

결제 웹훅(payment webhook)을 통합해야 한다고 가정해 봅시다. 이전에는 라우트 핸들러를 작성하고, 페이로드를 파싱하며, 서명을 검증하고, 트랜잭션 내에서 데이터베이스를 업데이트한 뒤 영수증 이메일을 큐에 넣어야 했습니다. 이제는 요구사항을 설명하기만 하면 됩니다: “들어오는 Stripe 웹훅을 검증하고, 이벤트를 멱등하게(idempotently) 기록하며, 영수증 흐름을 트리거하세요. 데이터베이스 쓰기에 실패하면 롤백하세요.” 에이전트는 핸들러를 작성하고, 파싱 전략을 선택하며, 재시도 로직을 구조화하고, 테스트를 생성합니다. 당신의 역할은 저자(author)에서 감독(director)으로 전환됩니다.

이것이 가능한 이유는 에이전트가 단순히 생성에서 멈추지 않기 때문입니다. 에이전트는 루프(loop)에 진입합니다.

에이전트 루프 내부

핵심 작업은 더 이상 인간의 타이핑이나 수동 디버깅이 아닙니다. 생성과 검증 사이의 긴밀한 순환입니다. 에이전트는 코드를 생성하고, 테스트 스위트에서 이를 실행하며, 출력을 읽고, 실패를 스스로 수정합니다. 누락된 임포트, 타입 불일치, 실패하는 어설션(assertion) 등 — 에이전트는 스택 트레이스(stack trace)를 확인하고, 파일을 수정하고, 스위트를 다시 실행합니다. 당신은 이 루프 안에 있지 않습니다. 이 사이클은 기계의 속도로 돌아갑니다.

당신은 루프 자체가 깨질 때 개입합니다. 에이전트가 두 의존성 간의 충돌을 해결하지 못하거나, 단위 테스트는 통과하지만 상위 수준의 비즈니스 규칙을 위반하는 코드를 계속 생성하는 경우입니다. 이러한 경계가 바로 인간의 판단이 여전히 중요한 지점입니다.

당신의 진짜 역할: 제약 조건 설계자 및 엣지 케이스 탐색자

기계가 함수를 작성한다면, 당신에게 남은 것은 무엇일까요? 두 가지가 있으며, 이는 구문을 타이핑하는 것보다 훨씬 어렵습니다.

첫째, 에이전트가 경로를 이탈하지 않도록 제약 조건을 작성해야 합니다. 에이전트는 광범위한 지식을 가지고 있지만 당신의 특정 환경에 대한 이해는 없습니다. 당신은 다음과 같이 지시해야 합니다: “내부 결제 API만 사용하고, 원본 카드 토큰을 절대 로그에 남기지 마세요. 응답 지연 시간은 200밀리초 미만으로 유지하세요.” 이러한 경계는 단순한 프롬프트가 아닙니다. 성공과 실패를 결정짓는 사양(specification)입니다.

둘째, 에이전트가 실패하는 10%의 케이스를 잡아내야 합니다. 에이전트는 일반적인 경로는 잘 처리합니다. 하지만 미묘한 레이스 컨디션(race condition), 모호한 비즈니스 로직의 엣지 케이스, 학습 데이터에 내재된 보안 가정 등에서 실수를 범합니다. 당신의 경쟁력은 웹훅 핸들러와 환불 크론 잡(cron job) 사이의 레이스 컨디션을 포착하거나, 생성된 재시도 로직이 결제를 중복 발생시킬 수 있음을 인지하는 데서 나옵니다. 기계는 표준적인 문제를 해결합니다. 당신은 위험한 예외를 잡아냅니다.

코드 리뷰를 검증 하네스로 대체하기

에이전트가 하룻밤 사이에 50개의 파일을 만들어낼 수 있다면, 단순히 "맞아 보이는지" 확인하기 위해 디프(diff)를 훑어보는 방식으로는 리뷰할 수 없습니다. 그 양 때문에 인간의 육안 검사는 불가능합니다. 코드가 당신에게 도달하기 전에 오류를 잡아낼 수 있는 하네스(harness)가 필요합니다.

이 하네스는 세 가지 기둥 위에 세워집니다.

내구성 있는 실행(Durable execution). 에이전트 작업은 종종 단일 요청 타임아웃보다 오래 실행됩니다. 일시적인 네트워크 장애로 인해 단계가 실패하면, 하네스는 상태를 손상시키지 않고 작업을 일시 중지했다가 재시도하고 다시 재개합니다. 작업은 중단 상황에서도 유지됩니다.

구조화된 출력(Structured outputs). 에이전트가 잘 구성된 설정 파일을 반환하기를 막연히 기대하는 대신, 사전에 계약(contract)을 강제합니다. JSON Schema와 같은 도구를 사용하여 출력을 즉시 검증합니다. 에이전트가 필수 필드를 누락하거나 잘못된 데이터 타입을 사용하면, 코드가 저장소에 반영되기 전에 하네스가 이를 거부합니다.

동적 가드레일(Dynamic guardrails). 에이전트에게 비밀 정보를 읽거나 운영 데이터베이스에 쓸 수 있는 자유를 주어서는 안 됩니다. 하네스는 권한을 동적으로 제어하여 에이전트를 샌드박스(sandboxing) 처리함으로써, 지정된 테스트 데이터베이스와 내부 엔드포인트에만 접근할 수 있도록 제한합니다. 당신은 모든 줄을 리뷰하는 것이 아닙니다. 당신은 에이전트를 둘러싼 울타리를 감사(auditing)하는 것입니다.

코드는 작동하지만 제품은 실패할 때

여기에 역설이 있습니다. 테스트 하네스는 잘못된 코드는 잡아낼 수 있지만, 잘못된 의도는 잡아낼 수 없습니다.

만약 명세서에 “모든 신규 사용자에게 환영 이메일을 보내라”고 적혀 있다면, 에이전트는 해당 이메일을 보내는 깔끔하고 테스트를 거친 코드를 작성할 것입니다. 하지만 당신의 의도가 “사용자가 주소를 인증하고, 마케팅 수신에 동의했으며, 현지 시간대 기준으로 업무 시간 중에 가입했을 때만 환영 이메일을 보내라”는 것이었다는 사실은 알지 못할 것입니다. 코드는 기술적으로 결점이 없지만, 상업적으로는 위험합니다.

의도 기반 개발(Intent-Driven Development)의 진짜 위험은 모호한 명세에 있습니다. 불분명한 의도는 교과서적인 우아함을 갖추었으나 정작 잘못된 문제를 해결하는 소프트웨어를 만들어냅니다. 이것이 바로 명세를 실제 자산처럼 다뤄야 하는 이유입니다. 명세의 버전을 관리하십시오. 이해관계자들과 함께 검토하십시오. 에이전트가 구축을 시작하기 전에 실제 워크플로우에 맞춰 검증하십시오. 채팅창에 휘갈겨 쓴 프롬프트는 명세가 아닙니다. 그것은 위험 요소일 뿐입니다.

엔지니어링적 판단이 상류로 이동한다

엔지니어링적 판단이 사라지는 것이 아닙니다. 더 높은 차원으로 이동하고 있는 것입니다.

이제 더 이상 맵을 어떻게 반복(iterate)할지, 클래스 계층 구조를 어떻게 설계할지에 정신적 에너지를 쏟지 않습니다. 대신 시스템이 장애 상황에서 무엇을 해야 하는지, 어떤 데이터를 절대 노출해서는 안 되는지, 그리고 분산 서비스 전반에서 어떤 불변성(invariants)이 유지되어야 하는지에 에너지를 쏟습니다. 코딩의 기술이 요구사항 정의의 기술로 변모하고 있습니다.

이는 명세에도 과거에 코드에 적용했던 것과 동일한 엄격함이 필요함을 의미합니다. 제약 조건을 정확하게 명시하십시오. 장애 모드(failure modes)를 명시적으로 정의하십시오. 과거에 타입을 선언했듯이 비즈니스 규칙을 명확하게 기술하십시오. 구현은 에이전트가 처리할 것입니다. 당신은 그 구현이 구축할 가치가 있는지를 보장해야 합니다.

품질 기준을 풀 리퀘스트(pull request)에서 프롬프트로 옮기십시오. 하네스를 먼저 구축하십시오. 그다음 명세를 작성하십시오. 그런 다음 기계가 구문(syntax)을 처리하도록 맡기고, 당신은 문제가 올바르게 정의되었는지와 경계가 안전하게 설정되었는지에 집중하십시오.

이러한 변화의 이면에 있는 아이디어를 더 깊이 탐구하고 싶다면, 의도 기반 개발에 관한 원문 토론을 여기에서 확인할 수 있습니다. AI 네이티브 엔지니어링에 관한 지속적인 대화에 참여하려면 GyaanSetu 커뮤니티에 가입할 수도 있습니다.