[AI] 완전 자율 소프트웨어 구축 시스템 개발 경험과 과정에 대한 글

 

open AI 에서 공개한 글에 대해 요약하고 제 생각을 추가한 글입니다.

 

지난 5개월 동안 수동으로 작성한 코드가 단 한 줄도 없이 소프트웨어 제품의 내부 베타 버전을 개발하고 배포했습니다.

이 제품은 어플리케이션 로직,테스트,CI 구성, 문서화, 관찰 가능성 및 내부 도구 등 모든 코드를 Codex 가 작성을 했습니다.

사람이 코딩하는 것 보다 10배 빠른 효과를 낸 것으로 추정합니다.

 

에이전트에 맞춘 환경 구축

에이전트가 유용한 작업을 수행할 수 있도록 큰 목표를 설계, 코딩, 검토, 테스트 등으로 분해하고

각 구성요소를 구축하도록 유도한 다음에 이를 통해 더 큰 작업을 수행하게 했습니다.

 

에이전트가 실패 했을때 "더 열심히 해보세요" 가 아니라

"어떤 기능이 부족하고, 에이전트가 이를 명확하게 이해하고 실행할 수 있도록 하려면 어떻게 해야할까요? 라고 질문했습니다.

 

인력 기반의 QA 병목을 제거

고정된 제약 조건은 사람의 시간과 집중력이었기에 UI, 로그, 앱 메트릭 등 Codex 가 가능한 모든 정보를 읽을 수 있게 했습니다.

 

Chrome 개발자 도구 프로토콜을 에이전트 런타임에 통합하고 DOM 스냅샷, 스크린샷 및 탐색 작업을 위한 스킬을 개발했고

이를 통해 Codex는 버그를 재현, 수정 사항 검증, UI 동작에 대해 직접 분석 가능하게 되었습니다.

 

작업이 완료되면 제거되는 격리된 버전에서 로그, 메트릭, 트레이스를 수집하고,

LogQL를 통해 로그를 쿼리, PromQL을 이용해 메트릭을 쿼리하여 "서비스 시작이 800ms 이내에 완료되도록 보장", "핵심 사용자 여정에서 어떤 구간도 2초를 초과하지 않도록 보장" 과 같은 요구 사항을 효과적으로 처리했습니다.

 

 

저장소의 지식을 기록 시스템으로 구축

초기에 배운 교훈: Codex 에게 1000페이지짜리 설명서가 아닌 지도를 제공해야합니다.

 

하나의 큰 AGENTS.md 실패했습니다.

1. 많은 컨텍스트를 소비하고 에이전트가 핵심 제약 조건을 놓치거나 잘못된 제약 조건에 최적화 하게 됩니다.
2. 모든 것이 중요하다고 하면 결국 아무것도 중요하지 않은게 됩니다. 의도적인 탐색 대신에 국소적인 패턴 매칭에 매몰되게 됩니다.
3. 거대한 메뉴얼은 금방 낡게되고 무엇이 유효한지 알 수 없게 됩니다.
4. 단일 데이터 덩어리는 기계적인 검사에 적합하지 않습니다.

AGENTS.md 는 백과사전이 아닌 목차(index) 처럼 취급하세요.

100줄 정도의 짧은 설명이 맥락에 삽입되게 하여 지도 역할을 하고, 더 심층적인 정보 소스를 가리키는 포인터 역할을 해야합니다.

AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/
│   ├── index.md
│   ├── core-beliefs.md
│   └── ...
├── exec-plans/
│   ├── active/
│   ├── completed/
│   └── tech-debt-tracker.md
├── generated/
│   └── db-schema.md
├── product-specs/
│   ├── index.md
│   ├── new-user-onboarding.md
│   └── ...
├── references/
│   ├── design-system-reference-llms.txt
│   ├── nixpacks-llms.txt
│   ├── uv-llms.txt
│   └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md

 

설계 문서 (DESIGN): 검증 상태 및 에이전트 우선 운영 원칙을 정의하는 핵심 신념 세트를 포함한 색인

아키텍처 문서 (ARCHITECTURE): 최상위 도메인 및 패키지 계층 구조 맵

품질 문서 (QUALITY_SCORE): 제품 도메인 및 아키텍처 계층을 등급화하고 시간 경과에 따른 격차를 추적

계획 (PLAN): 최우선 산출물로 취급. 간단 변경 사항에는 일시적 계획을 사용

실행 계획(ExecPlan): 몇 시간씩 걸리는 복잡한 문제를 해결

