에이전트가 작업을 끝냈다고 보고했다. 테스트는 통과했다. 그런데 내가 실제로 눌러보는 화면에서는 원하는 결과가 보이지 않았다. 여기서 가장 빠른 대응은 보고 직전에 확인 단계를 하나 더 붙이는 것이다. 다음에도 잘못 말하면 새 확인 단계를 하나 더 붙이면 된다. 나는 한동안 이런 방식이 안전해지는 길이라고 생각했다.
문제는 확인 단계가 늘어나도 에이전트가 무엇을 완료라고 부르는지는 그대로였다는 점이다. 테스트 결과를 사용자 경험으로 바꿔 읽는 잘못된 기준을 고치지 않으면, 다음 작업에서 같은 오판이 다른 모습으로 돌아온다. 실수 뒤에 무엇을 더 세울 것인가보다, 어떤 생각을 바꿔야 하는가를 묻게 됐다.
1. 막는 장치는 곧 일을 이해하는 방식이 된다
여기서 가드란 에이전트가 행동하기 전에 자동으로 걸리는 실행 차단 장치다. 나쁜 값을 보면 실행을 멈추고, 사람의 확인을 요구하거나 실패로 돌린다. 잘 쓰면 손실을 막는다. 하지만 가드를 붙였다는 사실만으로 잘못된 판단 기준이 고쳐지지는 않는다.
예를 들어 에이전트가 메일 초안을 완성했다고 한다. 본문만 보면 그럴듯하지만, 받는 사람과 첨부가 원래 대화와 다를 수 있다. 이때 모든 메일 작업마다 새 확인 프로그램을 붙이기 전에, ‘확인 완료’라는 말의 뜻부터 바꿔야 한다. 원래 대화의 받는 사람, 참조, 제목, 첨부, 서명과 초안을 하나씩 대조하는 것이다. 작업을 더 복잡하게 만드는 대신, 작업의 끝을 다시 정의한다.
규칙이 여러 겹 쌓이면 에이전트는 서로 다른 말을 듣는다. ‘혼자 끝내라’와 ‘조금이라도 의심스러우면 물어라’가 함께 있으면, 애매한 작업은 모두 내게 돌아온다. 사람에게 묻는 행위가 안전하다는 이유로 조사를 건너뛴다. 결국 내 시간을 쓰면서도 원인은 그대로 남는다.
작은 실패마다 차단 장치를 하나씩 만들면 다음 작업은 먼저 장치가 요구하는 것을 맞추는 일이 된다. 결과가 맞는지보다 확인 표시를 얻는 데 집중하기 쉽다. 에이전트를 도와주려는 문장이 에이전트가 스스로 살펴볼 수 있는 자료까지 사람에게 되묻게 만들면, 1인 회사에서는 확인할 일만 늘어난다. 안전과 위임을 동시에 얻으려면 어디에서 사람의 선택이 정말 필요한지 더 좁게 말해야 한다.
2. 기록과 다짐은 수리가 아니다
8월 28일, 에이전트와 일하는 기준을 고치면서 이렇게 정했다. 문제가 생겼다면 어떻게 기록할지 묻기 전에 조사하고, 원인을 고치고, 실제 경로에서 확인한다. ‘다음엔 주의하겠다’는 일을 끝냈다는 문장이 아니다. ‘규칙을 하나 더 추가했다’도 마찬가지다.
내 에이전트에는 잘못된 완료 선언과 뒤늦게 드러난 사실을 따로 남기는 기록이 있다. 9월 28일까지 쌓인 항목을 직접 세어 보니, 이전 주장이 뒤집힌 일이 949건이었다. 그중 393건은 확인이 실제 사용자 경로보다 정적인 구조나 도구 출력에 쏠린 유형으로 분류된다. 이 숫자는 어떤 수정이 효과를 냈다는 증거가 아니다. 어디에서 잘못 생각하는 일이 자주 드러나는지 보여주는 분류일 뿐이다. 한 항목에 ‘고쳤다’고 적는 것과 다음 작업에서 실제로 덜 틀리는 것은 다르다.
‘완료’가 무엇인지 바꾼 문장은 훨씬 구체적이다. 에이전트가 만든 화면이라면 사용자가 여는 주소에서 확인한다. 통화라면 실제 녹음과 사용자가 겪은 흐름을 본다. 자동으로 실행될 일을 등록했다면, 등록됐다는 표시와 실제로 한 번 성공했다는 증거를 구분한다. 테스트나 빌드 도구가 띄우는 통과 표시는 진행 상황이지, 사람에게 닿은 결과가 아니다.
다만 이것도 ‘이제 무조건 사람에게 확인받아라’라는 뜻이 아니다. 조사할 수 있는 일은 에이전트가 먼저 조사해야 한다. 내가 말해야 하는 것은 되돌릴 수 없는 행동을 정말 실행해도 좋은지 같은 마지막 선택이다. 에이전트가 자료를 펼쳐보지도 않고 ‘어떻게 할까요?’라고 묻는 것은 신중함이 아니라 일을 되돌려 보내는 것이다.
3. 9월 3일, 가드를 붙이는 조건을 좁혔다
처음에는 재발을 발견할 때마다 새 차단 장치를 생각했다. 9월 3일에 그 방향을 다시 고쳤다. 새 가드는 기본 수리 수단이 아니다. 에이전트가 지켜야 할 문장이 분명하다면, 평범한 실수까지 실행 단계에서 한 번 더 검사할 이유는 약해진다고 봤다.
물론 예외가 있다. 고객에게 실제로 보내는 일, 중요한 데이터를 지우는 일, 비밀이 밖으로 새는 일, 운영 중인 서비스를 파괴할 수 있는 일처럼 되돌릴 수 없는 손실 앞에는 실행을 막는 장치가 필요하다. 이런 곳에서는 좋은 문장만으로 안전을 보장할 수 없다. 말로 ‘조심하라’고 써둔 것과 실행 자체가 멈추는 것은 다르다.
그 밖의 일에서는 먼저 가이드라인 문장을 의심한다. ‘확인하고 보고하라’는 무슨 화면에서 무엇을 확인하는지 빠져 있다. ‘메일을 검토하라’는 본문만 읽으면 되는 것처럼 보인다. ‘일정을 등록했다’는 실제로 한 번 작동했는지를 말하지 않는다. 막는 장치를 붙이기 전에, 빠진 대상을 문장 안에 넣는다.
4. 두 번째 재발에는 질문을 두 개만 한다
같은 종류의 문제가 두 번 나타났을 때 나는 바로 새 가드를 설계하지 않는다. 먼저 실패한 결과와 당시 에이전트가 실제로 읽은 지시를 나란히 놓는다. 그다음 아래 순서로 본다.
| 질문 | 발견하면 하는 일 | 확인할 것 |
|---|---|---|
| 지켜야 할 문장이 모호하거나 서로 부딪혔나? | ‘잘 확인해라’ 대신 무엇을 어디서 확인해야 끝인지 적고, 반대되는 지시는 하나로 정리한다. | 다른 자료를 다루는 다음 작업에서도 묻지 않고 적용하는가. |
| 문장은 분명한데 값·경로·작업의 약속이 틀렸나? | 오래된 주소, 잘못된 기본값, 틀린 데이터 연결을 원래 쓰이는 자리에서 고친다. | 같은 실제 사용 경로를 다시 밟아 결과가 바뀌었는가. |
첫 질문에 답이 나오면 더 많은 문장을 덧붙이는 게 아니라 기존 문장을 바꾼다. 한 군데서는 ‘끝났다’고 말하라 하고 다른 곳에서는 ‘확인될 때까지 기다려라’고 하면, 어느 쪽을 따를지 명확히 정한다. 둘째 질문에 답이 나오면 지시를 아무리 정교하게 써도 고장 난 값은 그대로다. 잘못된 주소를 참조하는 일을 막는 코드보다 주소 자체를 고치는 게 먼저다.
여기서 중요한 것은 새 문장이 길어지는가가 아니다. 다른 일을 시작할 때도 읽고 적용할 수 있을 만큼 분명해지는가다. ‘실제로 확인하라’는 말은 모든 일을 대충 포괄한다. ‘완료라고 보고하기 전, 사용자가 여는 화면에서 요청한 변화를 직접 보라’는 말은 에이전트가 손댈 대상과 확인할 장소를 함께 준다. 한 줄을 고치는 일은 작아 보여도, 다음 작업에서 무엇을 먼저 볼지 순서를 바꾼다.
그 뒤에는 원래 사례 하나만 다시 돌려보지 않는다. 같은 판단이 필요하지만 자료가 다른 작업에서, 에이전트가 내가 다시 설명하지 않아도 바뀐 기준을 적용하는지 본다. 다시 묻지 않고 해내는 장면이 없다면, 바꾼 것은 문서의 글자일 뿐일 수 있다.
5. 내 설정에 바로 적용하려면
지금 에이전트 설정에서 ‘주의’, ‘확인’, ‘필요하면 질문’이라고 적힌 문장 하나를 고른다. 그리고 최근의 실패 하나를 놓고 다음 순서로 읽는다.
- 에이전트가 실제로 받은 지시와 실제로 본 자료를 확인한다. 보고만 보고 원인을 추측하지 않는다.
- 지시가 모호했는지, 다른 지시와 충돌했는지 본다. 그렇다면 덧붙이지 말고 그 문장을 교체한다.
- 지시가 분명했다면 잘못된 값이나 연결이 없는지 본다. 발견하면 출발점에서 고친다.
- 한 번의 실수로 돌이킬 수 없는 손실이 나는 행동인지 분리한다. 그렇다면 사람의 최종 선택이나 실행 차단 장치를 둔다. 아니라면 새 가드를 만들 이유를 다시 묻는다.
- 실제 사용하는 길에서 수정 결과를 확인하고, 자료가 바뀐 다음 작업에서 같은 기준이 살아 있는지 본다.
한 번 고쳤다고 영원히 다시 안 틀린다는 주장은 못 한다. 나도 반복된 잘못된 완료 선언을 기록하고 있다. 다만 기록의 수나 가드의 수를 안전의 증거로 삼지 않기로 했다. 되돌릴 수 없는 행동 앞의 차단 장치는 그대로 둔다. 그 밖에서 실수가 돌아왔을 때는 에이전트가 멈추는 횟수를 늘리는 것보다, 같은 상황을 읽는 방법을 바꿔 다음 일을 혼자 제대로 끝내게 하는 것이 내가 원하는 수리다.