에이전트 기반 코딩 (Agentic Coding) 시대에 신뢰할 수 있는 소프트웨어 구축하기

단순한 자동 완성 (Autocomplete) 용도가 아니라, 실제로 여러 파일에 걸친 변경 사항을 주도하고, 통합 작업을 연결하며, 에이전트 파이프라인 (Agent pipelines)을 구축하기 위해 코딩 에이전트 (Coding agents)를 본격적으로 사용한 지 몇 주가 지났을 때, 저는 한 가지 패턴을 발견했습니다. 생성된 코드는 올바르게 보였습니다. 컴파일되었고, 실행되었으며, 데모도 작동했습니다. 하지만 며칠 후, 에이전트가 자신이 작업하던 시스템을 실제로 이해하지 못했다는 사실이 명백히 드러나는 방식으로 무언가 고장 났습니다. 에이전트는 그저 그럴듯해 보이는 답변을 내놓기 위해 패턴 매칭 (Pattern-matching)을 수행했을 뿐이었습니다.

이것이 내재화해야 할 핵심입니다. 코딩 에이전트는 매우 뛰어난 패턴 완성자 (Pattern completer)이지, 엔지니어가 아닙니다. 엔지니어는 의도 (Intent), 제약 조건 (Constraints), 실패 모드 (Failure modes), 그리고 트레이드오프 (Tradeoffs)를 동시에 머릿속에 담고 있습니다. 에이전트는 컨텍스트 윈도우 (Context window)를 담고 있을 뿐입니다. 이 둘을 혼동하는 지점에서 신뢰성 문제가 시작됩니다.

코딩 에이전트가 실제로 잘하는 것

도구들에 대해 공정하게 말하자면, 이들은 워크플로우 (Workflow) 내에서 자신의 자리를 확보했습니다:

• 보일러플레이트 (Boilerplate) 및 스캐폴딩 (Scaffolding). CRUD 엔드포인트 (Endpoints), 설정 파일 (Config files), 테스트 스켈레톤 (Test skeletons), 코드베이스 전반에 걸친 반복적인 글루 코드 (Glue code).
• 명확한 사양 (Spec)을 초안으로 번역하기. 원하는 형태를 정확하게 설명할 수 있다면, 에이전트는 80%의 작업을 빠르게 완료해 줄 것입니다.
• 익숙하지 않은 구문 (Syntax) 작업하기. 당신보다 Terraform이나 SQL 방언 (Dialects)을 수천 번 더 많이 접해본 에이전트는 실제 조사 시간을 절약해 줄 수 있습니다.
• 기계적인 리팩터링 (Refactors). 40개 파일에 걸친 이름 변경, API 서피스 (API surface) 마이그레이션, 나타나는 모든 곳의 의존성 (Dependency) 사용 패턴 업데이트.

이것들은 실제적인 생산성 향상입니다. 실수는 "보일러플레이트에 능숙하다"는 사실로부터 "아키텍처 (Architecture)를 믿고 맡길 수 있다"로 비약하는 데서 발생합니다.

그들이 실패하는 지점

실패는 무작위로 일어나지 않으며, 예측 가능한 지점에 모여 있습니다:

• 조용한 범위 축소 (Silent scope narrowing). 에이전트에게 "에러를 적절히 처리해줘"라고 요청하면, 에이전트는 현재 파일에서 보이는 에러만 처리할 뿐, 실제 운영 트래픽이 맞닥뜨리는 호출 스택(call stack) 상위 세 단계의 에러는 처리하지 못합니다.
• 확신에 찬 오답 (Confident wrongness). 에이전트는 "잘 모르겠다"라는 강력한 신호를 보내지 못합니다. 에이전트는 올바른 코드와 똑같은 확신을 가지고, 관용적(idiomatic)으로 보이지만 멱등성(idempotency) 측면에서 미묘하게 틀린 Daraja API 콜백 핸들러를 작성할 것입니다.
• 지역적 최적화, 전역적 맹목 (Local optimization, global blindness). 한 서비스의 버그를 수정하는 에이전트는 자신이 방금 변경한 동작에 의존하는 다른 세 서비스에 대한 모델을 가지고 있지 않습니다.
• 사후 고려 사항으로서의 보안 (Security as an afterthought). 에이전트에게 자율성을 맡기면, 비밀 키를 하드코딩하거나, 입력 검증(input validation)을 건너뛰거나, SQL 인젝션(injection) 공격에 취약한 문자열을 생성하는 일을 기꺼이 수행할 것입니다. 왜냐하면 이 중 그 어떤 것도 당면한 과제를 수행하는 데에는 방해가 되지 않기 때문입니다.
• 테스트 연극 (Test theater). 에이전트는 통과하는 테스트를 작성할 것입니다. 때로는 의도된 동작이 아니라 구현된 실제 (잘못된) 동작에 맞춰 테스트를 작성하기 때문입니다.

