인간의 개입은 실패 신호다
HUMAN IN THE LOOP = BOTTLENECK
HUMAN IN THE LOOP = BOTTLENECK
자율 주행을 생각해 보십시오. 인간이 운전대를 잡아야 한다면, 그것은 기능이 아니라 시스템의 실패입니다. 자동차가 스스로 상황을 감당하지 못한 것입니다.
코딩이라고 다를 이유가 있습니까?
당신이 다음과 같은 상황에 처해 있다면:
- AI가 작성하다 만 코드를 고치고 있거나
- 뻔한 실수를 직접 수정하고 있거나
- 에이전트에게 작업을 단계별로 하나하나 지시하고 있거나
- 같은 요구사항을 반복해서 설명하고 있다면
...그것은 "인간과 AI의 협업"이 아닙니다. AI가 제 역할을 못하고 있는 것입니다.
Oh My OpenCode는 이 전제 위에 구축되었습니다: 에이전트 작업 중 인간의 개입은 근본적으로 잘못된 신호입니다. 시스템이 올바르게 설계되었다면, 에이전트는 당신이 돌봐주지 않아도 작업을 완수해야 합니다.
구별할 수 없는 코드
목표: 에이전트가 작성한 코드는 시니어 엔지니어가 작성한 코드와 구별할 수 없어야 한다.
"정리가 필요한 AI 생성 코드"가 아닙니다. "좋은 시작점"도 아닙니다. 실제, 최종, 프로덕션 준비가 완료된 코드여야 합니다.
이는 다음을 의미합니다:
- 기존 코드베이스 패턴을 정확히 따르는 것
- 요청하지 않아도 적절한 에러 처리를 하는 것
- 실제로 필요한 것을 검증하는 테스트를 작성하는 것
- AI Slop(과도한 엔지니어링, 불필요한 추상화, 범위 확장)이 없는 것
- 가치가 있을 때만 주석을 다는 것
커밋을 인간이 했는지 에이전트가 했는지 구분할 수 있다면, 그 에이전트는 실패한 것입니다.
토큰 비용 vs. 생산성
생산성을 획기적으로 높일 수 있다면 더 많은 토큰 사용은 허용됩니다.
더 많은 토큰을 사용하여:
- 여러 전문 에이전트가 병렬로 조사하게 하고
- 인간의 개입 없이 작업을 완전히 끝내고
- 완료 전에 작업을 철저히 검증하고
- 작업 전반에 걸쳐 지식을 축적하는 것
...이것이 10배, 20배, 100배의 생산성 향상을 의미한다면 가치 있는 투자입니다.
하지만:
불필요한 토큰 낭비는 지양합니다. 시스템은 다음을 위해 최적화합니다:
- 단순 작업에는 더 저렴한 모델(Haiku, Flash) 사용
- 중복 탐색 방지
- 세션 간 학습 내용 캐싱
- 충분한 맥락이 수집되면 조사 중단
토큰 효율성은 중요합니다. 하지만 작업 품질이나 인간의 인지 부하를 희생해서는 안 됩니다.
인간의 인지 부하 최소화
인간은 원하는 것이 무엇인지만 말하면 됩니다. 나머지는 모두 에이전트의 몫입니다.
이를 달성하기 위한 두 가지 접근 방식:
접근 방식 1: Ultrawork
그냥 "ulw"라고 말하고 자리를 비우십시오.
당신이 말합니다: ulw add authentication
에이전트는 자율적으로:
- 코드베이스 패턴과 아키텍처를 분석하고
- 공식 문서에서 모범 사례를 조사하고
- 내부적으로 구현 전략을 수립하고
- 기존 컨벤션을 따르며 구현하고
- 테스트와 LSP 진단으로 검증하고
- 문제가 생기면 스스로 수정하고
- 100% 완료될 때까지 계속 밀어붙입니다
개입 제로. 완전 자율. 오직 결과뿐.
접근 방식 2: Prometheus + Atlas
전략적인 제어가 필요할 때.
Tab을 눌러 에이전트를 전환한 뒤: add authentication
Prometheus (전략 기획자):
- 병렬 에이전트를 통해 심층적인 코드베이스 조사를 수행하고
- 지능적이고 맥락에 맞는 질문으로 당신을 인터뷰하고
- 엣지 케이스와 아키텍처에 미칠 영향을 식별하고
- 의존성이 포함된 상세한 YAML 작업 계획을 생성합니다
Atlas (마스터 오케스트레이터):
/start-work를 통해 계획을 실행하고- 전문 에이전트(Oracle, Frontend Engineer 등)에게 작업을 위임하고
- 효율성을 위해 병렬 실행 웨이브를 관리하고
- 진행 상황을 추적하고, 실패를 처리하며, 완료를 보장합니다
당신은 설계하고, 에이전트는 실행합니다. 완전한 투명성.
두 경우 모두, 인간의 역할은 원하는 것을 표현하는 것이지, 어떻게 할지를 관리하는 것이 아닙니다.
예측 가능성, 지속성, 위임 가능성
이상적인 에이전트는 컴파일러처럼 작동해야 합니다: 마크다운 문서가 들어가면, 작동하는 코드가 나와야 합니다.
예측 가능성 (Predictable)
동일한 입력이 주어졌을 때:
- 동일한 코드베이스 패턴
- 동일한 요구사항
- 동일한 제약조건
...출력은 일관되어야 합니다. 무작위적이거나, 놀랍거나, 요청하지 않은 방식으로 "창의적"이어서는 안 됩니다.
지속성 (Continuous)
작업은 중단되어도 지속되어야 합니다:
- 세션이 충돌했나요?
/start-work로 재개하십시오 - 자리를 비워야 하나요? 진행 상황은 추적됩니다
- 며칠 걸리는 프로젝트인가요? 맥락은 보존됩니다
상태 유지는 에이전트가 합니다. 당신이 할 필요가 없습니다.
위임 가능성 (Delegatable)
유능한 팀원에게 업무를 맡기고 믿는 것처럼, 에이전트에게도 위임할 수 있어야 합니다.
이는 다음을 의미합니다:
- 독립적으로 검증된 명확한 인수 조건
- 문제가 발생했을 때의 자가 수정 행동
- 정말 필요할 때만 (Oracle이나 사용자에게) 에스컬레이션
- "거의 다 된" 것이 아닌, 완전히 끝난 작업
핵심 루프 (The Core Loop)
Oh My OpenCode의 모든 것은 이 루프가 작동하도록 설계되었습니다:
| 기능 | 목적 |
|---|---|
| Prometheus | 지능형 인터뷰를 통해 의도 추출 |
| Metis | 버그가 되기 전에 모호함 포착 |
| Momus | 실행 전 계획의 완전성 검증 |
| Orchestrator | 인간의 마이크로매니지먼트 없이 작업 조정 |
| Todo Continuation | 완료를 강제하고, "다 했어요"라는 거짓말 방지 |
| Category System | 인간의 결정 없이 최적의 모델로 라우팅 |
| Background Agents | 사용자를 차단하지 않고 병렬 조사 |
| Wisdom Accumulation | 작업에서 학습하여 실수 반복 방지 |
우리가 만드는 미래
다음과 같은 세상입니다:
- 인간 개발자는 AI에게 어떻게 만들게 할지가 아니라, 무엇을 만들지에 집중합니다
- 코드 품질이 누가(또는 무엇이) 작성했는지와 무관합니다
- 복잡한 프로젝트도 단순한 프로젝트만큼 쉽습니다 (단지 시간이 더 걸릴 뿐)
- "프롬프트 엔지니어링"이 "컴파일러 디버깅"만큼이나 구시대의 유물이 됩니다
에이전트는 보이지 않아야 합니다. 숨겨져 있다는 뜻이 아니라, 전기나 수돗물, 인터넷처럼 그저 작동한다는 의미에서 그렇습니다.
스위치를 켜면 불이 들어옵니다. 전력망에 대해서는 생각하지 않습니다.
그것이 목표입니다.