운영기록

하네스 엔지니어링을 내 AI 작업 시스템에 적용해 본 기록

이 글의 목차
  1. 도입 전에는 완료 보고가 너무 가벼웠다
  2. 내가 이해한 하네스는 작업을 묶는 장치다
  3. 프롬프트로 부탁하던 것을 통과 지점으로 옮겼다
  4. 내 시스템에 옮겨온 다섯 가지 하네스
  5. 첫 적용은 Markdown 파일 몇 개였다
  6. 블로그 운영에도 같은 방식을 붙였다
  7. 써보니 자유보다 경계가 더 중요했다
  8. 처음부터 자동화하지 않는 것도 하네스였다
  9. 검증은 작업 종류마다 달라야 했다
  10. 여러 에이전트는 결정권자가 아니었다
  11. 실패했을 때의 길도 설계에 포함했다
  12. 글쓰기에도 같은 기준이 필요했다
  13. 도입해 보니 남은 기준

스테이징에만 반영했다고 생각한 글이 운영 admin preview에서도 보였다. 공개 발행은 아니었다. draft: true 상태였고, 운영 공개 URL은 404가 나와야 했다. 그런데 그 사실을 말로만 확인하면 불안하다. 운영 admin에는 보이는지, 공개 URL에는 빠졌는지, D1 상태에는 published로 잡히지 않았는지 각각 확인해야 한다.

작은 혼선이었지만, 이런 순간이 쌓이면 AI에게 일을 맡기는 속도보다 확인하는 부담이 더 커진다. 내가 하네스를 붙이고 싶었던 이유도 거기에 있었다.

AI 에이전트와 같이 일하다 보면 처음에는 속도에 먼저 눈이 간다. 요약도 빠르고, 코드 수정도 빠르고, 배포 명령까지 정리해 준다. 그런데 이런 운영 작업에 붙여 보면 곧 다른 질문이 앞에 선다.

“정말 끝났는가?”

이 질문은 생각보다 까다롭다. 에이전트가 “완료했습니다”라고 말하는 것과 실제로 코드가 빌드되고, 초안이 공개 라우트에서 제외되고, 원하는 환경에 반영되고, 문제가 생겼을 때 어디까지 되돌리면 되는지를 아는 것은 전혀 다른 일이다. 말은 빠르게 끝나지만, 운영은 확인된 상태 위에서만 끝난다.

그래서 요즘 내 시스템에 하네스 엔지니어링 관점을 조금씩 넣고 있다. 여기서 말하는 하네스는 거창한 새 방법론이라기보다, 테스트 하네스처럼 작업을 붙잡아 두고 관찰 가능하게 만드는 장치에 가깝다. 모델의 지능을 더 끌어올리는 일보다, 모델이 일하는 환경을 어떻게 설계할지가 더 중요해지는 순간이 있었다. 에이전트가 더 똑똑하게 답하게 만드는 일이 아니라, 에이전트가 한 일을 더 잘 확인하고 이어받을 수 있게 만드는 일이다.

이 글은 하네스 엔지니어링을 이론으로 설명하려는 글이 아니다. 내 OpenClaw 운영 방식과 블로그 배포 흐름에 그 관점을 적용해 보면서 무엇을 파일로 남기고, 어떤 검증을 요구하고, 어디서 멈추게 했는지 정리한 사용기다.

도입 전에는 완료 보고가 너무 가벼웠다

사람이 혼자 코드를 고칠 때도 착각은 생긴다. 저장을 안 했거나, 테스트를 일부만 돌렸거나, 로컬에서는 되는데 배포 환경에서는 깨질 수 있다. AI 에이전트는 여기에 한 가지 문제가 더 붙는다. 대화를 그럴듯하게 마무리하는 능력이 좋기 때문에, 실제 확인이 부족해도 문장만 보면 다 끝난 것처럼 보일 수 있다.

예를 들어 블로그 글을 고치는 작업이라면 이런 식의 완료 보고는 충분하지 않다.

  • 글을 수정했습니다.
  • 빌드가 될 것 같습니다.
  • 배포하면 반영됩니다.
  • 화면도 문제없어 보입니다.

