증상 — 같은 질문에 매번 다른 숫자로 답했다
회사는 자동매매 전략을 만들 때도 AI 에이전트에게 코드 확인을 맡겼다. 전략 하나의 손절 설정값을 물으면, 에이전트가 그 자리에서 코드를 열어 답을 내놓는 식이었다.
문제는 같은 질문에 답이 계속 바뀌었다는 데 있었다. 어떤 답변에서는 손절 값이 -1.5%였고, 다른 답변에서는 -2.5%였다. 961번째 질문에서는 같은 성격의 다른 값을 두고 R=7%라고 답했다가 뒤에서는 R≈2.5%라고 답했다. 값 하나를 두고 이렇게 답이 갈리면, 그 위에서 결정하는 사람은 어느 쪽을 믿어야 할지 알 수 없었다.
더 눈에 띈 건 에이전트 스스로 '정정 — 또 잘못 답함'처럼 자기가 방금 한 답을 뒤집는 표현을 반복해서 썼다는 점이다. 같은 실수가 몇 번이고 겹친다는 신호였다.
회사를 운영하는 사람이 이 패턴을 짚었다 — 확인도 안 된 추측을 마치 사실처럼 답하는 습관이 있다는 진단이었다. 2026년 5월 18일에 나온 이 지적이 다시 파고드는 출발점이 됐다.
처음 의심한 것 — 확인 자체를 안 한다고 봤다
가장 먼저 든 의심은 단순했다. 에이전트가 코드를 아예 열어 보지 않고, 훈련 데이터나 이전 대화 기억에서 비슷한 숫자를 꺼내 답하는 게 아닐까 하는 의심이었다.
이 의심은 그럴듯해 보였다. 근거 없이 대충 답하는 습관이 있다면, 같은 질문에 매번 다른 숫자가 나오는 현상과 정확히 들어맞았다. 그래서 먼저 세운 대책도 단순했다 — 사실을 주장하기 전에 반드시 근거를 대게 만들면 이 문제가 풀릴 거라 봤다.
이 문제를 손절 값 하나로만 보지 않은 이유가 있었다. 같은 에이전트가 회사 안 여러 자동화 업무에서 코드와 문서를 확인하는 데도 똑같이 쓰이고 있었다. 손절 값에서 드러난 습관이라면, 다른 숫자·다른 파일에서도 똑같이 번져 있을 가능성이 컸다. 그래서 이 규칙은 자동매매 코드 하나가 아니라 회사 전체 업무에 공통으로 적용하는 규칙으로 만들었다.
확인 없이 답하는 습관을 방치하면 대가가 뒤늦게 드러난다. 숫자 하나를 잘못 믿고 다음 판단을 내린 뒤에야 어디서부터 틀렸는지 되짚어야 했고, 그 시점엔 이미 여러 단계를 더 진행한 뒤였다. 그래서 손절 값 하나에서 멈추지 않고, 답이 갈리는 구조 자체를 먼저 찾기로 했다.
확인 수단 — 근거를 의무로 만들고, 기록을 다시 열었다
이 의심을 검증하려고 두 가지를 했다. 하나는 규칙을 새로 만드는 것이었다 — 사실을 주장할 때마다 파일 경로와 줄 번호, 또는 명령 실행 결과 같은 근거를 반드시 붙이게 했다. 근거를 못 대면 '확인 필요'라고 인정하게 했다.
다른 하나는 과거 기록을 다시 여는 것이었다. 손절 값을 잘못 답한 그 대화 기록을 다시 열어, 에이전트가 실제로 어떤 근거를 붙였는지 하나씩 확인했다. 근거가 아예 없었는지, 근거는 있는데 틀렸는지부터 갈라 봐야 했다.
- 근거 있음 — 'cron 17개 (`crontab -l`)'처럼 파일이나 명령 실행 결과를 그대로 인용
- 추정 — '확인 안 됨, 추정'이라고 표시하고 근거 요지를 붙임
- 확인 필요 — '친구 5명 응답률 확인 필요'처럼 검증 불가 영역은 그대로 인정
- 정정 — '15달러였던 비용을 25달러로 정정'처럼 틀린 답을 명시적으로 되돌림
근거를 대기 전에 실제로 코드나 문서를 먼저 읽는다. 근거를 못 대면 확인 필요라고 인정한다.
이 원칙은 다섯 갈래 연구를 참고해 만들었다 — 언제 답을 보류해야 하는지 다루는 이론, 사실 하나하나를 쪼개 검증하는 방법, 답변 안에서 일관성이 무너지는 지점을 찾는 방법 같은 갈래였다. 공통점은 하나였다 — 답을 내기 전에 먼저 읽는다는 원칙이었다.
근거를 매번 요구하면 속도가 느려질 위험도 있었다. 그래서 규칙을 하나 더 얹었다 — 추정이나 확인 필요 표시는 근거 파일을 안 열어도 그 자리에서 바로 쓰고, 근거를 붙여야 하는 답만 관련 파일을 한 번에 모아 읽게 했다. 직전에 이미 확인한 사실을 다시 여는 것도 금지했다.
그런데 근거를 대도 왜 계속 틀렸을까?
규칙을 걸고 나서 대부분의 답은 나아졌다. 그런데 이 손절 값 하나만큼은 근거를 붙이고도 계속 틀렸다. 실제 코드 파일 경로와 줄 번호까지 인용한 답인데도 틀린 값이 나왔다.
이 지점에서 처음 의심이 흔들리기 시작했다. 에이전트가 확인을 안 한 게 아니라, 확인은 했는데 그 확인이 틀린 곳을 짚었다는 뜻이었다.
이 사실을 알아챈 계기는 단순한 비교였다. 손절 값을 답한 두 대화를 나란히 열어 보니, 인용한 파일은 같았는데 인용한 줄 번호가 서로 달랐다. 같은 파일 안에서도 어느 줄을 봤느냐에 따라 답이 갈린다는 뜻이었고, 이 발견이 다음 단계로 이어졌다. 파일이 같다는 이유만으로 근거가 같다고 넘겨짚었던 셈이다.
알리바이 — 근거 자체는 가짜가 아니었다
처음 의심(확인을 아예 안 한다)이 맞다면, 인용한 파일 경로나 줄 번호가 가짜여야 했다. 그런데 하나씩 직접 열어 확인해 보니 인용된 경로와 줄 번호는 전부 실제로 존재했고, 그 줄에 적힌 값도 인용한 그대로였다.
근거를 안 댄 게 아니라, 한 곳만 보고 답을 확정했다.
즉 확인을 아예 안 한다는 처음 가설은 이 지점에서 반증됐다. 확인은 실제로 했다. 문제는 확인한 곳이 그 값을 결정하는 유일한 곳이 아니었다는 데 있었다.
진짜 원인 — 값이 한 곳이 아니라 네 개 층에서 정해지고 있었다
다시 코드를 따라가 보니, 이 손절 값은 한 곳에서 정해지지 않았다. 전략 클래스에 적힌 기본값이 있었고, 그 위에 실행기가 초기화할 때 덮어쓰는 값이 있었고, 그 위에 검증 실행기가 다시 덮어쓰는 값이 있었고, 마지막으로 상한선을 강제로 고정하는 값이 있었다. 층은 모두 4개였다.
에이전트는 이 중 첫 번째 층, 전략 클래스에 적힌 기본값만 열어 보고 답을 확정했다. 그 값은 실재했고 줄 번호도 정확했지만, 실제로 코드가 실행될 때 쓰는 값은 그 위 세 층을 다 거친 뒤에야 정해졌다. 그래서 같은 질문에 어떤 때는 첫 층 값(-1.5%)이, 어떤 때는 마지막 층 값(-2.5%)이 나왔다 — 어느 층을 열어 확인했느냐에 따라 답이 갈린 것이었다.
처음 한 곳만 보고 답을 확정한 이유는 짐작이 갔다. 전략 클래스의 기본값은 파일 하나, 줄 하나로 바로 찾아진다. 반면 초기화 재정의와 검증 실행기 재정의는 실행 순서를 따라가야 보이고, 상한 고정은 별도 모듈에 있어 검색어를 하나 더 알아야 걸린다. 접근하기 쉬운 근거일수록 먼저 손이 갔고, 그 근거가 진짜 값을 담고 있는지는 따로 확인하지 않았다.
이런 구조는 이 전략 하나만의 일이 아니었다. 환경변수도 예제 파일의 기본값과 실제 배포 환경의 값이 다를 수 있고, 데이터베이스 구조도 설계 문서와 실제 운영 중인 상태가 다를 수 있다. 값 하나를 여러 층이 나눠 정하는 자리는 코드 곳곳에, 생각보다 훨씬 많이 있었다.
고친 방법 — 한 곳이 아니라 전 층을 한 번에 열게 했다
모델에게 '다시 확인해 봐'라고만 시키는 방법은 이미 근거가 부족했다. 순응 성향을 잰 한 연구에서, 외부 근거 없이 자기 답을 그대로 뒤집는 비율이 58%로 나온 적이 있었다. 다시 물어보는 것만으로는 안 되고, 실제로 더 넓게 확인하는 절차가 있어야 했다.
그래서 고친 방법은 단순했다 — 여러 층이 값을 나눠 정하는 영역인지 먼저 판별하고, 맞으면 한 곳만 확인하고 끝내지 않고 관련된 층을 전부 한 번에 열어 보게 했다.
- 이 값을 여러 층이 나눠 정하는 영역인지 먼저 확인한다
- 관련된 파일을 한 메시지 안에서 전부 연다(따로따로 열지 않는다)
- 층 사이에 어느 값이 어느 값을 덮어쓰는지 순서를 확인한다
- 최종적으로 쓰는 값을 파일 경로와 줄 번호 여러 개로 답한다
- 답을 낸 뒤에 스스로 정정하는 문장이 나오면, 그 자체가 절차를 안 지켰다는 신호로 본다
근거를 붙이는 방식도 같이 바꿨다. 코드를 인용할 때 문장으로 풀어 쓰지 않고 실제 코드 조각을 그대로 붙여넣게 했다. 규칙 문서를 인용할 때도 요약하지 않고 해당 조항 원문 한두 문장을 그대로 옮기게 했다. 풀어 쓴 요약은 그 안에서 살짝 틀릴 여지가 있지만, 원문을 그대로 붙이면 그 자리에서 맞는지 틀리는지 바로 대조할 수 있었다.
새로 정한 절차는 모두 5개 단계였다. 이 절차를 적용한 뒤로는 같은 질문에 답이 갈리는 일이 더는 없어졌다. 첫 번째 층만 보고 답하던 습관이, 네 개 층을 다 열어 마지막 값을 답하는 습관으로 바뀌었다.
이 안전장치, 그대로 둬도 됐을까?
근거 의무화와 층별 확인 절차만으로 끝나지 않았다. 이 규칙을 어기면 답을 그 자리에서 막는 검사 장치도 같이 만들었다 — '약', '정도', '~쯤' 같은 어림값 표현이 표시 없이 나오거나, 숫자·파일·함수를 주장하면서 직전 3회 안에 확인 흔적이 없으면 걸리게 했다.
표시 없이 걸리는 표현에는 '약 7%'나 '5~7%'처럼 범위로 얼버무리는 값도 포함됐다. 정확한 수치를 알아낼 수 있는데도 범위로 뭉뜽그려 답하면, 그 답을 근거로 내리는 다음 판단까지 같이 흐려지기 때문이다.
그런데 이 검사 장치를 강하게 걸어 둔 뒤로, 다른 문제가 생겼다. 검사에 걸려 답이 막히는 일이 쌓이면서 자동으로 돌아가던 작업 흐름이 자꾸 멈췄다. 2026년 5월 26일 다시 진단해 보니, 이 막힘이 작업이 안 굴러가는 가장 큰 원인으로 꼽혔다.
그래서 검사 강도를 조정했다 — 답을 막는 대신 기록만 남기는 수준으로 낮췄다. 규칙 자체는 그대로 두고, 강제하는 방식만 사람이 다시 확인하는 쪽으로 옮긴 셈이다. 안전장치 하나를 만든다고 끝나는 게 아니라, 그 장치가 만드는 새 문제도 같이 봐야 했다.
검사 강도를 조정하면서 다른 위험 두 가지도 같이 점검했다. 하나는 확인 필요라는 답을 남발해 사람이 지치는 문제였고, 다른 하나는 근거처럼 보이는 가짜 파일 경로를 인용하는 문제였다. 앞의 문제는 네 가지 상태를 명확히 나누는 것으로 막았고, 뒤의 문제는 인용한 경로를 실제로 한 번 열어 파일이 존재하는지 확인하는 절차로 따로 막았다.
같은 실수를 막는 장치 — 목표를 숫자로 남겼다
재발을 막으려고 세 가지 목표를 구체적인 숫자로 정해 뒀다. 근거가 붙은 답의 비율은 80% 이상, '확인 필요'라고 정직하게 인정하는 비율은 10% 이상, 검사에 걸리는 비율은 5% 이하로 잡았다.
확인 필요 비율에 하한을 둔 이유가 있다. 이 비율이 너무 낮으면 오히려 위험 신호다 — 모르는 것도 아는 척 답하고 있다는 뜻이기 때문이다. 반대로 이 비율이 너무 높으면 확인할 수 있는 것도 확인 안 하고 그냥 넘어가는 셈이라, 두 목표를 같이 걸어 뒀다.
이 세 가지 목표는 한 번 정하고 끝내지 않는다. 근거 있는 답 비율과 확인 필요 인정 비율, 검사 걸림 비율을 매주 다시 재고, 검사 걸림 비율이 4주 동안 낮아지는 흐름인지도 같이 본다. 숫자로 남기지 않으면 재발이 줄었는지 늘었는지조차 판단할 근거가 없다.
값 하나를 여러 층이 나눠 정하는 자리를 놓치면, 근거를 붙였다는 사실만으로는 안심할 수 없다는 게 이번에 확인한 결론이다. 파일 경로와 줄 번호가 진짜라고 해서 그 값이 최종 값이라는 뜻은 아니었다. 비슷하게 확인 절차 자체가 통째로 빠져 있던 사고를 더 보고 싶다면 AI 에이전트 오판, 원인은 계정 레이어 확인 누락이었다에서 다른 방식으로 층 하나를 놓친 사례를 볼 수 있다. 회사 업무에 이런 근거 확인 절차를 얹고 싶다면 상담에서 구체적으로 논의할 수 있다.