[AI] PLAN.md 몇 시간이 걸리는 복잡한 계획을 수행하는 프롬프트 (번역)

 

[기록 시스템 검증과 정리]

• 전용 린터와 CI 작업이 지식 기반이 최신 상태이고, 상호 연결되어 있으며, 올바르게 구성되어 있는지 검증함.
• 정기적으로 실행되는 "문서 정리" 에이전트가 실제 코드 동작을 반영하지 않는 오래되거나 더 이상 사용되지 않는 문서를 찾아 수정 풀 리퀘스트를 생성

 

 

목표는 에이전트의 가독성

에이전트가 모든 일을 수행하므로 에이전트 가독성을 최우선으로 고려하여 최적화함.

에이전트가 저장소 전체 비즈니스 도메인에 대해 직접 추론 가능하게 함.

실행 중에 컨텍스트 내에서 접근할 수 없는 것은 존재하지 않는 것과 마찬가지입니다.

외부문서, 채팅 스레드, 사람의 머릿속 지식은 시스템에서 접근 불가함.

 

새로운 팀원에게 제품 원칙, 엔지니어링 규범, 팀 문화를 교육하는 것처럼,

에이전트에게 이러한 정보를 제공하면 더욱 일관성 있는 결과를 얻을 수 있습니다.

어떤 경우에는 공개 라이브러리의 기능 일부를 에이전트가 재구현하는 것이 더 저렴했습니다.

 

에이전트를 위한 엄격한 제약 조건 설정

저희는 구현을 세세하게 관리하지 않고, 불변 조건을 강제하여 기반을 훼손하지 않고 더 빠르게 배포가 가능했습니다.

에이전트는 엄격한 경계와 예측 가능한 구조를 가진 환경에서 가장 효과적입니다.

엄격한 아키텍처 모델을 기반으로 어플리케이션 구축하고 각 비즈니스 도메인은 고정된 계층으로 나누고, 종속성 방향은 엄격하게 검증되고 허용되는 연결은 제한됩니다. 이러한 제약 조건은 린터와 구조적 테스트를 통해 자동으로 적용됩니다.

 

이러한 구조는 보통 큰 조직 구조에서 적합한데 에이전트를 사용하는 경우에는 초기 단계부터 필수 조건입니다.

이러한 제약 조건 덕분에 아키텍처의 퇴보나 변질 없이 속도 유지가 가능합니다.

구조화된 로깅, 스키마 및 유형에 대한 명명 규칙, 파일 크기 제한, 플랫폼별 안정성 요구 사항 등을 사용자 지정 린터를 통해 적용.

린터가 사용자 지정 방식이기 때문에 오류 메시지를 작성하여 에이전트 컨텍스트에 수정 지침을 삽입합니다.

 

또한 제약 조건이 중요한 부분과 아닌 부분을 명확히 구분합니다.

중앙에서 경계를 설정하고, 각 팀(담당자)에게 자율성을 부여하는 것입니다.

경계, 정확성, 재현성을 매우 중요하게 생각하면서도, 이러한 경계 내에서 팀(담당자)가 표현하는 방식에는 자유를 허용합니다.

생성된 코드가 항상 사람의 스타일 선호도와 일치하지 않아도, 출력 결과가 정확하고 유지 관리가 용이하고 향후 에이전트 실행 시 읽기가 쉬우면 조건 충족

 

병합을 차단하는 요소 최소화

Codex 처리량이 증가함에 따라 기존의 엔지니어링 관행은 비효율적이 되었습니다.

PR은 수명이 짧고, 테스트 오류는 진행을 무기한으로 막는 대신 후속 실행을 통해 해결됩니다.

에이전트의 처리량이 사람의 처리량을 압도하는 시스템에서는 수정 비용이 저렴하고 대기 시간이 매우 깁니다.

 

완전한 에이전트 자율성의 새로운 문제점

저장소에 이미 존재하는 패턴, 불균형하거나 최적화되지 않은 패턴까지 복제하는 문제가 발생했습니다.

초기에는 사람이 직접 해결하려고 시도했으나 확장성 떨어졌습니다.

그래서 "황금 원칙" 이라고 불리는 것들을 저장소에 직접 인코딩하고 정기 프로세스를 구축했습니다.