여기에는 확인 가능한 것이 거의 없다. 어떤 파일을 고쳤는지, 실제 빌드를 돌렸는지, 스테이징에서 확인했는지, 운영 배포와 어떤 관계인지 알 수 없다. 다음 사람이 이어받아도 같은 판단을 처음부터 반복해야 한다. 완료 보고처럼 보이지만, 사실은 새로 확인해야 할 목록에 가깝다.

하네스 엔지니어링을 내 시스템에 넣어 보려 한 이유도 여기에 있다. 답변을 더 길게 받기 위해서가 아니라, 작업이 끝났다는 말을 검증 가능한 상태로 바꾸고 싶었다.

처음부터 이렇게 정리되어 있던 것은 아니다. 초반에는 에이전트가 빠르게 처리한 일을 내가 다시 하나씩 확인해야 했고, 배포 대상이 스테이징인지 운영인지, 초안이 공개 URL에 걸렸는지 같은 질문이 자주 남았다. 하네스 엔지니어링을 들여온 뒤 달라진 점은 에이전트가 갑자기 완벽해졌다는 것이 아니라, 불안한 지점이 파일과 검증 항목으로 보이기 시작했다는 것이다.

내가 이해한 하네스는 작업을 묶는 장치다

내가 받아들인 하네스 엔지니어링의 핵심은 “에이전트를 믿지 말자”가 아니다. 오히려 에이전트를 더 많이 쓰기 위해 필요한 운영 장치에 가깝다.

작업에 하네스를 붙인다는 것은 대략 이런 뜻이다.

  • 작업의 범위를 파일이나 문서로 고정한다.
  • 현재 상태와 다음 액션을 남긴다.
  • 검증 명령과 결과를 완료 보고에 붙인다.
  • 배포 대상과 공개 영향을 분리해서 본다.
  • 실패했을 때 돌아갈 지점을 기록한다.

이렇게 해 두면 에이전트가 빠르게 움직여도 사람이 다시 확인할 수 있다. 작업이 길어지거나 세션이 바뀌어도 마지막으로 확인된 지점으로 돌아올 수 있다. 하네스는 속도를 줄이는 장치가 아니라, 속도가 났을 때 작업이 궤도 밖으로 나가지 않게 해 주는 장치에 가깝다.

프롬프트로 부탁하던 것을 통과 지점으로 옮겼다

하네스를 적용하기 전에는 좋은 지시를 더 자세히 쓰는 쪽으로 문제를 풀려고 했다. “운영 배포 전에는 꼭 확인해”, “초안은 공개하지 마”, “검증 결과를 남겨” 같은 문장을 프롬프트나 작업 지시에 넣는 방식이다.

이 방식이 쓸모없다는 뜻은 아니다. 대부분의 작은 작업에서는 충분히 도움이 된다. 하지만 운영 작업에서는 부탁만으로는 부족했다. 에이전트가 지시를 이해했는지보다, 지시를 어겼을 때 작업이 그냥 지나가지 못하는지가 더 중요했다.

그래서 기준을 문장 밖으로 빼기 시작했다. 모든 것을 한 번에 막는 거대한 장치를 만든 것은 아니다. 자주 흔들리는 지점부터 통과 지점으로 바꿨다.

  • “작업 상태를 기억해”가 아니라 TASK_STATE.md에 현재 상태와 다음 액션을 남긴다.
  • “완료 기준을 지켜”가 아니라 COMPLETION_CRITERIA.md에 작업 종류별 증거를 둔다.
  • “검증했는지 말해줘”가 아니라 build, URL check, UI screenshot 결과를 완료 보고에 붙인다.
  • “운영 배포 조심해”가 아니라 deploy script가 브랜치, clean tree, origin/main 일치, 확인 env, 배포 기록을 요구하게 한다.