이것은 도구에 대한 비판이 아닙니다. 이는 "이 시스템을 시간이 지나도 책임질 수 있게 만들기"보다는 "그럴듯한 다음 토큰을 생성하기"를 최적화하는 시스템에서 기대할 수 있는 결과입니다.

기본기가 더 중요해지는 이유, 덜 중요해지는 것이 아니라

유혹적인 서사는 에이전트 기반 코딩(agentic coding)이 엔지니어링의 기본기를 덜 중요하게 만든다는 것입니다. 즉, AI가 코드를 작성한다면 당신은 코드를 그만큼 깊이 이해할 필요가 없다는 논리입니다. 하지만 사실은 그 반대입니다.

당신이 모든 줄을 직접 작성할 때는, 타이핑하는 행위 자체를 통해 이해가 강제됩니다. 하지만 에이전트(Agent)가 작성할 때는 이해가 선택 사항이 되며, 이를 건너뛰는 행위는 나중에 아무도 설명할 수 없는 부채를 시스템에 축적하는 바로 그 방식이 됩니다. 엔지니어의 역할은 올바른 코드를 '작성하는' 것에서 올바른 코드를 '명세하고(specifying), 검증하며(verifying), 경계를 설정하는(bounding)' 것으로 전환됩니다. 이는 결코 쉬운 기술이 아니라, 오히려 더 어려운 기술이라고 할 수 있습니다. 작성 시점이 아닌 리뷰 시점에 적용될 뿐, 데이터 모델링(Data modeling), 실패 모드(Failure modes), 동시성(Concurrency), 그리고 시스템 경계(System boundaries)에 대한 동일한 기초 지식을 요구하기 때문입니다.

만약 당신이 레이스 컨디션(Race condition)이 어떤 모습인지 이미 알고 있지 않다면, 에이전트가 9초 만에 생성한 400줄짜리 디프(Diff)에서 이를 잡아낼 수 없을 것입니다.

컨텍스트 관리 (Context management)

내가 추적해 온 대부분의 에이전트 실패 원인은 추론(Reasoning)의 실패가 아니라, 컨텍스트(Context)의 실패였습니다. 에이전트 앞에 올바른 정보가 없었기에, 그 공백을 그럴듯해 보이는 무언가로 채워 넣은 것입니다.

도움이 되는 실질적인 습관들:

• 에이전트의 작업 컨텍스트(Working context)를 실제로 관련이 있는 시스템의 가장 작은 조각으로 범위를 제한하세요. 비대해진 컨텍스트 윈도우(Context window)가 더 나은 결정을 의미하지는 않습니다. 오히려 주의력(Attention)이 희석됨을 의미할 때가 많습니다.
• 제약 사항(Constraints)을 추론될 것이라고 가정하는 대신 외부화하세요: 속도 제한(Rate limits), 멱등성 요구 사항(Idempotency requirements), 데이터 보존 규칙(Data retention rules), 컴플라이언스 경계(Compliance boundaries) 등. 에이전트가 3턴 전의 내용을 기억하고 있을 것이라고 믿기보다, 매번 명시적으로 말해 주어야 합니다.
• 코드베이스에 대한 에이전트의 기억을 실시간 뷰(Live view)가 아닌 스냅샷(Snapshot)으로 취급하세요. 다른 세션에서 무언가를 변경했다면, 에이전트가 그것을 알고 있다고 가정하지 마세요.

AI 생성 코드 테스트 (Testing AI-generated code)

에이전트가 작성한 코드는 인간이 작성한 코드와는 다른 테스트 태세(Testing posture)가 필요합니다. 실패의 분포가 다르기 때문입니다. 인간 엔지니어는 시간 압박 속에서 누락(Omission)에 의한 오류를 범하는 경향이 있는 반면, 에이전트는 '거짓된 자신감(False confidence)'에 의한 오류를 범하는 경향이 있습니다. 즉, 완성된 것처럼 보이지만 명세(Spec)에서 조용히 벗어난 무언가를 구현해 버립니다.

