"코드는 인간에 의해 작성되어서는 안 된다."
"코드는 인간에 의해 검토되어서는 안 된다."
이것은 2026년 2월, Simon Willison을 통해 재현된 StrongDM의 AI 팀 두 가지 창립 규칙입니다. Willison은 두 번째 규칙에 가장 흥미를 느꼈고, 저 역시 마찬가지였습니다. 소프트웨어를 배포한 15년 경력에서 오는 모든 본능이 검토되지 않은 코드가 사고를 일으키는 원인이라고 말합니다.
하지만 이 아이디어는 사라지지 않습니다. 이제 코딩 에이전트들은 몇 시간 동안 실행되고, 풀 리퀘스트(pull requests)를 병렬로 열고, 스스로 실패하는 테스트를 수정합니다. '자동 완성'과 '아무도 더 이상 코드를 읽지 않는다' 사이 어딘가에 선이 있고, 대부분의 팀은 그 선이 어디인지 결정하지 않은 채 건너가고 있습니다.
그 선에는 이제 이름이 생겼습니다. **다크 팩토리(dark factory)**는 AI 에이전트가 인간이 아무도 읽지 않은 코드를 작성하고, 테스트하고, 배포하는 소프트웨어 파이프라인입니다. **라이트 팩토리(light factory)**는 판단이 중요한 지점에서는 인간을 유지한 채 동일한 파이프라인입니다 (Addy Osmani는 이를 'lit' 팩토리라고 부릅니다).
본 게시물은 세 가지 내용을 다룹니다:
- 다크 팩토리 대 라이트 팩토리 구분이 실제로 무엇인지, 그리고 이 용어들이 어디에서 왔는지.
- 결정적인 요소가 모델의 지능이 아니라 검증(verification)이라는 점.
- 회사가 아닌 루프(loop) 단위로 어떤 작업은 어둠 속에서 실행될 수 있고 어떤 작업은 밝게 유지되어야 하는지 결정하는 실용적인 방법.
| 출처 | 기여 내용 |
|---|
| Dan Shapiro's five levels (2026년 1월) | 자율 주행 레벨을 모델로 한 AI 지원 프로그래밍 사다리. 가장 높은 단은 '다크 소프트웨어 팩토리(dark software factory)'입니다. |
| ... | |
| Osmani의 어휘가 제가 찾은 것 중 가장 유용해서, 이 게시물 나머지 부분에서도 이를 사용할 것입니다: | |
- Loop: 하나의 에이전트가 한 가지 작업을 반복적으로 수행하는 것. 컨텍스트를 수집하고, 행동하며, 확인하고, 특정 조건이 충족될 때까지 반복합니다.
- Harness: 루프 주변의 모든 것. 샌드박스(Sandbox), 도구(tools), 메모리, 그리고 '완료'를 정의하는 게이트입니다.
- Factory: 작업 대기열(work queue)을 통해 공급되고 검토 게이트(review gate)를 거쳐 생산으로 배출되는 여러 개의 장치화된 루프들입니다.
다크와 라이트의 질문은 오직 마지막 게이트에 관한 것입니다. 누가, 또는 무엇이 변화가 배포하기에 충분히 좋은지 결정하는가?
┌──────────── HARNESS ────────────┐
work queue ──▶ │ agent loop: context → act → check │ ──▶ REVIEW GATE ──▶ production
└──────────────────────────────────┘ │
...
진짜 문제: 생성은 저렴하지만, 검증은 그렇지 않다
에이전트들은 코드를 작성하는 것을 거의 무료로 만들었습니다. 하지만 코드 이해를 더 싸게 만든 것은 아닙니다. 이 격차가 Osmani가 **이해 부채(comprehension debt)**라고 부르는 것입니다. 이는 존재하는 코드의 양과 인간이 여전히 이해할 수 있는 코드의 양 사이의 증가하는 거리를 의미합니다.
다크 팩토리는 코드를 생산하는 속도만큼이나 빠르게 이해 부채를 떠안고, 테스트는 계속 녹색 상태를 유지합니다. 팀원 누구도 시스템의 특정 부분이 어떻게 작동하는지 모르는 사이에 무언가가 고장 나기 전까지는 아무것도 잘못된 것처럼 보이지 않습니다.
실패 양상(failure modes)은 구체적이며, 각 측면마다 다릅니다:
| 다크 팩토리 실패 (Dark factory failure) | 라이트 팩토리 실패 (Light factory failure) |
|---|
| 무엇이 잘못되는가 | 모든 검사를 통과하는 "비인간적인" 실수가 담긴 그럴듯한 코드가 배포된다 | 인간이 병목 현상이 되어 하루에 40개의 PR을 승인만 한다 |
| ... | | |
| 라이트 측면의 마지막 행이 사람들이 과소평가하는 부분입니다. 사람들이 읽지 않고 "승인" 버튼을 누르는 라이트 팩토리는 추가적인 지연 시간(latency)을 가진 다크 팩토리와 같습니다. 당신은 다크 버전의 위험과 라이트 버전의 비용을 모두 갖게 됩니다. | | |
다크 측면에는 직접적인 금전적 비용도 존재합니다. Willison이 보고한 StrongDM의 벤치마크에 따르면, 한 공장은 인력 엔지니어 1인당 하루 약 $1,000의 토큰 비용을 지출해야 합니다. Willison은 이것이 엔지니어 1인당 월 $20,000 정도임을 지적하며, 이 접근 방식을 대부분의 팀에게 비즈니스 모델 질문으로 만듭니다.
결정적인 요소: 기계가 이를 저렴하고 정직하게 검증할 수 있는가?
Shapiro의 레벨과 그 주변의 대부분 논평은 동일한 결론을 가리킵니다. 자율성은 모델이 얼마나 똑똑하냐에 의해서가 아니라, 검증(verification)에 의해 제한됩니다. 루프는 다음 조건에서만 다크해질 수 있습니다:
- 저렴함 (Cheap): 아무도 기다리지 않고 모든 변경 사항에 대해 실행될 수 있다.
- 빠름 (Fast): 에이전트가 자체 루프 내에서 피드백을 받을 수 있다.
- 속이기 어려움 (Hard to fake): 에이전트가 실제 작업을 수행하지 않고는 검사를 통과시킬 수 없다.
세 번째 속성에서 대부분의 설정이 실패합니다. 만약 동일한 에이전트가 코드와 테스트를 작성한다면, 녹색(green) 스위트만으로는 거의 아무것도 증명할 수 없습니다. 에이전트는 당신이 주는 어떤 검사라도 만족시키는 데 매우 능숙하며, 심지어 그 검사를 약화시킴으로써도 가능합니다.
StrongDM의 답변은 정확히 이 부분을 겨냥하고 있기 때문에 연구할 가치가 있습니다. 그들은 엔드투엔드 시나리오(scenarios)를 코드베이스 외부에 유지하는데, 이는 코딩 에이전트들이 볼 수 없는 영역입니다. 이는 모델 학습에서의 홀드아웃 세트(holdout set)와 유사합니다. 그들은 제3자 서비스의 행동 복제본으로 이루어진 "디지털 트윈 유니버스(Digital Twin Universe)"를 대상으로 테스트합니다. 그리고 단순히 통과/실패 여부를 측정하는 대신, 사용자에게 만족할 가능성이 있는 시나리오 실행 비율인 "만족도(satisfaction)"를 측정합니다.
원칙을 적용하기 위해 그들의 예산이 필요하지 않습니다. 최소한의 holdout gate 버전은 다음과 같습니다:
# .github/workflows/holdout-gate.yml (예시)
name: holdout-scenarios
on: pull_request
...
중요한 부분은 Playwright나 GitHub Actions가 아닙니다. 경계입니다. 즉, 코드를 작성하는 에이전트가 자신을 판단하는 검사(checks)를 읽거나 편집할 수 없어야 합니다. 이러한 경계가 없다면, '다크'는 단순히 '검증되지 않음'만을 의미합니다.
결정 방법: 루프마다 스위치를 켜고 끄기
Osmani의 에세이에서 가장 실용적인 아이디어는 완전히 다크하거나 완전히 라이트하는 것 모두가 각기 다른 방식으로 실패한다는 것입니다. 이 결정은 조직에 속하는 것이 아니라, 각 루프(loop)에 속합니다.
저는 어떤 자율성을 부여하기 전에 각 루프를 네 가지 질문으로 점수화하는 것이 도움이 된다고 생각합니다:
| 질문 | 다크가 합리적인 경우... | 라이트를 유지해야 하는 경우... |
|---|
| 어떻게 검증되는가? | 타입 체크(Type checks), 속성 테스트(property tests), holdout 시나리오, 린터(linters) | '괜찮아 보인다'거나 같은 에이전트가 작성한 테스트 |
| ... | | |
| 여기 코드가 사용된 것과 동일한 기준표가 있으므로, 누군가의 머릿속에 있기보다 공장의 라우터에 존재할 수 있습니다: | | |
type Verification = "machine-hard-to-fake" | "machine-self-written" | "human-judgment";
type BlastRadius = "local" | "service" | "critical";
...
'라이트(light)'에는 두 가지 종류가 있다는 점에 주목하세요. 이것이 다크/라이트 분할 자체보다 더 중요합니다.
**머지 시점의 라이트(Light at merge)**는 전형적인 코드 리뷰입니다. 사람이 diff를 읽습니다. 이는 비용이 많이 들고 에이전트 출력량에는 확장되지 않으므로, 실수가 정말로 치명적인 소수의 변경 사항에만 할당해야 합니다.
**계획 시점의 라이트(Light at plan)**는 인간의 판단을 상류(upstream)로 이동시킵니다. 에이전트는 짧은 계획(접근 방식, 건드릴 파일, 위험 요소, 검증 방법)을 작성하고, 사람이 이를 승인하거나 재지정하며, 그 후에 구현이 기계적 검사를 거쳐 실행됩니다. 1페이지짜리 계획을 검토하는 것은 2,000줄의 생성된 코드를 검토하는 것보다 훨씬 저렴하며, 테스트로는 잡을 수 없는 실수(잘못된 것을 구축하는 것)를 잡아냅니다.
실제 적용하기
가상의 팀이 중규모 SaaS 제품에서 에이전트를 실행하는 과정을 살펴보겠습니다. 이들이 가질 수 있는 반복 작업(loop)들과 각각의 위치는 다음과 같습니다:
| Loop | Verification | Mode |
|---|
| 야간: 린트 경고 하나 수정, 작은 PR 하나 열기 | Linter + 타입 검사 + 기존 테스트 | 다크 |
| ... | | |
| 이 패턴은 다크 루프가 작고 지루하며 잘 보호된다는 것입니다. 이것은 한계가 아니라 핵심입니다. Osmani는 에이전트가 대략 3~10단계까지 유지되다가 20단계를 넘어서면 흐름을 놓치기 쉽다는 Dex Horthy의 경험칙을 인용합니다. 강력한 게이트를 가진 짧은 루프야말로 다크함을 저렴하게 만드는 요소입니다. | | |
에이전트 측면도 문서화되어야 합니다. 왜냐하면 에이전트는 어디가 밝은지 추론하지 못하기 때문입니다. 저는 이 규칙을 CLAUDE.md 파일에 보관하여 모든 세션이 이것으로 시작되도록 합니다:
## 자율성 경계 (Autonomy boundaries)
- 요청 없이 PR을 열 수 있는 경우: 린트 수정, 패치 레벨 종속성 증가(dependency bumps), 테스트 추가, 문서.
각 PR은 변경 라인 수를 200줄 미만으로 유지하세요.
...
마지막 줄이 있는 이유는 이것이 원격으로 실행되는 루프가 '실패하면서 성공하는' 가장 흔한 방식이기 때문입니다.
마지막으로, 다크 루프를 측정(instrument)해야 합니다. 만약 사람이 코드를 읽지 않는다면, 적어도 인간은 공장(factory)이 무엇을 했는지 볼 수 있어야 합니다: 어떤 루프가 어떤 변경 사항을 생성했는지, 어떤 검사가 실행되었는지, 각 루프가 얼마나 자주 에스컬레이션되거나 되돌려졌는지. 다크 루프에서 반전율(revert rate)이 높아지는 것은 빛을 다시 켜야 한다는 신호입니다.
트레이드오프와 다크 공장이 잘못된 선택인 경우
저는 사람들이 의존하는 어떤 시스템에서도 완전히 다크하게 운영되는 것에 회의적이며, 오늘날 회의론자들이 더 강력한 주장을 하고 있다고 생각합니다. 하지만 전면적인 '절대 안 된다' 역시 틀린 말입니다.
| | 다크 공장 (Dark factory) | 라이트 공장 (Light factory) | |
| --- | --- | --- |
| 처리량 (Throughput) | 컴퓨팅 및 예산에 의해 제한됨 | 검토자의 주의력에 의해 제한됨 |
| ... |
이러한 경우 중 하나라도 해당한다면 루프를 다크하게 실행하지 마세요:
에이전트와 독립적으로 테스트 케이스를 작성할 수 없습니다. 만약 유일한 테스트가 에이전트가 작성한 것이라면, 당신은 에이전트 스스로 자신을 평가하도록 신뢰하는 것입니다.
해당 도메인이 규제되거나 안전과 관련된 경우입니다. "인간이 검토하지 않았습니다(No human reviewed this)"라는 답변은 감사관에게 제시하기에 매우 어려운 대답입니다.
시스템이 테스트가 취약한 레거시 코드베이스인 경우입니다. 에이전트는 그곳에 존재하는 모든 것을 증폭시킵니다. 문서화가 제대로 되지 않은 시스템에서는 혼란을 증폭시킵니다.
팀원 누구도 그것을 디버그할 수 없는 경우입니다. 만약 새벽 3시에 코드가 고장 난다면, 누군가가 그것을 이해해야 합니다. 그런 사람이 존재하지 않는다면, 당신은 자신이 갖지 않은 이해력에 대해 대출을 받는 것과 같습니다.
그리고 습관 때문에 루프 라이트(loop light)를 유지만 하지 마십시오. 견고한 테스트 스위트가 이미 검증한 의존성 변경 사항에 대해 선임 엔지니어들에게 라인 리뷰(line-review)를 요청하는 것은, 필요한 변경 사항에 대한 검토가 의미를 잃게 만드는 방식입니다.
FAQ
다크 팩토리(dark factory)는 "바이브 코딩(vibe coding)"과 같은 것인가요?
아닙니다. 바이브 코딩은 검증 단계를 건너뜁니다. 진지한 다크 팩토리는 인간의 검토를 더 강력한 기계적 검증(machine verification)으로 대체합니다: 숨겨진 시나리오(hidden scenarios), 서비스 트윈(service twins), 적합성 검사(conformance checks). 검토의 부재는 오직 그 검증이 검토보다 더 강력할 때만 방어 가능합니다.
이 용어를 누가 만들었나요?
"다크 팩토리(dark factory)"는 무인 제조(lights-out manufacturing)에서 유래했습니다. 소프트웨어 분야에서는 Dan Shapiro의 다섯 가지 레벨과 StrongDM이 발표한 접근 방식(둘 다 Simon Willison에 의해 다루어짐)이 2026년 초에 이를 대중화했습니다. 소프트웨어 팩토리에 대한 라이트/다크 페어링은 Addy Osmani의 2026년 7월 에세이에 설명되어 있습니다. 이 용어들은 여전히 비공식적이며 사람마다 경계를 다르게 그립니다.
라이트 팩토리(light factory)는 에이전트가 작성하는 모든 라인을 검토한다는 의미인가요?
그렇지 않습니다. 인간의 판단력이 가장 효과적인 곳은 코드가 존재하기 전의 계획(plan)과 아키텍처입니다. 라인 레벨 검토(Line-level review)는 소수의 고위험 변경 사항에 적합합니다.
시간이 지나면서 라이트(light)에서 다크(dark)로 이동할 수 있나요?
네, 한 루프씩 가능합니다. 특정 루프가 장기간에 걸쳐 강력하고 독립적인 검사(checks)를 수행하고 되돌림율(revert rate)이 낮다면, 인간의 게이트(human gate)를 줄일 수 있습니다. 되돌림율이 높아지면 다시 추가해야 합니다.
에이전트가 코드를 작성한다면 아키텍처는 여전히 중요할까요?
예전보다 더 중요합니다. 명확한 모듈 경계(module boundaries), 좋은 타입(types), 의존성 주입(dependency injection) 및 테스트 시음(test seams)이 기계 검증(machine verification)을 가능하게 하는 요소입니다. 약한 아키텍처는 모든 것을 라이트 상태로 유지하도록 강요합니다.
핵심 요약 (Takeaway)
- 다크 대 라이트 선택은 에이전트가 얼마나 많은 코드를 작성하느냐가 아니라, 검토 게이트(review gate)에 관한 것입니다.
- 자율성(Autonomy)은 검증(verification)에 의해 통제됩니다. 한 루프는 그 검사들이 저렴하고, 빠르고, 위조하기 어렵다는 조건 하에서만 다크 상태가 될 수 있습니다.
- 검사기(checker)와 실행자(doer)를 분리하세요. 코딩 에이전트가 읽거나 편집할 수 없는 격리 시나리오(holdout scenarios)를 유지하세요.
- 인간의 판단을 상류(upstream)로 이동시키세요. 생성된 라인을 검토하는 것보다 계획(plan)을 검토하는 것이 더 저렴하고 더 많은 것을 포착합니다.
- 루프별로 결정하세요. 린트 수정(Lint fixes)은 다크 상태에서 실행될 수 있지만, 인증(auth), 결제(payments), 마이그레이션(migrations)은 라이트 상태를 유지해야 합니다.
- 되돌림율을 관찰하세요. 이는 다크 루프가 다시 라이트 상태로 돌아가야 할 시점을 알려줍니다.
귀하의 팀에서 오늘 감시 없이 실행되는 루프는 무엇이며, 잘못되었을 때 그것을 포착할 것이라고 신뢰하는 검사는 무엇인가요? 댓글로 들려주세요.
저는 Diogo Soares이며, AI 에이전트 및 레거시 현대화(legacy modernization)를 다루는 스태프 AI 엔지니어입니다. 이 내용이 유용했다면 DEV.to에서 저를 팔로우해 주시고, LinkedIn에서 연결하거나 diogosoares.dev을 확인해 주세요.