이 변화가 내게는 하네스 엔지니어링의 핵심에 가까웠다. 에이전트를 옭아매려는 것이 아니라, 마음 놓고 더 많은 일을 맡기기 위해 필요한 손잡이를 붙이는 일이다. 문장으로 설득하는 대신, 다음 단계로 넘어가기 위한 통과 지점을 둔다.

이렇게 바꾸면 완료 보고의 모양도 달라진다.

Before
- 초안 퇴고 완료
- 운영에 반영됨
- 문제 없어 보임

After
- Commit: `502edde`
- Production Version ID: `1d59cd89-1e90-46e4-b7a2-6c6dcb2aa570`
- `draft: true` 유지
- 공개 URL 404 확인
- admin preview Access 302 확인
- `verify-production.sh` 통과
- `verify:ui` 통과

둘 다 “끝났다”는 말을 할 수 있다. 하지만 뒤쪽은 다음 사람이 이어받을 수 있고, 문제가 생기면 어디를 먼저 봐야 하는지도 보인다. 하네스가 만든 차이는 답변의 자신감이 아니라 답변 뒤에 남는 증거였다.

내 시스템에 옮겨온 다섯 가지 하네스

Claude Code Harness 같은 흐름을 보면서 가장 유용했던 것은 특정 도구 이름보다 분류 방식이었다. 에이전트가 잘 일하려면 좋은 프롬프트 하나가 아니라, 맥락, 권한, 검증, 세션, 협업 구조가 같이 필요하다는 관점이다. 나는 이 분류를 그대로 가져오기보다 OpenClaw와 블로그 운영에 맞게 바꿔서 보고 있다.

첫째는 context harness다. 에이전트에게 모든 것을 한꺼번에 읽히지 않고, 지금 작업에 필요한 파일과 상태를 먼저 잡아 준다. 블로그 글을 고칠 때는 해당 Markdown, 배포 기록, status snapshot, 관련 스크립트 정도가 핵심이다. 대화가 길어질수록 기억에 기대기보다 TASK_STATE.md나 작업 요약을 기준으로 다시 출발하게 하는 것도 이 범주에 들어간다.

둘째는 permission harness다. 에이전트가 할 수 있는 일과 멈춰야 하는 일을 나눈다. 로컬 초안 수정, 파일 읽기, 빌드 같은 일은 비교적 자유롭게 맡긴다. 반대로 운영 배포, 외부 공개, 권한 변경, 비용이 발생하는 일은 승인이나 명시적인 확인 지점을 둔다. 이것은 에이전트를 못 믿어서가 아니라, 운영 작업에서 원래 분리해야 하는 경계를 에이전트에게도 똑같이 적용하는 일이다.

셋째는 verification harness다. 완료 보고를 말이 아니라 검증 결과로 바꾸는 부분이다. 코드면 테스트나 빌드, UI면 스크린샷, 배포면 실제 URL과 배포 버전, 초안이면 공개 라우트 제외 여부를 확인한다. 이 글을 운영 admin preview에 반영할 때도 draft: true, 공개 URL 404, admin preview Access 보호, D1 status row를 따로 봤다.

넷째는 session hygiene이다. 에이전트와 오래 대화할수록 맥락은 많아지지만 판단은 흐려질 수 있다. 그래서 길어진 작업은 상태 파일, manifest, 배포 로그, 요약으로 남긴다. 다음 세션이 이전 대화를 전부 다시 읽지 않아도 어디까지 확인됐는지 알 수 있어야 한다. 세션을 오래 붙잡는 것보다, 이어받을 수 있는 상태로 자주 정리하는 쪽이 안정적이었다.

다섯째는 multi-agent harness다. GeminiBot이나 CodexBot을 붙인다고 해서 결정권을 넘기는 것은 아니다. 한쪽은 외부 자료와 글의 논지를 보고, 다른 쪽은 코드 구조나 변경 리스크를 볼 수 있다. 하지만 마지막에는 어떤 의견을 받아들였고, 무엇을 보류했으며, 실제 검증은 무엇으로 했는지를 OpenClaw가 종합해야 한다. 여러 에이전트는 책임을 나누기 위한 장치가 아니라, 판단 입력을 늘리기 위한 장치다.