이는 다음과 같은 필요성을 뒷받침합니다:

• 에이전트가 구현(Implementation)과 테스트를 모두 작성하게 두는 대신, 직접 테스트 케이스(Test cases)를 작성하거나 최소한 한 줄씩 검토해야 합니다.
• 에이전트에게 명시적으로 지시되지 않은 경계 조건(Boundaries), 즉 빈 리스트(Empty list), 네트워크 타임아웃(Network timeout), 잘못된 형식의 웹훅 페이로드(Malformed webhook payload) 등을 테스트해야 합니다. 왜냐하면 바로 그 지점들이 패턴 완성(Pattern-completion)이 무너지는 지점이기 때문입니다.
• 생성된 코드를 깨끗한 피스처(Fixtures)에 대해 신뢰하기 전에, 실제의 지저분한 데이터(Messy data)를 대상으로 실행해 보아야 합니다.

보안 위험 (Security risks)

에이전트 기반 코딩(Agentic coding)은 5년 전에는 존재하지 않았던 보안 표면(Security surface)을 도입하며, 이는 가설이 아닌 현실입니다:

• 비밀 정보 유출 (Secrets leakage). 에이전트가 로그, 커밋 또는 프롬프트(Prompts)에 포함해서는 안 될 자격 증명(Credentials)을 끌어오는 경우입니다.
• 의존성 확산 (Dependency sprawl). 에이전트가 작은 문제를 해결하기 위해 패키지를 가져다 쓰지만, 아무도 그 패키지의 유지 관리 상태나 공급망 위험(Supply-chain risk)을 평가하지 않는 경우입니다.
• 생성된 코드를 통한 인젝션 (Injection through generated code). 문자열로 구축된 쿼리(String-built queries), 정제되지 않은 입력값(Unsanitized inputs), 허용 범위가 넓은 CORS 등 고전적인 실수들이 더 빠르고 더 많은 곳에서 동시에 발생합니다.
• 에이전트 파이프라인에서의 프롬프트 인젝션 (Prompt injection in agent pipelines). 만약 에이전트가 작업의 일부로 외부 콘텐츠(웹페이지, 고객 메시지, 파일 등)를 읽는다면, 명시적으로 방어 조치를 취하지 않는 한 해당 콘텐츠는 에이전트가 따르게 될 지시 사항을 포함할 수 있습니다.

이 중 그 어떤 것도 "에이전트는 보통 조심스럽다"라는 말로 해결되지 않습니다. 이는 에이전트가 손댄 모든 표면을 검토 전까지는 신뢰할 수 없는 것으로 취급함으로써 해결됩니다. 이는 여러분이 한 번도 만난 적 없는 기여자(Contributor)에게 적용할 것과 동일한 규율입니다.

에이전트의 결정 검토하기 (Reviewing agent decisions)

에이전트 출력물에 대한 코드 리뷰(Code review)는 동료의 PR(Pull Request)에 대한 코드 리뷰와는 달라야 합니다. 실패 모드(Failure mode)가 다르기 때문입니다. 동료의 실수는 대개 심문할 수 있는 추론 과정(Reasoning trail)을 동반합니다. 하지만 에이전트의 실수는 종종 그렇지 않으며, 그저 결과물만을 내놓을 뿐입니다.

이는 리뷰가 단순히 "무엇(What)"을 확인하는 것을 넘어, "왜(Why)"를 재구성해야 함을 의미합니다:

• 중요도가 높은 변경 사항을 수락하기 _전(before)_에 에이전트에게 그 추론 과정을 설명하도록 요청하고, 그 설명을 형식적인 절차가 아닌 비판적인 시각으로 읽으십시오.
• 단순히 이전 버전과 비교하는 것이 아니라, 의도(intent)와 비교하여 차이(Diff)를 확인하십시오. 이 변경 사항이 실제로 요청된 대로 수행되었습니까, 아니면 눈에 보이는 테스트는 통과하지만 요청과는 인접한 다른 무언가를 수행하고 있습니까?
• 작업에 필요한 것보다 더 많은 파일을 건드리는 변경 사항은 특히 의심하십시오. 이는 에이전트가