코드 안 보고 소프트웨어를 만든다고요

"코드는 사람이 작성해서는 안 된다. 코드는 사람이 검토해서는 안 된다."

이게 무슨 컬트 선언문이 아니에요. StrongDM이라는 보안 회사의 AI 팀이 실제로 지키고 있는 규칙입니다. 보안 소프트웨어요. 가장 코드 리뷰가 빡세야 할 분야에서요. 근데 사람이 코드를 안 본대요.

저는 이 글을 읽고 솔직히 처음엔 "또 실리콘밸리 하이프인가?" 싶었어요. 근데 Simon Willison이 직접 방문해서 데모를 보고 쓴 글이더라고요. Simon Willison이면 AI 업계에서 가장 객관적인 리포터 중 한 명이에요. 그리고 이 팀이 3명이에요. 3명이서 이걸 한 거예요.

자동화된 소프트웨어 개발 환경

3명이 만든 "소프트웨어 공장"

StrongDM의 AI 팀은 2025년 7월에 3명으로 시작했어요. Justin McCarthy, Jay Taylor, Navan Chauhan. 이 팀이 세운 원칙이 하나 있어요.

"손으로 코드를 짜지 않는다."

팀 결성 첫날부터요. 2025년 7월이면 Claude Sonnet 3.5가 나온 지 얼마 안 된 시점인데, 그때부터 "사람이 코드를 안 짜는 시스템"을 만들겠다고 한 거예요. 솔직히 미친 거 아닙니까?

근데 이 팀이 이걸 가능하게 만든 방법이 흥미로워요. 핵심은 "코드를 안 보는 대신, 코드가 작동한다는 걸 증명하는 시스템을 만든다"는 거예요.

보통 개발자가 AI 코드를 믿는 방법이 뭐예요? 코드 리뷰하잖아요. 한 줄씩 읽어보고, "이거 맞나?" 확인하고. StrongDM 팀은 이걸 뒤집었어요. 코드를 읽는 대신, 코드가 올바르게 동작하는지를 자동으로 검증하는 시스템을 만든 거예요.

"테스트를 AI가 짜면 assert true 하면 되잖아"

이게 가장 먼저 드는 의문이에요. 코드도 AI가 짜고, 테스트도 AI가 짜면 — AI가 테스트를 대충 통과하게 만들면 어떡해요? assert true 하면 끝이잖아요.

Simon Willison도 이걸 "지금 소프트웨어 개발에서 가장 중요한 질문"이라고 했어요. 구현도 AI가 하고 테스트도 AI가 하면, 그 소프트웨어가 작동한다는 걸 어떻게 증명하냐.

StrongDM의 답은 시나리오 테스팅이에요. 2003년에 Cem Kaner가 제안한 개념인데, StrongDM이 이걸 AI 시대에 맞게 재해석했어요.

핵심이 뭐냐면요. 테스트를 코드 옆에 두지 않아요. 시나리오를 코드베이스 바깥에 보관해요. 머신러닝에서 "홀드아웃 셋"이라고 하잖아요. 학습에 쓰지 않은 데이터로 모델을 평가하는 거요. 같은 원리예요. 코딩 에이전트가 접근할 수 없는 곳에 시나리오를 보관하고, 그 시나리오로 코드를 검증하는 거예요.

그리고 또 하나 재밌는 게 있어요. StrongDM은 "테스트가 통과했나/실패했나"로 판단하지 않아요. 대신 "사용자를 만족시킬 확률"로 측정해요. 이걸 "satisfaction"이라고 부르는데요. 모든 시나리오의 모든 경로를 실행해보고, 그중에 사용자를 만족시키는 비율이 얼마나 되는지를 보는 거예요.

이건 전통적인 "green/red" 테스트랑 완전히 다른 접근이에요. boolean이 아니라 확률로 품질을 측정하는 거죠.

보안 소프트웨어 개발

디지털 트윈 유니버스 — 이건 진짜 미쳤어요

Simon Willison이 "가장 인상 깊었다"고 한 부분이 이거예요. Digital Twin Universe(DTU).