이 다섯 가지를 갖추면 에이전트에게 더 큰 자유를 줄 수 있다. 중요한 것은 자유를 줄이는 것이 아니라, 자유가 운영 사고로 이어지지 않도록 작업대의 모서리를 세워 두는 일이다. 내가 하네스 엔지니어링에서 가져온 것도 바로 이 감각이었다.

첫 적용은 Markdown 파일 몇 개였다

처음부터 복잡한 시스템을 만든 것은 아니다. 실제로는 몇 개의 Markdown 파일을 두고, 에이전트가 작업할 때 그 파일들을 기준으로 삼게 했다. 중요한 것은 파일 이름 자체가 아니라, 대화가 끝난 뒤에도 남는 판단 기준과 검증 흔적이다.

작업 상태는 TASK_STATE.md처럼 한눈에 읽히는 파일에 둔다.

task-id — Goal: short outcome. Status: active | waiting | blocked | done.
Owner: OpenClaw | CodexBot | GeminiBot | mixed.
Next: one concrete action.
Verification: command, screenshot, log, review, or pending.

이 파일은 긴 대화를 다시 읽지 않아도 현재 작업이 살아 있는지, 막혔는지, 끝났는지 알려준다. 에이전트 입장에서도 “어디까지 했더라”를 추측하지 않고, 상태 파일을 기준으로 다음 행동을 고를 수 있다.

내가 이 파일을 좋게 보는 이유는 멋진 문서라서가 아니다. 작업이 흔들릴 때 블랙박스처럼 남아 있기 때문이다. 언제 멈췄는지, 무엇을 확인했는지, 다음에 어디서 이어가야 하는지를 대화 기억이 아니라 파일에서 바로 확인할 수 있다.

완료 보고의 기준은 COMPLETION_CRITERIA.md에 따로 둔다. 여기에는 작업 종류별로 어떤 증거가 필요한지 적어 둔다.

- Code change: changed files summary plus targeted test, lint/typecheck/build.
- UI change: desktop/mobile verification and screenshot checks.
- Deployment: target, deploy result, service health check, and key URL check.

이 문서를 둔 뒤부터는 “완료”라는 말이 조금 덜 헐거워졌다. 코드 작업이면 테스트나 빌드가 붙어야 하고, UI 작업이면 화면 확인이 따라와야 하며, 배포 작업이면 실제 URL과 배포 버전이 남아야 한다.

증거가 많아지는 작업은 templates/task-evidence-manifest.md 같은 manifest로 빼기도 한다.

| Check | Command or Source | Result | Artifact |
| --- | --- | --- | --- |
| Build | `npm run build` | passed | n/a |
| UI screenshot | `npm run verify:ui` | passed | `.playwright-checks/...` |

처음에는 이런 표가 과해 보일 수 있다. 하지만 작업이 커질수록 “무엇을 봤는가”와 “어디에 결과가 남았는가”를 같은 줄에 묶어 두는 것이 훨씬 편하다. 특히 하루 뒤에 다시 보면 대화보다 manifest가 훨씬 빠르다.

블로그 운영에도 같은 방식을 붙였다

이 블로그 작업에도 같은 방식을 적용했다. 글을 쓰고 고치는 일은 단순한 문서 작업처럼 보이지만, 실제로는 스테이징, 운영 admin preview, 공개 발행, 검색 색인, RSS, 댓글과 연결된다. 그래서 글 하나를 고칠 때도 “어디에 보이는가”를 분리해서 봐야 했다.

예를 들어 이 글은 한동안 draft: true 상태로 운영 admin preview에는 보이지만, 공개 URL에서는 404가 나와야 했다. 이때 필요한 확인은 “배포했다”가 아니라 다음에 가깝다.

  • frontmatter의 draft: true가 유지됐는가
  • production build에서 공개 /blog/... 라우트가 제외됐는가
  • admin preview는 생성됐는가
  • 운영 공개 URL은 실제로 404인가
  • 운영 D1 상태에 published row가 생기지 않았는가
  • Cloudflare Worker 배포 Version ID가 남았는가

