개발자가 SA 기획까지 하면 무엇이 달라질까?

인쇄기 롤러를 만드는 제조사와 첫 협의를 했을 때 들은 요청은 두 가지였습니다. 견적 단계마다 영업사원이 직접 방문해야 해서 하루에 처리할 수 있는 건수가 막힌다는 것, 그리고 중국어와 독일어 대응이 필요하다는 것이었습니다.

따로 들으면 하나는 업무 효율 이야기이고 하나는 번역 이야기입니다. 저는 둘을 같은 문제로 읽었습니다. 영업 인력이 닿을 수 있는 범위가 좁다는 것입니다. 그래서 제안서의 목적을 한 문장으로 적었습니다. "영업사원이 못 가는 곳까지 카탈로그가 대신 간다."

SI에서는 SA(System Analysis)가 현행 업무를 분석하고 요구사항과 설계를 정리해 개발자에게 넘깁니다. 이 프로젝트에서는 그 분석과 제안서, 그리고 구현까지 제가 했습니다. 계약서 초안이 오가기 전에 이미 카탈로그와 견적함이 돌고 있었습니다. 한 사람이 둘 다 하면서 좋았던 점과, 그래서 놓친 점을 적어 둡니다.

휴대폰 사진 세 장에서 시작한 데이터 이관

받은 자료는 롤러 규격 시트를 찍은 휴대폰 사진이었습니다. 기종마다 롤러 부품명, 외경, 철심경, 면장이 표로 적혀 있고 맨 아래에 롤러 개수의 「계」가 있습니다. 처음 여섯 기종을 옮긴 뒤 사진을 더 받아 열두 기종, 롤러 131종이 됐습니다.

사진에서 옮긴 값은 틀리기 쉽습니다. 끝자리가 잘린 칸이 있었고, 어떤 기호는 알파벳 W인지 다른 글자인지 분명하지 않았습니다. 그래서 시트를 옮기면서 동시에 검사를 짰습니다. 시트의 「계」와 실제 줄 수가 맞는지, 철심경이 외경보다 작은지 확인하고, 틀리면 DB를 건드리기 전에 멈추게 했습니다.

이 검사가 실제로 한 번 멈췄습니다. 사진대로 읽은 한 롤러가 외경과 철심경이 모두 65였습니다. 철심이 롤러와 굵기가 같을 수는 없으니 사진을 잘못 읽은 것이고, 외경을 85로 고쳤습니다. 확실하지 않은 칸은 임시값으로 넣고 주석을 달아 거래처 확인 대기로 남겼습니다.

나중에 받은 사진이 앞의 빈칸을 채워 주기도 했습니다. 새로 받은 기종 하나가 1번부터 8번 롤러까지 이전 기종과 규격이 똑같았고, 잘려 있던 칸이 거기서는 온전히 보였습니다. 그 값을 보고 임시로 1110이라 넣었던 면장을 1116으로 옮겼습니다. 규격표를 사람 눈으로만 검토했다면 두 기종의 앞 여덟 줄이 같다는 것을 알아채기 어려웠을 겁니다.

「계」를 계산하지 않고 손으로 옮겨 적은 이유

검사를 짤 때 한 가지를 일부러 불편하게 했습니다. 시트의 「계」를 코드에서 줄 수로 계산하지 않고, 사진에 적힌 숫자를 손으로 옮겨 적었습니다.

줄 수에서 합계를 계산하면 검사가 제 자신과 비교하게 됩니다. 줄을 하나 빠뜨려도 합계가 같이 줄어드니 검사는 언제나 통과합니다. 사진 속 「계」는 거래처가 직접 쓴 숫자이고, 이 숫자와 대 봐야 제가 옮긴 줄이 맞는지 알 수 있습니다.

저는 이런 판단이 분석과 구현을 같이 할 때 가장 자연스럽게 나온다고 봅니다. 요구사항 문서에는 "규격 데이터 이관"이라고 한 줄로 적힙니다. 그 한 줄 안에서 무엇을 믿을 수 있고 무엇을 의심해야 하는지는 자료를 직접 옮기는 사람이 가장 잘 압니다.

부품명이 겹치는 한 기종 안의 롤러 넷

롤러를 무엇으로 구분할지도 자료를 옮기면서 정해졌습니다. 부품명이 곧 롤러 이름이라고 보기 쉽지만, 한 기종 안에서 같은 부품명을 가진 롤러가 넷인 경우가 있었습니다. 그래서 롤러를 구분하는 키를 기종과 부품명과 규격의 조합으로 잡았습니다. 반대로 부품명과 규격이 모두 같은 줄이 두 번 나오면 한 벌에 두 개가 들어간다는 뜻이라 세트당 수량으로 묶었습니다.

이런 사실은 협의 자리에서 나오지 않습니다. 롤러를 매일 다루는 사람에게는 너무 당연해서 설명할 이유가 없기 때문입니다. 설계서만 받은 개발자였다면 실제 데이터를 넣는 날 유일 키 충돌로 처음 만났을 것이고, 그때는 표를 고치는 비용이 훨씬 큽니다.

