AI R&D 요구사항 정의를 망치는 흔한 문서 작성 습관

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

“정확도가 높은 AI를 만들어 주세요.” 이 한 문장으로 시작한 AI R&D 프로젝트는 대개 중간 보고 시점부터 흔들립니다. 발주자는 기대한 결과가 아니라고 말하고, 개발자는 합의된 기준이 없었다고 답합니다. 문제는 기술력이 아니라 AI R&D 요구사항을 검증 가능한 문장으로 바꾸지 않은 것에서 시작되는 경우가 많습니다.

요구사항 문서는 개발팀에 일을 지시하는 목록이 아닙니다. 데이터의 범위, 사용 환경, 실패 허용 수준, 납품 결과물을 하나의 기준으로 묶는 약속입니다. 실제 현장에서 반복되는 실패 사례를 따라가며 이것만은 하지 말아야 할 문서 작성 습관을 짚어보겠습니다.

목표를 성능 수치 한 줄로 끝내는 실수

정확도만 높으면 성공이라는 착각

가장 흔한 실패는 “정확도 95% 이상”처럼 숫자 하나를 사업 목표로 사용하는 것입니다. 정확도는 어떤 데이터로, 어떤 방식으로 계산했는지에 따라 의미가 크게 달라집니다. 정상 데이터가 95%인 불균형 데이터셋에서는 모든 입력을 정상으로 예측해도 정확도 95%가 나올 수 있습니다.

현업이 원하는 것은 높은 숫자 자체가 아니라 놓치면 안 되는 사례를 제대로 찾아내는 능력일 가능성이 큽니다. 제조 불량 탐지라면 미검출과 오검출의 비용이 다르고, 문서 분류라면 잘못 분류된 문서를 사람이 다시 처리하는 시간이 중요합니다. 따라서 평가지표와 업무 손실을 연결하지 않은 요구사항은 성능 논쟁만 키웁니다.

이것만은 하지 마세요. 공개 데이터로 계산한 수치, 내부 시험 데이터의 수치, 실제 운영 데이터의 수치를 같은 의미로 취급하면 안 됩니다. 연구기관의 역할과 기술 연구의 맥락을 이해할 때는 한국과학기술연구원 관련 지식백과처럼 기관의 성격을 확인할 수 있는 자료도 참고할 수 있지만, 개별 프로젝트의 성공 기준은 반드시 해당 조직의 데이터와 업무 흐름을 기준으로 새로 정의해야 합니다.

• 대상 업무: AI 결과가 실제로 사용되는 부서와 처리 단계를 적습니다.
• 오류 비용: 미검출, 오검출, 응답 지연이 각각 어떤 손실을 만드는지 구분합니다.
• 평가 데이터: 수집 기간, 장비, 지역, 사용자군과 중복 제거 방식을 명시합니다.
• 최소 기준: 전체 평균뿐 아니라 핵심 클래스별 재현율과 정밀도를 함께 둡니다.
• 비교 기준: 기존 규칙 기반 시스템이나 담당자의 현재 처리 성능을 기준선으로 기록합니다.

전문가 팁: “정확도는 몇 퍼센트인가?”보다 “어떤 오류를 줄였을 때 현장 비용이 가장 크게 감소하는가?”를 먼저 물어보세요. 답이 나오면 필요한 지표도 훨씬 선명해집니다.

통제할 수 없는 목표를 확정하는 문제

“모든 환경에서 동작”, “어떤 질문에도 답변”, “오류 없는 자동 판정”과 같은 표현도 위험합니다. AI는 입력 데이터의 범위가 바뀌면 성능이 달라질 수 있으며, 학습 단계에서 보지 못한 예외를 완전히 제거할 수 없습니다. 그런데 문서에 범위를 열어 두면 한 번도 논의하지 않은 상황까지 개발 범위로 해석됩니다.

목표는 야심 차게 정하더라도 검수 조건은 통제 가능해야 합니다. 예를 들어 촬영 거리, 조도, 파일 형식, 지원 언어, 문서 길이, 동시 사용자 수를 정하고 범위를 벗어난 입력에 대해서는 거부 메시지나 사람 검토 절차를 설계해야 합니다. 잘 모르는 입력을 잘못 맞히는 것보다 안전하게 보류하는 기능도 중요한 성능입니다.

