설명을 들었지만 설계를 소유한 것은 아니었다
AI와 RAG MCP를 구현하며 놓친 프로젝트 범위를 다시 바로잡기까지
나는 AI 에이전트와 WorkShield 프로젝트를 진행하며 내린 결정을 가능한 한 모두 기록했다. 발견한 문제, 제안받은 대안, 채택하거나 폐기한 기능을 시간순으로 남겼다. 나중에 개발 과정을 복기하기 위해서였다.
기록만 보면 프로젝트는 논리적으로 발전한 것처럼 보였다.
검색 점수 산출의 계약 오류를 고쳤고, 평가 데이터 형식을 맞췄다. 실제 실행 과정에서 진단 정보를 수집하며 기준에 못 미치는 실험은 되돌렸다.
그러나 그 결정들을 글로 정리하는 과정에서 모순이 드러났다.
정작 당시 나는 그 선택들을 온전히 이해하고 내린 것이 아니었다.
AI가 제안한 구조를 읽고 이해가 안 가면 설명 요구를 반복했다. 선택지가 여러 개면 장단점과 권장안을 물어 타당해 보이는 쪽을 골랐다. 코드를 무작정 복사한 것은 아니었기에 당시에는 충분히 검토했다고 여겼다.
프로젝트를 처음부터 다시 되짚어보자 설명하기 까다로운 결정들이 쏟아졌다.
이 구조가 왜 필요한지, 제거하면 무엇이 무너지는지, 계산된 점수가 어디서 나와 어떤 의미로 쓰이는지 내 언어로 설명하지 못했다.
AI의 설명에 납득한 것과 설계를 내 것으로 이해한 것은 전혀 다른 문제였다.
더 나은 해결책을 고른다는 착각
WorkShield의 초기 목표는 단순했다.
사용자가 계약서 조항을 입력하면 공개 표준계약서에서 함께 검토할 후보를 찾고, 두 원문을 MCP로 외부 AI나 사람에게 전달한다. 위법 여부나 유불리를 직접 판단하지 않고, 다시 읽어야 할 범위를 좁혀주는 검색 도구였다.
개발 중 문제가 생기면 AI에게 원인과 해결책을 구했다. 제안이 오면 설명을 읽고 테스트 통과 여부를 확인한 뒤 적용했다.
내가 주로 살핀 점은 다음과 같았다.
- 당장의 문제를 해결하는가
- 이전 방식보다 나아 보이는가
- 테스트와 코드 실행에 이상이 없는가
정작 더 본질적인 질문은 놓치고 있었다.
- 이 문제가 원래 우리가 풀려던 문제가 맞는가
- 현재 데이터로 결과를 검증할 수 있는가
- 잘못 동작하면 어떤 오해가 생기는가
- 입력과 출력, 실패 조건을 내 언어로 설명할 수 있는가
좋은 해결책을 고르는 것과 풀어야 할 문제를 정의하는 것은 별개의 일이었다.
검색 도구가 상세 비교 엔진으로 변했다
프로젝트 범위가 흔들린 계기는 긴 조항을 다루면서부터였다.
표준조항 하나에는 납품, 검수, 하자 통지, 보수 기한처럼 여러 내용이 함께 들어갈 수 있다. 반면 사용자 계약에는 그중 일부만 들어갈 때가 많았다.
일부 항목만 대응하더라도 관련 부모 조항을 놓치지 않으려고 조항을 항 단위로 나누고, 가장 높은 세부 점수를 부모 조항에 반영했다.
여기까지는 후보 검색이라는 목표와 맞닿아 있었다.
하지만 검색된 두 조항이 정확히 어디서 다른지 확인하려 하면서 구조가 비틀렸다. 표준조항과 사용자 조항을 항·호 단위로 정렬하고 당사자, 금액, 기한, 부정 표현까지 비교하기 시작했다. 문장이 나뉘거나 합쳐지는 예외 처리까지 품으려 했다.
각 기능은 당장 눈앞의 문제를 해결하기 위해 제안된 것이었다. 나는 설명을 읽고 그 제안들을 하나씩 승인했다.
정신을 차렸을 때, 후보와 원문을 전달하려던 MCP는 두 계약서의 차이를 직접 해석하는 엔진으로 바뀌어 있었다.
늘어난 것은 코드뿐만이 아니었다. 시스템이 책임져야 할 질문 자체가 달라졌다.
관련 후보를 찾는 문제와 법률 문장의 의미 차이를 확정하는 문제는 차원이 다르다. 후자에는 깊은 도메인 지식과 평가 데이터, 실패 기준이 필수적이다.
나는 이 변화를 제때 감지하지 못했다. AI가 제시하는 다음 문제와 해결책을 순성하게 따라가다 보니, 어떤 문제를 계속 풀 것인지 결정하는 주도권을 놓쳤다.
설계를 공유한 것이 아니라 결과를 전달했다
이 문제는 팀 협업에서도 나타났다.
AI와 정리한 설계와 인터페이스를 모듈별로 나누어 팀원들에게 전달했다. 입출력과 담당 범위가 명확해 병렬 개발은 빠르게 진행됐다.
당시에는 이를 효율적인 협업이라고 판단했다.
그러나 설계를 전달하는 것과 팀이 설계를 함께 이해하는 것은 별개였다.
내가 공유한 내용은 함께 검토할 가설이라기보다 이미 확정된 지침에 가까웠다. 팀원들은 각자 모듈을 구현했지만, 프로젝트 전체가 어떤 질문에 답하려는지, 인접 모듈의 결과가 어떤 의미인지 함께 고민할 기회는 부족했다.
팀원들이 수동적이었다는 뜻이 아니다.
문제와 가설을 함께 논의할 판을 만들지 않고, 결론과 작업 범위부터 넘겼다는 의미다. 나부터 전체 구조를 완전히 이해하지 못했기에 통합 기준도 공동의 문제 이해보다는 단순 인터페이스 일치에 그쳤다.
AI가 높여준 구현 속도를 팀원의 학습과 프로젝트 소유권으로 전환하지 못했다.
리드의 역할은 정답을 가장 먼저 찾아 전달하는 데 그치지 않는다. 팀이 같은 질문을 바라보고, 각자의 관점에서 대안을 내며, 결정 근거를 함께 소유하도록 이끄는 일이 필요했다.
해결책보다 증거를 먼저 보기 시작했다
프로젝트 후반에는 독소 조항 검색을 개선하기 위해 예시 문장을 40건에서 90건으로 늘렸다.
단일 문장을 검색하면 새 예문이 정상적으로 나왔지만, 전체 평가에서는 참 양성(True Positive)이 여전히 0건이었다.
원인은 데이터 양 문제가 아니었다.
평가 질의에는 조항 제목과 헤더가 포함된 반면, 독소패턴 코퍼스에는 본문만 들어있었다. 질의와 검색 대상이 서로 다른 표현 규칙을 따르고 있었던 것이다.
진단 방식도 실제 판정을 설명하지 못했다. 최종 판정이 끝난 뒤 검색과 재정렬을 다시 실행해 진단 자료를 만들고 있었기 때문이다. 다시 호출한 외부 모델 결과는 실제 판정 순간과 달라질 수 있었다.
이후에는 실제 판정 과정에서 사용된 후보와 점수를 그대로 수집하고, 색인·실행·평가 경로가 동일한 정규화 규칙을 공유하도록 고쳤다.
이때부터 문제가 생기면 해결책을 바로 덧붙이기 전에 증거부터 확인하기 시작했다.
- 지금 보는 값이 실제 실행을 반영하는가
- 평가셋 정답이 시스템이 답할 수 있는 질문인가
- 무엇이 좋아져야 개선이라고 부를 수 있는가
- 어떤 지표가 나빠졌을 때 변경을 버릴 것인가
- 실패했을 때 돌아갈 기준선이 있는가
실험 전에는 가설과 채택 기준을 먼저 기록했다. 일부 지표가 좋아져도 전체 기준을 충족하지 못하면 기본 동작에 남기지 않았다.
구현할 수 있다는 사실과 제품에 남길 수 있다는 결정은 엄연히 달랐다.
AI가 주도권을 빼앗은 것은 아니었다
한동안은 AI가 프로젝트 주도권을 가져갔다고 생각했다.
그러나 AI가 스스로 프로젝트 목적을 바꾼 적은 없다.
내가 문제를 넘기고 더 나은 해결책을 요구했기에, AI는 그 문제를 더 깊고 정교하게 풀었을 뿐이다.
이 문제를 더 잘 해결하려면 무엇을 해야 하는가?
이 질문에는 AI가 언제든 답할 수 있다.
하지만 다음 질문은 사람의 몫이다.
이 문제가 여전히 우리가 해결해야 할 문제인가?
나는 구현의 완성도는 물었지만, 그 기능이 제품의 책임인지, 팀이 검증하고 설명할 수 있는 범위인지는 충분히 묻지 않았다.
상세 비교를 계속 가져갈지 고민할 때 질문을 바꿨다.
“어떻게 더 완성할까?”가 아니라 “이 기능이 원래 목적에 필요한가?”를 물었다.
그 기준으로 다시 보니 상세 비교는 단순히 구현이 어려운 기능이 아니었다. 검색 도구의 책임을 넘어섰고, 현재 데이터와 일정으로는 결과를 검증하기도 어려웠다.
결국 상세 비교를 1차 기능에서 제외했다.
AI의 판단이 달라진 것이 아니었다. 내가 판단을 요청하는 기준을 바꾼 것이었다.
답보다 판단 과정을 공유하기
이 경험 이후 몇 가지 기준을 세웠다.
우선 목표와 비목표를 문서에 명시한다. 새로운 구조가 제안되면 기술적 장점뿐 아니라 필요성, 검증 가능성, 실패 시 위험과 더 단순한 대안을 점검한다.
점수와 상태값은 생성 위치와 범위, 소비 목적까지 설명할 수 있어야 한다. 입력과 출력, 실패 조건과 제거 영향을 내 언어로 설명하지 못한다면 아직 승인할 준비가 되지 않은 것이다.
팀에는 완성된 설계만 전달하지 않는다.
문제와 제약, 검증되지 않은 가설부터 공유하고 함께 대안을 검토한다. 각 담당자가 자신의 코드뿐 아니라 전체 흐름에서 그 결과가 어떤 의미인지 설명할 수 있어야 한다.
실험을 시작하기 전에는 채택 기준과 중단 조건을 정한다. Result와 실패를 팀 전체에 공유해 다음 판단의 근거로 남긴다.
이 과정은 초기 개발 속도를 약간 늦출 수 있다.
하지만 팀원을 주어진 코드를 작성하는 인력에 가두지 않고, 문제를 이해하고 판단에 참여하는 개발자로 세운다. 구성원의 역량과 프로젝트 소유권을 키우는 일 또한 리더십의 본질이다.
이 프로젝트가 남긴 것
WorkShield를 거치며 RAG, 하이브리드 검색, reranker, MCP, 그리고 평가 데이터 구축을 경험했다.
그러나 가장 깊게 배운 점은 특정 검색 기법이 아니었다.
AI가 구현할 수 있는 범위는 빠르게 넓어지지만, 제품과 팀이 책임질 수 있는 범위까지 저절로 확장되지는 않는다.
AI 시대의 기술적 주도권은 모든 코드를 직접 타이핑하는 데 있지 않다.
무엇을 문제로 정의할지, 어떤 결과를 증거로 인정할지, 시스템이 어디까지 말하게 할지, 누구와 설계를 공유할지, 언제 실험을 멈출지를 결정하는 데 있다.
나는 AI와 함께 벽을 빠르게 쌓았고, 정리한 도면을 팀원들에게 나눠 주었다.
그러나 어느 순간 우리가 처음 만들려던 건물과 다른 방향으로 벽이 자라고 있음을 알았다. 각자 맡은 벽은 알고 있었지만, 건물 전체의 모습을 함께 그리지는 못했던 것이다.
그 뒤부터는 벽돌을 더 잘 쌓는 방법보다 먼저 묻게 되었다.
우리는 어떤 건물을 만들고 있는가.
이 벽은 정말 필요한가.
누가 이 도면을 함께 검토했는가.
그리고 어디에서 공사를 멈춰야 하는가.
이 질문들이 WorkShield가 내게 남긴 가장 귀중한 유산이다.
