SA 기획: 경험 기반의 아이디어를 현실화

카카오 채널로 발주를 받아 자동으로 ERP에 넣는 화면을 만들었다고 해 봅시다. 데모에서는 문제없이 돌았고 고객도 만족했습니다. 그런데 출시 첫 주에 거래처 담당자가 수량 칸에 규격을 잘못 눌러 보냈고, 그 값이 그대로 ERP에 들어갔습니다. 이걸 누가 발견하고, 누구에게 알리고, ERP의 어느 값을 고쳐야 하는지는 화면설계서 어디에도 적혀 있지 않았습니다.

화면이 끝나는 지점에서 시작되는 질문

현장에서는 이런 말이 자주 나옵니다.

데모 통과했으니 끝난 거 아닌가요

아이디어를 현실화한다는 것을 "예쁜 화면과 동작하는 기능을 만드는 일"로 이해하면 이 질문에 답할 수 없습니다. SA 기획이 요구사항 정의서에 "카카오 채널로 발주를 받는다"고 써 두어도, 그 문장은 잘못된 값이 들어왔을 때 무엇을 해야 하는지는 말하지 않습니다. 요구사항이 끝나는 지점과 시스템이 실제로 돌아가는 지점 사이에는 항상 이런 빈틈이 남고, 이 빈틈을 메우는 일이 곧 현실화입니다.

프론트 설계부터 운영까지, 한 사람이 이어 보는 이유

이 빈틈은 화면 하나만 보고는 찾아지지 않습니다. 발주 화면의 입력 값이 ERP의 어느 테이블에 들어가는지, 잘못된 값이 들어갔을 때 담당자가 어느 화면에서 그것을 확인하는지, 확인한 값을 고치면 이미 나간 세금계산서는 어떻게 되는지까지 이어 봐야 빈틈이 보입니다. 프론트 화면과 데이터베이스와 운영 절차를 따로 맡은 사람 셋이 있으면, 이 셋을 잇는 질문은 누구의 담당도 아닌 채로 남습니다. 저는 이 잇는 역할이 플랫폼 전체를 한 사람이 볼 때만 제대로 작동한다고 봅니다.

SA와 PM 사이, 현실화를 맡는 역할

	정의하는 것	결과물	실패하면 드러나는 곳
SA 기획	무엇을 만들지	요구사항 정의서	검수 회의
서비스 기획	화면이 어떻게 동작할지	화면설계서	사용 지표
현실화(PM)	완성 후 누가 어떻게 돌릴지	운영 인수인계 문서	출시 첫 달

앞의 두 줄은 SA 기획과 서비스 기획이 이미 정의합니다. 세 번째 줄, 운영 인수인계 문서를 실제로 쓰는 사람은 조직마다 다릅니다. 외주로 시스템을 받는 제조업체처럼 SA와 서비스 기획과 운영 기획을 나눌 인력이 따로 없는 곳에서는 이 세 번째 줄을 PM이 떠맡습니다. 요구사항과 화면 설계를 이미 알고 있는 사람이 그 사이의 빈틈도 가장 먼저 알아채기 때문입니다.

운영 인수인계 문서에 실제로 들어가야 할 것

이 문서에 무엇을 적어야 하는지는 표준 양식이 없습니다. 저는 최소한 세 가지는 빠지면 안 된다고 봅니다. 첫째는 확인 경로입니다. 잘못된 값이 들어왔을 때 담당자가 어느 화면, 어느 메뉴에서 그것을 발견하는지를 적습니다. 둘째는 되돌리는 절차입니다. 값을 고치면 그 값에 연결된 다른 문서, 이미 나간 세금계산서나 발주 확인서가 어떻게 되는지를 적습니다. 셋째는 연락 체계입니다. 담당자가 혼자 못 고치는 값이면 누구에게, 어떤 경로로 알려야 하는지를 적습니다.