1. 운영 환경에서 정상적으로 들어오는 입력 범위를 정의합니다.
2. 범위 밖 입력을 탐지할 조건과 사용자 안내 방식을 정합니다.
3. 자동 처리, 재시도, 담당자 검토로 이어지는 분기 기준을 적습니다.
4. 검수 시 사용할 대표 상황과 고위험 예외 상황을 분리합니다.

데이터 제공 조건을 나중으로 미루는 실수

파일이 있다는 말과 학습할 수 있다는 말의 차이

“데이터는 충분히 보유하고 있습니다”라는 말만 믿고 일정을 확정했다가 첫 달을 파일 정리에 쓰는 프로젝트가 적지 않습니다. 수십만 건의 파일이 있어도 중복, 손상, 개인정보, 잘못된 라벨이 많으면 학습에 사용할 수 있는 양은 급격히 줄어듭니다. 저장 위치를 아는 담당자와 반출 승인 담당자가 다르면 접근 허가에만 몇 주가 걸리기도 합니다.

요구사항 단계에서 데이터 샘플을 열어보지 않고 전체 규모만 기록하는 행동은 피해야 합니다. 최소한 파일 형식, 컬럼 정의, 결측률, 클래스 분포, 기간별 편향, 라벨 생성 주체를 확인해야 합니다. 특히 같은 고객이나 같은 장비에서 나온 데이터가 학습용과 시험용에 동시에 들어가면 데이터 누수로 성능이 부풀려질 수 있습니다.

보유 데이터에 개인정보나 영업기밀이 포함된다면 익명화 책임과 작업 장소도 미리 정해야 합니다. 외부 개발자가 원본을 받는지, 내부 보안 구역에서만 작업하는지, 가공본만 제공되는지에 따라 비용과 일정이 달라집니다. 데이터 제공일이 늦어질 때 전체 일정을 어떻게 조정할지도 계약 일정과 요구사항 문서에 함께 연결해야 합니다.

• 규모 확인: 전체 건수와 실제 열람 가능한 유효 건수를 따로 셉니다.
• 권리 확인: 학습, 평가, 결과물 납품에 데이터를 사용할 권한이 있는지 검토합니다.
• 품질 확인: 무작위 표본뿐 아니라 희귀 사례와 최근 수집분을 함께 살펴봅니다.
• 접근 확인: 계정 발급, 망 접속, 승인 담당자와 예상 소요일을 기록합니다.
• 분할 확인: 시간, 사용자, 장비 단위로 학습·검증·시험 데이터를 분리합니다.

라벨 기준을 작업자의 상식에 맡기는 문제

라벨링 지침을 “전문가가 보면 알 수 있음”으로 남기면 작업자마다 다른 정답이 만들어집니다. 경계가 흐린 사례에서는 숙련자끼리도 판단이 다를 수 있습니다. 이 차이를 모델 오류로만 처리하면 모델을 여러 번 바꿔도 성능은 안정되지 않습니다.

먼저 같은 표본을 두 명 이상이 독립적으로 판정해 일치도를 살펴보세요. 불일치가 집중되는 유형은 정의를 보완하고, 판정 불가나 복수 라벨 같은 선택지도 마련해야 합니다. 억지로 하나의 정답을 붙이는 것보다 불확실성을 데이터로 남기는 편이 연구 결과의 신뢰성을 높입니다.

1. 정상 사례와 경계 사례를 포함한 라벨 예시집을 만듭니다.
2. 판정 근거가 되는 화면 영역이나 문장 구간도 함께 표시합니다.
3. 의견이 갈릴 때 최종 판단할 도메인 전문가를 지정합니다.
4. 지침이 바뀌면 기존 라벨을 어느 범위까지 다시 검수할지 정합니다.
5. 라벨 버전과 수정 이력을 모델 학습 기록에 연결합니다.

데이터 검토 회의에서 “누가 맞는가”만 따지지 마세요. 사람끼리도 합의하기 어려운 사례를 AI에 어떻게 요구할 것인가를 결정하는 자리가 되어야 합니다.

납품물을 모델 파일 하나로 적는 실수

실행 환경과 운영 책임이 빠진 요구사항

