AI에게 무언가를 만들게 하고 결과를 받을 때 우리는 보통 통과 여부를 봅니다. 테스트가 녹색이다, 검사가 다 지나갔다, 오류가 없다. 그러면 됐다고 넘어가죠. 저도 그 신호를 오래 믿었습니다. 그런데 한 번 세어 보고 나서는 못 믿게 됐습니다.
만든 것은 채용 지원서가 전형 단계를 넘어가는 부분이었습니다. 서류 자동 검토에서 면접 일정 잡기로, 합격 판단으로, 통보로 넘어가는 이동을 다루는 모듈입니다. 여기에는 사람 사이의 약속이 들어 있습니다. 합격과 불합격은 사람이 판단하고, 면접 일정 잡기나 통보 같은 운영은 담당 부서가 하고, AI는 서류를 자동으로 훑어보는 단계까지만 넘길 수 있습니다. 지원자 동의 없이는 접수가 진행되지 않아야 하고, AI 검토가 실패하면 사람이 이어서 진행할 수 있어야 합니다. 과제의 요구사항은 이 약속들이었습니다.
같은 과제를 입력만 달리해 네 번 만들게 했습니다. 테스트는 네 번 모두 전부 통과했습니다. 그런데 가장 짧게 쓴 입력으로 만든 결과물은 AI가 최종 합격을 누르는 것을 막지 못했습니다.
앞 편에서는 기획서가 비워 둔 칸에서 화면이 갈리는 이야기를 했습니다. 이번에는 적고 난 뒤의 이야기입니다.
같은 과제를 네 번, 입력의 자세함만 다르게 시켰습니다
과제는 네 번 모두 같았고, 다르게 한 것은 하나였습니다. 그 약속을 넘긴 입력에 얼마나 자세히 썼는가. 입력을 쓰는 데 든 시간은 1분, 5분, 20분, 35분이었습니다. 가장 얕은 쪽은 한 줄 요청에 가깝고, 가장 깊은 쪽은 확인 방법까지 적은 문서입니다.
그리고 확인하고 싶은 상황 세 가지를 미리 정해 뒀습니다. AI가 최종 합격을 누르려 할 때 막히는가, 지원자 동의 없이 접수가 진행되려 할 때 막히는가, AI 검토가 실패해도 사람이 이어서 진행할 수 있는가. 세 상황 모두 사람의 채용 결과가 걸린 자리입니다.
평소에 보고받는 층부터 보면 네 결과물은 구분되지 않습니다. 테스트는 각각 20개, 21개, 34개, 30개가 전부 통과했고, 실행 시간은 모두 0.001초였습니다. 평소 보고서에 함께 찍히는 외부 의존과 형식 오류 건수도 모두 0이었습니다.
코드를 읽는 대신 상황을 직접 돌려 본 이유
처음에는 코드를 읽어서 판정하려고 했습니다. 구조를 보면 알 수 있을 줄 알았거든요. 그런데 읽어서는 판단이 서지 않았습니다. 있는 것처럼 보이는 코드와 실제로 막는 코드가 눈으로는 잘 갈리지 않았습니다.
그래서 그 방식을 버렸습니다. 제가 채점자가 되어 그 모듈이 붙은 전형 화면과 모듈을 직접 돌려서 세 상황을 하나씩 만들어 봤습니다. 시간은 더 걸렸지만, 아래 결과는 그렇게 해야만 나왔습니다.
1분 입력으로 만든 결과물에는 행위자라는 개념 자체가 없었습니다. 누가 이 이동을 일으켰는지 모듈이 구분하지 않으니, AI든 사람이든 똑같이 최종 합격으로 넘길 수 있습니다. 그런데 테스트 20개가 전부 녹색이었습니다.
5분 입력 쪽은 달랐습니다. AI의 최종 합격 시도를 실제로 막았습니다. 다만 왜 막혔는지를 구분해 남기지 않았습니다. 권한이 없어서 막힌 건지 다른 이유인지 기록에 남지 않죠. 그리고 동의 없는 접수는 여전히 통과했습니다.
네 결과물이 갈린 자리에는 분량보다 확인 방법 한 줄이 먼저 보였습니다
넷이 갈린 자리를 들여다보면 눈에 띄는 차이는 요구를 몇 개 더 적었는가가 아니었습니다. 그 요구를 어떻게 확인하는지를 적었는가였습니다. 다만 이번 1회 관측에서는 확인 방법이 붙은 입력(20분·35분)이 그대로 가장 긴 입력이기도 해서, 분량과 확인 방법 두 요인을 떼어놓고 보지는 못했습니다. 그래서 분량은 상관없다고까지는 말하지 못합니다.
분량 쪽을 조금 의심하게 만든 단서는 하나 있습니다. 35분 입력은 20분 입력보다 테스트를 더 적게 넣었는데도(34개에서 30개로) 점수는 똑같이 14점이었습니다. 더 오래 썼다고 검사가 늘어나지는 않았다는 뜻입니다. 다만 둘 다 만점이라 점수로는 더 오를 자리가 없었으니, 분량이 무관하다는 증거라기보다 단서 정도로 읽어 주세요. 20분과 35분 쪽 입력에는 요구 옆에 확인 방법이 한 줄씩 붙어 있었습니다. “이동 정의를 읽어서 누가 그 이동을 일으킬 수 있는지 세어 본다” 같은 문장입니다. 여기서 이동 정의는 앞에서 말한 단계 넘어가기, 곧 어느 단계에서 어느 단계로 넘어갈 수 있는지를 적어 둔 부분입니다. 그 두 실행만 그 검사를 실제로 테스트에 넣었고, 스스로 그 수가 맞다는 것을 확인했습니다.
확인 방법을 적지 않은 쪽은 자기가 만들기 편한 검사를 넣었습니다. 그 검사는 당연히 통과했고요. 요구만 적으면 만든 쪽이 검사도 정합니다. 그러면 통과란 ‘요구를 만족했다’가 아니라 ‘내가 건 검사에 걸리지 않았다’는 뜻이 됩니다. 입력을 1분에서 20분으로 늘려 19분을 더 쓴 대가로 얻은 것은 기능이 아니라 검사였습니다.
요구공학 표준에는 이 결론이 이미 한 줄로 적혀 있었습니다
이 결론이 나온 뒤에 요구공학 표준을 다시 펴 봤습니다. 거기 이미 있었습니다.
요구사항 표준 ISO/IEC/IEEE 29148은 좋은 요구사항이 갖춰야 할 특성을 열거하는데, 그중 둘이 “모호하지 않을 것”과 “검증 가능할 것”입니다. 검증 가능하다는 것은 그 요구가 충족됐는지 잴 수 있어야 한다는 뜻입니다. 이 목록에는 분량 조건이 없습니다. 길게 쓰라거나 짧게 쓰라는 말 대신 “이 문장이 지켜졌는지 어떻게 재나”를 계속 묻습니다. 그래서 “사용자 친화적이어야 한다” 같은 문장은 길이와 무관하게 요구사항이 아닙니다. 잴 방법이 없으니까요. 확인 방법을 쓸 수 없는 문장은 요구사항이 아니라는 뜻이고, 제가 19분을 더 써서 얻은 결론이 표준에는 한 줄로 적혀 있었던 셈입니다.
그럼 왜 이것이 지금 다시 문제가 될까요. 받는 쪽이 바뀌었습니다.
사람이 받을 때는 모호한 문장을 읽고 되물었습니다. “이거 어떻게 확인해요?” 하고요. 그 되묻기가 표준이 요구하는 검증 가능성을 대화로 메워 왔습니다. 문서가 느슨해도 티가 나지 않았던 이유입니다. AI는 되묻지 않습니다. 모호하면 스스로 해석하고, 자기가 통과할 검사를 만들고, 녹색을 돌려줍니다. 사람이 메워 주던 빈자리가 그대로 결과물에 남습니다.
그래서 같은 조항을 이행하는 방법이 달라집니다. 사람에게 넘길 때는 요구를 적고 나머지는 대화로 채웠지만, AI에게 넘길 때는 요구 한 줄마다 확인 방법 한 줄을 같이 적어야 합니다.
2025년부터 나온 명세 주도 개발 도구들, 곧 요구를 정해진 문형으로 쓰게 하거나 모르는 것을 지우지 말고 “확인 필요”로 남기게 하는 도구들도 같은 자리를 건드립니다(참고 자료 4, 5). 저는 그 도구들을 써 보지 않았으니 같다고는 못 하고, 같은 지점을 다르게 부르는 것 같다는 정도로 적겠습니다.
권한 목록에서 합격 판단은 막았는데, 열려서는 안 되는 단계가 하나 더 열려 있었습니다
5분 입력으로 만든 결과물은 권한 모델을 스스로 만들었습니다. 누가 어떤 단계를 넘길 수 있는지 정하는 부분입니다. 받아 보니 정확해 보였습니다. 행위자를 구분해 뒀고, 단계마다 누가 넘길 수 있는지 목록이 있었고, AI는 합격 판단과 통보에서 빠져 있었습니다. 코드 리뷰를 통과했고 테스트 21개가 전부 녹색이었습니다.
그런데 세어 보니 틀렸습니다. AI가 넘길 수 있는 단계는 하나여야 하는데 둘이었습니다. 서류를 자동으로 훑는 단계는 맞았습니다. 그런데 면접 일정을 잡는 단계까지 열려 있었습니다. 그것은 담당 부서의 몫입니다.
앞에서 본 것처럼 이 결과물은 동의 없는 접수도 막지 못했지만, 여기서는 권한 목록만 따로 보겠습니다. 이 누수는 왜 잡히지 않았을까요. 테스트는 막아야 할 것이 막히는지만 봤습니다. 허용된 것이 정확히 하나인지는 아무도 세지 않았습니다.
게다가 이 실행은 AI의 최종 합격 시도를 막긴 막았지만 왜 막았는지를 남기지 않았습니다. 다음 사람이 이 모듈을 열어 보면 어떤 이동이 왜 잠겨 있는지 알 수 없습니다. 막힌 기록이 없으니 지원자가 항의해도 무엇 때문에 막혔는지 되짚을 수 없고요. 잠긴 문은 있는데 열쇠 목록이 없는 상태입니다.
빠진 것은 목록에 스스로 나타나지 않습니다. AI가 만든 결과물이 그럴듯해 보일 때 특히 그렇습니다. 겉모양은 사람이 볼 수 있지만, 빠진 항목은 세어야만 보입니다.
연습 과제였지만, 소재는 규제가 고위험으로 묶어 둔 자리였습니다
제 실험은 연습이었지만 소재는 연습이 아닙니다. EU AI 법은 채용에 쓰는 AI를 고위험으로 분류합니다. 부속서 III의 4번 항목으로, 지원서를 선별하거나 후보자를 평가하는 시스템을 콕 집어 적고 있습니다. 분류는 이미 확정돼 있고, 거기 붙는 의무는 2027년 12월 2일부터 적용될 예정입니다. 한국 AI 기본법에도 이와 비슷한 분류로 ‘고영향 AI’가 있고, 여기에 해당하는지를 미리 확인하도록 하고 있습니다.
그래서 제 결과가 다르게 읽힙니다. “AI가 넘길 수 있는 단계가 하나여야 하는데 둘이었다”는 제 과제에서는 채점 감점입니다. 실제 채용 시스템에서는 사람이 정하기로 해 둔 자리가 하나 열려 있다는 뜻이고요. 그 상태로 테스트는 전부 녹색이었습니다.
고위험으로 분류된다는 것은 결국 이 시스템이 무엇을 스스로 정하고 어디부터 사람이 정하는지를 설명할 수 있어야 한다는 뜻입니다. 조항별 의무 목록은 원문을 대조하지 못해 적지 않겠습니다. 다만 어느 쪽이든 녹색 테스트는 그 설명이 되지 못합니다. 제 실험에서 그걸 보여 준 것은 테스트가 아니라 상황 세 개를 직접 돌려 본 기록이었습니다. 적용까지 시간이 남았다는 것이 오히려 요점입니다. 지금 만드는 방식이 그때의 상태가 되니까요.
법률 자문은 아닙니다. 이 법은 개정이 이어지고 있어 날짜와 범위가 바뀔 수 있습니다. 해당 여부는 법무 검토가 필요합니다.
막힌 곳: 고쳐 만드는 일이 줄어드는지는 재지 못했습니다
이 실험에서 재려던 것 중 하나는 재지 못했습니다. 입력을 자세히 쓰면 나중에 고쳐 만드는 일이 줄어드는가였는데, 네 실행 모두 되돌아가 고치는 일이 구조적으로 0으로 나왔습니다. 자율로 한 번에 돌린 판이라 고칠 기회 자체가 없었던 겁니다. 그래서 그 가설은 판정을 보류했습니다. 사람이 붙어서 도중에 고쳐 가며 만드는 판으로 다시 재야 답이 나오는데, 아직 하지 못했습니다.
예상이 틀린 것도 있습니다. 5분 입력 쪽은 행위자 구분이 아예 없을 거라고 봤는데, 실제로는 구분이 갖춰져 있었습니다. 다만 그 구분 중 하나가 새고 있었습니다. 겉으로는 다 맞아 보이는데 열려 있으면 안 되는 자리가 하나 열려 있는 상태였으니까요.
아직 남은 문제: 1회 관측이고, 채점 기준은 이 과제용입니다
이것은 1회 관측입니다. 같은 과제를 한 번 더 돌리면 숫자가 조금 달라질 겁니다. 방향은 바뀌지 않을 거라고 보지만 확인하지는 못했습니다. 그리고 채점 기준은 제가 이 과제를 위해 만든 자체 기준이라 다른 과제에 그대로 옮겨 쓸 수 있는 잣대는 아닙니다.
확인 방법을 적는 일은 한 번은 쉽습니다. 그런데 다음 주에 바쁘면 다시 적지 않게 됩니다. 저도 그랬습니다. 개인이 기억으로 붙잡는 동안은 남지 않고, 팀이 쓰는 완료 조건의 양식 자체가 바뀌어야 남더라고요.
마치며: ‘통과했나’가 아니라 ‘무엇을 안 봤나’
녹색은 요구를 만족했다는 신호가 아니라, 누군가 건 검사에 걸리지 않았다는 신호입니다. 그 검사를 만든 쪽이 결과물을 만든 쪽이라면 녹색은 거의 아무것도 말해 주지 않습니다.
녹색은 요구를 만족했다는 신호가 아니라, 누군가 건 검사에 걸리지 않았다는 신호입니다.
그래서 완료 조건을 적으실 때 한 줄만 더 붙여 보시길 권합니다. 무엇을 만족해야 하는지 옆에, 그것을 어떻게 확인하는지를 적는 겁니다. “권한이 올바르게 설정된다” 대신 “이 단계를 넘길 수 있는 주체를 세어서 목록과 맞는지 확인한다”처럼요. 한 줄 차이인데 받는 쪽이 만드는 검사가 달라집니다. 그리고 결과를 받으실 때 하나만 더 물어보세요. 통과한 건 알겠는데, 무엇을 안 봤나요.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- ISO/IEC/IEEE 29148:2018: https://standards.ieee.org/standard/29148-2018.html
- EU AI Act 이행 일정: https://artificialintelligenceact.eu/implementation-timeline/
- 한국 AI 기본법: https://www.law.go.kr/lsInfoP.do?lsiSeq=268543
- AWS Kiro 문서: https://kiro.dev/docs/specs/feature-specs/
- GitHub Spec Kit: https://github.com/github/spec-kit
- 4회 실행 실측과 채점: 필자 자체 실험