코드 너머의 채널 개발자

예전에 면접에서 이런 질문을 받은 적이 있습니다.

“왜 이렇게 다양한 서비스를 담당하게 되었나요?”

당시에는 명확하게 답하지 못했던 것 같습니다. 지나고 보니 이유는 단순했습니다. 채널 서비스를 개발하다 보면 어느 한 영역으로 구분하기 어려운 일이 자연스럽게 모이기 때문입니다.

고객이 만나는 화면은 앱이나 웹으로 보이지만, 그 뒤에는 인증과 원장 서비스, 공통 API와 운영 시스템이 함께 움직입니다. 어느 한 부분만 잘 만든다고 고객 서비스가 자연스럽게 이어지는 것은 아니었습니다.

화면을 만드는 일이라고 생각했습니다

처음 채널 개발을 시작했을 때는 주어진 화면을 안정적으로 구현하는 것이 가장 중요한 역할이라고 생각했습니다.

기획과 디자인을 확인하고, API를 연결하고, 고객이 불편하지 않도록 화면을 만드는 일에 집중했습니다. 물론 지금도 중요한 일입니다.

하지만 담당하는 서비스가 늘면서 화면 밖의 문제를 더 자주 마주하게 되었습니다.

로그인 상태는 어디에서 판단할지, 앱과 웹의 화면 이동은 어떻게 맞출지, 원장의 기술적인 메시지는 고객에게 어떻게 보여줄지, 장애가 발생했을 때 어느 구간부터 확인해야 할지 고민해야 했습니다.

채널에서 마주하는 문제는 앱, 웹, 서버 중 한곳의 문제로만 설명하기 어려운 경우가 많았습니다.

WebView 안에서 발생한 현상도 앱 브릿지의 문제일 수 있고, 웹의 상태 관리나 서버 응답의 문제일 수 있습니다. 인증과 전자서명 역시 성공 결과를 전달받는 것만으로 끝나지 않고, 실제 업무 요청까지 같은 흐름으로 검증되어야 했습니다.

이런 문제를 해결하려면 각 영역을 모두 직접 구현하는 것보다 서로의 역할과 경계를 이해하는 일이 먼저였습니다.

앱이 책임져야 할 것, 웹에서 유연하게 바꿀 것, 서버가 신뢰할 수 있는 기준으로 검증할 것을 함께 정해야 했습니다.

예전에는 회의가 많아지면 개발할 시간이 줄어든다고만 생각했습니다.

하지만 프로젝트를 진행하는 방식이 달라지면서 채널 개발자가 더 앞쪽의 논의에 참여해야 하는 일이 많아졌습니다. 기획과 디자인이 모두 확정된 뒤 구현하는 것이 아니라, 앱과 웹의 경계나 인증 흐름처럼 구현 전에 정해야 하는 기준을 함께 이야기하게 되었습니다.

회의가 많아진 것이 언제나 좋은 것은 아닙니다. 다만 필요한 기준을 미리 맞추는 회의라면 뒤에서 발생할 시행착오를 줄이는 개발의 일부라고 생각하게 되었습니다.

채널 개발은 한 가지 기술을 깊게 다루는 일과 여러 영역을 연결해서 보는 일이 함께 필요합니다.

때로는 담당 영역이 모호해 보이기도 합니다. 하지만 그 모호한 경계에서 고객 서비스가 끊기지 않도록 기준을 찾는 일이 채널 개발자의 역할이라고 생각합니다.

코드만으로 해결할 수 없는 문제를 만나고, 여러 영역의 언어를 이해하며 하나의 고객 경험으로 이어지게 만드는 것.

저는 그래서 채널 개발이 좋습니다.