업무 담당자 가이드 — 개발 지식 없이 AI와 함께 기능을 요청하고 확인하기
대상: 업무를 가장 잘 아는 사람(현업 담당자, 기획자, 제품 책임자). 코딩이나 화면 설계 지식은 필요 없습니다.
이 문서에서 할 수 있는 일
- 원하는 일을 개발팀이 바로 쓸 수 있는 문서(
intent.md)로 정리한다 - 업무 규칙을 모호함 없이 확정한다
- 만들어진 결과를 시나리오로 확인한다
- 변경 요청과 장애 신고를 정확하게 한 다
목차
- 전체 흐름에서 내가 하는 일
- 1단계 — 원하는 일 쓰기 (
intent.md) - 2단계 — 업무 규칙 확정하기
- 3단계 — 명세 검토하기
- 4단계 — 인수 시나리오로 확인하기
- 변경 요청·장애 신고 방법
- AI에게 요청할 때 지켜야 할 것
- 용어 풀이
1. 전체 흐름에서 내가 하는 일
[나] 의도 쓰기 → [나+개발자] 규칙·명세 확정 → [개발자] 계획·구현·점검 → [나] 인수 확인 → [운영자] 배포
| 단계 | 내가 하는 일 | 결과물 |
|---|---|---|
| 1 | 문제와 원하는 결과를 내 말로 쓴다 | intent.md |
| 2 | 업무 규칙의 숫자·경계·예외를 정한다 | 규칙 표 |
| 3 | 명세를 읽고 "내가 원한 것"인지 확인한다 | 승인 또는 수정 요청 |
| 4 | 인수 시나리오대로 직접 써 본다 | 통과/실패 기록 |
개발은 "무엇을 만들지가 정확할수록" 빨라지고 틀리지 않습니다. 이 단계들은 그 정확함을 만드는 일입니다.
2. 1단계 — 원하는 일 쓰기 (intent.md)
2-1. AI와 대화로 만들기
처음부터 문서를 쓰지 않아도 됩니다. AI에게 상황을 말하면 질문을 해 주고, 대화가 끝나면 문서로 정리해 줍니다. 템플릿을 AI에게 첨부하세요.
나는 총무팀 담당자야. 지금은 부서원이 엑셀로 비품을 신청해서 메일로 보내고, 내가 월말에 합쳐서 구매해.
누락이 자주 있고 부서별로 한도를 넘게 신청하는 경우도 있어. 이걸 시스템에서 처리하고 싶어.
첨부한 intent.md 템플릿에 맞춰 정리하기 전에, 내가 빠뜨린 것을 알아내도록 질문을 5~8개 해 줘.
기술 용어는 쓰지 말고, 한 번에 질문 두세 개씩만 물어봐.
AI가 묻는 것(예): 누가 신청하나요? 누가 승인하나요? 한 번에 몇 품목? 한도는 부서 기준인가요 개인 기준인가요? 월의 기준일은? 신청 후 취소·수정이 가능한가요? 기존 엑셀 데이터는 옮겨야 하나요?
답을 다 한 뒤:
지금까지 내용으로 intent.md를 작성해 줘. 내가 말하지 않은 내용은 추측하지 말고 "미해결 질문"에 넣어 줘.
2-2. 좋은 예 / 나쁜 예
| 나쁜 예 | 좋은 예 |
|---|---|
| "비품 신청 화면을 만들어 주세요" | "부서원이 비품을 신청하고, 총무팀이 월별로 현황을 한 화면에서 확인한다. 지금은 월말에 엑셀 12개를 합치는 데 반나절이 걸린다." |
| "한도를 적당히 두세요" | "한 부서는 한 달에 최대 5건. 취소한 건은 세지 않는다." |
| "빠르게 처리되면 좋겠어요" | "신청 후 총무팀 화면에 즉시 보인다. 목록 조회는 3초 안에." |
| "기존처럼" | "기존 엑셀의 열: 품목, 수량, 사유, 신청일. 같은 항목을 유지한다." |
2-3. 직접 쓸 때의 체크
- 문제: 누가 어떤 불편/위험을 겪는지 숫자와 함께
- 원하는 결과: 화면 모양이 아니라 "할 수 있는 일"
- 업무 규칙(초안): 한 줄에 하나, 숫자·기준 포함
- 범위 밖: 이번에 하지 않는 일
- 성공 기준: 측정 가능
- 미해결 질문: 모르는 것은 솔직히 적기
- 개인정보·비밀번호·실제 고객 데이터를 쓰지 않았다
완성한 intent.md는 개발팀이 정한 위치(보통 저장소의 intent/ 폴더, 또는 티켓)에 올립니다. 올리는 방법이 어렵다면 개발자에게 파일을 전달해도 됩니다.
3. 2단계 — 업무 규칙 확정하기
시스템은 "적절히"를 구현할 수 없습니다. 개발자와 AI가 규칙 표를 만들면, 담당자는 빈칸을 채우고 예외를 정해 주는 역할입니다. 규칙 표 템플릿.
3-1. 규칙마다 확인할 질문
| 질문 | 예 |
|---|---|
| 숫자의 경계는? | 5건 "이상"이 막히나, 5건 "초과"가 막히나? |
| 기준 시점은? | 월의 기준은 신청일? 승인일? 한국 시간 기준 자정? |
| 취소·수정 시 어떻게? | 취소한 건은 한도에서 빠지나? |
| 규칙이 바뀌면 기존 건은? | 한도를 5에서 3으로 줄이면 이미 4건인 부서는? |
| 규칙을 여러 개 어기면? | 비활성 + 한도 초과일 때 어떤 사유를 보여 주나? |
| 누가 예외를 승인하나? | 한도 초과 예외 신청 가능? 승인자는? |
| 규칙의 근거는? | 규정 문서, 결재자 |
3-2. 조건이 여러 개일 때: 결정표
/handstack-rules-and-verification 아래 규칙을 결정표로 만들어 줘. 빠진 조합이 없는지, 서로 겹치는 규칙이 없는지 확인해서 알려 줘.
- 비활성 부서는 신청할 수 없다
- 당월 신청이 5건이면 더 신청할 수 없다
- 품목이 단종이면 신청할 수 없다
- 여러 사유가 겹치면 위 순서대로 첫 사유만 보여 준다
결과(표)를 읽고 "이 칸의 결과가 내가 원한 것이 맞는지" 만 확인하면 됩니다. 이 표에서 테스트 케이스가 자동으로 나옵니다.
4. 3단계 — 명세 검토하기
개발자가 만든 spec.md(템플릿)를 받으면 아래 순서로 읽습니다. 분량이 많아도 이 질문들만 답하면 됩니다.
4-1. 체크리스트
- 요구사항 요약이 내가 쓴
intent.md의 "원하는 결과"와 같은 일을 말한다 - 미해결 질문이 답변됐거나 다음 단계로 명시적으로 넘겨졌다
- 규칙 표의 숫자·경계·예외가 내 의도와 같다
- 화면: 누가 어떤 화면에서 무엇을 할 수 있는지가 업무 순서와 맞다
- 권한: 조회/등록/수정/삭제/승인을 각각 누가 하는가 (메뉴가 보이는 것과 서버가 허용하는 것은 별개)
- 우려와 충돌 항목에 내가 결정할 것이 남아 있지 않다
- 범위 밖에 들어간 것이 사실은 꼭 필요한 일이 아닌가
4-2. 화면 상태 확인 (자주 빠지는 부분)
화면마다 아래 일곱 가지 상황에서 사용자에게 무엇이 보이는지 적혀 있어야 합니다. 빠진 칸이 있으면 되돌려 보내세요.
| 상황 | 예 |
|---|---|
| 처음 열었을 때 | 조회 조건 안내 |
| 조회·저장 중 | 버튼이 잠기고 "처리 중" |
| 결과가 없을 때 | "조건에 맞는 신청이 없습니다" (오류 아님) |
| 입력이 잘못됐을 때 | 어느 칸이 왜 잘못됐는지 |
| 규칙에 걸렸을 때 | "이번 달 신청 한도(5건)를 초과했습니다" |
| 성공했을 때 | 신청 번호와 확정된 내용 |
| 응답을 못 받았을 때 | "저장 여부를 확인 중입니다. 목록에서 확인 후 다시 시도하세요" |
4-3. AI에게 질문하기
첨부한 spec.md를 업무 담당자 입장에서 검토해 줘. 기술 용어 없이 답해 줘.
(1) 내 intent.md와 다르게 해석된 부분, (2) 규칙 표에서 경계가 모호한 곳,
(3) 화면 상태 중 빠진 것, (4) 내가 결정해야 하는데 결정하지 않은 항목을 표로 정리해 줘.
5. 4단계 — 인수 시나리오로 확인하기
개발자가 "완료"라고 하면 시나리오대로 직접 써 봅니다. "마음에 드세요?"가 아니라 "이 과업을 할 수 있나요?"로 확인합니다.
5-1. 시나리오 예
| 번호 | 시나리오 | 기대 결과 | 관련 규칙 |
|---|---|---|---|
| S1 | 영업팀 김 대리가 모니터 2개를 신청한다 | 신청 번호가 나오고 목록에 보인다 | BR-01 |
| S2 | 이미 이번 달 5건을 신청한 영업팀이 6번째를 신청한다 | "월 한도 초과" 메시지, 목록에 추가되지 않음 | BR-01 |
| S3 | 같은 신청서에서 [저장] 을 빠르게 두 번 누른다 | 한 건만 저장(중복 방지가 설계에 포함된 경우) | 재시도 |
| S4 | 권한 없는 직원이 총무팀 현황 화면을 연다 | 메뉴가 안 보이거나 접근이 거부된다 | 권한 |
| S5 | 신청을 취소한 뒤 다시 신청한다 | 취소한 건은 한도에서 빠진다 | BR-03 |
| S6 | 월말 마지막 날 23:59와 다음 달 00:00에 신청한다 | 각각 해당 월로 집계 | 경계 |
5-2. 결과 보고서 읽는 법
개발자의 보고에는 어떤 수준까지 확인했는지가 적혀 있어야 합니다.
| 표시 | 의미 | 담당자가 할 일 |
|---|---|---|
| 정적 | 코드·계약의 연결을 읽어서 확인(실행하지 않음) | 안심하지 말고 실제 화면 확인 필요 |
| SQL 단독 | 테스트 DB에서 SQL만 실행 | 화면 동작은 아직 미확인 |
| 거래 실행 | 서버 거래를 실제로 호출 | 화면 표시는 미확인일 수 있음 |
| 화면 | 브라우저에서 시나리오 수행 | 직접 한 번 더 확인 |
| 미수행(이유) | 하지 못함 | 위험을 이해하고 인수 시점에 직접 확인 |
"테스트 100% 통과"만으로 받아들이지 마세요. 어떤 시나리오를 다뤘는지, 남은 위험이 무엇인지 물어보세요.
5-3. 인수 판단
- 시나리오가 모두 기대 결과대로 동작한다 (실패한 것은 결함으로 기록)
- 중대한 미해결 결함이 없다
- 운영 안내(사용 방법, 문의처)와 권한 설정이 준비됐다
- 시범 운영 기간 동안 성공률, 거절 사유, 오류를 누가 확인하는지 정해졌다
6. 변경 요청·장애 신고 방법
6-1. 변경 요청 (기존 기능 수정)
## 변경 요청: <한 줄 제목>
- 화면/메뉴: (알면) 비품 신청 > 신청 목록
- 현재 동작: 신청 목록에서 상태로 필터링할 수 없다
- 원하는 동작: 상태(신청/승인/반려)를 선택해 조회한다
- 이유/효과: 월말 정리에 하루 3시간 소요
- 규칙 변경 여부: 없음 / 있음(어떤 규칙?)
- 긴급도: 이번 달 안 / 다음 분기
필드 하나 추가하는 작은 변경도 화면·서버·권한에 영향이 갑니다. "규칙 변경 여부"와 "영향받는 화면"을 같이 알려 주면 개발자가 놓치지 않습니다.
6-2. 장애 신고
개발자/운영자가 원인을 빨리 찾도록 재현 방법을 적어 주세요.
## 장애 신고
- 언제: YYYY-MM-DD HH:MM경 (처음 발견)
- 어디서: 비품 신청 > 신청 목록 (환경: 운영/검증)
- 한 일: 조회 조건에 '영업팀' 입력 → [조회] 클릭
- 화면에 나온 메시지 (그대로): "거래 응답 정의와 데이터 갯수가 다릅니다"
- 기대한 결과: 영업팀의 신청 목록
- 얼마나 자주: 항상 / 가끔 / 한 번
- 영향: 총무팀 5명이 조회 불가
- 화면 캡처: (첨부 — 개인정보 가리기)
메시지는 한 글자도 바꾸지 말고 그대로 적어 주세요. 오류 문구가 원인을 찾는 가장 큰 단서입니다.
7. AI에게 요청할 때 지켜야 할 것
- 개인정보·비밀번호·키·실제 고객 데이터를 붙여 넣지 않습니다. 예시가 필요하면 가짜 데이터로 바꾸세요.
- 사내 정책 문서를 첨부할 때는 조직의 규칙(허용된 도구인지)을 먼저 확인합니다.
- AI가 모르는 것을 지어내는 경우가 있습니다. 규칙의 숫자·근거는 내가 확인하고, AI가 "추측"이라고 표시한 부분은 사실로 받아들이지 않습니다.
- AI가 만든 문서의 책임은 승인한 사람에게 있습니다. 내용을 읽고 승인하세요.
- 운영 환경의 변경(배포, 설정, 데이터 수정)을 AI에게 직접 시키지 않습니다. 운영자의 승인 절차를 거칩니다.
8. 용어 풀이
| 용어 | 쉬운 설명 |
|---|---|
| 화면 | 사용자가 보는 한 장의 업무 페이지. 화면 ID(예: SUP010)로 구분 |
| 거래 | 화면이 서버에 "조회/저장해 줘"라고 보내는 요청 하나. 서비스 ID(예: LD01)로 구분 |
| 계약 | 거래가 서버에서 어떻게 처리되는지 적은 설명서 파일(.txn, .dbc 등). 화면과 서버를 이어 준다 |
| 메뉴 | 화면을 열 수 있는 목록. 메뉴가 보이는 것과 서버가 허용하는 것은 별개 |
| 권한/역할 | 누가 무엇을 할 수 있는지 |
| 환경 | 개발(D), 검증(S), 운영(P). 운영에서 먼저 시험하지 않는다 |
| 규칙 표 | 업무 규칙을 한 줄씩 정리한 표. 테스트의 기준 |
| 결정표 | 조건 조합마다 결과를 정리한 표 |
| 인수 | 만들어진 결과를 업무 담당자가 확인해 받아들이는 것 |
| PR(변경 요청) | 개발자가 코드 변경을 검토받기 위해 올리는 단위 |
| 릴리즈 | 운영에 새 버전을 반영하는 것 |
| 롤백 | 문제가 있을 때 이전 버전으로 되돌리는 것 |