칼럼 | AWS에서 보낸 20년, 에이전틱 AI에 대한 깨달음

올해는 AWS 출범 20주년이자, 필자가 아마존에서 개발자로 일한 지 20년이 되는 해다.

필자의 커리어는 줄곧 한 가지 목표를 향해 이어져 왔다. 바로 개발자의 일을 더 쉽게 만드는 것이다. 개발자인 필자에게도 다소 이기적인 목표이긴 했다. 예를 들어 데이터베이스 운영에 많은 시간을 빼앗기자, 이를 서비스로 해결하기 위해 DynamoDB 팀에 합류했다. 개발자가 더 이상 직접 데이터베이스를 운영하지 않아도 되도록 하기 위해서였다.

이후에는 람다(Lambda)와 API 게이트웨이(API Gateway) 개발에 참여했다. 덕분에 서버를 일일이 관리하거나 요청 라우팅을 직접 처리할 필요가 없어졌다. 이어 클라우드워치(CloudWatch) 개발에도 참여해 운영 환경에서 코드가 실제로 어떻게 동작하는지 손쉽게 확인할 수 있도록 했다. 매번 목표는 같았다. 반복적이고 번거로운 작업을 없애고, 누구나 별다른 고민 없이 사용할 수 있는 서비스로 만드는 것이었다.

지금도 같은 목표를 추구하고 있다. 달라진 것은 사용하는 도구뿐이다.

바이브 코딩의 등장과 한계

LLM은 자연어로 원하는 기능을 설명하면 필요한 코드를 즉시 생성할 수 있는 시대를 열었다. 초기에는 이른바 ‘바이브 코딩(vibe coding)’ 방식이 주를 이뤘다. 스크립트 수정을 요청하고, 코드를 컴파일해 실행한 뒤, 발생한 오류를 다시 입력하면서 다음 결과가 더 나아지기를 기대하는 식이었다.

하지만 바이브 코딩의 전체 과정을 에이전트 루프(agentic loop) 로 자동화하면서 상황은 크게 달라졌다. 이제는 사람이 오류를 일일이 전달하지 않아도 에이전트가 스스로 모델을 호출하고, 코드를 실행한 뒤 실패 원인을 확인하며, 테스트를 통과할 때까지 반복 작업을 수행할 수 있게 됐다.

그러나 한 가지 큰 문제가 있었다. 에이전트가 쉽게 방향을 잃는다는 점이다. 개인 프로젝트에서는 큰 문제가 아닐 수 있지만, 대규모의 핵심 코드베이스에서는 결코 용납할 수 없는 한계다.

에이전트를 위한 명세 기반 개발

필자가 에이전트가 방향을 잃지 않도록 하는 방법은 명세 기반 개발(spec-driven development)이다.

막연한 프롬프트만 입력한 채 에이전트를 코드 저장소(repo)에 투입하는 대신, 본격적인 코딩에 앞서 에이전트와 함께 세 가지 핵심 산출물을 먼저 만든다. 요구사항 명세(requirements specification), 설계 문서(design document), 작업 분해(task breakdown)이며, 모두 마크다운(Markdown) 형식으로 작성한다.

이 문서들은 ‘개발 완료(done)’의 기준을 정의하는 공동 계약서 역할을 한다. 사람과 에이전트 모두 읽고, 검토하고, 수정할 수 있는 형태로 관리된다.

실제 업무에서는 일반적인 AI에 입력할 법한 프롬프트로 시작한다. 그러면 에이전트는 이를 ‘반드시 수행해야 한다(shall)’는 요구사항과 수용 기준(acceptance criteria)을 포함한 구조화된 요구사항 문서로 확장한다. 필자는 이 문서를 검토하면서 에이전트와 대화를 이어가고, 원하는 내용과 일치할 때까지 수정한다.

요구사항이 정리되면 에이전트는 설계안을 제시한 뒤, 우선 실제로 동작하는 기능을 구현하는 데 초점을 맞춰 작업을 세분화한다. 이후 완성도를 높이고 포괄적인 테스트를 추가하는 방식으로 개발을 진행한다.

이 과정의 장점은 절차가 경직돼 있다는 데 있지 않다. 실제로는 여러 단계를 오가며 반복적으로 수정한다. 설계를 검토하다 보면 빠진 요구사항이 발견되기도 하고, 코드 예시를 본 뒤 구현 방식을 바꾸기도 한다.

핵심은 에이전트가 더 이상 합의한 내용을 잊지 않는다는 점이다. 요구사항과 설계, 작업 목록이 모두 명시적으로 문서화되고 버전 관리되며 언제든 확인할 수 있기 때문이다. 새로운 기능을 추가하거나 버그를 수정할 때도 변경 내용을 정확히 담은 새로운 명세부터 작성한다.

속성 기반 테스트의 역할

명세가 명확해지면 이를 불변 조건(invariant)으로 정의하고, 속성 기반 테스트(property-based testing)에 활용해 에이전트가 명세를 벗어나지 않도록 검증할 수 있다.

