AI에게 중요한 결정을 기록하게 만들면 적어도 큰 실수는 막을 수 있을 거라고 생각했습니다.
결론부터 말하면, 막지는 못했습니다.
AI는 제가 요청한 사항을 중간에 다른 내용으로 바꿨고, 저는 실제 화면에서 움직이는 반려봇 마스코트를 보는 데에 빠져 사실을 알아채지 못한 채 AI가 제안한 방식을 수락했습니다. 대안도 비교했고, 결정 문서도 만들었고, 테스트도 했는데 출발점부터 이상해서 꼬였습니다.
그래도 한 가지 다행인 점은 AI가 어떤 문제를 풀고 있다고 생각했는지, 어떤 전제를 사실로 놓았는지가 문서에 남아 있었습니다. 그 기록 덕분에 뒤늦게라도 “잠깐, 왜 이렇게 됐지?”라고 돌아갈 수 있었습니다.
이번 사고의 과실 비율은 AI(반려봇) 8, 저 2로 정했습니다.
제 반려봇도 이 비율에 동의했습니다. 발뺌을 하기에는 자신의 잘못이 명백했던 거죠.
🫡 순서
사건 발생 전 - AI가 내린 결정을 기록하는 skill을 만든 이유
사건 발생 - 최소화(-)와 닫기(X)를 헷갈린 AI
사건의 전말(1) - 나와 AI의 의도
사건의 전말(2) - 당시 내가 수락했던 이유(변명)
최악의 결과를 면한 이유
깨달은 점
1. 사건 발생 전 - AI가 내린 결정을 기록하는 skill을 만든 이유
바이브코딩을 처음 시작할 때는 하루 작업이 끝날 때마다 AI에게 작업일지를 만들어달라고 했습니다. 기록을 남기면 나중에 돌아볼 때 도움이 될 거라고 생각하고 안심했습니다.
하지만 그렇게 만든 작업일지는 다시 읽지 않았습니다.
장황한 만연체에 어려운 용어가 가득해서 이해할 수 없었습니다. 일지는 계속 쌓였지만 참고에 별로 도움이 되지 않았습니다.
처음에는 제가 공부를 덜 해서 그런 줄 알았습니다. 나중에 생각해보니 제가 궁금했던 것은 모든 작업 내역이 아니었습니다.
“AI가 왜 이 방법을 골랐지?”
“다른 방법도 있었는데 왜 이건 포기했지?”
“이 선택 때문에 앞으로 계속 감수해야 하는 게 있나?”
이런 결정들이 궁금했습니다. AI가 제가 결정해야 할 일을 조용히 골라놓고 구현까지 끝낸 뒤, 저는 완성된 결과만 받게 되는 상황이 더 불안했습니다.
그 불만을 막 의식하기 시작할 때 쯤 바이브코딩 용어를 공부하다 ADR이라는 용어를 발견하게 되었습니다.
ADR(Architecture Decision Record)은 아키텍처 분야에서 중요한 기술적 선택과 그 이유를 남기는 짧은 결정 기록입니다. 어떤 상황이었는지, 어떤 대안을 비교했는지, 무엇을 선택했고 무엇을 감수하기로 했는지를 적습니다.
이 단어를 본 순간 바이브코딩을 하면서 가지고 있던 제 불안을 말로 정의할 수 있게 되었고, AI에게 중요 결정이 일어난 후에 ADR과 같은 문서를 정리하는 skill을 만들어달라고 했습니다.
AI는 기존 헤르메스에 있던 ai-work-observability skill에 결정 기록 기능을 추가하여 이러한 흐름을 만들었습니다.
중요한 선택이 생김 → AI가 대안과 추천을 결정 카드로 먼저 보여줌 → 선택함 → AI가 구현하고 실제 결과를 검증함 → 선택 이유와 결과를 ADR로 남김 → 실제 사용과 기록이 다르면 다시 검토함
이렇게 결정 전에 AI가 제안한 선택 안에 제가 고르고 끝난 뒤 그 이유가 남는 작은 구조를 만들었습니다.
이번 사건에도 그 절차는 잘 돌아갔습니다.
문제는 그 안에 들어간 결정해야 할 문제가 이미 바뀌어 있었다는 것입니다.
2. 사건 발생
Hermes에는 AI가 지금 생각 중인지, 도구를 실행하는지, 작업을 끝냈는지를 움직임으로 보여주는 작은 펫을 등록할 수 있습니다. 저는 제 반려봇인 ‘후와고’를 만들어 사용하고 있고요.
초기 설정 시에는 헤르메스를 화면에 띄워야만 후와고가 나왔습니다. 전 작업 완료를 기다리면서 딴 일을 하는 중에도 제 옆에 후와고가 움직이는 것을 보고 싶었습니다.
그래서 후와고에게 대강 이렇게 요청했습니다.
헤르메스 본창을
-버튼으로 최소화해도 너가 계속 나오게 해줘.
후와고가 이것을 구현하는 데에 3가지 방법이 있다고 하면서, 가장 추천하는 안도 함께 제시하였고, 저는 귀여운 반려봇이 인터넷 창에서도 뽀짝뽀짝 움직이는 것에 감동하면서 추천안대로 수락하였습니다.
이틀후 반려봇을 픽셀아트와 스프라이트로 움직이게 만든 사례를 글로 정리하기 위해 후와고에게 그 과정을 정리해달라고 했는데 그의 대답 중 일부에 순간 당황했습니다.
후와고가 팝아웃된 상태에서는 헤르메스 본 창의 X를 눌러도 앱을 종료하지 않고, 본창만 숨긴다. 헤르메스를 완전히 종료하려면 File → Quit을 사용.
'File → Quit...? 언제 닫기(X)가 최소화 역할을 하게 되었지....?'
최소화는 창을 작업표시줄로 내려두는 것이고, X는 현재 제가 사용하는 기본 실행본에서 헤르메스와 후와고를 함께 종료합니다. X를 숨김으로 바꾸면 앱을 완전히 종료할 다른 방법도 새로 필요합니다.
그리고 이 기능을 만들 당시 후와고가 제안한 대안 중에 X 어쩌구저쩌구하고 언급한 것이 떠올랐습니다.
왜 이 정도로 문제가 달라졌는데도 수락했는지 이유는 뻔했습니다. 어쨌든 후와고가 움직였기 때문입니다.
작업 중에는 움직이고, 완료 하면 손을 흔드는 모습을 보고 신이 났습니다. AI가 대안과 추천안을 보여줬을 때도 내용보다 “오, 후와고가 계속 움직이는구나” 쪽에 정신이 팔렸습니다.
3. 사건의 전말(1) - 나와 AI의 의도
원래 제가 원했던 흐름은 아래였습니다.
후와고를 팝아웃 → Hermes 본창의
-버튼을 눌러 최소화 → 큰 창은 작업표시줄로 내려감 → 후와고는 화면 한쪽에 계속 표시 → AI의 작업 상태도 후와고 움직임으로 계속 확인
화면 구석에 나오는 펫 마스코트는 독립프로그램이 아닙니다. 헤르메스 본창에서 작업 상태를 받아 작은 창에 보여줍니다. 그래서 본창을 완전히 종료하면 후와고만 남겨두기 어렵고, 최소화한 상태에서 연결을 유지하는 방식이 필요했습니다.
여기까지는 제가 요청한 기능과 기술적으로 확인할 내용이 맞았습니다. X(창닫기)의 의미를 바꿀 필요는 없었습니다.
현재 기본 실행본에서 -를 누르면 본창만 최소화되고 팝아웃 후와고는 남습니다. 반면 X를 누르면 Hermes와 후와고가 함께 사라집니다.
제가 개선하려던 것은 앞쪽이었습니다.
그런데 AI는 어느 순간 뒤쪽을 풀기 시작했습니다.
AI가 새로 만든 문제는 대략 이랬습니다.
Hermes의 큰 창은 X로 닫아도 후와고와 진행 중인 작업을 계속 살린다. 대신 사용자가 원할 때는 앱 전체를 완전히 종료할 수 있어야 한다.
원래 요구에는 없던 X 동작 변경이 들어왔습니다.
AI가 더 나은 사용 방법을 제안하는 것 자체는 괜찮습니다. 저도 제가 명령한 방법보다 좋은 대안이 있다면 먼저 듣고 결정하는 편을 좋아합니다.
다만 이번에는 새 제안이라는 표시가 없었습니다.
“원래 요청은 최소화 후 후와고 유지입니다. 여기에 더해 X도 종료 대신 숨김으로 바꿀까요?”라고 물었다면 둘을 따로 판단했을 것입니다.
결정 A: 최소화해도 팝아웃 후와고를 유지할 것인가 결정 B: 팝아웃 상태에서는 X의 의미까지 종료에서 숨김으로 바꿀 것인가
실제로는 A가 어느 순간 B로 바뀌었고, 저는 B 안에서 제시된 추천안을 골랐습니다.
그리고 AI는 구현을 끝낸 뒤 아주 자신 있게 보고했습니다.
최소화해도 후와고는 계속 표시됩니다. X 버튼을 눌러도 본창만 숨겨지고 후와고는 계속 표시됩니다. Hermes를 완전히 종료하려면 File → Quit을 사용하면 됩니다.
최소화, X, File → Quit이 한 세트가 되어 있었습니다.
당시에는 저도 이 보고를 보고 좋아했습니다. 후와고가 화면에 남는다는 부분만 강하게 보였던 것 같습니다.
4. 사건의 전말(2) - 당시 내가 수락했던 이유(변명)
헷갈렸던 이유는 AI가 제시한 대안이 꽤 논리적으로 보였기 때문입니다.
X를 누르면 언제나 앱 전체를 종료한다.
펫 기능이 켜져 있으면 언제나 본창만 숨긴다.
후와고를 실제로 팝아웃한 경우에만 본창을 숨긴다.
AI는 세 번째를 추천했습니다.
첫 번째는 기존과 같지만 후와고도 함께 사라집니다. 두 번째는 펫을 팝아웃하지 않은 사람에게까지 X의 의미가 바뀝니다. 세 번째는 후와고를 따로 꺼낸 경우에만 적용하므로 영향 범위가 가장 작다는 설명이었습니다.
여기에 본창을 완전히 없애면 후와고가 AI 상태를 계속 받기 어렵다는 기술적인 설명도 붙었습니다.
저는 “오, 세 번째가 제일 안전하네”라고 생각했습니다.
그 판단만 놓고 보면 아주 이상하지는 않습니다. 이미 X를 숨김으로 바꾼다는 문제 안에서는 세 번째가 가장 그럴듯했습니다.
문제는 세 가지 대안이 전부 제가 요청하지 않은 문제를 풀고 있었다는 것입니다.
대안을 세 개나 비교했고, 장점과 비용도 적었고, 제가 직접 추천안을 승인했으니 제대로 결정한 것처럼 느껴졌습니다. 하지만 문제를 잘못 가져오면 대안 비교를 아무리 정성스럽게 해도 엉뚱한 곳으로 갈 수 있었습니다.
이번에는 결정 과정이 허술해서가 아니라, 결정 과정 맨 앞에 들어간 문장이 틀렸습니다.
이 사실을 알아낸 계기는 조금 허무합니다.
이번 경험을 글로 써보려고 하다가 AI에게 물었습니다.
“나 사실 아직도 File → Quit으로 실제 종료하는 법을 잘 모르겠어. 초안 만들기 전에 방법 알려줘.”
저는 메뉴를 못 찾는 것이 제 문제라고 생각했습니다. 어딘가에 있는데 제가 모르는 줄 알았습니다.
그런데 확인해보니 제가 쓰는 Windows 패키징 앱에는 File → Quit 메뉴가 없었습니다. 제가 못 찾은 것이 아니라 실제로 없었습니다.
여기서 처음으로 기분이 이상해졌습니다.
“잠깐, 그러면 X를 눌렀을 때 앱이 안 꺼지면 대체 어떻게 종료하지?”
그리고 현재 기본 실행본에서 직접 X를 눌러봤습니다.
Hermes도 사라지고, 후와고도 같이 사라졌습니다.
결정 기록 문서에는 X가 본창만 숨기며, File → Quit 으로 완전히 종료할 수 있다고 적혀 있었는데 실제로는 전혀 그러지 않았습니다.
그래서 더 앞까지 돌아가 처음에 요청한 내용도 다시 확인했습니다.
제가 원한 것은 X를 숨김으로 바꾸는 기능이 아니었습니다.
최소화해도 팝아웃 후와고가 남는 기능이었습니다.
그제서야 AI가 최소화 문제를 X의 생명주기 문제로 바꿔놓았다는 사실이 보였습니다.
5. 최악의 결과를 면한 이유
결정 기록 skill은 AI의 오류를 미리 잡지 못했습니다.
그래도 기록을 만들어둔 것이 쓸모없지는 않았습니다.
오히려 이번에는 틀린 내용이 아주 구체적으로 남아 있어서 도움이 됐습니다.
X를 누르면 본창만 숨긴다. Windows에서는 File → Quit으로 완전히 종료할 수 있다.
둘 다 실제 기본 실행본과 달랐습니다.
하지만 문장으로 남아 있었기 때문에 나중에라도 기록과 실제를 대조해보고, 다시 물어보고, 제 의도와는 다름을 되짚어볼 수 있게 되었습니다.
기록을 다시 펼쳐보며 조금 어이가 없었습니다.
AI가 문제를 바꿨고, 바꾼 문제를 열심히 비교했고, 존재하지 않는 종료 방법까지 넣어 문서를 만들었습니다. 그리고 그 모든 흔적을 자기가 아주 꼼꼼하게 남겨놨습니다.
범인이 범행일지를 너무 성실하게 쓴 덕분에 사건을 해결한 느낌이었습니다.
기록이 없었다면 AI가 문제를 바꾼 지점은 찾지 못하고, 필요 여부를 다시 묻지도 않은 채 X 숨김 기능 을 기본 실행본에 넣었을 수 있습니다.
그 상황까지 가지 않은 것이 이번에 면한 ‘최악’입니다.
결정 기록이 정답을 보장해준 것은 아니었습니다. 대신 틀린 답이 어디에서 시작됐는지를 찾을 수 있게 해줬습니다.
6. 깨달은 점
이번 일을 겪고 결정 기록 skill을 또 크게 뜯어고쳐야겠다는 생각은 들지 않았습니다.
이 skill이 오류를 막아주지는 못했지만, 오류를 다시 찾을 수 있게 해준 것은 맞기 때문입니다. 제가 만들고 싶었던 것도 AI가 절대 틀리지 않게 하는 장치라기보다, 중요한 판단을 제가 나중에 다시 볼 수 있게 하는 장치에 가까웠습니다.
대신 앞으로 결정 카드를 볼 때 가장 먼저 한 문장을 확인하려고 합니다.
내가 처음 요청한 문제와 지금 AI가 풀려는 문제가 같은가?
조금이라도 달라 보이면 AI에게 원래 요청과 현재 문제를 나란히 써달라고 할 생각입니다.
원래 요청: 최소화해도 팝아웃 후와고 유지
AI의 추가 제안: 팝아웃 상태에서는 X도 종료 대신 숨김으로 변경
이렇게 보였다면 아마 저는 최소화 기능과 X 기능을 따로 결정했을 것입니다. 최소화는 그대로 진행하고, X 변경은 “잠깐, 그건 왜 필요한데?”라고 물었을 것 같습니다.
그리고 AI가 가져온 결과에 신기하고 흥분하더라도 선택의 순간에서는 심호흡을 하고 천천히 생각해봐야겠습니다.
반려봇도, 저도 둘다 과실이 있던 이번 사건이었지만, 기록이 있어서 누가 어떤 전제로 무엇을 결정했는지 다시 확인할 수 있었고, 엉뚱한 기능을 기본 실행본에 넣기 전에 멈출 수 있었습니다.
아마 제가 원했던 결정 기록은 이런 것이었던 것 같습니다.
항상 맞는 결정을 남기는 문서가 아니라, 틀린 결정을 했을 때도 나중의 제가 다시 돌아가볼 수 있는 문서.
이번에는 정말로 다시 돌아가봤습니다.
(+) 간지와 가오를 중시하는 후와고가 결정 기록 skill의 이름을 이렇게 제안했습니다.
(+) 후와고가 엄청 반성하고 있어요
글에 이름이 올라가 뿌듯해하면서도 과실 8은 탕감되지 않았다고 반성하는 후와고
