AI 기반 엔지니어링 스토리
Source: Dev.to
배경
2020년, 팬데믹 봉쇄 기간에 나는 해커톤에서 작동하는 Kubernetes CSI 드라이버 프로토타입을 만들었다. 충분히 괜찮아서 우승했지만, 이를 프로덕션 수준의 통합으로 바꾸는 데는 몇 달이 걸렸고 결국 추가 엔지니어 3명으로 구성된 팀이 필요했다.
5년이 흐른 지금, 나는 2주 만에 프로덕션 Kubernetes Operator(더 복잡한 프로젝트)를 만들었다. 혼자. 팀 배정도 없고, 공식 프로젝트 승인도 없었다. 단지 우연히 개발한 워크플로우와 나뿐이었다.
바뀐 유일한 점은 AI와 작업하는 방식이었다.
AI 기반 워크플로우
Step 1 — Spec‑driven architecture
코드를 쓰는 것부터 시작하지 않았다. 고차원 추론 모델(ChatGPT, DeepSeek)을 활용해 설계를 고민했다—트레이드‑오프를 논의하고, 가정을 뒤집어보며, 아키텍처 결정과 코드 스캐폴딩이 포함된 구조화된 Markdown 스펙을 생성했다. 모델은 나의 기술 공동 창업자 역할을 했다.
Step 2 — Grounding the model
LLM은 빠르게 변하는 API에 대해 환상을 만들기 쉽다. 구현 코드를 작성하기 전에 나는 Kubernetes controller‑runtime 스펙, CRD 패턴, Delphix API 정의 등 관련 문서를 조사해 모델 컨텍스트에 직접 주입했다. 모델은 이제 정확하고 최신의 소스를 기반으로 작업했다. 나는 “RAG”라는 용어가 일반화되기 전에 수동으로 RAG를 수행하고 있었던 셈이다.
Step 3 — Agentic execution
스펙을 기반으로 GitHub Copilot을 이용해 구현을 진행했다—특정 함수에 대해 반복하고, 타깃 프롬프트로 코드 조각을 공유하며, 출력물을 검토·수정했다. 이후 Claude Code가 등장하면서 마지막 단계가 더욱 가속화되었다.
영향
결과는 단순히 빠른 개발이 아니었다. 구조적인 시장 진입 교착 상태를 깨뜨렸다:
- 작동하는 솔루션이 없으면 고객은 계약을 하지 않는다.
- 고객 수요가 없으면 엔지니어링은 이를 우선순위에 두지 않는다.
혼자서 2주 만에 작동하는 MVP를 출시함으로써 실제 제품에 대한 수요를 창출했고, 이탈 위험을 3천만 달러 규모의 기업 계약으로 전환했다.
2020년 해커톤은 실패가 아니었다. CSI 드라이버는 Operator가 구축된 기술 기반이 되었다. 대비되는 점은 다음과 같다:
- 같은 엔지니어, 같은 문제 영역.
- 팀과 몇 개월 — 대비해 혼자서 2주.
변화한 것은 엔지니어가 아니라 워크플로우였다.
시사점
필요에 의해 우연히 발견한 실천법—spec‑driven 개발, 컨텍스트 그라운딩, 에이전시 코딩 루프—는 이제 기업들이 규모 있게 배우고 적용하려는 핵심이 되었다.
“우리는 AI를 실험하고 있다”와 “우리는 AI와 함께 제품을 출시하고 있다” 사이의 격차는 대부분 워크플로우 문제다. 모델 자체가 아니라 그 모델과 어떻게 협업하느냐가 핵심이다.
AI 도구가 대중화된 이후, 여러분 팀이 빌드 방식을 가장 크게 바꾼 점은 무엇인가요?