방문 표 없이 만든 영업 기록과 2단계 제안서

카탈로그 말고도 영업 관리 화면을 만들었습니다. 직원이 휴대폰에서 버튼 하나로 사무실 출발, 고객사 도착, 상담, 복귀 같은 시각을 찍고, 사무실에서는 그 하루를 직원별 시간축으로 봅니다.

여기서 「방문」을 표로 저장하지 않았습니다. 방문을 시작과 끝이 있는 한 줄로 저장하면 시작만 찍고 닫지 않은 방문이 반드시 생깁니다. 그 뒤처리가 기록 자체보다 커집니다. 그래서 시각 스탬프만 쌓고, 도착부터 복귀까지를 한 방문으로 묶는 일은 화면에 맡겼습니다.

이 결정이 다음 제안서의 근거가 됐습니다. 고객사가 다음 단계로 말한 것 중 하나가 공정 기록이었습니다. 검토 보고서를 쓰면서 공정 기록도 상태 표를 두지 않고 기록을 쌓는 방식으로 설계했습니다. 그리고 "현장에서 버튼으로 시각을 찍는 방식은 이미 1단계에서 돌고 있다"고 적을 수 있었습니다. 설계서에 쓴 방식이 가능한지를 말로 설득하지 않고 동작하는 화면으로 보여 줄 수 있다는 점이, 제가 보기에 개발자가 SA를 할 때 얻는 가장 큰 이점입니다.

재생 롤러는 고객의 자산이라는 전제

2단계 검토에서 가장 중요했던 판단은 코드가 아니라 업무에서 나왔습니다. 이 회사는 롤러를 새로 만들기도 하지만, 고객사가 쓰던 롤러를 받아 고무를 벗기고 다시 성형해 돌려주는 재생 작업도 합니다. 작업하는 동안에는 고객사의 물건을 맡아 두고 있는 셈입니다.

그러면 공정 기록 시스템의 첫 번째 목적이 달라집니다. 흔히 공정 관리는 생산성을 재는 도구로 제안합니다. 하지만 맡은 물건이 있는 곳에서 먼저 필요한 것은 "그 롤러가 지금 어디 있느냐"에 답하는 일입니다. 한 주문에 여러 본이 들어오고 본마다 진행 속도가 다르니, 주문 단위가 아니라 롤러 한 본 단위로 추적해야 합니다.

견적과 생산 사이에 수주 단계가 비어 있다는 것도 이때 보였습니다. 지금은 담당자의 기억이 둘을 잇고 있습니다. 수주가 없으면 공정 기록 시스템은 무엇을 만들어야 하는지 스스로 알 수 없으니 순서상 가장 앞에 둬야 합니다.

제안서에 공란으로 남긴 기준 수량

좋은 점만 있지는 않았습니다. 1단계 제안서의 기준 수량 칸을 "기종 ○○종, 롤러 규격 ○○○개"라는 공란으로 남겼습니다. 초과분을 규격 100개 단위로 따로 산정한다고 적어 놓고, 그 기준이 되는 숫자를 비워 둔 것입니다. 2단계 검토 보고서를 쓰면서 이것이 분쟁의 여지로 남아 있다는 것을 제 손으로 다시 적어야 했습니다.

열두 기종, 131종이라는 숫자는 사진을 옮기면서 코드에 정확히 들어가 있었습니다. 코드에는 있고 계약 문서에는 없었습니다. 같은 사람이 두 곳을 다 쓰면 한쪽에 적은 것을 다른 쪽에도 적었다고 착각하기 쉽습니다.

비슷한 틈이 하나 더 있습니다. 제안서에는 "전화나 대면으로 받은 견적도 직원이 같은 화면에서 입력할 수 있다"고 적었습니다. 지금 관리 화면은 들어온 견적을 고칠 수는 있지만 새로 만들 수는 없습니다. 기술 정리 문서의 미완 목록에 올려 두었지만, 제안서를 쓴 사람과 코드를 쓴 사람이 달랐다면 인수인계 자리에서 누군가 먼저 물었을 항목입니다.

대조할 사람이 없다는 약점

분석과 구현을 한 사람이 하면 설계서와 코드 사이의 간극이 거의 사라집니다. 사진에서 옮긴 규격이 맞는지 코드가 검사하고, 제안서에 쓴 방식을 이미 돌고 있는 화면으로 보여 줄 수 있습니다.

대신 그 간극에 있던 대조도 같이 사라집니다. 원래는 넘겨받는 사람이 "이 숫자는 어디서 왔습니까", "이 기능은 어디 있습니까"라고 묻는 자리입니다. 저는 지금 그 질문을 스스로에게 하는 수밖에 없다고 봅니다. 제안서의 항목 하나하나가 코드 어디에 있는지 표로 대 보는 일이, 혼자 하는 SA에게는 빠뜨리면 안 되는 단계입니다.