앞서 나온 카카오 발주 사례라면, 확인 경로는 "수량 칸의 값이 재고 최대치를 넘으면 주문 목록 화면에 빨간 표시가 뜬다"처럼 구체적이어야 합니다. "이상 발주를 확인한다"는 문장은 화면설계서에서도 인수인계 문서에서도 검증할 수 없는 문장입니다. 세 가지 다 화면설계서에는 나오지 않는 정보이기도 합니다. 화면설계서는 정상 경로만 그리고, 이 세 가지는 정상 경로를 벗어났을 때만 필요하기 때문입니다.

서비스 기획자가 이 역할을 대신하기 어려운 이유

서비스 기획자도 화면과 정책을 잘 압니다. 그런데 서비스 기획은 불특정 다수의 사용자를 상대하고, 정책을 다음 달에 또 바꿀 수 있다는 전제로 일합니다. 이 인수인계 문서가 다루는 것은 반대로 특정 조직 하나의 회계 마감 주기, 특정 담당자의 권한, 이번 계약에서 합의한 범위처럼 그 회사에만 해당하는 사실입니다. 이 사실은 서비스 기획자가 아니라 요구사항을 직접 들었던 사람의 머릿속에만 있습니다.

그래서 저는 이 역할을 서비스 기획자에게 넘기면 문서의 절반, 화면이 어떻게 동작하는지는 채워지지만 나머지 절반, 이 회사만의 예외는 비어 있는 채로 남는다고 봅니다. 요구사항을 처음 들었던 사람이 결국 다시 불려 오는 이유입니다.

조직이 커지면 이 역할은 다시 나뉜다

이 글은 SA와 서비스 기획과 운영 기획을 나눌 인력이 없는 조직을 전제로 썼습니다. QA 팀, 운영팀, 고객지원팀이 따로 있는 큰 조직에서는 이 세 번째 줄이 PM 한 사람에게 몰리지 않습니다. 잘못된 값을 발견하는 일은 QA나 모니터링 도구가, 되돌리는 절차는 운영팀이, 고객 연락은 CS가 나눠 맡습니다.

그렇다고 이 글의 논지가 무효가 되지는 않는다고 저는 봅니다. 역할이 나뉘어도 그 역할들을 처음 설계하고 서로 잇는 사람은 필요하고, 큰 조직에서는 그 사람이 PM 대신 프로덕트 오너로 불릴 뿐입니다. 이름이 바뀌어도 이 이음을 아무도 맡지 않으면 같은 빈틈이 남습니다.

이 문서를 언제 써야 하는가

많은 조직이 이 문서를 출시 후 사고가 한 번 터지고 나서야 씁니다. 잘못된 발주 값이 ERP에 들어간 뒤에야 "이런 경우엔 누가 고치나"를 논의하고 그제서야 절차를 정합니다. 문제는 그 논의가 담당자들이 이미 화가 난 상태에서 이루어진다는 점입니다.

저는 이 문서를 출시 전, 적어도 마지막 검수 회의 전에는 초안이라도 있어야 한다고 봅니다. 완벽하게 채우지 못해도 괜찮습니다. 빈칸으로 남은 항목이 있다면 그 항목에서 출시 후 가장 먼저 사고가 나기 때문입니다. 검수 회의 안건에 "이 기능이 잘못됐을 때 누가 고치는가"라는 질문을 하나 넣는 것만으로도 이 빈칸의 절반은 회의 중에 채워집니다.

이 판단을 놓쳤을 때 드는 비용

인수인계 문서의 빈칸은 출시 직후에는 티가 나지 않습니다. 시스템이 예외 없이 돌아가는 동안에는 화면과 기능만으로 충분해 보입니다. 문제는 처음 예외가 났을 때 드러납니다. 담당자가 무엇을 어떻게 고쳐야 할지 몰라 개발팀에 다시 문의하고, 개발팀은 이미 다른 프로젝트로 넘어간 뒤라 응답이 늦어지고, 그사이 잘못된 값은 다음 공정으로 넘어갑니다.