기존처럼 ‘특정 입력에는 특정 출력이 나와야 한다’는 개별 테스트를 작성하는 대신, 다양한 입력값과 실행 순서에서도 반드시 유지돼야 하는 속성을 정의하는 방식이다.

명세에서 도출한 강력한 테스트가 없으면 에이전트는 코드를 수정하는 대신 테스트를 통과하도록 테스트 자체를 우회하는 경우가 있다. 예를 들어 검증(assertion)을 주석 처리하거나 조건을 느슨하게 만들어 빌드만 성공시키는 식이다.

속성 기반 테스트는 이러한 문제를 막는 데 효과적이다. 기대하는 동작을 한 번 정의해 두면 사람과 에이전트 모두 지속적으로 그 요구사항을 충족하는지 검증할 수 있기 때문이다.

이 접근 방식은 보안 측면에서도 의미가 크다. 보안팀이 데이터 처리 방식이나 권한 관리, 오류 처리에 대한 요구사항을 에이전트가 사용하는 동일한 명세 언어로 불변 조건 형태로 정의하면, 속성 기반 테스트를 통해 다양한 시나리오에서 이를 반복적으로 검증할 수 있다. 이는 모든 개발자가 촉박한 일정 속에서도 모든 보안 규칙을 빠짐없이 기억하기를 기대하는 것보다 훨씬 효과적으로 보안을 개발 초기 단계부터 내재화하는 방법이다.

데브옵스 에이전트와 앞으로 10년의 개발 방식

지난 20년 동안 얻은 가장 큰 교훈은 장애 대응의 핵심이 단순히 근본 원인(root cause)을 찾는 데 있지 않다는 점이다. 무엇이 변경됐는지, 호출하는 시스템에는 어떤 변화가 있었는지, 어떤 한계에 도달했는지, 어떤 구성 요소가 의도대로 실패했는지, 그리고 어떤 의존성이 영향을 미쳤는지를 체계적으로 확인하는 것이 더 중요하다.

이제 데브옵스 에이전트는 통합개발환경(IDE)만큼 중요한 도구가 되고 있다. 데브옵스 에이전트는 개발팀이 이미 사용하는 도구와 연동돼 경보가 발생하면 이러한 조사 과정을 자동으로 수행한다. 로그와 메트릭, 분산 추적(trace), 코드까지 분석하며, 개발자가 노트북을 열기도 전에 진단 결과와 대응 계획을 제시하는 경우도 적지 않다.

실제로 과거에는 사람이 8시간 동안 분석해야 했던 장애를 에이전트가 15분 만에 해결한 사례도 경험했다. 에이전트는 버그의 원인을 설명하고 근거를 제시하는 것은 물론, 롤백과 후속 수정 방안까지 추천했다.

장애가 없는 기간에도 동일한 시스템은 과거 장애 사례와 인프라를 분석해 예방 작업을 제안한다. 코드 안정성 강화와 재시도(retry) 로직 개선, 경보 설정 최적화 등이 대표적이다. 대부분의 개발팀은 이런 작업에 우선순위를 부여할 여유가 없다. 그러나 이것이야말로 가장 중요한 부분이다. 다운타임을 줄이는 것도 중요하지만, 애초에 장애가 발생하지 않도록 만드는 것이 더 큰 목표이기 때문이다.

앞으로는 개발자가 운영자와 제품 관리자, 고객 지원 담당자 등 다양한 역할을 수행하게 될 것으로 본다. 반면 에이전트는 반복적이고 일상적인 업무를 맡게 될 것이다. 결국 개발자의 가장 중요한 역할은 문제를 해결하고, 시스템이 올바르게 설계돼 본래 목적에 맞게 동작하도록 만드는 일이 될 것이다.

물론 변하지 않는 원칙도 있다. ‘만든 사람이 운영한다(If you build it, you run it)’는 철학은 에이전트가 코드의 일부 또는 전부를 작성했더라도 그대로 유지된다. 개발자는 여전히 운영 환경을 책임지고, 장애 회고(post-incident retrospective)를 통해 재발 방지 방안을 마련해야 한다.

데이터 수집과 영향 분석, 근본 원인 분석 같은 작업은 에이전트 덕분에 훨씬 빨라질 수 있다. 하지만 조사 방향을 결정하고 근본적인 해결책을 선택하며, 그 경험과 교훈을 조직 전체와 공유하는 역할은 여전히 개발자의 몫이다.

20년 전 가장 큰 변화는 인프라를 서비스로 전환한 것이었다. 덕분에 개발자는 서버를 직접 설치하거나 데이터베이스를 일일이 관리하는 데 시간을 쏟지 않아도 됐다.

이제 새로운 시대에는 모범 사례와 운영 경험, 보안 요구사항을 명세(spec)와 AI 에이전트로 구현해 어떤 규모의 환경에서도 일관되게 실행하는 방향으로 변화가 진행되고 있다.

지난 20년의 교훈은 지금도 유효하다. 오늘 감수하는 불편은 내일 누군가가 플랫폼으로 해결하게 된다. 다만 이제는 AI 에이전트 덕분에 그 간극을 훨씬 더 빠르게 메울 수 있게 됐다.
dl-ciokorea@foundryco.com