모델 가중치 파일을 받았는데 사내 서버에서 실행되지 않는 사례가 있습니다. 개발 환경에서는 특정 GPU와 라이브러리 버전을 사용했지만 발주 조직의 서버에는 다른 운영체제와 제한된 메모리만 있었던 것입니다. “모델 납품”이라는 표현에 실행 환경, 의존성, 호출 방식이 포함되지 않았기 때문에 누구의 책임인지도 모호해집니다.

AI R&D 결과물은 모델 파일만으로 끝나지 않습니다. 추론 코드, 전처리와 후처리 로직, 환경 설치 방법, API 명세, 시험 데이터, 성능 보고서가 함께 있어야 재현할 수 있습니다. 운영을 목표로 한다면 로그 항목, 장애 대응, 모델 교체 절차, 입력 데이터 보관 정책까지 요구사항에 포함해야 합니다.

기업과 기술 조직은 각자 사업 구조와 개발 환경이 다릅니다. 예컨대 우리기술 기업 정보처럼 기술 기업의 배경을 확인하는 자료는 조직 맥락을 이해하는 출발점이 될 수 있습니다. 다만 다른 기업의 산출물 목록을 그대로 복사하지 말고, 실제로 인수할 사람이 재실행할 수 있는 단위를 기준으로 납품물을 정해야 합니다.

• 실행 패키지: 모델, 코드, 라이브러리 버전, 환경 설정 파일을 포함합니다.
• 재현 자료: 학습 조건, 난수 설정, 데이터 버전과 실험 결과를 연결합니다.
• 연동 문서: 입력·출력 형식, 오류 코드, 제한 용량과 응답 시간 기준을 적습니다.
• 검수 도구: 발주자가 같은 결과를 확인할 시험 스크립트와 표본을 제공합니다.
• 운영 문서: 모니터링 항목, 장애 시 우회 절차, 담당자 연락 체계를 담습니다.

연구 성공과 서비스 완성을 섞는 문제

연구 단계의 목표는 기술 가능성과 한계를 확인하는 것이고, 서비스 단계의 목표는 안정적으로 반복 운영하는 것입니다. 두 단계를 한 문장으로 묶으면 연구팀에는 화면 개발과 운영 대응이 갑자기 추가되고, 발주자는 시연 화면을 완성된 시스템으로 오해하기 쉽습니다. 프로토타입의 버튼이 작동한다고 해서 보안, 동시 접속, 장애 복구까지 준비된 것은 아닙니다.

단계를 연구 결과, 시험용 프로토타입, 제한 사용자 실증, 정식 운영으로 나누고 각 단계의 종료 조건을 달리하세요. 연구 실패 가능성도 문서에 넣어야 합니다. 목표 성능에 도달하지 못했더라도 어떤 가설을 검증했고 무엇이 병목인지 설명할 수 있다면 후속 의사결정에 쓸 수 있는 성과가 됩니다.

1. 연구 단계: 기준선 대비 개선 폭과 실패 원인을 확인합니다.
2. 프로토타입 단계: 대표 사용 흐름과 연동 가능성을 시험합니다.
3. 실증 단계: 제한된 실제 사용자와 운영 데이터로 효과를 측정합니다.
4. 운영 단계: 보안, 부하, 복구, 유지보수 책임과 비용을 확정합니다.

비용 항목도 단계에 맞춰 분리하는 것이 좋습니다. 데이터 정제비, 라벨링비, 클라우드·GPU 사용료, 외부 API 호출료, 보안 환경 구축비, 운영 모니터링비를 하나의 개발비로 묶으면 변경 요청이 생길 때 근거를 찾기 어렵습니다. 고정 금액이 어려운 연산비나 API 비용은 단가와 사용량 상한을 두어 관리할 수 있습니다.

상담 분류 프로젝트가 석 달 뒤 다시 출발한 과정

모호한 자동화 요청에서 검수 가능한 범위까지

A사는 고객 상담 내용을 자동으로 분류하는 AI R&D를 시작했습니다. 최초 요구사항은 “상담을 정확히 분류하고 답변까지 자동 추천”하는 두 줄이 전부였습니다. 데이터는 충분하다고 했고 정확도 목표는 90%로 정했지만, 분류 항목과 평가 표본, 답변 추천의 허용 범위는 적지 않았습니다.

