“AI로 뭘 할 수 있나요?”라는 질문은 최근에 불편했던 업무 한 건을 고르면 요구사항으로 바꿀 수 있습니다. AI의 기능을 먼저 나열하기보다 누가 어떤 상황에서 무엇을 확인하느라 막혔는지 묻는 것이 출발점입니다. 그다음 입력 자료, 원하는 결과, 완료 기준을 붙입니다.
요구사항은 전문가만 쓰는 문서가 아닙니다. “어제 들어온 문의를 담당자가 분류하고 답변 초안을 확인할 수 있으면 좋겠다”처럼 업무 장면을 설명하는 문장부터 만들면 됩니다. 이 글은 그 문장을 찾기 위한 인터뷰 질문과 정리 방법을 다룹니다.
인터뷰가 필요한 이유는 요청한 기능과 줄이고 싶은 일이 다를 수 있기 때문입니다. 문의를 빨리 분류하는 화면을 만들어도 실제 병목이 답변 근거를 찾는 일이라면 담당자의 부담은 남습니다. 실제 한 건을 따라가면 어느 단계의 결과를 바꿔야 하는지와 그 변화가 유용했는지 확인할 기준을 함께 찾을 수 있습니다.
기능을 묻기 전에 최근의 한 장면을 묻습니다
“어떤 기능이 필요하세요?”라고 물으면 챗봇, 요약, 대시보드 같은 답이 나오기 쉽습니다. 대신 “최근 같은 일을 두 번 확인한 적이 있나요?” 또는 “다른 사람이 올 때까지 처리하지 못한 일은 무엇인가요?”라고 묻습니다. 답을 들으면 그 건의 자료와 처리 과정을 따라갑니다.
예를 들어 “문의가 많아서 힘들다”는 말에는 문의 분류가 늦는 문제와 답변 근거를 찾기 어려운 문제가 함께 들어 있을 수 있습니다. 문의를 자동으로 분류해도 제품 자료를 찾는 시간이 그대로면 기대한 변화가 생기지 않습니다. 불편하다는 표현을 바로 기능으로 번역하지 말고 어떤 단계가 불편한지 한 번 더 묻습니다.
실무자와 책임자가 같은 문제를 다르게 설명하는 것도 확인합니다. 실무자는 반복 입력을, 책임자는 누락과 마감을 걱정할 수 있습니다. 어느 쪽이 맞는지 고르는 대신 각자가 기대하는 결과를 따로 적고 이번 범위에서 함께 확인할 수 있는지 봅니다.
인터뷰에서 사용할 질문과 남길 답
| 질문 | 확인하려는 것 | 남길 답의 형태 |
|---|---|---|
| 가장 최근에 막힌 건을 보여주실 수 있나요? | 추상적인 불편의 실제 상황 | 한 건의 자료와 발생 시점 |
| 그 일을 시작하게 만든 사건은 무엇인가요? | 실행 조건 | 문의 접수, 마감일 도래 등 |
| 처리할 때 어느 자료를 찾아보나요? | 필요한 입력과 기준 | 자료 위치와 관리 역할 |
| 결과를 다음에 누가 사용하나요? | 산출물의 용도 | 담당 역할과 다음 행동 |
| 무엇이 빠지면 진행할 수 없나요? | 필수 정보와 예외 | 보완 요청할 항목 |
| 결과가 맞는지는 어떻게 확인하나요? | 검증 방법 | 대조할 원본과 판정 기준 |
| 이번에는 어디까지 바꾸면 되나요? | 적용 범위 | 포함 업무와 보류 업무 |
질문을 모두 빠르게 소화하는 것보다 한 답을 실제 자료와 연결하는 편이 낫습니다. “매뉴얼을 본다”는 답이면 어느 매뉴얼의 어떤 부분인지 확인합니다. “담당자가 알아서 한다”는 답이면 판단에 사용한 조건을 설명해 달라고 요청합니다. 말로 정하기 어려운 조건은 미확정 질문으로 남깁니다.
설명용 예시: 문의 자동화를 업무 문장으로 바꾸기
처음 요청이 “고객 응대를 AI로 해 주세요”라고 가정해 보겠습니다. 인터뷰 결과, 이번에 줄이고 싶은 일은 영업 담당자가 문의 내용을 읽고 제품명과 질문 유형을 옮겨 적는 일이었다고 합시다. 가격 협상과 계약 조건 판단은 이번 범위에서 보류합니다.
이때 요구사항은 다음처럼 쓸 수 있습니다. “운영 담당자는 새 문의를 받으면 문의 원문에서 제품명과 질문 유형을 추출한 초안을 확인하고, 빠진 정보가 있으면 보완 요청 대상으로 분리할 수 있어야 합니다.” 누가 쓰는지, 언제 시작하는지, 무엇을 받는지, 다음 행동이 무엇인지가 들어 있습니다.
답변 작성까지 포함하려면 근거 자료를 추가로 정해야 합니다. 제품 설명과 정책 문서 중 어떤 자료를 기준으로 삼을지, 근거가 충돌하면 누구에게 넘길지 확인합니다. 분류 요구와 답변 요구를 한 문장으로 합쳐 놓으면 어느 부분이 완료됐는지 판정하기 어려워집니다.
요구사항이 되는 과정
완료 기준은 정상과 예외를 함께 적습니다
“문의 분류가 잘된다”는 표현만으로는 검수하기 어렵습니다. 제품명이 명확한 문의, 제품명이 없는 문의, 여러 제품이 섞인 문의를 준비하고 각 경우에 기대하는 결과를 적습니다. 없는 제품명을 만들어 넣지 않는지, 확인이 필요한 이유가 표시되는지도 봅니다.
정답을 정할 수 없는 입력은 별도 보류 대상으로 두어야 합니다. 담당자 사이에서도 답이 다르다면 모델 성능을 평가하기 전에 업무 규칙부터 합의합니다. 테스트에서 틀렸다는 사실과 기대 결과 자체가 미정이라는 사실은 다른 문제입니다.
요구사항마다 근거 자료와 결정 역할을 연결하면 나중에 요청이 바뀔 때도 도움이 됩니다. 누가 먼저 말했는지보다 어떤 업무 조건 때문에 정했는지 남겨야 합니다. “영업팀 요청”에서 멈추지 말고 “출고 전 확인이 필요해서”처럼 이유를 적습니다.
인터뷰를 마친 뒤 확인할 항목
- 요청을 설명할 실제 업무 자료가 한 건 이상 있습니까?
- 결과를 사용하는 사람과 다음 행동을 설명할 수 있습니까?
- 정상 입력과 정보가 빠진 입력의 기대 결과가 나뉘어 있습니까?
- 미확정 규칙에 답할 내부 책임자가 정해졌습니까?
- 이번에 할 일과 다음 검토로 넘길 일을 구분했습니까?
개발 범위 전체를 정리하는 단계라면 ERP 요구사항 체크리스트를 이어서 활용하세요. 자동 전송과 사람 확인의 경계는 AI 업무의 사람 승인 기준에서 별도로 볼 수 있습니다.
시온랩의 S-Agent는 사내 데이터와 권한에 연결해 조회와 업무 실행을 구성하는 서비스입니다. 연결 전에 우리 회사가 먼저 정할 것은 “AI에게 무엇이 가능한가”보다 “이번 업무에서 어떤 결과를 확인할 것인가”입니다. 최근 막힌 한 건을 가져오면 그 질문부터 함께 구체화할 수 있습니다.
