코드 100%를 AI가 짜는 회사의 운영법
연매출 200만 유로 헬스케어 SaaS가 공개한 '100% 에이전트 코딩' 운영 모델
유럽의 한 헬스케어 소프트웨어 기업이 프로덕션 코드의 거의 전부를 AI 에이전트에게 맡기는 개발 방식을 공개했다. 고객 약 3,500곳, 연매출 약 200만 유로(약 30억 원) 규모의 앱포인트메드(appointmed)는 사람이 코드를 한 줄씩 타이핑하는 대신, 에이전트가 구현을 맡고 사람은 방향과 책임을 쥐는 구조로 돌아간다. 창업자 베른하르트 케프르트(Bernhard Keprt)가 자신의 운영 기록을 통해 그 방법을 밝혔다.
무슨 일인가 / 배경
'100% 에이전트 코딩'이라는 말은 오해를 부르기 쉽다. 케프르트는 이 방식이 엔지니어링 판단을 대체하는 게 아니라고 못 박는다. 에이전트가 바꾸는 것은 '타이핑'이지 '책임'이 아니다. 무엇을 만들지, 아키텍처를 어떻게 잡을지, 어디까지 검토할지, 릴리스 리스크를 누가 질지는 여전히 사람의 몫이다. 에이전트는 그 안에서 '구현'이라는 일을 받아 처리한다. 운영 루프도 단순하다. 맥락을 다듬어 넘기고, 에이전트가 구현하고, 테스트로 검증하고, 의도에 맞는지 리뷰하고, 신중히 배포한 뒤, 그 배움을 다음 워크플로로 되돌린다.
핵심 짚어보기
글에서 가장 인상적인 대목은 실제 사례다. 이들은 로그인에 '계정 잠금' 기능을 붙였다. 실패가 일정 횟수 쌓이면 계정이 스스로 잠기는, 약 100줄짜리 작은 기능이었지만 보안에 직결됐다. 에이전트가 구현을 마쳤고 겉보기엔 완성돼 보였다. 그런데 풀 리퀘스트에 붙은 두 AI 리뷰어가 서로 다른 결함을 하나씩 잡아냈다.
첫째는 카운팅 버그였다. 실패 횟수를 '읽고' 나서 새 값을 '쓰는' 두 단계가 분리돼 있어, 같은 순간 도착한 두 시도가 모두 옛 숫자를 읽고 한도를 빠져나갈 수 있었다. 수정은 세는 동작을 쪼갤 수 없는 한 단계로 묶어 동시 시도가 그 틈으로 새지 못하게 했다. 둘째는 정반대 실패였다. 검사가 느려져 도중에 끊기면, 끊긴 보안 검사를 '무조건 거부'로 처리하도록 돼 있었다. 우리 쪽 지연 한 번이 멀쩡한 사용자를 잠가버리는 셈이다. 수정은 검사에 짧은 마감 시간을 걸고, 제때 답하지 못하면 오히려 통과시키는 '페일 오픈(fail open)' 방식으로 바꿨다. 같은 100줄이 한쪽으로는 침입을 허용하고, 다른 한쪽으로는 정당한 사용자를 막고 있었던 것이다. 케프르트는 요점이 속도가 아니라고 말한다. 에이전트는 '그럴듯하지만 미묘하게 틀린' 결과를 두 방향으로 동시에 내놨고, 그것을 안전하게 바꾼 것은 겹겹의 리뷰였다.
1인기업 실전 적용 포인트
- 에이전트에게 던지는 첫 인터페이스는 채팅창이 아니라 '티켓'이다. 바꿀 동작, 건드리지 말 것, 관련 파일, 실패 시 사용자 리스크, 완료 증거 5가지를 티켓에 미리 적어두면 결과 품질이 크게 갈린다.
- 리포지토리가 에이전트를 가르치게 하라. 명령어를 명확히, 모듈을 작게, 이름을 예측 가능하게, 테스트를 동작 가까이 두면 에이전트가 '하나의 정답 방식'을 따라간다. 방식이 다섯 개면 가장 최근·시끄러운 걸 고른다.
- 리뷰 질문을 바꿔라. '내가 이렇게 짰을까?'가 아니라 '이게 옳은 변경인가, 옳은 자리에, 증거와 함께, 숨은 비용 없이 들어갔나?'로 물어야 한다.
- 보안·결제처럼 민감한 코드는 AI 리뷰어를 2개 이상 붙여 교차 검증하라. 위 사례처럼 한 리뷰어가 놓친 결함을 다른 리뷰어가 잡는다.
전망 / 주의점
이 사례가 주는 교훈은 'AI가 코드를 짜준다'가 아니라, 에이전트를 둘러싼 시스템(티켓·테스트·리뷰·릴리스 규율)이 정밀할수록 에이전트가 진짜 일을 해낸다는 것이다. 반대로 그 시스템이 허술하면 에이전트 코딩은 장난감 데모거나 위험한 지름길이 된다. 1인기업이라면 리뷰어를 여럿 둘 여력이 없을 수 있지만, 최소한 '테스트로 증거를 남기는' 습관과 '작은 변경으로 쪼개는' 규율만은 그대로 가져갈 만하다. 사람의 역할은 타이핑에서 '감독'으로 옮겨간다.
출처: AgenticPrime (https://agenticprime.ai/issues/agentic-coding-healthcare-saas/)