TL;DR
요즘 내가 AI를 어떻게 쓰는지 돌아보다가 이상한 점을 깨달았다.
나는 AI에게 세세한 절차를 거의 지시하지 않는다.
대체로 말하는 것은 “이기고 싶다”, “일을 줄이고 싶다”, “중간에 멈추지 마라”, “정말 됐는지 확인해라” 정도다.
대충이다. 꽤 대충이다.
그런데 그 대충 던진 목표를 진지하게 만족시키려 하면, AI 쪽은 알아서 조건을 나누고, 완료 기준을 만들고, 검증 방법을 생각하고, 실패한 곳에 가드레일을 더해 간다.
그 결과, 사람이 매번 꼼꼼히 확인하는 운영이 아니라, AI가 만들고, AI가 확인하고, 외부 증거로 맞춰 보고, 이상할 때만 보고하는 운영에 가까워졌다.
찾아보니, 이것은 OpenAI가 2026년에 공개한 “Harness Engineering”이라는 생각과 꽤 비슷했다.
사람은 의도와 경계를 정한다. 에이전트는 실행한다.
다만 개인에게는 강한 이 방식도, 회사에 가져가면 갑자기 어려워진다.
개인 프로젝트는 정치가 없는 독재국가다.
회사에 가져가는 순간 국회가 열린다.
출발점은 “이기고 싶다”와 “일을 줄이고 싶다”뿐
상위 목표는 놀랄 만큼 단순하다.
카드 게임이라면, 이기고 싶다.
글이나 자동화라면, 내 일을 줄이고 싶다.
이 두 가지는 강하다.
시뮬레이터를 만들었다. 대량 대전을 돌렸다. 탐색 알고리즘을 넣었다.
그래도 마지막에는 “그래서 승률이 올랐나?”로 끝난다.
글 처리를 자동화했다. 다국어로 만들었다. QA를 만들었다. 큐, 해시, 재시도를 넣었다.
그래도 마지막에는 “내 일이 줄었나?”로 끝난다.
기술은 복잡해져도, 목표는 복잡해지지 않는다.
목표가 흔들리지 않으니, 구체적인 방법은 AI에게 꽤 자유롭게 맡길 수 있다.
세세한 지시는 하지 않는다. 필요하면 AI에게 “되어야 할 모습”부터 만들게 한다
사람이 매번 완료 조건을 처음부터 설계할 필요는 없다.
“최신 글을 사람 손을 거치지 않고 올바른 상태로 공개까지 가져간다.”
이 정도 목표를 주면, AI에게 이렇게 생각하게 만들 수 있다.
- 무엇을 “최신”으로 볼 것인가
- 무엇을 “올바른” 상태로 볼 것인가
- 번역은 현재 원문과 맞는가
- 50개를 처리하려 했는데 1개만 성공하고 끝나도 되는가
- GitHub에 반영한 것만으로 공개라고 말할 수 있는가
- 실제 사이트까지 확인해야 하는가
즉, 사람이 쥐고 있는 것은 목표와 바뀌지 않아야 할 조건이고, 세세한 수용 기준은 AI가 펼치게 한다.
물론 AI가 만든 기준도 틀릴 수 있다.
그래서 다음에는 “검증”이 필요하다.
AI를 꽤 많이 쓴다. 하지만 “AI가 됐다고 말했다”는 증거로 삼지 않는다
겉으로 보면 AI에게 통째로 맡기는 것처럼 보인다.
실제로 작업도 AI에게 맡기고, 확인도 AI에게 맡긴다.
나는 가능하면 로그도 보고 싶지 않다.
이상이 있다면 이렇다.
작업한다 → 자동으로 검사한다 → 문제가 없으면 짧게 보고한다 → 이상하면 원인과 수정안만 가져온다.
여기서 중요한 점은, AI의 자기 보고를 그대로 완료 조건으로 삼지 않는 것이다.
“됐습니다”가 아니라, 개수, 테스트 결과, 해시, GitHub의 실제 파일, 실제 URL, 실제 사이트 HTML처럼 밖에서 볼 수 있는 것을 가져오게 한다.
같은 AI에게 같은 맥락으로 “네 일을 확인해”라고만 말하면, 같은 착각을 두 번 할 수 있다.
그래서 강한 형태는 생성, 검사, 외부 증거를 나누는 쪽이 된다.
사람이 전부 읽을 필요는 없다.
하지만 “확인했습니다” 한마디로 끝내지도 않는다.
대충 말하면,
“나는 안 볼 거다. 네가 확인해라. 다만 증거는 가져와라.”
라는 것이다.
걸리는 지점은 “아직 사람 손이 남아 있는 곳”
일을 진심으로 줄이려고 하면, 중간에 남아 있는 작은 수작업이 전부 눈에 밟힌다.
매번 여기만 누른다.
이 예외만 사람이 판단한다.
실패하면 사람이 로그를 본다.
공개 뒤에만 사람이 확인한다.
보통은 “뭐, 여기만 손으로 하면 되지” 하고 끝난다.
하지만 목표가 “일을 줄이고 싶다”라면, 그곳은 아직 미완성이다.
사람이 애써야만 돌아가는 공정을 찾았다면, 그 공정의 설계는 아직 끝나지 않았다.
이렇게 보면 오류는 단순한 사고가 아니다.
1개만 처리하고 멋대로 끝났다면, 남은 49개를 더해서 끝낼 일이 아니다.
“왜 1개만 처리하고 정상 종료할 수 있었는가”를 막아야 한다.
오래된 번역을 최신판으로 다뤘다면, 그 번역만 고치고 끝낼 일이 아니다.
“어떻게 해야 오래된 번역을 정상으로 볼 수 없게 만들까”를 구조에 넣어야 한다.
실패가 계속 규칙으로 올라가면, 사람의 일은 조금씩 사라진다.
“모르는 상사”는 아직 낫다. 무서운 것은 현실을 바꾸는 리뷰다
2026년 8월 Zenn에 공개된 “AI로 생산성이 3배가 된 우리가, 팀을 두고 앞서가 버린 이야기”에서는 AI 활용이 늘어난 결과, 상사가 내용을 충분히 리뷰할 수 없게 되는 상황을 다룬다.
상징적인 반응은 “바로 이해되지는 않지만, 맞는 말을 하고 있는 것 같다”이다.
리뷰로서는 약하다.
하지만 관리 측면에서 더 위험한 상태가 있다.
모르면서도, 윗사람의 위치를 지키기 위해 사실이나 기준을 나중에 바꾸는 것이다.
사전에 기준이 없는데, 결과를 보고 “보통 이렇게 하지 않나”라고 말한다.
상담하면 “스스로 생각해라”, 스스로 진행하면 “멋대로 하지 마라”라고 말한다.
이렇게 되면, 정답에 가까워지는 게임 자체가 성립하지 않는다.
반대로 “나는 지금 리뷰할 수 없다”고 인정할 수 있다면, 전문 리뷰를 더하거나, 검증 항목을 기계화하거나, 근거와 미확인 사항을 내게 하는 식으로 고칠 수 있다.
능력 부족은 보완할 수 있다.
판정 기준이 움직이는 리뷰는 품질 보증 장치 자체를 망가뜨린다.
QC가 싫었던 이유도, 지금은 조금 알 것 같다
QC 서클의 본래 목적은 현장의 작은 그룹이 계속 품질과 일을 개선하는 데 있다.
일본과학기술연맹도 QC 서클을 현장 직원들이 계속 관리하고 개선하는 활동으로 설명한다.
문제는 QC가 아니다.
개선보다 “QC를 한 모양새”를 완성하는 것이 목적이 되는 순간이다.
주제를 만든다.
그래프를 만든다.
QC 스토리에 끼워 맞춘다.
발표 자료를 만든다.
심사한다.
박수친다.
끝.
이러면 개선 활동이 아니라, 개선 활동 흉내 내기 대회가 된다.
반대로 AI로 지금 돌리는 루프는 꽤 투박하다.
실패한다.
원인을 본다.
다시 일어날 조건을 찾는다.
종료 조건이나 검사를 고친다.
다시 돌린다.
같은 실패가 정상 종료로 통과하지 않는지 확인한다.
발표 자료는 없다.
하지만 다음번 사람의 일은 줄어든다.
아이러니하게도, 이쪽이 QC의 “계속 개선한다”는 원형에 더 가깝다.
정신을 차려 보니 OpenAI의 Harness Engineering과 꽤 가까웠다
OpenAI는 2026년 2월, “Harness Engineering”이라는 글에서 Codex를 쓴 에이전트 중심 개발 방식을 공개했다.
그 글에서는 손으로 쓴 코드 0줄이라는 제약으로 내부 제품을 만들었고, 예전이라면 필요했을 시간의 약 10분의 1로 만들 수 있었다고 말한다.
중요한 것은 속도 자체가 아니다.
사람의 주된 일이 코드를 쓰는 것에서, 환경을 설계하고, 의도를 지정하고, 피드백 루프를 만드는 것으로 옮겨 갔다고 설명한 점이다.
또 OpenAI는 경계, 정확성, 재현성처럼 중요한 제약은 중앙에서 강제하고, 그 안에서 에이전트에게 큰 자유를 준다고 말한다.
이것은 꽤 가깝다.
“어떻게 구현할지”는 세세하게 말하지 않는다.
“여기는 반드시 지켜라”는 정한다.
실패하면 그 실패를 문서, 테스트, lint, 도구 규칙으로 남겨 다음번에 쓰게 한다.
나는 “귀찮으니 세세하게 보고 싶지 않다”였을 뿐인데, 결과적으로 에이전트가 스스로 달릴 수 있는 발판을 만드는 일이 되어 간다.
사상에서 출발한 것이 아니라, 게으름으로 같은 산을 오르고 있었다.
이건 조금 재미있다.
개인 프로젝트는 정치가 없는 독재국가다. 회사에서는 국회가 열린다
개인으로 하면 이 방식은 매우 강하다.
오너는 나다.
사용자도 나다.
평가자도 나다.
성공의 정의를 내리는 사람도 나다.
“카드 게임에서 이기고 싶다”라면 승률이 오르는지 본다.
“일을 줄이고 싶다”라면 사람이 끼어드는 일이 줄어드는지 본다.
목적 함수가 하나라서, AI가 내놓은 복잡한 구현도 마지막에는 쉬운 질문으로 돌아올 수 있다.
그래서 이길 수 있나?
그래서 내 일이 줄었나?
개인 프로젝트는 정치가 없는 독재국가다.
게다가 독재자가 게으르니, 관료 AI가 계속 자동화한다.
하지만 회사에서는 그렇게 쉽지 않다.
“공수를 줄이고 싶다”에 대해 현장 작업, 감사, 승인 권한, 기존 시스템, 책임, 평가, 부서의 존재 이유까지 다른 목적이 줄줄이 생긴다.
Harvard Business Review도 2025년 AI 도입론에서, 기업이 AI에서 가치를 얻지 못하는 장벽을 기술이 아니라 people, processes, and politics의 문제로 정리했다.
개인이라면 되어야 할 모습을 정한 뒤 AI에게 최적화시키면 된다.
회사에서는 되어야 할 모습을 정하는 것 자체가 협상이 된다.
게다가 전부 시시한 정치라고만 할 수도 없다.
책임 설명이나 감사를 위해 사람 승인을 남기는 것이 합리적인 경우도 있다.
반대로, 단지 권한이 줄어드는 것이 싫어서 승인을 남기고 싶은 경우도 있다.
AI가 보기에는 둘 다 “사람 승인이 필요하다”는 같은 제약으로 보인다.
그 제약이 정말 필요한지 정하는 것은, 마지막에는 사람 사회다.
마지막으로: 사람이 쥐는 것은 “목표”와 “현실”만으로 충분할지도 모른다
AI 시대에는 사람이 전부 생각하고, 전부 구현하고, 전부 확인할 필요가 점점 줄어들고 있다.
목표를 정한다.
AI에게 되어야 할 모습과 기준을 만들게 한다.
AI에게 구현하게 한다.
AI에게 검사하게 한다.
외부 증거로 맞춰 본다.
실패하면 그 실패를 다음번 규칙으로 바꾼다.
사람의 일이 남았다면, 그곳을 다음 개선 대상으로 삼는다.
이 루프가 돈다면, 사람이 세세한 구현을 알아야 할 필요는 꽤 줄어든다.
다만 끝까지 넘기기 어려운 것이 있다.
애초에 무엇을 이루고 싶은가.
그 목표는 현실과 맞는가.
그래서 결국에는,
사람: 목표를 정한다. 현실을 본다.
AI: 그 사이를 전부 메운다.
정도까지 역할이 나뉠지도 모른다.
개인으로 하면 꽤 편하다.
회사에서 하면 국회가 열린다.
역시 정치는 강하다.