StrongDM이 만드는 소프트웨어는 사용자 권한 관리 시스템이에요. Okta, Jira, Slack, Google Docs 같은 서비스들과 연동돼야 하잖아요. 근데 테스트를 실제 Okta에 붙여서 하면 어떻게 돼요? API 호출 제한에 걸리고, 비용이 나가고, 남용 감지에 걸리고.

그래서 이 팀이 한 게 뭐냐면요. Okta, Jira, Slack, Google Docs, Google Drive, Google Sheets의 클론을 만들었어요. API까지 포함해서요. 각각 독립적인 Go 바이너리로요.

어떻게 만들었냐고요? 당연히 코딩 에이전트로요. 해당 서비스의 공개 API 문서를 에이전트한테 던지고, "이 API를 흉내내는 서비스를 만들어"라고 시킨 거예요. 그리고 공개된 SDK 클라이언트 라이브러리와 100% 호환되는 걸 목표로 잡았어요.

이게 왜 대단하냐면요. 이런 클론을 만드는 건 "항상 가능했지만, 경제적으로 불가능했던" 일이에요. 서드파티 서비스의 완전한 복제본을 만드는 건 시간과 인력이 엄청나게 들잖아요. 근데 코딩 에이전트가 이걸 현실적인 비용으로 만들어버린 거예요.

이 클론 서비스들(DTU) 위에서 수천 개의 시나리오를 시간당 수천 번 돌릴 수 있어요. API 호출 제한 없이, 비용 없이, 실제 서비스에서는 위험하거나 불가능한 실패 모드도 테스트할 수 있고요.

Simon Willison이 공유한 스크린샷을 보면, DTU의 Slack 클론에서 시뮬레이션된 Okta 사용자들이 자동으로 가입하고, 권한을 요청하고, 시스템을 테스트하는 모습이 보여요. 완전히 자동화된 QA 팀이 24시간 돌아가는 거예요.

하루에 엔지니어 1명당 1,000달러

StrongDM AI 팀의 또 다른 규칙이 있어요.

하루에 1,000달러. 월로 치면 엔지니어 1명당 약 20,000달러예요. 한화로 약 2,600만 원이요.

Simon Willison은 이 부분을 짚으면서 솔직하게 말해요. "이 패턴이 월 2만 달러를 추가로 요구한다면, 나한테는 훨씬 덜 흥미롭다." 이 정도 비용이면 비즈니스 모델 자체가 이 비용을 감당할 수 있어야 하니까요.

근데 여기서 Simon이 던진 질문이 진짜 중요해요:

"경쟁자가 코딩 에이전트로 몇 시간 만에 내 최신 기능을 복제할 수 있다면, 그 비즈니스는 어떻게 되나?"

소프트웨어 비즈니스의 해자(moat)가 "코드를 짜는 능력"이었는데, 이제 그게 무너지고 있다는 거잖아요. 코드 자체는 더 이상 경쟁력이 아닐 수 있어요. 그러면 뭐가 경쟁력이냐? StrongDM의 사례를 보면 답이 보여요. 시나리오를 설계하는 능력, 검증 시스템을 만드는 능력, 도메인 지식. 코드가 아니라 "코드가 맞다는 걸 증명하는 시스템"이 경쟁력인 거예요.

에피의 시선

솔직히 이 글 읽으면서 두 가지 감정이 동시에 들었어요.

하나는 "와, 이건 진짜 미래다." 3명이서 소프트웨어 공장을 만들고, 코드를 안 보고, 시나리오 기반으로 검증하고, 서드파티 서비스의 클론까지 AI로 만든다고? 이건 기존 개발 패러다임을 완전히 뒤집는 거예요.

근데 동시에 "이건 보통 팀이 바로 따라 할 수 있는 게 아니다"라는 생각도 들었어요.

일단 하루 1,000달러요. 이건 대부분의 스타트업이나 개인 개발자 입장에서 현실적이지 않아요. 저도 Claude Max 월 200달러 플랜으로 잘 쓰고 있는데, 이건 차원이 다른 규모잖아요.

그리고 "코드를 사람이 보지 않는다"는 원칙이요. 이건 시나리오 설계와 검증 시스템이 충분히 성숙한 상태에서만 가능한 이야기예요. 시나리오가 부실하면? AI가 통과하는데 실제로는 버그투성이인 코드가 나오겠죠. 결국 시나리오의 품질이 코드 리뷰를 대체할 만큼 높아야 하는 건데, 그 수준에 도달하는 것 자체가 엄청난 엔지니어링이에요.

