캡스톤 프로젝트에서 가장 먼저 해야 할 일은 모델을 고르는 일이 아니다. 검색 엔진을 붙일지, 에이전트 구조를 넣을지, 어떤 벤더를 쓸지를 논의하기 전에 먼저 답해야 할 질문이 있다. 이 시스템은 누구를 위해 존재하는가. 무엇에 답해야 하는가. 무엇에는 답하면 안 되는가. 그리고 무엇을 잘하면 성공이라고 부를 것인가.
내부 지식 도우미를 실패하게 만드는 가장 흔한 원인은 기술이 부족해서가 아니다. 문제를 너무 넓게 잡았기 때문이다. "사내 문서를 다 알아서 답해 주는 AI"는 멋져 보이지만, 실제로는 범위가 지나치게 넓다. 정책 문서, 운영 절차, 보안 규정, 제품 매뉴얼, 인사 기준, 법무 이슈, 예외 승인 프로세스가 한 시스템 안에 뒤섞이면 정확성도 떨어지고 책임 경계도 무너진다. 좋은 시스템 설계는 복잡한 기능을 더하는 데서 시작하지 않는다. 문제를 뾰족하게 좁히는 데서 시작한다.
이 장에서는 최종 캡스톤의 대상인 정책 문서 기반 내부 지식 도우미를 예로 삼아, 서비스 수준의 요구사항을 어떻게 정의해야 하는지 살펴본다. 핵심은 네 가지다. 대상 사용자를 분명히 정하고, 답변 범위를 제한하고, 금지 범위를 명시하고, 성공 기준을 측정 가능하게 만드는 것이다.
왜 문제 정의가 설계보다 먼저인가
많은 팀이 내부 지식 도우미를 만들 때 곧바로 프롬프트 초안부터 작성한다. 하지만 프롬프트는 문제 정의를 구현하는 수단이지, 문제 정의 자체가 아니다. 문제 정의가 흐리면 프롬프트는 길어지고, 예외 처리 규칙은 끝없이 늘어나며, 결국 시스템은 "그럴듯하지만 믿기 어려운 도우미"가 된다.
예를 들어 사용자가 "재택근무 장비 구매비는 얼마까지 청구할 수 있나요?"라고 물었다고 하자. 이 질문에 답하려면 먼저 시스템의 역할이 정해져 있어야 한다. 해당 도우미가 복지 정책만 다루는가, 비용 처리 정책까지 다루는가, 국가별 지사 규정도 포함하는가, 최신 개정 문서를 기준으로 하는가, 애매하면 담당 부서로 넘기는가. 이런 기준 없이 모델만 바꾸거나 프롬프트만 다듬어서는 운영 가능한 품질에 도달하기 어렵다.
문제 정의가 선명하면 이후의 설계가 쉬워진다. 어떤 문서를 인덱싱할지 정할 수 있고, 어떤 질문을 검색 기반으로 처리할지 나눌 수 있으며, 어떤 질문에서는 답변을 거부해야 하는지도 명확해진다. 평가셋을 만드는 일도 훨씬 수월해진다. 결국 문제 정의는 시스템의 첫 번째 안전장치이자 가장 강력한 최적화다.
캡스톤 시나리오: 정책 문서 기반 내부 지식 도우미
이번 캡스톤에서 만들 시스템은 범용 사내 비서가 아니다. 이름은 비슷해 보여도 목표는 훨씬 좁고 실무적이다. 이 시스템의 1차 목적은 내부 정책과 절차 문서에 근거해 직원 질문에 일관되게 답하는 것이다.
여기서 중요한 단어는 "정책", "근거", "일관성"이다. 이 도우미는 창의적인 아이디어를 내는 브레인스토밍 도구가 아니다. 누군가를 대신해 의사결정을 내려 주는 승인 시스템도 아니다. 문서에 근거한 안내자에 가깝다. 즉, 이미 조직 안에 존재하는 규칙과 절차를 더 빠르게 찾고, 이해하기 쉽게 설명하고, 필요한 경우 정확한 담당 채널로 연결하는 역할을 맡는다.
이렇게 정의하면 시스템의 정체성이 분명해진다. 정답을 만들어 내는 기계가 아니라, 문서화된 조직 지식을 안전하게 전달하는 인터페이스가 되는 것이다.
대상 사용자 정의
대상 사용자는 넓게 잡을수록 좋아 보이지만, 실제로는 서비스 품질이 희석된다. 캡스톤에서는 사용자를 전사 임직원 전체로 두기보다, 우선순위가 높은 집단부터 정의해야 한다. 가장 현실적인 시작점은 다음과 같다.
일반 직원: 휴가, 비용 처리, 보안 수칙, 장비 신청, 교육 이수, 출장 규정처럼 반복적으로 묻는 질문이 많다.
팀 관리자: 승인 절차, 예외 요청 경로, 팀 운영에 필요한 정책 확인이 자주 필요하다.
운영 지원 부서의 초급 담당자: 문의 1차 응대에서 문서 위치와 기본 정책을 빠르게 확인해야 한다.
겉으로 보면 세 집단 모두 "질문자"이지만, 실제 요구는 조금씩 다르다. 일반 직원은 빠르고 쉬운 답을 원한다. 관리자는 예외 조건과 책임 범위를 더 중요하게 본다. 운영 지원 담당자는 근거 문서와 절차 링크가 꼭 필요하다. 따라서 대상 사용자 정의는 단순한 사용자 목록이 아니라, 사용자별 질문 의도와 실패 비용을 함께 정리하는 작업이어야 한다.
예를 들어 일반 직원이 복지 포인트 지급 시점을 잘못 이해하면 불편이 생긴다. 하지만 관리자가 승인 권한 범위를 잘못 이해하면 운영상 문제가 커질 수 있다. 같은 "정확성"이라도 사용자에 따라 필요한 답변 깊이와 안전장치가 달라진다는 뜻이다.
이 캡스톤에서는 초기 대상 사용자를 다음처럼 좁히는 편이 좋다.
본사 소속 일반 직원과 팀 관리자
한국어로 질문하는 사용자
정책 문서 열람 권한이 있는 내부 사용자
텍스트 채팅 인터페이스를 이용하는 사용자
이렇게 시작하면 다국어 대응, 지역 법규 차이, 권한별 문서 분리 같은 어려운 문제를 1차 범위 밖으로 둘 수 있다. 좋은 첫 버전은 모든 사람을 만족시키는 시스템이 아니라, 명확한 사용자 집단에서 믿을 수 있게 작동하는 시스템이다.
사용자의 대표 질문을 먼저 모아라
요구사항을 쓸 때 많은 팀이 기능 목록부터 만든다. 하지만 내부 지식 도우미는 기능보다 질문이 먼저다. 사용자가 실제로 무엇을 묻는지 모르면 범위를 정할 수 없기 때문이다.
대표 질문은 다음처럼 수집할 수 있다.
헬프데스크 티켓에서 반복 문의 추출
사내 메신저나 메일에서 자주 등장하는 정책 질문 수집
운영 부서 인터뷰를 통한 상위 20개 문의 정리
신규 입사자, 관리자, 지원 부서별 자주 묻는 질문 분리
이 과정을 거치면 멋있어 보이는 요구사항보다 훨씬 유용한 정보가 나온다. 예를 들어 "이 시스템은 사내 정책을 안내한다"는 문장보다, "사용자는 연차 이월, 경조사 휴가, 재택 장비 비용, 출장 정산 마감일, 보안 교육 이수 기한을 가장 자주 묻는다"는 문장이 훨씬 설계에 도움이 된다. 전자는 추상적이지만, 후자는 인덱싱할 문서와 평가셋을 바로 떠올리게 만든다.
답변 범위 정의
답변 범위는 "어디까지 답할 것인가"를 정하는 일이다. 이 범위를 넓게 잡으면 시스템은 만능처럼 보이지만, 실제로는 가장 중요한 순간에 흔들린다. 따라서 범위는 사용자 기대를 조절할 수 있을 정도로 구체적이어야 한다.
캡스톤의 내부 지식 도우미는 다음 범위 안에서 동작하도록 정의할 수 있다.
인사, 복지, 비용 처리, 정보보안, 장비 신청, 출장, 교육 이수 등 정책 문서에 명시된 내용을 안내한다.
절차형 질문에 대해 필요한 단계, 제출 문서, 담당 부서, 시스템 경로를 요약한다.
답변의 근거가 되는 문서명이나 관련 조항을 함께 제시한다.
문서 간 충돌이나 모호함이 있으면 단정하지 않고 확인 필요 상태로 처리한다.
정책상 예외 가능성이 있는 경우, 예외 승인 주체나 문의 채널을 함께 안내한다.
여기서 중요한 점은 "답변"의 의미를 좁게 보는 것이다. 이 시스템은 사용자의 질문에 대해 정책 문서를 해석해 전달할 수는 있지만, 정책을 새로 만들거나 공식 결정을 대신 내려서는 안 된다. 예를 들어 "이 경우 제가 반드시 승인받을 수 있나요?" 같은 질문에는 확정적 판정을 내려서는 안 된다. 문서상 원칙과 예외 절차를 설명하는 것이 역할의 한계다.
또한 답변 범위에는 정보의 원천도 포함되어야 한다. 어떤 저장소의 어떤 문서를 기준으로 삼는지 정하지 않으면 최신성 문제가 바로 발생한다. 따라서 범위 문서에는 적어도 다음 항목이 들어가야 한다.
포함 문서군: 사내 정책 포털의 공식 게시 문서
우선 버전: 최신 승인본
업데이트 주기: 하루 1회 동기화 또는 게시 시 즉시 반영
제외 문서군: 초안, 개인 노트, 회의 메모, 승인되지 않은 FAQ
이렇게 해야 시스템이 "어디서 답을 가져오는지"가 정해지고, 나중에 근거성 평가와 운영 정책도 안정된다.
금지 범위 정의
좋은 시스템은 많이 답하는 시스템이 아니라, 답하면 안 되는 것을 분명히 아는 시스템이다. 금지 범위는 품질을 제한하는 규칙이 아니라, 품질을 지키는 울타리다.
정책 문서 기반 내부 지식 도우미에서 금지 범위는 대체로 네 종류로 나뉜다.
첫째, 권한을 넘는 판단이다. 시스템은 승인 여부를 확정하거나 인사 평가, 징계, 법적 해석 같은 민감한 결정을 대신해서는 안 된다. 이런 영역은 문서 안내와 담당 부서 연결까지만 허용해야 한다.
둘째, 근거 없는 추정이다. 문서에 없는 내용을 상식이나 패턴으로 메우기 시작하면 내부 지식 도우미는 매우 위험해진다. "보통은 이렇다", "대개 회사들은 이렇게 한다" 같은 답변은 내부 정책 서비스에서는 금지하는 편이 좋다.
셋째, 민감정보 노출이다. 개인 인사정보, 급여, 건강 정보, 조사 기록, 보안 사고 내역처럼 접근 통제가 필요한 데이터는 검색 대상과 답변 대상에서 모두 제외해야 한다.
넷째, 범용 업무 대행이다. 메일 작성, 보고서 요약, 코드 생성, 일정 계획처럼 일반 생산성 도우미 기능은 이번 캡스톤의 핵심 범위가 아니다. 이런 기능을 섞으면 사용자는 시스템을 "뭐든지 해 주는 봇"으로 오해하고, 정책 안내라는 본래 목적은 흐려진다.
금지 범위를 문장으로 정리하면 다음처럼 쓸 수 있다.
공식 문서에 근거 없는 답변 생성 금지
개인별 사례에 대한 법률적, 인사적 확정 판단 금지
비공개 또는 권한 외 문서 인용 금지
사용자 대신 승인, 제출, 변경 같은 실행 행위 수행 금지
일반 목적의 범용 비서 역할 수행 금지
이 규칙은 단순히 프롬프트에만 넣을 것이 아니라, 제품 설명, UI 안내, 실패 응답, 운영 정책에도 똑같이 반영되어야 한다. 사용자가 기대를 잘못 가지면 시스템은 기술적으로 잘 만들어져도 "쓸모없거나 불친절한 도구"로 보이기 쉽다. 반대로 처음부터 역할을 명확히 안내하면 거절도 서비스의 일부가 된다.
성공 기준 정의
"좋은 내부 지식 도우미"라는 말은 너무 모호하다. 성공 기준은 반드시 측정 가능해야 한다. 그래야 평가셋도 만들 수 있고, 개선도 논리적으로 할 수 있다. 이 캡스톤에서는 성공 기준을 네 층으로 나누어 정의하는 것이 좋다.
첫 번째는 정확성이다. 답변이 문서 내용과 일치해야 한다. 단순히 그럴듯한 문장이 아니라, 실제 정책과 맞아야 한다.
두 번째는 근거성이다. 답변이 어디에서 나왔는지 추적 가능해야 한다. 내부 지식 도우미는 특히 이 항목이 중요하다. 사용자는 "왜 그런 답을 했는지"를 확인할 수 있어야 신뢰한다.
세 번째는 범위 준수다. 답변하면 안 되는 질문에 대해 적절히 제한하거나 담당 부서로 넘길 수 있어야 한다. 고품질 시스템은 모든 질문에 답하는 시스템이 아니라, 경계 밖 질문을 안전하게 처리하는 시스템이다.
네 번째는 업무 효율성이다. 사용자가 문서를 직접 뒤질 때보다 더 빨리 필요한 정보를 찾도록 도와야 한다. 정확하지만 너무 느리거나, 답은 맞지만 이해하기 어렵다면 실무 도구로 채택되기 어렵다.
이를 조금 더 운영적으로 풀어 쓰면 다음과 같은 성공 기준을 둘 수 있다.
상위 빈도 질문 세트에서 높은 정답 일치율을 보일 것
답변 가능 질문의 상당수에서 근거 문서 또는 조항을 함께 제시할 것
금지 범위 질문에 대해 무리한 추정 없이 제한 응답을 반환할 것
사용자 질문부터 첫 유의미한 답변까지 걸리는 시간이 기존 문서 검색보다 짧을 것
운영 부서로의 단순 반복 문의를 줄일 것
여기서 중요한 것은 숫자 자체보다 측정 단위가 선명한가다. 예를 들어 "사용자가 만족한다"보다 "정책 FAQ 상위 100문항 기준 정답 일치율", "근거 포함 비율", "부적절한 확답 비율", "평균 응답 시간" 같은 표현이 훨씬 좋다. 나중에 23장에서 평가와 운영 계획을 세울 때도 이런 기준이 그대로 기준선이 된다.
기능 요구사항과 비기능 요구사항
문제 정의가 끝났다면 요구사항은 기능과 비기능으로 나누어 적는 것이 좋다. 기능 요구사항은 시스템이 무엇을 해야 하는지에 관한 것이고, 비기능 요구사항은 어떤 품질로 해야 하는지에 관한 것이다.
기능 요구사항은 다음처럼 정리할 수 있다.
사용자의 정책 관련 질문을 자연어로 입력받는다.
질문과 관련된 공식 문서를 검색한다.
검색된 문서 중 관련 근거를 골라 요약 답변을 생성한다.
가능하면 근거 문서명, 조항, 링크를 함께 제시한다.
답변 범위를 벗어나거나 근거가 부족하면 제한 응답과 문의 채널을 제시한다.
동일 주제의 후속 질문을 이어서 처리한다.
비기능 요구사항은 다음이 핵심이다.
답변은 한국어로 명확하고 간결하게 작성한다.
문서에 없는 내용을 추정하지 않는다.
최신 승인본을 우선 사용한다.
민감정보와 권한 외 문서는 검색 및 응답에서 제외한다.
응답 시간은 실무 사용에 무리가 없을 정도로 유지한다.
로그는 개선과 감사에 활용 가능하도록 남기되, 불필요한 민감정보는 저장하지 않는다.
실무에서는 기능 요구사항만 쓰고 비기능 요구사항을 나중으로 미루는 경우가 많다. 하지만 내부 지식 도우미에서는 오히려 비기능 요구사항이 시스템의 성격을 결정한다. 같은 질문에 답하더라도, 추정을 허용하느냐 금지하느냐에 따라 이 시스템은 검색 보조 도구가 되기도 하고 위험한 자동화 도구가 되기도 한다.
사용자 경험 관점의 요구사항
내부 지식 도우미는 정확하기만 하면 끝나는 시스템이 아니다. 사용자가 답을 믿고 다음 행동으로 이어갈 수 있어야 한다. 그래서 사용자 경험 관점의 요구사항도 초기에 정의해야 한다.
좋은 답변은 세 가지 요소를 함께 갖는다. 먼저 한 줄로 핵심 결론을 말해 준다. 그다음 왜 그런지 근거를 보여 준다. 마지막으로 사용자가 다음에 무엇을 하면 되는지 안내한다. 예를 들어 "가능합니다" 또는 "불가능합니다"에서 끝나는 답변은 실무에서 부족하다. 어떤 조건에서 가능한지, 어디에 신청해야 하는지, 예외는 누구에게 문의해야 하는지까지 이어져야 진짜 도움이 된다.
또한 불확실성의 표현 방식도 중요하다. 문서 근거가 약하거나 부서별 차이가 있을 때는 애매함을 숨기지 말아야 한다. "확인되지 않았습니다", "최신 개정 여부를 담당 부서와 확인해 주세요", "문서 간 차이가 있어 인사팀 문의가 필요합니다" 같은 표현은 품질이 낮아서가 아니라, 시스템이 신뢰할 만하다는 신호다.
범위를 잘못 잡았을 때 생기는 실패
문제 정의가 부정확하면 이후의 모든 설계가 흔들린다. 대표적인 실패는 세 가지다.
첫 번째는 지나치게 넓은 목표다. 내부 지식, 일반 업무 자동화, 보고서 작성, 승인 대행, 외부 정보 검색을 한 시스템에 넣으려 하면 품질 기준도 제각각이 된다.
두 번째는 책임 경계의 부재다. 시스템이 단순 안내자인지, 검토 보조자인지, 의사결정 자동화 도구인지가 불분명하면 실패했을 때 누구의 책임인지도 불분명해진다.
세 번째는 평가 불가능한 목표다. "똑똑한 도우미", "친절한 답변", "사람 같은 응대"는 멋진 표현이지만, 테스트셋과 회귀 테스트로 증명하기 어렵다. 캡스톤의 목표는 인상적인 데모가 아니라 운영 가능한 서비스다. 운영 가능한 서비스는 반드시 측정 가능한 문제 정의를 가진다.
한 페이지 요구사항 초안
캡스톤에서 실제로 사용할 수 있도록, 이 장의 내용을 한 페이지 요약 형태로 정리해 보자.
서비스 목적 정책 문서 기반 내부 지식 도우미를 통해 임직원이 사내 규정과 절차를 빠르게 이해하고 필요한 다음 행동을 알 수 있도록 돕는다.
주요 사용자 본사 소속 일반 직원, 팀 관리자, 운영 지원 부서의 1차 응대 담당자.
주요 질문 영역 휴가, 복지, 비용 처리, 출장, 장비 신청, 정보보안, 필수 교육, 사내 절차.
답변 원칙 공식 문서에 근거해 답변하고, 관련 문서명 또는 조항을 제시하며, 근거가 부족하면 추정하지 않는다.
금지 범위 개인 인사 판단, 법률 자문, 승인 대행, 비공개 정보 노출, 문서에 없는 내용 추정, 범용 생산성 도우미 역할.
성공 기준 반복 정책 질문에서 높은 정답 일치율과 근거 제시율을 확보하고, 범위 밖 질문에 대해 안전하게 제한 응답하며, 기존 수동 검색 대비 더 빠른 안내를 제공한다.
이 한 페이지는 단순 요약이 아니다. 이후의 RAG 설계, 프롬프트 레이어, 권한 경계, 평가셋, 레드팀 시나리오, 운영 지표가 모두 여기서 나온다. 문제 정의가 흔들리면 뒤의 설계는 화려해도 공중에 떠 있게 된다.
마무리
내부 지식 도우미를 만드는 일은 "AI에게 회사 문서를 읽혀 주는 것"이 아니다. 조직 안에서 어떤 질문을 어떤 책임 범위 안에서 처리하게 할지 정하는 일이다. 대상 사용자를 좁히고, 답변 범위를 정하고, 금지 범위를 명시하고, 성공 기준을 측정 가능하게 만드는 순간 비로소 시스템 설계가 시작된다.
좋은 아키텍처는 복잡한 모델 구성에서 나오지 않는다. 문제를 정확히 자르는 칼 같은 정의에서 나온다. 다음 장에서는 이 문제 정의를 바탕으로, 실제 내부 지식 도우미의 시스템 설계를 어떻게 구성할지 살펴보자.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.