8. 프로젝트 수행

“문서를 읽고 자동으로 승인해 주는 AI를 만들 수 있을까요?”

고객이 이렇게 묻는 상황을 생각해 보자. 이 장의 문서 검토 프로젝트는 FDE의 일을 설명하기 위해 구성한 가상 사례다. 고객은 승인에 시간이 오래 걸리고, 담당자마다 판단이 다르다는 문제를 겪고 있다. 자동화하면 빨라질 것이라고 기대한다.

이 요청을 바로 개발 항목으로 옮기면 문서 업로드, 내용 추출, 승인 결과 표시 같은 기능이 나온다. 하지만 아직 중요한 사실을 모른다. 어디에서 시간이 걸리는지, 판단이 다른 이유가 무엇인지, 승인에 따른 책임을 누가 지는지다.

업무 조사

FDE는 검토자가 실제 문서를 처리하는 과정을 함께 살펴본다. 검토자는 문서를 읽는 시간보다 이전에 승인한 비슷한 건을 찾는 데 더 오래 걸린다. 승인 기준은 존재하지만 예외 규정이 여러 문서에 흩어져 있다. 최신 규정인지 확인하려고 다른 부서에 메시지를 보내기도 한다.

이 상황에서 자동 승인 기능을 만드는 것은 고객의 요청에는 맞지만 현재의 병목을 충분히 해결하지 못할 수 있다. 엔지니어는 근거 문서를 찾아주고 해당 조항을 보여주는 기능부터 시험하자고 제안한다. 최종 승인은 당분간 사람이 맡는다. 고객이 원한 결과인 처리 시간 단축을 유지하면서 시스템이 맡는 판단의 범위를 줄이는 것이다.

이 결정은 인터뷰만으로 끝나지 않는다. 대표 문서와 과거 처리 기록을 가져와 실제로 근거를 찾을 수 있는지 확인해야 한다. 필요한 문서가 디지털화되어 있지 않거나, 검토자마다 접근 권한이 다르다면 설계가 다시 달라진다.

프로토타입 검증

첫 구현에서는 몇 개의 대표 문서를 넣고 검색 결과를 검토자에게 보여준다. 이때 “답이 맞는가”만 물으면 중요한 정보를 놓친다. 검토자가 결과를 확인할 때 원문을 여는지, 오래된 규정을 알아볼 수 있는지, 설명을 읽은 뒤에도 동료에게 묻는지 관찰한다.

예를 들어 시스템이 근거 문서를 찾았지만 개정 전 조항을 우선 보여준다고 하자. 검색 정확도를 조정하기 전에 문서의 시행 시점과 개정 관계를 데이터로 관리해야 할 수 있다. 모델을 바꾸는 것보다 자료의 구조를 바꾸는 일이 먼저라는 사실을 작은 구현을 통해 알게 된다.

이런 발견은 일정에도 영향을 준다. 문서 정리가 예상보다 크다면 처음부터 모든 부서를 지원하기 어렵다. 한 부서의 특정 문서 유형으로 범위를 좁히고, 무엇을 지원하지 않는지 사용자에게 보여주는 쪽으로 계획을 바꿀 수 있다.

배포 준비

개발이 진행되면 업무 담당자 외의 사람들도 참여한다. 보안 담당자는 문서 접근과 기록 보관을 살피고, IT 담당자는 인증과 배포 환경을 확인한다. 운영 담당자는 문서를 갱신하는 방법과 오류 신고를 어떻게 받을지 묻는다.

FDE는 각 담당자의 요구를 시스템의 동작으로 연결한다. 읽기 권한이 없는 문서는 검색 결과에서도 숨겨야 한다. 근거가 부족한 질문에는 답변을 보류할 수 있어야 한다. 문서 갱신이 실패하면 누군가 알아차릴 수 있어야 한다. 이런 조건이 설계와 테스트에 들어가면서 시연용 구현이 업무용 시스템으로 바뀐다.

승인 권한까지 FDE에게 생기는 것은 아니다. 기술적으로 가능한 선택과 그 영향을 설명하고, 해당 업무에 책임을 지는 사람이 결정하도록 해야 한다. 결정이 미뤄지면 개발에서 무엇을 진행할 수 있고 무엇이 막히는지도 분명해진다.

초기 운영

처음 배포한 날은 프로젝트의 중요한 이정표지만 사용 방식이 안정되는 시점과 같지는 않다. 사용자는 예상하지 못한 문서를 넣고, 검색 결과를 다른 업무에 활용하려 하고, 결과가 불편하면 원래 방식으로 돌아간다.

FDE는 오류 기록과 사용자 반응을 함께 본다. 답변 생성이 성공했는데 사용자가 매번 원문 전체를 다시 읽는다면 검토 부담이 줄지 않았을 수 있다. 인용 위치를 더 정확하게 표시하거나, 답변보다 관련 조항을 먼저 보여주는 편이 나을 수 있다. 이 단계의 수정은 모델 성능뿐 아니라 사용자가 결과를 믿고 확인하는 방식에 관한 개발이다.

운영 인수

고객 운영팀이 새 문서를 등록하고, 실패한 처리를 확인하고, 해결할 수 없는 문제를 정해진 경로로 문의할 수 있게 되면 원래 개발자에게 의존하는 일이 줄어든다. 인수 과정에서는 안내서를 읽었다는 확인보다 실제로 이 작업을 수행해 보는 편이 도움이 된다.

남는 결과물에는 코드뿐 아니라 업무 범위를 바꾼 이유, 평가에 사용한 사례, 남아 있는 제약과 담당자도 포함된다. 다음 개발자는 이 기록을 통해 왜 자동 승인 대신 근거 제시 기능으로 시작했는지 이해할 수 있다.

핵심 요약

FDE의 일은 고객의 첫 요청을 그대로 개발하는 데서 끝나지 않는다. 업무를 관찰하고 작은 구현을 시험하는 동안 문제와 범위가 바뀐다. 배포 이후에도 사용자가 결과를 확인하고 운영팀이 시스템을 관리하는 과정까지 살펴야 프로젝트의 실제 끝이 보인다.