이런 배포 기록은 docs/DEPLOYMENT_LOG.md에 남긴다.

### 2026-05-30 production

- Commit: `7545871`
- Version ID: `05b306c6-6194-4256-bdcf-53fd26aa2d2c`
- 내용: 확인 가능한 에이전트 운영 초안 퇴고본 admin preview 반영
- 확인: production build; draft:true confirmed; public blog route excluded

운영 배포 자체도 스크립트 안에 몇 가지 관문을 넣었다. production deploy는 main에서만 실행되고, worktree가 깨끗해야 하며, HEAD가 origin/main과 같아야 한다. DEPLOY_PRODUCTION_CONFIRM이 맞지 않으면 멈추고, 기본 정책에서는 DEPLOY_RECORD_SUMMARY가 없으면 배포 기록 없이 지나가지 못한다. 배포 뒤에는 scripts/verify-production.sh와 npm run verify:ui로 실제 운영 상태를 다시 본다.

이런 장치가 있으면 “운영 배포 조심해”라는 문장을 매번 반복하지 않아도 된다. 조심해야 하는 부분이 스크립트와 기록 형식 안에 들어가 있기 때문이다. 에이전트가 배포를 돕더라도, 운영에 닿는 순간에는 같은 관문을 통과해야 한다.

조금 더 큰 작업은 docs/work-manifests/ 아래에 작업 단위 문서로 남긴다. 여기에는 바뀐 표면, 검증, 배포 여부, 남은 리스크를 한 번에 적는다.

## Changed Surface
- Files: deploy scripts, workflow, UI verification script, operations docs.

## Verification
- Build: `npm run build:staging` passed; `npm run build` passed.
- UI screenshots: Playwright verification passed.

## Follow-Up
- Residual risk: workflow syntax should be validated before relying on it.

이런 파일들은 완벽한 프로세스 문서라기보다 작업을 이어받기 위한 손잡이에 가깝다. 대화는 길어지면 흐려지지만, 파일은 다음 세션에서도 같은 위치에 남는다. 그래서 에이전트에게 “기억해 둬”라고 말하는 대신, 실제 md 파일에 상태와 검증을 남기게 하는 쪽이 더 안정적이다.

써보니 자유보다 경계가 더 중요했다

하네스를 붙이고 나서 가장 크게 달라진 것은 에이전트에게 주는 자유의 양이 아니라 경계의 선명도였다.

예를 들어 로컬 파일을 읽고 초안을 만드는 일은 비교적 자유롭게 맡길 수 있다. 되돌리기 쉽고, 공개 영향도 없다. 반대로 운영 배포, 권한 변경, 외부 공개, 비용이 발생하는 작업은 바로 실행하지 않고 승인 지점을 둔다. 단순한 코드 수정도 운영 화면에 영향을 주면 최소한 빌드와 화면 확인을 거친다.

이 기준은 AI를 못 믿어서라기보다, 운영 작업 자체가 원래 그렇게 해야 하는 일이기 때문이다. 사람에게 맡겨도 배포 전에는 빌드하고, 권한 변경 전에는 영향 범위를 확인하고, 민감한 정보는 외부로 보내지 않는다. AI와 일할 때도 같은 기준이 필요하다.

오히려 에이전트는 경계가 명확할수록 더 쓸모 있어진다. 어디까지 스스로 처리해도 되는지, 어디서 멈춰야 하는지, 어떤 증거를 남겨야 하는지가 분명하면 작업이 안정적으로 반복된다. 사람은 매번 같은 판단을 다시 설명하지 않아도 되고, 에이전트는 불필요하게 멈추거나 위험하게 앞서 나가지 않아도 된다.

처음부터 자동화하지 않는 것도 하네스였다

하네스 엔지니어링을 도입한다고 해서 모든 작업을 바로 자동화해야 하는 것은 아니었다. 오히려 처음부터 자동화하려고 하면 기준이 덜 잡힌 상태에서 이상한 절차만 단단해질 수 있다.

