최근 “AI가 지식노동을 빠르게 대체한다”는 톤의 글이 다시 크게 돌고 있습니다. 방향 자체는 맞습니다. 다만 실무에 그대로 가져오면 사고 납니다.
핵심은 이겁니다.
이제 경쟁력은 모델 선택보다 하네스(운영체계) 설계에서 갈립니다.
왜 이런 글이 설득력 있게 들릴까
요즘 체감은 분명히 달라졌습니다.
- 모델 릴리즈 주기가 짧아졌고
- 코드 생성이 “초안 작성”을 넘어 “실행+수정 루프”로 이동했고
- 개발자 역할이 “직접 구현자”에서 “성공조건 설계자/검수자”로 이동 중입니다.
즉 2023~2024의 경험값으로 2026을 판단하면 오차가 큽니다.
하지만 그대로 믿고 달리면 실패하는 이유
강한 서사는 대체로 운영 현실을 생략합니다.
- 개인 경험 일반화 위험
특정 도메인 성공이 산업 평균은 아닙니다. - 선택 편향
성공 사례는 보이고, 재작업/검증 비용은 덜 보입니다. - 운영 병목 누락
규제, 보안, 책임소재, 레거시 통합은 모델 성능과 별개 병목입니다. - 품질보증 비용 상승
생성량이 늘수록 테스트/리뷰/감사 비용도 같이 증가합니다.
결론: AI 성능 향상과 조직 실행력은 다른 문제입니다.
실무에서 진짜 필요한 3가지
1) Agent Harness
- Initializer/Worker 역할 분리
- 각 턴 종료 시 다음 턴이 이어받을 아티팩트(progress log, commit context) 남기기
- 장기 작업에서 컨텍스트 단절 방지
2) Eval Harness
- “잘 된 것 같다” 금지
- lint/test/e2e/perf/security 자동 채점
- 합격선 미달 시 merge 차단
3) Ops Gate (HITL)
- 스키마 변경, 대량 데이터 수정, 배포는 사람 승인
- 저위험 구간만 자동화
- 속도와 안정성 균형 확보
사이드 프로젝트는 더 단순해야 한다 (ROI 우선)
사이드에서 가장 흔한 실패는 처음부터 과한 구조입니다.
채택:
- Contract-first (API/스키마/AC 먼저)
- 최소 테스트 게이트
- 빠른 롤백 절차
보류:
- 멀티 에이전트 스웜
- 과한 관제 체계
- 초기부터 복잡한 운영 콘솔
실제 적용 팁 (도메인 무관)
도메인과 무관하게 초기에 가장 ROI가 높은 방식은 같습니다.
- 읽기 트래픽은 정적/캐시 친화 구조로 시작
- 쓰기/운영 기능은 최소 백엔드로 분리
- 테스트 게이트 통과 전에는 자동 배포 금지
- 비용보다 더 중요한 지표(장애율/회귀율)를 먼저 고정
즉 정답은 “처음부터 크게”가 아니라 작게 시작해서 지표로 확장입니다.
바로 써먹는 체크리스트
- OpenAPI + DB migration + Acceptance Criteria 고정
- 머지 조건: lint/test/e2e/perf 최소 4종 통과
- 배포 승인 1단계(HITL) 적용
- 장애 시 10분 단위 롤백 플레이북 보유
- 릴리즈 판단은 “체감”이 아니라 채점 리포트로 수행
모델 성능 격차는 계속 줄어듭니다. 운영체계 격차는 오히려 벌어집니다.
AI 시대의 차이는 모델 스펙이 아니라 하네스 설계에서 납니다.
참고 링크
- Matt Shumer, “Something Big Is Happening”
https://www.linkedin.com/pulse/something-big-happening-matt-shumer-so5he - Anthropic, Demystifying evals for AI agents
https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents - Anthropic, Effective harnesses for long-running agents
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents - OpenHands Docs, Evaluation Harness
https://docs.openhands.dev/openhands/usage/developers/evaluation-harness