인프라 서비스를 구축하며 코드의 90% 이상을 AI로 생성한 경험을 바탕으로, 설계와 반복 방식, 실패 지점과 강점, 실전 팁과 배운 점을 공유한다.
2025년 9월 29일 작성
“I think we will be there in three to six months, where AI is writing 90% of the code. And then, in 12 months, we may be in a world where AI is writing essentially all of the code”
세 달 전 나는 AI가 모든 것을 바꾼다고 말했다. 그 결론에 이르기까지 회의가 많았다. 여전히 AI가 모든 코드를 쓰게 될지 의심할 만한 이유는 많지만, 내 현재 현실은 그에 꽤 가깝다.
내가 새 회사에서 시작한 인프라 컴포넌트의 경우, 아마도 코드의 90% 이상이 AI가 쓴 것이다. 당신을 설득하려는 건 아니다 — 그저 내가 배운 걸 공유하고 싶다. 부분적으로는, 이전의 AI 보조 코딩 실험과는 다르게 이번 프로젝트에 접근했기 때문이다.
이 서비스는 Go로 작성되었고 의존성은 적으며 OpenAPI 호환 REST API를 제공한다. 핵심은 이메일을 보내고 받는 일이다. 또한 커스텀 SDK 생성기로 Python과 TypeScript용 SDK도 만들었다. 총합은 약 4만 줄로, Go, YAML, Pulumi, 그리고 커스텀 SDK 글루 코드가 포함된다.
나는 특히 운영 신뢰성을 높이기 위해 기준을 높게 잡았다. 비슷한 시스템을 운영해 본 경험이 있고, 내가 원하는 바를 알고 있었다.
어떤 스타트업들은 이미 100%에 가까운 AI 생성 코드를 쓰고 있다. 많은 곳이 오픈 빌드를 하기에 코드를 직접 볼 수 있어 알 수 있다. 그게 장기적으로 통할지는 두고 볼 일이다. 나는 여전히 모든 코드를 내가 쓴 것처럼 책임지고 판단한다. AI가 그 사실을 바꾸지는 않는다.
엉뚱한 파일이 끼어 있지 않고, 중복 구현도 없으며, 이모지가 여기저기 난무하지도 않는다. 주석은 내가 원하는 스타일을 따르고, 결정적으로, 종종 주석이 아예 없다. 시스템 아키텍처, 코드 레이아웃, 데이터베이스 상호작용 같은 기본에 특히 신경 쓴다. 나는 엄청나게 의견이 강한 편이다. 그 결과, AI에게 맡기지 않는 부분들이 있다. 커밋에 서명해도 된다고 확신할 수준에 AI가 도달하지는 못할 거란 걸 안다. 그래서 100%가 아니다.
대조적으로: 우리가 만든 또 다른 빠른 프로토타입은 불분명한 데이터베이스 테이블, 리포지터리에 어지럽게 쌓인 마크다운 파일, 원치 않는 이모지가 잔뜩 들어간 엉망이었다. 아이디어를 검증하는 목적은 달성했지만 오래 갈 생각으로 만든 게 아니었고, 그럴 기대도 없었다.
나는 전통적인 방식으로 시작했다: 시스템 설계, 스키마, 아키텍처. 이 단계에서는 AI에게 작성을 맡기지 않지만, AI를 러버덕(고무오리)처럼 대화 상대로 둔다. 왔다 갔다 하며 대화하는 과정만으로도, 답을 그대로 쓰거나 신뢰하지 않더라도, 실수를 발견하는 데 도움이 된다.
기초를 한 번은 잘못 잡기도 했다. 처음에는 내가 원하는 것보다 더 복잡한 설정이 타당하다고 스스로 설득했다. 그 부분은 나중에 LLM을 활용해 초기에 큰 덩어리를 갈아엎고 정리했다.
AI가 생성하거나 지원하는 코드는 이제 다음과 같은 스택으로 귀결된다. 예전부터 원했지만 손으로 하기엔 너무 어려웠던 것들이다:
AI가 대신 SQL을 써줘서 내가 더는 SQL을 직접 쓰지 않아도 된다는 사실은 판도를 바꿨다.
마이그레이션도 이제는 생(SQL)으로 한다.
지금은 Claude Code와 Codex를 쓴다. 각자 강점이 있지만, 변하지 않는 축은 PR 이후 코드 리뷰에 Codex를 쓰는 것이다. 그 부분에서는 아주 뛰어나다. 디버깅과 많은 도구 접근이 필요할 때(예: 왜 데드락이 생기는지, 왜 데이터베이스에 손상된 데이터가 있는지 등) Claude는 여전히 없어서는 안 된다. 둘이 함께 작동할 때가 가장 마법 같다. Claude가 데이터를 찾아주면, Codex가 그걸 더 잘 이해할 때가 있다.
주의하지 않으면 이 에이전트들이 내놓는 코드가 얼마나 형편없을 수 있는지 아무리 강조해도 지나치지 않다. 이들은 시스템 아키텍처와 빌드 법을 이해하긴 하지만 전체 그림을 스코프에 계속 유지하지 못한다. 이미 있는 걸 다시 만들고, 문제 규모에 전혀 맞지 않는 추상을 만든다.
컨텍스트에 올바른 정보를 어떻게 공급할지 끊임없이 배우는 게 필요하다. 내 경우, 기존 구현을 가리키고 그대로 따라 하도록 아주 구체적인 지시를 내리는 편이다.
나는 보통 내가 리뷰할 수 있는 PR 크기의 청크로 작업을 나눈다. 방법은 둘이다:
에이전트 루프 + 마무리 손질: 결과가 근접할 때까지 프롬프트하고, 그다음 깔끔하게 정리한다.
락스텝 루프: 예전엔 편집 단위로 한 걸음씩 갔다. 지금은 대부분 첫 방법을 쓰되, 머지 전에 정리할 항목을 TODO 리스트로 관리한다.
각 방법이 언제 더 올바른 결과로 이어질지 판단하는 직관이 필요하다. 에이전트에 익숙해질수록 어떤 작업이 도저히 진전이 없을지 빨리 알아차려, 쓸데없는 사이클 낭비를 피할 수 있다.
에이전트와 일하는 데 가장 중요한 요소는 일반적인 소프트웨어 엔지니어링과 같다. 상태 머신, 어느 시점에 시스템이 어떻게 동작하는지, 데이터베이스를 이해해야 한다.
에이전트에 의존하면 겉보기에는 올바르게 동작하는 것처럼 보이지만 런타임 동작이 불분명한 시스템을 만들기 쉽다. 예를 들어, AI는 스레딩이나 고루틴을 완전히 이해하지 못한다. 초기에 나쁜 결정을 막아 두지 않으면, 나중에 안정적으로 운영할 수 없다.
예시: 레이트 리미터를 만들어 달라고 했다. “동작”은 했지만 지터가 없었고 저장소 선택도 엉망이었다. 레이트 리미터를 알면 쉽게 고칠 수 있지만, 모르면 위험하다.
에이전트는 인터넷의 통념에 기대어 작업하고, 그 결과로 내가 절대 하지 않을 일들을 하기도 한다. 의존성을 쓰길 좋아한다(특히 구식 것들). 오류를 삼키고 트레이스백을 몽땅 없애는 걸 좋아한다. 나는 문제를 숨기기보다는 강한 불변식을 지키고, 깨지면 크게 터지게 두는 편이다. 이걸 방치하면 불투명하고 관측 불가능한 시스템을 얻게 된다.
내게는 이제 다른 방식으로 일하는 게 상상이 되지 않는다. 그렇다, 아마 AI 없이도 할 수 있었을 것이다. 하지만 그랬다면 부분적으로는 다른 시스템을 만들었을 텐데, 다른 트레이드오프를 했을 것이기 때문이다. 이 방식은 내가 보통은 건너뛰거나 미뤘을 경로를 열어 준다.
이번 프로젝트에서 특히 즐거웠던 것들:
리서치 + 코드(나중에 코드가 아니라): 예전 같으면 하루나 이틀 걸려 익혔을 것을 지금은 10~15분이면 된다.
덕분에 어떤 문제에 대해 한두 가지 구현을 바로 손에 잡고 시험해 볼 수 있다. 추상적인 숙고에서 손으로 만지는 평가로 나를 옮겨 준다.
시도해 보기: 하루 만에 서로 다른 OpenAPI 구현과 접근을 세 가지나 시험했다.
지속적인 리팩터링: 리팩터링 비용이 꽤 낮아서, 그렇지 않았을 때보다 코드가 더 정돈되어 보인다. 무엇을 하는지 알고 있어야 하지만, 잘 세팅하면 리팩터링이 쉬워진다.
인프라: Claude 덕분에 AWS와 Pulumi를 무난히 넘겼다. 원래라면 대체로 싫어하는 일이 며칠 만에 끝났다(보통은 몇 주 걸린다). 진행하면서 설정 문제도 같이 디버깅해 줬다. 나는 문서를 거의 읽지 않아도 됐다.
새 패턴 채택: 테스트 코드를 쓰는 건 형편없지만, 내가 필요하다는 걸 몰랐던 테스트 인프라를 세팅하는 데는 아주 뛰어났다. 트위터에서 testcontainers로 Postgres에 대해 테스트하라는 추천을 받았다. 이 방식은 마이그레이션을 한 번 돌린 뒤 테스트마다 데이터베이스 클론을 만든다. 엄청 유용하더라. 직접 옮기려면 꽤 공사가 컸을 텐데, Claude가 한 시간 만에 모든 테스트에 적용했다.
SQL 품질: 내가 절대 외워서 못 쓰는, 탄탄한 SQL을 작성한다. 나는 리뷰만 하면 된다. 솔직히 지금도 MERGE와 WITH를 손으로 쓸 때마다 헷갈린다.
코드의 90%를 AI가 쓰게 될까? 모르겠다. 하지만 내 경우, 이번 프로젝트에서는 이미 그렇다. 나는 이렇게 실제 시스템을 만드는 개발자 집합이 점점 커지는 그 일부다.
동시에, 내게 AI가 코드의 주인은 아니다. 나는 여전히 모든 줄을 리뷰하고, 아키텍처를 빚고, 운영 환경에서의 책임을 진다. 하지만 에이전트에게 생성하도록 맡기는 양 자체가 불과 6개월 전만 해도 상상도 못 했을 정도다.
그래서 나는 이것이 먼 미래의 예언이 아니라고 확신한다. 이미 여기 와 있다 — 다만 고르게 퍼지지 않았을 뿐 — 그리고 이렇게 일하는 개발자는 계속 늘어날 것이다.
그렇다고 해서, 좋은 엔지니어가 될 필요가 없어지는 건 아니다. 판단 없이 AI에게 넘기면, 부서지기 쉬운 시스템과 고통스러운 놀람(데이터 손실, 보안 구멍, 확장 불가한 소프트웨어)을 맞이하게 된다. 도구는 강력하지만, 책임을 면제해 주지는 않는다.