이 지연은 계약서에 적히지 않는 비용입니다. 재작업 시간, 담당자가 다음번엔 시스템을 안 믿고 엑셀로 다시 대조하기 시작하는 습관, "역시 외주는 이래서 안 된다"는 평판까지 이어집니다. 저는 이 세 번째 비용이 가장 크다고 봅니다. 화면과 기능은 다음 계약으로 다시 팔 수 있지만, 한번 깨진 신뢰는 같은 고객에게 다시 팔기 어렵습니다.

PM 연차가 갈리는 판단

이 빈틈을 메우는 일은 매뉴얼로 옮겨지지 않는다고 저는 봅니다. 잘못된 발주 값을 누가 고칠지는 그 회사의 조직도를 봐야 알 수 있고, 세금계산서가 이미 나갔는지는 회계 마감 주기를 알아야 판단할 수 있습니다. 이런 판단은 시스템을 여러 번 넘겨 보고 출시 첫 달에 무엇이 터지는지를 직접 본 사람만 미리 채울 수 있습니다. 신입 PM에게 이 인수인계 문서를 맡기면, 화면과 기능은 빠짐없이 적고도 "누가 고치나"라는 줄은 비워 둔 채로 넘어갑니다.

예를 들어 신입 PM은 "거래처 담당자에게 전화로 알린다"라고 적고 끝내지만, 시니어 PM은 그 담당자가 부재중이면 누가 대신 받는지, 전화를 안 받으면 몇 시간 뒤에 문자로 넘어가는지까지 적습니다. 이 차이가 실제 사고 상황에서 문서의 그 줄이 도움이 되느냐 안 되느냐를 가릅니다.

디자인과 개발보다 운영 역량을 먼저 보는 기준

그래서 저는 아이디어를 현실화할 때 가장 먼저 물어야 할 것이 화면의 완성도나 코드의 품질이 아니라고 봅니다. 그 시스템을 넘겨받을 조직이 잘못된 값을 발견하고 고칠 기술적 능력이 있는지가 먼저입니다. 능력이 없다면 화면 안에 그 확인과 수정 절차까지 넣어야 하고, 있다면 그 조직이 이미 할 수 있는 일을 화면에 다시 만들 필요가 없습니다. 같은 발주 화면도 이 판단에 따라 만들어야 할 기능의 범위가 달라집니다.

예를 들어 담당자가 엑셀 매크로를 직접 짤 수 있는 조직이라면, 발주 화면은 오류가 났을 때 원본 데이터만 내려받게 해 주면 충분합니다. 반대로 엑셀도 겨우 쓰는 조직이라면, 화면 안에 오류 수정 버튼까지 넣어야 합니다. 같은 기능인데 한쪽은 한 줄, 한쪽은 화면 하나가 됩니다.

이 판단이 맞았는지 확인하는 방법

이 판단이 맞았는지는 출시 첫 달이 지나야 압니다. 저는 그 한 달 동안 실제로 발생한 예외 목록과 인수인계 문서에 적어 둔 목록을 나란히 놓고 대조하는 것 말고 다른 검증 방법을 알지 못합니다. 문서에 없던 예외가 나왔다면 그 항목을 채우고, 다음 프로젝트의 인수인계 문서에는 그 항목이 기본값으로 들어갑니다.

이렇게 쌓인 목록은 결국 PM 개인의 경험이 됩니다. 매뉴얼로 옮겨지지 않는다고 앞서 말한 이유가 여기 있습니다. 한 사람의 머릿속에 프로젝트마다 하나씩 늘어나는 목록이고, 다른 사람에게 그대로 넘겨줄 수 있는 형태가 아닙니다.

이 판단 기준을 수치로 검증한 자료는 아직 갖고 있지 않습니다. 계량화된 체크리스트가 없다는 뜻이고, 그래서 이 판단은 여전히 사람의 경험에 크게 기대고 있습니다.