기획과 지원의 담당 범위

요청을 받자마자 기능을 약속하지 않습니다

동아리 운영자가 “승인 알림을 만들어 주세요”라고 말했습니다. 신입 기획자가 곧바로 알림 버튼을 그리면 해결 방법이 먼저 고정됩니다. 신청자가 결과를 못 찾는지, 운영자가 검토하지 않았는지, 안내 문구를 이해하지 못하는지는 아직 모릅니다. 기획의 첫 책임은 요구한 기능을 받아 적는 데서 한 걸음 더 나아가, 누가 어떤 상황에서 무엇을 못 하고 있는지 확인할 질문을 만드는 일입니다.

이번 트랙은 행사 신청 업무 개선 제안서를 만드는 연습입니다. 결과물은 실제 서비스 배포가 아니라 조사 근거, 화면 초안, 인수 기준, 지원 안내와 관찰 결과의 묶음입니다. 실습은 별도 폴더에 내려받아 수행하며 Python 3와 터미널을 사용합니다. 실제 학교 계정이나 운영 서버에는 접속하지 않습니다. 등장하는 사용자는 가상 인물이며 예제 수치와 상황은 실제 조사 결과가 아닙니다. 세 개의 문서 실습에서는 제출 기준에 맞는 글을 작성하고, 파일 실습과 모듈 미션에서는 제공 검사 명령으로 구조를 확인합니다.

사용자 문제·해결 후보·담당 업무를 나눕니다

사용자 문제는 달성하려던 목표와 막힌 조건을 함께 적습니다. “알림이 없다”는 기능의 부재를 표현하지만 사용자의 목표를 충분히 설명하지 못합니다. “신청자는 다음 일정을 정하려고 승인 결과를 확인하려는데 결과가 어디에 있는지 몰라 운영자에게 다시 묻는다”로 쓰면 조사할 행동이 보입니다. 이 문장은 지금은 제공된 사례의 요약입니다. 실제 사용자를 관찰하기 전에는 모든 신청자가 그렇다고 확대하지 않습니다.

해결 후보에는 상태 화면, 안내 문구, 운영자 처리 절차, 알림 등을 나란히 둡니다. 기술적 난이도와 실제 원인은 조사 뒤에 확인합니다. 담당 업무는 후보와 다릅니다. ‘사용자 문의를 가명으로 기록한다’는 지원의 행동이고, ‘승인 상태가 누락되는 조건을 재현한다’는 개발팀에 전달할 분석 작업입니다. 같은 문제에 여러 역할이 참여해도 각 역할이 남길 산출물은 서로 달라집니다.

역할	이번 연습의 책임	다른 역할에 전달할 자료
기획	문제와 범위의 근거를 정리하고 조건을 합의합니다.	문제 문장·범위표·판단 이유
개발	구현 가능성과 실패 원인을 확인합니다.	재현 결과·기술 제약·수정 영향
지원	환경과 문의 내용을 수집하고 확인된 해결 절차를 안내합니다.	재현 단계·사용자 영향·해결 확인
행사 운영자	업무 규칙과 실제 승인 절차를 설명합니다.	검토 기준·처리 예외·업무 승인

표는 이 교육 프로젝트의 책임 배치입니다. 실제 회사에서는 직함이 같아도 권한이 다르므로 조직의 담당자와 확인합니다. 기획자가 업무 규칙을 정리할 수 있어도 실제 승인 기준을 혼자 바꿀 권한이 생기지는 않습니다. 개발자가 수정안을 설명했다고 해서 사용자 안내가 자동으로 끝나지도 않습니다. 담당자 이름을 외우기보다 결정 권한과 확인 행동을 묻는 습관을 익힙니다.

책임표는 다음 행동까지 적습니다

