개발자 경험과 고객 경험은 트레이드오프가 아니다

최근에 팀에서 SSR 이야기를 하다가 개발자 경험 이야기가 나왔다. 우리에는 이미 SSR을 돌릴 수 있는 인프라가 있다. 그런데 디버깅하기 어렵고, 코드 복잡도가 올라가서 관리가 어렵다는 말이 나왔다.

나는 그 말을 듣고 속으로 답했다. 고객 경험이 우선이지. 회사에서 돈을 받아 일하는 직장인으로서 내 편함보다 고객에게 전달되는 가치가 먼저라고 생각했다. 지금도 그 생각은 다르지 않다.

그런데 자리가 끝나고 나서도 그 답이 마음에 걸렸다. 어딘가 모르게 꽤나 불편했다. 이 글은 그 불편함을 풀어본 기록이다.

너무 쉽게 나온 답

그 답이 틀려서 걸린 게 아니었다. 너무 맞아서 걸렸다. 고객 경험이 우선이라는 말은 항상 옳다. 그런데 항상 옳은 말은 꺼내기만 하면 고민이 끝나버린다. 그날 나도 그랬다. 옳은 말을 꺼냈고, 동료가 본 어려움이 뭔지 끝까지 묻지 않았다.

그때는 이게 취향 차이인지 가치관 차이인지 궁금했다. 돌아보니 둘 다 아니었다. 동료는 비용을 이야기하고 있었고 나는 우선순위를 이야기하고 있었다. 이야기가 엇갈린 것뿐이었다.

뭘 불편해했는지도 이제야 보였다. 나는 동료의 말을 "개발자의 편함과 고객 가치 중 어느 쪽이냐"로 듣고 있었다. 그런데 돌아보면 동료는 편함을 이야기한 게 아니었다. 어렵다는 것을 알려준 것이었다.

개발자 경험은 두 종류다

개발자 경험이라는 말 안에는 사실 두 개가 섞여 있다.

하나는 고객에게 도착하는 것이다. 관리하기 어려운 코드는 장애 대응을 늦추고, 수정을 꺼리게 만들고, 버그를 낳는다. 빌드가 느리면 고객에게 가야 할 수정이 늦게 나간다. 특정 사람만 고칠 수 있는 코드는 그 사람이 자리를 비우면 고객이 기다린다. 이건 개발자의 편함이 아니라 고객 경험의 재료다.

다른 하나는 고객에게 도착하지 않는 것이다. 다들 써보고 싶은 기술로 코드를 갈아엎는 일, 고객 눈에 보이지 않는 부분을 완벽하게 다듬는 일. 이건 일이 아니라 취향이다.

고객 경험이 우선이라는 말은 앞의 것에는 투자하라고 하고 뒤의 것에는 그만두라고 한다. 같은 말이 정반대로 쓰인다. 그러니 이 말만으로는 아무것도 고를 수 없다. 고르는 건 다른 질문이 한다.

이게 좋아지면 고객에게 무엇이 달라지는가. 답이 있으면 투자이고, 답이 없으면 취향이다.

개발자 경험과 고객 경험은 트레이드오프가 아니다. 트레이드오프라는 건 둘을 같은 저울에 올려놔야 하는데, 하나는 재료이고 하나는 결과라 같은 저울에 올라가지 않는다. "제품 품질과 개발자 월급 중 무엇이 우선한가"라고 물으면 이상하게 느껴지는 것과 같은 이유다.

그날의 어려움을 쪼개보니

그 기준으로 그날 나온 어려움 두 가지를 쪼개봤다.

디버깅이 어렵다는 얘기부터. 서버에서 화면을 그리는 동안 무슨 일이 벌어지는지 보여주는 도구가 없으면 디버깅은 당연히 어렵다. 원인을 찾아 들어가야 하는데 창이 없는 것이다. 이건 SSR 탓이 아니라 도구가 없어서 그런 것이다. 관측 도구도 인프라다. 예전에 성능 이야기를 하면서 인프라가 정돈 안 되면 SSR이 코드를 아무리 잘 짜도 빨라지지 않는다고 쓴 적이 있는데, 디버깅도 같은 층이다. 채우면 되는 문제다.

복잡도가 올라간다는 얘기는 조금 더 미묘하다. 여기에도 두 가지가 섞여 있다. 하나는 익숙함의 문제다. 코드가 어디서 실행되는지, 서버와 클라이언트를 오가며 생각해야 하는 것들. 처음엔 낯설지만 반복하면 익숙해진다. 처음 한 번 내는 학습비다. 다른 하나는 서버와 클라이언트의 경계다. 서버에서 그린 화면을 클라이언트가 이어받으면서 생기는 일, 그 사이를 건너는 데이터를 옮기는 일. 이건 아무리 익숙해져도 매번 내야 하는 사용료다.

줄어드는 비용과 줄지 않는 비용을 나눠서 보지 않으면, 복잡하다는 말만 남는다. 그리고 줄지 않는 비용은 개발자 각자가 매번 내게 두는 방식과, 프레임워크나 공통 코드가 대신 내주는 방식이 있다. 팀마다 SSR이 어렵게 느껴지는 정도가 다른 이유 중 하나가 여기 있다.

그래서 그날의 어려움을 다시 쓰면 세 가지다. 도구가 없어서 그런 것, 익숙하지 않아서 그런 것, 공통으로 감당해야 하는 것. 셋 다 고객에게 도착한다. 관측이 없으면 장애가 오래 가고, 익숙하지 않으면 변경이 느리고, 경계가 코드 곳곳에 드러나면 버그가 나온다.

동료의 말은 정확한 비용 이야기였고, 그 비용은 전부 고객에게 도착하는 종류였다. 고객 경험이 우선이라는 내 기준으로도 이 이야기는 들어야 하는 것이었다.

그때 했어야 하는 질문

그날 내가 꺼냈어야 할 답은 "고객 경험이 우선이지"가 아니었다. "그 비용은 고객에게 어떻게 도착하는데?"였다. 그 질문을 했다면 대화는 끝나지 않았을 것이고, 나는 동료가 본 어려움의 실체를 더 일찍 알았을 것이다.

고객 경험이 우선이라는 믿음은 지금도 같다. 그런데 그 믿음을 말로 꺼내는 순간을 다시 보게 됐다. 우선순위 이야기로 대화를 정리하는 동안, 나는 고객을 앞세워 고객에게 도착할 비용 이야기를 듣지 못하고 있었다.

개발자 경험 이야기가 나오면 이제는 먼저 묻는다. 이게 좋아지면 고객에게 무엇이 달라지는가. 둘 중 무엇을 고를지 고민할 일이 아니라, 이 재료가 어떤 결과로 고객에게 도착하는지 볼 일이다.