그래서 반복 작업을 볼 때 성숙도를 나눠서 본다.

  • 한두 번 하는 일은 수동 체크리스트로 충분하다.
  • 같은 순서가 반복되면 실행 가이드로 문서화한다.
  • 명령이 거의 고정되면 스크립트로 만든다.
  • 실패하면 안 되는 검증은 자동화 게이트로 올린다.

이 순서가 중요한 이유는 기준이 먼저 생기고 자동화가 따라와야 하기 때문이다. 아직 판단 기준이 흐린 작업을 바로 스크립트로 만들면, 사람이 봐야 할 결정을 기계적으로 통과시키게 된다. 반대로 몇 번 반복하면서 “항상 보는 항목”과 “가끔만 필요한 판단”이 나뉘면, 자동화할 부분도 자연스럽게 보인다.

반복되는 실패도 같은 방식으로 본다. 같은 실수가 두세 번 나오면 그건 단순 실수가 아니라 운영 기준이 비어 있다는 신호다. 그때는 에이전트를 탓하기보다 체크리스트, 문서, 스크립트, 작업 지시 중 어디에 기준을 남겨야 할지 보는 편이 낫다. 자동화는 반복을 줄이는 도구이기도 하지만, 반복에서 배운 기준을 고정하는 방식이기도 하다.

검증은 작업 종류마다 달라야 했다

모든 작업에 같은 검증을 붙일 필요는 없다. 글 초안 하나를 고치는데 매번 복잡한 배포 절차를 돌리는 것은 과하다. 반대로 UI 레이아웃을 바꾸고도 빌드만 보고 끝내는 것은 부족하다.

내 시스템에서는 작업마다 증거의 무게를 다르게 둔다.

  • 문서 작업: 파일 변경 내용, 맞춤법·톤, 민감 정보 여부
  • 코드 작업: 테스트, 타입체크, 빌드, 변경 범위
  • UI 작업: 빌드, 스크린샷, 모바일/데스크톱 확인
  • 배포 작업: 대상 브랜치, 배포 로그, 실제 URL 확인
  • 자동화 작업: 실행 조건, 실패 알림, 중복 실행 방지

핵심은 “검증을 했다”가 아니라 “그 작업에 맞는 검증을 했다”이다. 증거의 양보다 중요한 것은 증거와 위험의 비례다.

여러 에이전트는 결정권자가 아니었다

여러 에이전트를 같이 쓰면 꽤 유용하다. 하나는 코드 구조를 보고, 하나는 글의 논지를 보고, 다른 하나는 외부 자료를 찾을 수 있다. 하지만 도우미 에이전트의 답을 그대로 최종 판단으로 삼으면 안 된다.

리뷰 역할의 에이전트는 관점을 늘려 주는 역할에 가깝다. 최종 결정은 작업을 조율하는 쪽에서 해야 한다. 어떤 의견을 받아들였는지, 어떤 의견은 왜 보류했는지, 실제 결과가 검증됐는지를 정리해야 한다.

이 과정을 대충 넘기면 에이전트가 많아질수록 오히려 책임 소재가 흐려진다. A는 괜찮다고 했고, B는 다른 얘기를 했고, C는 아직 답을 안 했는데 작업은 끝났다는 식이 된다.

그래서 여러 에이전트를 쓸 때는 마지막에 반드시 한 번 정리한다.

  • 받아들인 의견
  • 받아들이지 않은 의견
  • 추가로 확인한 내용
  • 남은 리스크
  • 최종 판단

이 정리가 있어야 협업이 된다. 그렇지 않으면 그냥 대화가 늘어날 뿐이다. 에이전트가 많아질수록 필요한 것은 더 많은 답변이 아니라 더 분명한 종합이다.

실패했을 때의 길도 설계에 포함했다

좋은 자동화는 성공할 때만 빠른 것이 아니다. 실패했을 때 어디서 멈추고, 무엇을 확인하고, 어떻게 복구할지까지 정해져 있어야 한다.

