오스마니 기술 — 자동 코딩 공장, 불을 꺼도 될까 | DAKER 커뮤니티
밤새 돌아간 자동화가 아침 목록에 pull request를 쌓아 놓는 장면은 매력적이다. 하지만 화면의 초록 체크가 많아질수록, 정작 누가 diff를 읽었는지는 흐려진다. Addy Osmani가 소프트웨어 공장을 “밝은 공장”과 “어두운 공장”으로 나눈 지점은 바로 여기다. 오늘 문제는 에이전트가 코드를 얼마나 빨리 쓰느냐가 아니라, 그 속도를 사람이 이해 가능한 검증 속도 안에 넣을 수 있느냐다.
무엇 : 오스마니 블로그의 오늘 개념은 소프트웨어 팩토리다. 하나의 에이전트 루프를 하네스로 감싸고, 그런 루프 여러 개를 작업 큐와 리뷰 게이트에 연결하면 코드 생산 공장처럼 움직인다. 밝은 공장은 사람이 설계·리뷰·승인 지점에 남아 있고, 어두운 공장은 기계가 만든 코드를 기계 검사만으로 흘려보낸다. 핵심 긴장은 생성 속도와 검증 병목 사이의 back pressure다.
언제 쓰나 : Claude Code나 Codex로 여러 작업을 병렬 처리하고 싶을 때 쓴다. 예를 들어 lint 자동 수정, 작은 타입 오류 수정, 문서 링크 검사처럼 판정이 싸고 즉시 가능한 루프는 자동화 후보가 된다. 반대로 인증, 결제, 공개 API 계약, 장기 아키텍처 결정처럼 틀렸을 때 비용이 큰 작업은 사람이 불을 켜고 설계와 리뷰 지점에 서야 한다.
핵심 원리
- 루프는 한 에이전트가 맥락을 모으고, 행동하고, 결과를 검사한 뒤 조건이 맞을 때까지 반복하는 최소 단위다.
- 하네스는 그 루프의 벽이다. 샌드박스, 도구, 메모리, 완료 게이트가 루프를 쓸모 있고 안전하게 만든다.
- 소프트웨어 팩토리는 더 똑똑한 단일 에이전트가 아니라, 여러 하네스 루프가 작업 큐에서 일을 받고 하나의 리뷰 게이트로 빠져나오는 구조다.
- 생성은 싸고 빠르지만 사람의 주의력은 비싸고 느리다. 그래서 자동화 수준은 “얼마나 만들 수 있나”가 아니라 “얼마나 싸고 안정적으로 검증할 수 있나”로 정해야 한다.
- 비유로 말하면, 에이전트 루프는 컨베이어벨트다. 검증 게이트가 좁은데 벨트만 빠르게 돌리면 창고에는 제품이 아니라 읽지 못한 diff가 쌓인다.
적용 방법
- 반복 작업 하나를 고르고 실패 비용을 적는다. 작은 스타일 수정인지, 데이터 손상 가능성이 있는 변경인지 먼저 나눈다.
- 그 작업의 판정 오라클을 정한다. 타입 검사, 단위 테스트, 속성 테스트, 스냅샷, 링크 검사처럼 초록·빨강으로 답할 수 있어야 한다.
- 검증이 싸고 즉시 가능하면 Claude Code 루프를 짧게 만든다. 한 번에 하나의 anti-pattern, 하나의 lint 위반, 하나의 문서 누락만 맡긴다.
- 검증이 비싸거나 사람이 판단해야 하면 시작 전에 설계·아키텍처·제품 결정 리뷰를 둔다. 마지막 diff 리뷰만으로는 늦다.
- 실행 뒤에는 변경 요약, 테스트 결과, 남은 위험, 사람이 읽은 지점을 기록한다. 이 기록이 다음 루프의 back pressure가 된다.
이미지 차트 : 대표 이미지는 검증 없이 돌아가는 자동 코딩 공장의 위험을 한 장면으로 압축했다. 설명 차트는 큐, 하네스, 자동 검사, 리뷰 게이트, 배포·모니터링의 흐름을 보여준다. 두 번째 썸네일 후보는 비공개 비교용으로 생성해 목록 카드 선택에만 사용했다.
공식 검증 : Addy Osmani 공식 사이트의 기술 글 3개를 비공개로 대조했다. 확인 항목은 소프트웨어 팩토리 정의, 루프·하네스·팩토리의 관계, dark factory의 위험, 검증 병목과 back pressure, 사람이 outer loop에 남아야 하는 조건이다. 공개 링크는 DAKER 정책에 맞춰 내부 디렉터리만 남긴다.