90%와 100%는 왜 10배 차이가 나나
엔지니어의 90%가 AI를 쓰는 조직과 100%가 쓰는 조직은 결과가 전혀 다릅니다. 10%라도 옛 방식으로 일하면, 조직 전체가 그 10%에 맞춰 뒤로 물러서야 하기 때문입니다.
모두가 코드 에디터에 손으로 타이핑하지 않을 때 비로소 열리는 일들이 있습니다. 여러 기능과 버그를 병렬로 처리하고, 코드가 싸지니 위험한 아이디어도 일단 프로토타이핑해 실험 횟수를 늘립니다. 단 10%의 예외가 이 모든 가능성을 닫아 버립니다.
15명이 제품 4개를 운영한다는 건 무슨 뜻인가
미국 Every는 15명이 소프트웨어 제품 4개를 운영합니다. 코드의 99%를 AI 에이전트가 쓰고, 앱 하나를 개발자 한 명이 맡습니다. 유료 구독자 7천 명, 누적 투자는 100만 달러뿐입니다.
장난감 수준의 앱이 아니라 복잡한 프로덕션 제품을 한 사람이 만들고 유지합니다. 몇 년 전이라면, 아니 1년 전이라도 성립하지 않았을 구조입니다. 작업을 에이전트에 위임하고 병렬로 일하는 방식이 이를 가능하게 했습니다.
컴파운딩 엔지니어링이란 무엇인가
전통적 개발은 기능을 하나 더할 때마다 다음 기능이 더 어려워집니다. 컴파운딩 엔지니어링의 목표는 그 반대로, 매 기능이 다음 기능을 더 쉽게 만들도록 설계하는 것입니다.
방법은 계획, 위임, 평가, 체화의 네 단계 루프입니다. 핵심은 마지막 체화 단계입니다. 계획하고 위임하고 평가하며 얻은 암묵지를 프롬프트로 명문화해 조직 전체가 공유합니다. 이렇게 쌓인 프롬프트 라이브러리가 다음 작업의 출발선을 끌어올립니다.
이 방식은 조직에 어떤 2차 효과를 낳나
암묵지를 명문화하면 비자명한 2차 효과가 따라옵니다. 옆자리 개발자의 레포를 가리키기만 하면 AI가 그 구현 과정을 읽어 내 다른 기술 스택으로 옮겨 줍니다. 신입은 첫날부터 환경 설정과 좋은 PR 작성법을 갖춘 채 생산적으로 일합니다.
제품 간 버그 수정 PR을 서로 주고받고, 스택을 하나로 표준화하지 않아도 AI가 언어와 프레임워크 사이를 번역합니다. 관리자나 CEO조차 코드를 커밋합니다. 집중 시간 3~4시간을 통째로 비우지 않아도, 회의 사이 짬에 조사를 위임하고 돌아와 PR을 올릴 수 있기 때문입니다.