AI 에이전트 작업도 마찬가지다. 명령이 두 번 실패했는데 같은 방식으로 세 번째를 시도하면 안 된다. 실패가 반복되면 잠깐 멈춰서 원인을 봐야 한다. 환경 문제인지, 명령이 잘못됐는지, 전제가 틀렸는지, 권한이나 네트워크 문제인지 나눠야 한다.

운영 작업에서는 특히 복구 기준이 중요하다.

  • 어떤 커밋으로 되돌릴 수 있는가
  • 어떤 배포 버전이 마지막 정상 상태인가
  • 어떤 파일이 기록용 변경이고 어떤 파일이 실제 기능 변경인가
  • 실패 알림은 어디로 가는가
  • 공개 사용자에게 영향이 있는가

복구 경로가 없으면 작은 작업도 부담스러워진다. 반대로 되돌릴 수 있는 지점이 명확하면 AI에게 맡길 수 있는 범위가 넓어진다. 이것도 하네스의 일부라고 느꼈다. 성공한 길만 남기는 것이 아니라, 실패했을 때 돌아올 길까지 작업 안에 포함하는 것이다.

글쓰기에도 같은 기준이 필요했다

이 기준은 코드나 배포에만 필요한 것이 아니었다. 블로그 글을 쓸 때도 비슷하게 적용됐다.

AI가 초안을 써줄 수는 있다. 하지만 그 초안이 내 경험에 맞는지, 공개해도 되는 정보만 담았는지, 과장된 표현이 없는지, 실제로 확인한 사실과 추측이 섞이지 않았는지는 따로 봐야 한다.

특히 개인 운영기록은 그럴듯한 일반론으로 흐르기 쉽다. “AI 시대에는 효율이 중요하다” 같은 문장은 틀리지는 않지만, 내 블로그에 꼭 남길 만한 문장은 아니다. 내가 실제로 겪은 문제, 바꾼 기준, 다음에 반복하지 않기 위해 남기는 체크가 있어야 한다.

그래서 글쓰기에서도 확인 기준이 필요하다.

  • 실제로 겪은 사건에서 출발했는가
  • 확인한 사실과 생각을 구분했는가
  • 민감한 내부 정보를 덜어냈는가
  • 독자가 자기 작업에 가져갈 기준이 있는가
  • 나중에 내가 다시 봐도 운영 기록으로 쓸모 있는가

글도 결국 하나의 작업 결과물이다. 초안이 만들어졌다는 말보다, 왜 이 글을 지금 쓰는지와 무엇을 남기려는지가 더 중요하다. 퇴고는 문장을 예쁘게 만드는 일만이 아니라, 공개해도 되는 주장과 남길 가치가 있는 경험을 가려내는 과정이다.

도입해 보니 남은 기준

하네스 엔지니어링 관점을 내 시스템에 적용해 보니, AI 협업에서 내가 기대하는 모양이 조금 더 분명해졌다. 완벽한 자동 조종을 바라는 것이 아니다. 작은 작업은 안정적으로 맡기고, 큰 작업은 확인 가능한 단계로 쪼개고, 공개 영향이 있는 일은 승인과 검증을 거치는 흐름을 원한다.

에이전트가 빠르게 움직이되, 중요한 지점에서는 멈출 줄 알아야 한다. 완료를 말로 꾸미기보다 증거를 남겨야 한다. 실패하면 숨기지 않고, 어디까지 확인했고 무엇이 남았는지 말해야 한다.

물론 아직은 매끄럽지 않다. 어떤 검증은 과하고, 어떤 기록은 부족하고, 어떤 작업은 여전히 사람이 직접 봐야 한다. 그래도 기준은 분명해졌다.

AI 작업에서는 말보다 증거를 믿는다. 하네스 엔지니어링을 내 시스템에 들여온 뒤 가장 크게 바뀐 것은 에이전트의 답변이 아니라, 답변 뒤에 남는 작업의 형태였다. 답변은 사라져도, 상태와 증거는 다음 작업의 출발점으로 남는다.

댓글

불러오는 중