개발팀은 과거 상담 시스템에서 약 18만 건을 전달받았습니다. 확인 결과 같은 상담이 이관 과정에서 여러 번 복제돼 있었고, 오래된 상품명이 현재 상품명과 섞여 있었습니다. 상담 유형은 담당자가 자유롭게 입력해 같은 문의가 ‘결제’, ‘요금’, ‘청구’로 나뉘었습니다. 개인정보가 포함된 원문은 외부 개발 환경으로 옮길 수 없어 첫 일정도 멈췄습니다.

두 달 뒤 시연된 모델의 정확도는 92%였습니다. 숫자만 보면 성공이었지만 자주 등장하는 단순 문의에만 강했고, 민원과 해지처럼 놓치면 비용이 큰 유형의 재현율은 낮았습니다. 답변 추천 기능은 과거 문장을 그대로 보여주면서 종료된 상품의 안내까지 제시했습니다. 운영 담당자는 사용할 수 없다고 판단했고, 개발팀은 제시된 정확도를 달성했다고 맞섰습니다.

• 성과지표가 전체 정확도 하나여서 고위험 상담의 실패가 가려졌습니다.
• 데이터 제공 전 품질 표본과 반출 조건을 확인하지 않았습니다.
• 유사한 상담 유형을 합치거나 구분할 업무 기준이 없었습니다.
• 답변 추천에서 금지할 표현과 최신 정보 확인 절차가 빠졌습니다.
• 시연용 화면과 운영 시스템의 범위를 구분하지 않았습니다.

범위를 줄이자 성과가 보이기 시작한 재설계

A사는 프로젝트를 폐기하는 대신 요구사항을 다시 작성했습니다. 우선 자동 답변은 범위에서 제외하고, 상담을 여덟 개 업무 유형으로 분류해 담당 부서에 연결하는 기능에 집중했습니다. 민원, 해지, 개인정보 관련 상담은 별도의 고위험군으로 지정하고 재현율을 우선 지표로 삼았습니다.

데이터는 최근 12개월분으로 제한했습니다. 중복 상담을 제거하고 상품 코드 기준으로 명칭을 통일했으며, 상담 관리자 두 명이 경계 사례를 독립적으로 판정했습니다. 합의되지 않은 사례에는 ‘검토 필요’ 라벨을 부여했습니다. 원문은 내부 보안 환경에 두고 개발자는 비식별 처리된 텍스트와 승인된 원격 환경만 사용했습니다.

검수 조건도 바뀌었습니다. 전체 정확도 외에 고위험군 재현율, 유형별 오분류표, 한 건당 처리 시간, 신뢰도가 낮을 때 사람에게 넘기는 비율을 측정했습니다. 모델이 판단을 보류하면 상담 화면에 이유와 후보 유형 두 개가 표시되도록 했습니다. 덕분에 무리한 자동화 대신 담당자가 빠르게 결정할 수 있는 흐름이 만들어졌습니다.

1. 첫 주: 현업 담당자와 실제 상담 처리 흐름을 그려 병목 구간을 선택했습니다.
2. 둘째 주: 최근 데이터 500건을 함께 읽고 분류 정의와 제외 조건을 고쳤습니다.
3. 셋째 주: 기준 모델을 만들어 유형별 실패 사례와 사람의 처리 성능을 비교했습니다.
4. 여섯째 주: 보류 기능을 포함한 프로토타입을 제한된 상담 인력에게 제공했습니다.
5. 열째 주: 처리 시간과 재분류율을 확인한 뒤 적용 부서를 한 곳 더 늘렸습니다.

재설계된 모델의 전체 정확도는 이전 시연 수치보다 조금 낮았습니다. 그러나 고위험 상담을 놓치는 비율이 줄었고, 자동 분류가 어려운 입력은 담당자에게 안전하게 넘어갔습니다. 상담 관리자는 유형별 오류를 매주 확인해 라벨 지침을 수정했고, 수정된 데이터 버전은 다음 학습 기록에 연결했습니다.

마지막 검수일에는 새로운 상품명이 포함된 상담이 들어왔습니다. 모델은 억지로 기존 유형을 확정하지 않고 ‘검토 필요’로 보류했고, 담당자는 새 상품 코드를 등록한 뒤 해당 사례를 다음 학습 후보에 추가했습니다. 처음 문서가 요구했던 화려한 자동 답변은 없었지만, 모르는 입력을 감지하고 사람의 판단과 다음 개선으로 연결하는 운영 가능한 AI R&D 결과가 그 자리에서 작동했습니다.