1. 불변 조건을 중앙 집중화 하기 위해 직접 작성한 헬퍼보다는 공유 유틸리티 패키지를 선호
2. 데이터를 YOLO 스타일로 탐색하지 않고 경계를 검증하거나 타입이 지정된 SDK를 사용하여 에이전트가 추측된 형태를 기반으로 실수로 구축하지 않게 합니다.
3. 정기적으로 백그라운드에서 실행되는 Codex 작업들을 통해 편차를 검사, 품질 등급을 업데이트, 특정 리팩토링 PR 생성.
   기술 부채를 한 번에 몰아서 갚는것 보다 지속적으로 나눠서 갚는게 효율적인것 처럼 이것도 마찬가지임. (like 가비지컬렉션)

 

마무리

 

에이전트 기반 시스템에서 아키텍처의 일관성이 시간이 지남에 따라 어떻게 진화하는지 아직 알 수 없습니다.

시간이 지남에 따라 모델의 능력이 향상되면서 이 시스템이 어떻게 진화하는지 알 수 없습니다.

 

코드베이스의 일관성을 유지하는 데 필요한 도구, 추상화, 피드백 루프가 점점 중요해지고 있습니다.

에이전트가 안정적인 소프트웨어를 대규모로 구축하고 유지 관리하는 데 도움이 되는 환경, 피드백 루프, 제어 시스템을 설계하는 것이 가장 중요하며 가장 어려운 과제입니다.

---

후기

자율주행 자동차 처럼 에이전트가 운행하는 완전 자율 SW 개발 솔루션이 실제로 세상에 작동하고 있고

멀지 않은 미래에 이렇게 개발 하는것이 표준이 될 것입니다.

 

개발자 역할의 변화

구 시대의 개발자의 역할이 기획서 검토하여 요구사항을 코드로 옮기고 테스트 후 배포하는 것이었다면

앞으로는 완전 자율 SW 개발 솔루션에 요구사항을 전달하고, 결과물을 검토하고, 유지보수하는 역할이 되었다는 겁니다.

개발자 = "도메인, 사업 특성에 맞게 에이전트가 작업할 환경을 설계, 유지보수 하는 역할"

 

서비스는 빨리 만들어도 여전히 사람은 느리다.

근데 미래에는 저비용으로 초고속 서비스 개발이 가능하게 되는건데, 문제는 그 서비스를 사람이 쓰고 있다는 것인데요.

지금도 미친듯이 쏟아져 나오는 서비스들이 감당이 안되는데 앞으로는 어떻게 될지 참 궁금합니다.

사람들은 나이가 들 수록 변화를 싫어하는데 세상이 더 빠르게 변하는걸 감당할 수 있을지 모르겠습니다. 

 

저희가 노인이 되었을때 온라인 상의 모든 것이 AI로 자동화가 되어있고, 오프라인의 모든 것이 로봇으로 대체되었을 것인데요...

"노동" 과 "소유" 라는 개념 자체가 사라지는 세상.. 모두 통속의 뇌 또는 메트릭스 안에서 살아가게 되겠죠.

컴퓨터가 처음 발명되었을때 사람들은 무슨 기분이었을까요? 이렇게 까지 될 거라고 생각했을까요?

 

나의 이야기

저는 요즘 회사에서 지식 저장소를 구축하는 것 부터 시작하고 있는데요.

물론 저희는 아직 완전 수동 에이전트 구동 환경이라서.. Open AI 처럼 만들지는 못하겠지만요. 그래도 따라겠다는 생각이 들어요.

한국은 느리고 보수적이기 때문에 아마 이렇게 되기 까지 5년, 10년은 더 걸릴지도 모릅니다...

 

처음부터 이렇게 구축하는건 불가능하고, 변화하는건 어렵다고 판단하고 있고

현재 머릿속에 이런 식으로 구상하고 있습니다.

1. 지식 저장소 구축을 먼저 진행 (현재 진행중 🔄)

2. 새로운 기획서를 넣었을때 Agent 가 전체 작업을 수행 (엄격한 제약, 규칙 설정 등을 재검토)

3. 수행된 결과물을 테스트/검토 하는 환경을 구축 (여기가 진짜 어려울 거 같습니다.)

4. 테스트/검토 통과되면 자동 PR 생성 (당장은 3번 과정을 사람이 PR 리뷰를 통해서 해도 될듯함. 간단한 작업은 고치는 것 보다 PR 올리고 굳이 리뷰받고 배포하는게 더 많은 리소스가 들기 때문에 당장 효과를 볼 수 있을것임)

5. 지식저장소 최신화/정리 Agent 생성 후 구동

아마 이러한 상용 서비스 나오기 전 까지 가장 크게 뜰 직업이 이 전체 과정을 구축하는 전문가가 아닐까요?

 

Harness engineering: leveraging Codex in an agent-first world