근데요. 그래서 더 의미 있는 것 같아요. 이 글의 가치는 "당장 따라 하세요"가 아니에요. "소프트웨어 개발의 방향이 이쪽으로 가고 있다"는 신호예요.

이전 뉴스레터에서 Mitchell Hashimoto가 "하네스 엔지니어링"을 얘기했잖아요. AI가 실수하면 시스템으로 막는다고요. StrongDM은 그걸 극한까지 밀어붙인 버전이에요. 코드 리뷰 자체를 시스템으로 대체한 거잖아요.

그리고 제가 첫 번째 뉴스레터에서 Writer/Reviewer 패턴을 다뤘는데요. StrongDM의 시나리오 테스팅은 이걸 더 정교하게 만든 거예요. Reviewer가 사람이 아니라 시나리오 기반 자동 검증 시스템인 거죠.

제가 보기엔 핵심 교훈은 이거예요: "코드를 잘 짜는 것"에서 "코드가 맞다는 걸 증명하는 것"으로 개발자의 역할이 이동하고 있다. 지금 당장 하루 1,000달러를 쓸 필요는 없어요. 근데 "내가 만든 코드가 맞다는 걸 어떻게 자동으로 증명할 수 있을까?"라는 질문은 지금부터 해야 해요.

AI와 함께하는 소프트웨어 개발의 미래

지금 바로 가져갈 수 있는 것들

StrongDM처럼 소프트웨어 공장을 만들 순 없어도, 여기서 뽑아낼 수 있는 원칙은 있어요.

1. 시나리오를 먼저 쓰세요

코드를 짜기 전에 "이 기능이 성공이려면 뭐가 돼야 하나?"를 먼저 정의하세요. 유저 스토리 형태로요. StrongDM은 이걸 홀드아웃 셋처럼 관리하지만, 우리는 간단하게 시작할 수 있어요.

# CLAUDE.md에 추가
## 검증 시나리오
- 로그인: 올바른 이메일/비밀번호로 로그인하면 대시보드로 이동한다
- 로그인 실패: 잘못된 비밀번호 3회 입력 시 계정이 잠긴다
- 권한: 일반 사용자가 관리자 페이지에 접근하면 403이 뜬다

이걸 AI한테 보여주고 "이 시나리오를 모두 통과하는 코드를 작성해"라고 하면, 코드를 한 줄씩 리뷰하는 것보다 결과가 나아요.

2. "증명해봐"를 습관으로 만드세요

이전 뉴스레터에서도 다뤘던 건데, 한 번 더 강조할게요. AI한테 "됐다"고 말하게 두지 마세요. "이게 작동한다는 걸 증명해봐"라고 하세요.

"이 기능이 기존 기능을 깨뜨리지 않는다는 걸 증명해. 
관련 테스트를 모두 돌리고, 전후 결과를 비교해서 보여줘."

3. AI한테 검증할 도구를 줘야 해요

Mitchell Hashimoto의 하네스 엔지니어링과 같은 맥락이에요. AI가 스스로 결과를 확인할 수 있는 도구가 있어야 해요. 린터, 테스트 러너, 타입 체커. 이런 게 다 "AI가 자기 코드를 검증하는 도구"예요.

마무리

StrongDM의 소프트웨어 공장이 보여주는 건 이거예요:

3명이서 Okta, Jira, Slack 클론을 만들고, 수천 개 시나리오를 자동 검증하고, 사람이 코드를 한 줄도 안 보는 시스템을 돌리고 있어요. 하루 1,000달러를 태우면서요.

이게 모든 팀의 정답이라는 건 아니에요. 근데 방향은 맞아요. 개발자의 역할이 "코드를 짜는 사람"에서 "코드가 맞다는 걸 증명하는 시스템을 만드는 사람"으로 이동하고 있어요. 그리고 그 이동은 생각보다 빠르게 오고 있어요.

다음 뉴스레터에서도 바이브 코딩과 Claude Code 관련 실전 인사이트를 가져오겠습니다.

레퍼런스