에이전틱 엔지니어링 워크플로우
2025 년 2월, Andrej Karpathy는 자연어로 의도를 설명하고, LLM 의 변경 사항을 최소한의 검토로 수용하며, 코드가 일반적인 이해 범위를 넘어서도록 하는 관행을 "바이브 코딩"이라고 설명했습니다. 이는 개인 프로젝트와 프로토타입에서 인상적인 속도를 제공했습니다.
1 년 후, 그는 에이전트 기능이 발전했다고 관찰하며, 에이전트를 오케스트레이션하면서도 아키텍처와 프로세스에 대한 강력한 인간의 감독을 유지하는 발전된 관행을 위해 "에이전틱 엔지니어링"이라는 이름을 제안했습니다. 그가 정의한 목표는 소프트웨어 품질을 손상시키지 않으면서 에이전트의 활용도를 확보하는 것입니다.
이 구분은 중요합니다. 바이브 코딩은 단일 사용자가 위험이 낮은 개인 작업을 수행할 때는 잘 작동하지만, 다른 사람이 결과에 의존하게 되는 순간 빠르게 숨겨진 부채, 보안 허점, 유지보수 문제를 축적합니다. 에이전틱 엔지니어링은 최신 에이전트의 속도와 활용도를 유지하면서도 모든 것을 명확한 구조, 추적 가능한 산출물, 인간의 책임에 기반합니다.
에이전틱 엔지니어링 워크플로우
대략적인 의도로 시작하여 AI 와 설계 대화를 진행하면서 기능을 구성 요소로 분해하는 설계 회의 노트에 문서화합니다. 설계가 견고해지면, 설계 계층 구조(사람들이 Obsidian "브레인"을 보여줄 때 표시하는 것)에 높은 수준의 뷰와 구성 요소 맵을 캡처합니다. 이는 사용자와 에이전트 모두가 주변 컨텍스트, 관련 의사 결정, 종속성에 쉽게 접근할 수 있는 탐색 가능한 구조입니다. 또한 UML(범용 모델 언어), 코드 또는 사용자 상호 작용 흐름과 같은 설계 다이어그램과 함께 구성 요소 간의 관계를 명확히 하는 ADR(아키텍처 결정 기록)에 대한 링크가 여기에 포함됩니다.
각 모듈 또는 가장 작은 기능 블록에 대해 LLD 내에 정확한 동작, 함수 시그니처, 엣지 케이스, 테스트 기대치, 통합 지점을 정의하는 집중된 spec.md 를 생성합니다. 전체 구조를 설계 컨텍스트 프롬프트로 사용하여 AI 가 위키 페이지와 사양에 직접 추적 가능한 티켓 스타일 계층 구조를 구축하도록 합니다. 에이전트가 관련 spec.md 를 계약으로 삼아 티켓별로 구현합니다. 그런 다음 검증 게이트를 실행하고, 배포하고, 관찰하며, 요구 사항이 발전함에 따라 살아 있는 산출물을 업데이트합니다.
실제 예시: 일일 백업 검증기
S3 백업을 매일 확인하고 실패 시 Slack 알림을 보내는 소규모 프로덕션 등급 CLI 도구를 생각해 보십시오.
"매일 백업이 정상인지 확인하는 안정적인 무언가가 필요해"라는 대략적인 목표로 시작합니다. 그런 다음 AI 와 아키텍처 대화를 진행하여 요구 사항과 엣지 케이스를 표면화합니다.
- 실제로 S3 백업의 현실적인 실패 모드는 무엇인가?
- 정확히 무엇을 확인해야 하는가(기간, 파일 수, 크기, 성공률)? 어떤 임계값이 적절한가?
- 로컬 개발과 프로덕션 IAM 역할 간에 구성 및 시크릿을 어떻게 처리해야 하는가?
- 일상적으로 어떤 CLI 명령과 출력 형식이 유용한가?
- 예약된 일일 도구에 가장 중요한 비기능적 요구 사항은 무엇인가?
이러한 대화는 범위를 명확히 하고 도구를 핵심 구성 요소(재시도 로직이 포함된 S3 메타데이터 가져오기, 검증 규칙 엔진, 알림 시스템, 구성 로더, CLI 인터페이스, 구조화된 로깅, 오류 처리)로 분해하는 데 도움이 됩니다.
설계가 명확해지면, 모든 페이지가 버전 관리되고 링크 가능한 설계 계층 구조 위키에 높은 수준의 뷰와 구성 요소 맵을 문서화합니다.
위키는 미래의 독자에게 평면 문서가 제공할 수 없는 주변 컨텍스트를 제공합니다. 동일한 설계 작업의 일환으로 각 모듈에 대한 하위 LLD 수준의 집중된 spec.md 를 생성합니다. 다음은 S3 메타데이터 가져오기에 대한 계약입니다.
이 spec.md 는 에이전트에 전달하는 계약입니다. 예: "s3_client/ 디렉토리에서 spec.md 에 따라 정확히 구현하고, 프로젝트 표준을 따르며, 포괄적인 테스트를 포함하십시오." 위키와 모듈 사양이 준비되면, AI 가 직접 이들로부터 티켓 계층 구조를 생성하도록 프롬프트합니다. 모든 항목은 기능 요구 사항과 해당 계약을 정의하는 사양으로 추적됩니다.
그런 다음 구현은 티켓별로 진행되며, 각 티켓은 일치하는 spec.md 를 계약으로 하여 에이전트에 전달됩니다. 실제로 이것이 생성하는 결과는 다음과 같습니다. 짧은 백업 세트를 포착하고 경보를 발동하는 예약 실행입니다.
실행이 0이 아닌 코드로 종료되어 cron 작업이 이를 감지하고 Slack 에 도착하는 경보를 발동합니다.
경보에는 당직 엔지니어가 조치를 취하는 데 필요한 규칙 컨텍스트(어떤 검사가 실패했는지, 무엇이 발견되었는지, 무엇이 예상되었는지, 어떤 백업 세트인지)가 포함되어 있습니다.
이 계층적 접근 방식의 이점
- 에이전트는 구현 볼륨을 처리하고, 인간은 모든 계층에서 아키텍처와 품질을 책임집니다.
- 위키는 프로젝트 수준의 발견 가능성과 의사 결정을 제공하고, spec.md 파일은 높은 수준의 설계를 비대하게 만들지 않으면서 정확한 모듈 수준 계약을 제공합니다.
- 요구 사항과 의사 결정은 위키 페이지와 사양에서 티켓과 코드로 직접 흘러갑니다.
- 변경 사항은 코드베이스를 리버스 엔지니어링하는 대신 살아 있는 설계 산출물에서 시작됩니다.
- 명확한 관심사 분리는 병렬 작업, 온보딩, 감사를 지원합니다.
- T 자형 전문가는 폭넓게 탐색하고 정밀하게 질문하며, 에이전트는 누구도 전체 시스템을 머릿속에 담도록 강요하지 않고 필요 시 깊이를 제공합니다.
바이브 코딩은 탐색과 빠른 개인 프로토타이핑을 위한 훌륭한 모드로 남아 있습니다. 에이전틱 엔지니어링은 동일한 대화형 힘을 다른 사람들이 신뢰하고 유지 관리할 수 있는 시스템으로 전환하는 방법입니다.
T 자형 전문가의 역할
이 워크플로우는 특히 T 자형 전문가에게 강력합니다. 즉, 애플리케이션 공간 전반에 걸쳐 광범위한 지식을 유지하면서 필요할 때 깊이 파고들 수 있는 능력을 가진 엔지니어입니다.
언제든지 전체 애플리케이션이 어떻게 작동하는지에 대한 완전하고 최신의 정신적 모델을 유지할 필요가 없기 때문입니다. 에이전트가 그 깊이를 유지하고 위키, spec.md 파일, 대화 기록에서 올바른 컨텍스트를 가지고 있는 한 요청 시 어떤 부분이든 다시 설명할 수 있습니다.
필요한 것은 무엇을 찾아야 하고 어디를 봐야 하는지 알 수 있는 능력과, 작업 중인 특정 항목을 이해할 때까지 정확한 질문을 계속하는 훈련입니다. T 의 넓은 부분은 시스템의 지도를 제공하고, AI 에이전트는 지금 중요한 정확한 모듈, 엣지 케이스, 통합 지점을 파고드는 데 필요한 기술을 지원합니다. 에이전트는 요청할 때마다 철저한 세부 정보를 제공합니다.
이것은 인간의 역할을 "나는 항상 모든 것을 이해해야 한다"에서 "나는 적절한 고도에서 탐색하고, 질문하고, 검증하는 방법을 안다"로 전환합니다. 이것이 바로 에이전틱 엔지니어링의 진정한 기술입니다.
