바꾸는 게 나도 싫다

하지만 크고 정성스러운 똥을 내놓을 순 없잖아요

나는 한 번 정한 건 웬만해서는 잘 바꾸지 않는다.

매일 같은 걸 먹어도 질리지 않고, 같은 루틴대로 살아도 크게 지루함을 느끼지 않는다. 한 번은 헬스장 PT 선생님이 나랑 너무 안 맞았는데, 바꿔달라고 말할까 말까 고민하다가 2년이 흘렀다. 결국 그 선생님께 끝까지 수업을 들었다.

그런데 얼마 전 내 알고리즘에 한 릴스가 떴다.

개발자 밈이었다. 누군가의 "아 요거 쫌만 이렇게 고쳐주세요^^"라는 요구사항이 얼마나 황당한 부탁인지를 재미있게 풀어놓은 릴스였다. 나는 개발자가 아니지만 그동안 눈칫밥은 배부르게 먹은 지라, 그게 말처럼 손바닥 뒤집듯 쉬운 일이 아니라는 건 안다. 디자이너에게 "심플하면서도 화려하게" 해달라는 것과 뭐가 다르겠나.

미들 레벨 연차까지만 해도, 이미 개발이 끝난 단계에서 스펙을 바꾸겠다고 말하는 건 동료에게 큰 죄를 짓는 것만 같았다. 이거 아닌데 싶을 때에도 그냥 넘어간 적이 꽤 있었다.

하지만 몇 번의 뼈아픈 시행착오 끝에 새긴 게 있다. 고객에게 전달하기 전에 바꾸는 게, 가장 싸게 먹히는 값이라는 것. 안타깝지만, 그게 설계를 뒤집는 일이라 해도.

얼마 전, 제법 오랫동안 준비한 기능을 배포했다.

중간에 이래저래 치고 들어오는 일들이 있어서 스펙 규모 대비 개발 시기가 꽤 늘어진 프로젝트였다. 그러다 보니 배포 전 QA를 하며 정말 오랜만에 그 기능을 직접 만져보게 됐는데, 정말 엉망인 거다. 이대로 나가면 욕먹기 딱 좋았다.

눈 딱 감고, 뼈대만 남기고 상당 부분을 뜯어고쳤다. 고맙게도 팀원 모두가 같은 가치관을 갖고 있어서, 이 결정에 마찰 없이 힘을 모았다. 마무리 후 최초 개발 완료 버전과 마지막 배포 버전을 나란히 놓고 보니, 정말 상당한 차이가 났다.

고쳐야겠다는 의사결정은 꼭 필요했다고 생각한다.

"진짜 이렇게 하면 목표에 닿아? 문제 해결 돼?"라는 질문에 가감 없이 YES가 나오지 않는다면, 방법이야 여러 가지겠지만 고쳐야 한다. 다만 이런 일을 겪을 때마다 개운치 못한 게 하나 있다. 왜 그건 직접 써보는 순간에야 비로소 가장 선명하게 보이는 걸까. 디자인할 때, 기획할 때 분명히 치열하게 고민했는데 그때는 왜 안 보였을까. 그대로 나갔으면 "멋지죠 고객님? 저희가 정성 들여 만든 똥입니다."가 되는 거다. 시간은 시간대로 쓰고, 아무런 변화도 만들어내지 못한 채.

당연히 기획 단계에서, 디자인 단계에서 이걸 잡아낼 수 있다면 가장 좋다.

(이번에야 예외였지만) MVP 위주의 빠른 배포 주기를 가져가고, 좋은 방법론들을 가져다 써보기도 하고, 나름대로 검증 과정을 촘촘하게 짜보기도 하는데, 그래도 결국 직접 만져봐야 드러나는 것들이 있다. 어느 단계에서 얼마만큼의 시간을 쏟아야 하는지도 매번 달라서, 결국은 직관을 벼려야 한다는 결론에 이른다. 이 감각을 좀 더 앞으로 끌어올릴 수 있는 방법이 분명 있을 텐데. 아직 잘 모르겠다. 그래서 또 돌아가는 중이다.