제 고객은 옆 팀에 있었습니다

11년 동안 그림을 다루는 회사에서 일했지만, 제가 만든 화면을 가장 오래 쓴 사람들은 그림을 빌리는 고객이 아니었습니다. 주문을 만들고 작품을 등록하고 계약서를 뽑는 옆 팀의 동료들이었습니다. 고객용 사이트가 손님이 다녀가는 곳이라면, 백오피스는 누군가 하루 여덟 시간을 사는 곳입니다. 그 여덟 시간을 만드는 개발자에게 고객이 누구냐고 물으면, 저는 옆 팀이라고 답해 왔습니다.

사람이 확인하면 된다는 전제

초창기의 작품 등록 화면에는 제약이 거의 없었습니다. 어떤 값이든 일단 받아 두고, 등록하는 사람이 확인하면 된다는 전제였습니다. 그때는 실제로 합리적인 선택이었습니다. 팀이 작고 화면이 몇 개뿐일 때는 규칙을 말로 전하는 편이 코드로 막는 것보다 빠릅니다. 사람은 규칙을 지킬 수 있으니까요. 문제는 그 규칙이 사람에게만 있다는 것입니다. 화면이 늘고 그 칸을 읽는 코드가 늘면, 말로 전한 규칙은 어디에도 온전히 남지 않습니다. 칸을 어떻게 나눠야 오래가는지는 지난 글에 적었습니다.

여기서 배운 것이 있습니다. 검증을 사람에게 맡기는 것은 시스템의 일을 미루는 것일 뿐이고, 제약을 두지 않은 칸은 결국 제 일을 옆 팀의 일로 넘긴 것이었다는 사실입니다. 그래서 지금 제가 지키는 원칙은 하나입니다. 친절은 화면에 두고, 제약은 데이터에 두는 것.

떠나지 않는 사용자의 신호

외부 고객은 불편하면 떠나는 것으로 신호를 줍니다. 내부 사용자는 다릅니다. 떠날 수 없으니, 도구가 못 하는 일을 사람이 메워 업무를 굴러가게 합니다. 어느 조직에나 이런 우회로가 생깁니다. 복사해서 붙여 넣고, 스프레드시트로 한 번 더 계산하고, 빈칸에 필요한 정보를 적어 두는 식으로요. 그 우회는 대개 정확합니다. 업무를 가장 잘 아는 사람이 만든 임시 해법이니까요. 문제는 그 해법이 화면 쪽으로는 신호가 되어 오지 않는다는 것입니다. 그래서 반응을 기다리면 늦습니다. 저는 도구를 만들기 전에 실무자들이 일하는 모습을 직접 보러 갔고, 새로 합류한 팀원의 온보딩에도 현업 참관을 넣었습니다. 화면 뒤의 업무 흐름을 본 사람과 못 본 사람은 같은 요청서를 읽어도 다른 것을 만듭니다.

반대 방향의 신호도 있습니다. 손으로 만들던 제안서를 자동으로 만들어 주는 화면을 붙였을 때, 고맙다는 말은 다음 요청과 함께 도착했습니다. 이 키워드도 인식되게 해 달라, 이 형식으로도 뽑고 싶다. 요청이 이어진다는 것은 도구가 업무의 일부가 되었다는 뜻입니다. 내부 사용자의 칭찬은 그렇게 도착합니다.

요청의 언어, 필요의 언어

요청은 눈에 보이는 자리에서 시작됩니다. 정렬이 이상해요, 이 버튼이 안 보여요. 이상을 가장 먼저 알아차리는 것은 늘 쓰는 사람이고, 원인은 대개 화면 뒤에 있습니다. 한번은 작품 정렬이 이상하다는 문의를 받고 들여다보니, 화면이 아니라 기준이 문제였습니다. 무엇을 기준으로 정렬할지가 합의된 적이 없었던 것입니다. 이상하다는 감각은 정확했고, 고칠 자리가 화면 밖이었을 뿐입니다. 실무 담당자들과 기준을 맞춰 결정할 문제로 정리했고, 다른 화면에 미칠 영향을 함께 확인해 적용 범위를 정했습니다. 요청받은 것은 정렬 수정이었지만, 필요한 것은 기준의 합의였습니다. 요청을 그대로 구현하지 않고 필요로 옮기는 일이, 돌아보면 제 일의 절반이었습니다.

도록의 첫 고객

도록(dolog)에는 옆 팀이 없습니다. 대신 작가가 있습니다. 작가도 불편하다고 잘 말하지 않습니다. 메모장에 적어 두고, 사진첩에 쌓아 두고, 공모 때마다 처음부터 다시 정리하면서 그냥 우회합니다. 그래서 요청을 기다리는 대신 작업의 흐름부터 보려 합니다. 입력은 너그럽게, 저장은 엄격하게. 아직 가야 할 길이 멀지만, 옆 팀을 고객으로 모시며 배운 습관 그대로 가려 합니다.