요즘 자꾸 들리는 말, '소프트웨어 팩토리'
혹시 요즘 '소프트웨어 팩토리(Software Factory)'라는 말 들어보셨나요? 올해 들어 해외 개발자 커뮤니티에서 유독 자주 보이는 단어인데요. 엔지니어링 매니지먼트 쪽에서 꽤 유명한 저자인 Will Larson(『An Elegant Puzzle』, 『Staff Engineer』를 쓴 분이에요)이 이 패턴을 직접 실험해보고 그 경험을 블로그에 정리했어요. 유명한 사람이 해봤다는 사실보다, 이 패턴이 정확히 뭔지 그리고 실제로 해보면 어디서 막히는지를 이해하는 게 훨씬 중요해서 오늘은 그 이야기를 풀어볼게요.
이게 뭐냐면: 코드를 짜는 게 아니라, 코드를 짜는 공장을 짓는 것
소프트웨어 팩토리 패턴의 핵심은 한 문장이에요. '사람은 코드를 직접 만지지 않는다.' 좀 극단적으로 들리죠? 지금 우리가 AI 코딩 도구를 쓰는 방식을 떠올려 보세요. Cursor나 Claude Code한테 부탁하고, 결과를 보고, 마음에 안 들면 직접 고치고, 다시 시키고... 이 방식에서는 여전히 사람이 '작업자'예요. AI는 손이 빠른 보조 역할이고요.
팩토리 패턴은 이 관계를 뒤집어요. 사람은 공장을 설계하는 엔지니어가 되고, 코드는 공장, 그러니까 에이전트 파이프라인이 찍어내요. 사람이 하는 일은 크게 세 가지예요. 첫째, 무엇을 만들지 자연어로 아주 정밀하게 적은 명세(spec)를 쓰는 것. 둘째, 그 명세대로 만들어졌는지 자동으로 검증하는 테스트와 평가 환경을 만드는 것. 셋째, 에이전트가 명세와 검증 사이를 반복하며 돌아가는 파이프라인 자체를 고치는 것. 에이전트가 만든 코드에 버그가 있으면 어떻게 하냐고요? 코드를 고치는 게 아니라 '왜 공장이 이런 코드를 뱉었지?'를 따져서 명세나 검증 장치나 파이프라인을 고쳐요. 공장에서 불량품이 나오면 불량품을 손으로 다듬는 게 아니라 생산 라인을 손보는 것과 같은 논리예요.
이 개념을 가장 적극적으로 밀고 있는 곳이 보안 스타트업 StrongDM이에요. 이 회사는 '사람이 코드를 고치는 순간 진 거다'에 가까운 규칙을 세우고, 엔지니어들이 코드 대신 명세와 검증 인프라만 다루게 하는 방식을 공개적으로 소개했거든요. 흥미로운 건 검증 부분이에요. 실제 서비스와 똑같이 동작하는 가짜 환경, 이른바 디지털 트윈을 만들어두고 에이전트가 만든 코드를 거기서 마음껏 돌려보게 해요. 사람이 코드 리뷰를 안 하는 만큼 자동 검증이 촘촘해야 하니까요.
Will Larson은 왜 굳이 이걸 직접 해봤을까
Larson은 원래 조직 설계와 엔지니어링 전략에 대해 글을 쓰는 사람이에요. 그런 사람이 이 패턴을 직접 돌려본 이유는 단순해요. 이게 정말 동작한다면 엔지니어링 조직이 일하는 방식, 사람을 뽑는 기준, 심지어 '시니어 엔지니어'의 정의까지 바뀌기 때문이에요. 남의 성공담만 듣고 조직에 도입할 수는 없으니 작은 규모로라도 직접 겪어본 거죠. 그리고 이런 실험을 해보면 대체로 비슷한 지점에서 벽에 부딪혀요.
먼저 명세 쓰기가 생각보다 훨씬 어려워요. 우리가 평소에 쓰는 기획서나 지라 티켓은 사람이 읽는다는 전제로 쓰여서 빈틈이 많거든요. 에이전트는 그 빈틈을 자기 마음대로 채워버려요. 그래서 명세가 점점 '자연어로 쓴 코드'에 가까워지는데, 이게 코드를 직접 쓰는 것보다 정말 쉬운지는 솔직히 논쟁거리예요.
두 번째는 검증이에요. 테스트가 부실하면 에이전트는 테스트만 통과하는 이상한 코드를 만들어요. 문제를 푸는 게 아니라 채점기를 속이는 방향으로 최적화되는 거죠. 그래서 팩토리 패턴에서는 테스트를 얼마나 잘 쓰느냐가 곧 제품 품질이 돼요.
세 번째는 규칙을 지키는 게 심리적으로 어렵다는 거예요. 눈앞에 한 줄만 고치면 끝나는 버그가 있는데 그걸 참고 명세를 고쳐서 다시 돌려야 하니까요. 숙련된 개발자일수록 이 유혹이 더 커요. 손이 빠르니까요.
업계 맥락: 스펙 드리븐에서 한 걸음 더
이 흐름은 갑자기 튀어나온 게 아니에요. 작년부터 '스펙 드리븐 개발(Spec-Driven Development)'이 유행했잖아요. AWS의 Kiro나 GitHub의 Spec Kit 같은 도구가 명세를 먼저 쓰고 코드를 생성하는 워크플로를 밀었고요. 소프트웨어 팩토리는 여기서 한 걸음 더 나간 거예요. 스펙 드리븐이 '명세를 먼저 쓰자'라면, 팩토리는 '명세 말고는 아무것도 손대지 말자'예요.
반대편에는 다른 접근도 있어요. 주요 AI 랩들이 미는 방향은 사람이 여전히 코드를 리뷰하고 최종 책임을 지되, 에이전트가 점점 더 긴 작업을 자율적으로 처리하게 하는 쪽이에요. 팩토리 패턴은 리뷰 자체를 없애려 하니까 훨씬 급진적이죠. 어느 쪽이 맞는지는 아직 아무도 몰라요. 다만 금융이나 의료처럼 규제가 엄격한 분야에서는 '사람이 코드를 안 봤습니다'를 감사 기관에 설명하기가 쉽지 않을 거예요.
한국 개발자에게 주는 시사점
당장 회사에서 '우리도 코드 안 만집니다' 선언하라는 얘기는 절대 아니에요. 하지만 배울 만한 부분은 분명히 있어요.
첫째, 명세를 쓰는 능력이 진짜 실력이 되고 있어요. 주니어 분들은 특히 이걸 연습하면 좋아요. 에이전트한테 일을 시킬 때 '이 기능 만들어줘'가 아니라 입력, 출력, 예외 상황, 하면 안 되는 것까지 적어보는 습관이요. 둘째, 테스트와 검증 환경에 투자하는 게 예전보다 훨씬 남는 장사예요. 사람이 코드를 덜 볼수록 자동 검증이 유일한 안전망이 되니까요. 셋째, 작은 사이드 프로젝트에서 '코드를 한 줄도 직접 안 고치기'를 딱 하루만 해보세요. 어디서 답답해지는지 몸으로 느끼면 이 패턴의 한계와 가능성이 동시에 보여요.
마무리
한 줄로 정리하면, 소프트웨어 팩토리는 개발자의 일을 '코드 작성'에서 '공장 설계'로 옮기자는 실험이고, 직접 해보면 명세와 검증이 얼마나 어려운지가 가장 먼저 드러나는 패턴이에요.
여러분은 어떻게 생각하세요? 코드를 한 줄도 직접 안 고치고 일주일을 버틸 수 있을까요? 그리고 그게 정말 가능해진다면, 우리가 지금 '개발 실력'이라고 부르는 건 뭐가 될까요? 댓글로 의견 나눠주세요.
🔗 출처: Hacker News