책임표의 한 줄은 작업, 주담당, 협의 대상, 전달물 네 칸으로 만듭니다. 주담당은 현재 단계가 끝났는지 확인할 한 역할입니다. 협의 대상은 필요한 사실이나 판단을 제공하는 역할입니다. 전달물에는 ‘공유’ 같은 동사만 쓰지 않고 무엇을 어느 조건에서 넘길지 적습니다. 예를 들어 ‘지원이 문의를 접수하고 개발에 발생 화면, 재현 순서, 가명 사례 ID를 전달한다’라고 쓰면 다음 사람이 시작할 수 있습니다.

‘로그인이 안 된다’는 문의가 왔다면 지원은 화면 문구와 발생 조건을 먼저 확인하고 비밀번호는 받지 않습니다. 기획은 실패가 신청 흐름을 어디에서 막는지 정리합니다. 개발은 전달받은 재현 조건으로 원인을 확인합니다. 기획자가 서버를 재시작하거나 지원이 미확인 원인을 사용자에게 단정하는 행동은 이 연습의 담당 범위를 벗어납니다. 모르는 내용은 담당자에게 물을 질문으로 남깁니다.

개발 전달물은 ‘오류 수정 부탁’만으로 끝내지 않습니다. ‘가상 신청자 P01이 제출 버튼을 한 번 누른 뒤 완료 문구를 보았으나 신청 목록이 비어 있었다’처럼 행동과 결과를 분리하고, 원인을 모르면 미확인으로 씁니다. 지원 전달물은 ‘서버 오류일 것’이라는 추측보다 사용자가 본 화면, 재시도 여부, 영향 범위를 우선합니다. 기획자는 이를 읽고 조사할 조건과 제외할 조건을 구분합니다.

접수부터 마무리까지 한 건을 따라갑니다

운영자의 승인 알림 요청을 접수한 뒤 기획은 요청 문장 그대로와 확인 질문을 남깁니다. 지원에 비슷한 문의가 있었는지 가명 사례를 요청하고 운영자에게 현재 결과 전달 방식을 확인합니다. 개발에는 구현 약속이 아닌 조사에 필요한 기술 제약 질문을 보냅니다. 사례가 모이면 해결 후보를 비교하고 담당자와 범위를 합의합니다. 이번 레슨에서 완료하는 것은 기능 개발이 아니라 이 협업의 첫 책임표입니다.

완료 기준도 역할별로 씁니다. 기획은 대상과 질문을 검토받았을 때, 지원은 필요한 증거와 전달 대상이 정리되었을 때, 개발은 확인해야 할 조건과 반환할 결과가 합의되었을 때 해당 준비 작업을 마칩니다. 일정이 급하다는 이유로 준비 단계와 구현 완료를 같은 것으로 표시하면 나중에 누가 어떤 사실을 확인했는지 복구하기 어렵습니다. 상태는 준비·확인 중·합의처럼 실제 행동에 맞춰 적습니다.

신입에게 자주 생기는 책임의 빈칸

‘모두 담당’은 협력이 좋아 보이지만 누가 누락을 발견할지 모호해집니다. 주담당을 한 역할로 정하고 나머지는 협의 대상으로 둡니다. ‘개발이 다 해결’이라고 적으면 사용자 목표와 업무 규칙 확인이 빠집니다. 반대로 기획이 기술 구현 방식까지 확정하면 검토 전 약속이 생깁니다. 각 줄에서 담당자를 지운 뒤에도 어떤 결과물이 필요한지 알 수 있는지 읽어 보면 빈칸을 찾기 쉽습니다.

책임표가 충돌하면 사람을 탓하기 전에 작업을 쪼갭니다. ‘신청 오류 처리’라는 한 줄을 문의 접수, 조건 확인, 원인 분석, 수정 검증, 결과 안내로 나누면 책임의 경계가 드러납니다. 이번 제출에서는 적어도 세 작업을 나누고 담당을 배정합니다. 그중 하나는 기술 확인이 필요한 사례로 정해, 아는 사실과 담당자에게 물을 질문을 함께 남깁니다.

요청: 승인 알림을 만들어 주세요.
질문: 최근 결과를 확인했던 상황은 무엇인가요?
질문: 현재 결과는 어떤 경로로 전달하나요?