의견이 좁혀지지 않고 평행선을 달리는 게 고민이라면
"이 기능 왜 넣으려는 거예요?"
개발자에게 이 질문을 받았을 때, 나는 말문이 막힌 적이 있다. 분명히 사용자에게 편한 기능이라고 생각했는데, 왜 넣으려는지를 설명하려니 막상 명확하지 않았다. 머릿속에서는 당연한 건데, 말로 풀어내려니 근거가 부족했다.
그날 이후로 나는 개발자와 대화하는 방식을 많이 바꿨다. 비개발자로서 개발자와 협업하면서 가장 많이 배운 건, 우리가 같은 화면을 보고 있어도 전혀 다른 걸 보고 있다는 거였다. 그리고 그 차이를 인정하는 순간부터 소통은 훨씬 수월해졌다.
디자이너인 나는 화면을 볼 때 "이게 있으면 사용자가 편하겠지"를 먼저 생각한다. 이 버튼이 여기 있으면 흐름이 자연스러울 것 같고, 이 정보가 한눈에 보이면 사용자가 덜 헤맬 것 같고. 항상 사용자의 행동과 감정을 먼저 떠올린다.
하지만 백엔드 개발자는 같은 화면을 완전히 다른 눈으로 본다. 이 화면 하나를 그리기 위해 몇 개의 테이블을 묶어서 데이터를 던져야 하는지, 그 사이에서 데이터 정합성이 깨질 확률은 없는지, 어떤 건 수정할 수 있고 어떤 건 절대 건드리면 안 되는지. 바로 이 화면 뒤에서 돌아가는 구조와 리스크를 본다.
한 번은 디자인 리뷰에서 "여기에 관련 정보를 같이 보여주면 좋겠어요"라고 가볍게 제안한 적이 있다. 나한테는 작은 텍스트 한 줄이었는데, 개발자가 돌아온 대답은 "이 유저정보 하나만 가져오는데도 테이블 세 개를 조인해야 하는데, 이정도면 페이지 로딩 속도가 눈에 띄게 느려질 수 있어요"였다. 같은 화면의 같은 자리를 보고 있었는데, 내 눈에는 빈 공간이 보였고 개발자 눈에는 성능 리스크가 보였던 거다.
쉽게 말해, 디자이너는 UX 관점에서 편리함을 고민하고, 개발자는 성능과 안정성 관점에서 리스크를 고민한다. 하나의 작은 기능을 위해 거대한 데이터를 불러와야 하는 과부하, 빠른 성능을 위해 어디까지 타협할 수 있는지. 이런 것들이 개발자의 머릿속에서 동시에 돌아간다.
시선 자체가 다르니까 충돌이 생길 수밖에 없다. 그런데 문제는 충돌 자체가 아니다. 서로 다른 걸 보고 있다는 사실을 모른 채 대화하는 것이 진짜 문제다.
교육을 관리하는 백오피스를 만들 때 일이다.
우리 서비스에는 교육생들을 팀으로 매칭하는 기능이 있었다. 운영진이 수십, 수백 명의 교육생을 팀에 배정해야 했는데, 한 명씩 넣는 건 너무 비효율적이었다. 그래서 나는 벌크 업로드 기능을 기획했다. 엑셀이나 CSV 파일을 올리면 한 번에 데이터가 들어가는 방식. 운영 효율을 생각하면 당연히 있어야 할 기능이었다.
그런데 백엔드 개발자 입장은 달랐다.
벌크로 데이터를 넣으려면 검증해야 할 게 한두 가지가 아니었다. 이미 서비스에 가입한 유저인지, 해당 프로그램을 실제로 수강하는 사람인지, 이미 다른 팀에 배정되어 있지는 않은지. 이 모든 걸 한꺼번에 처리해야 하는데, 중간에 하나라도 틀리면 되돌리기가 정말 어려운 구조였다. 이미 결정된 팀을 취소하고, 꼬인 데이터를 풀고, 다시 넣는 과정은 개발자 입장에서 악몽이나 다름없었다.
대화를 하다 보니 진짜 문제가 보였다. 휴먼에러를 이 기능이 어디까지 감당할 수 있느냐. 운영진이 파일을 잘못 올리거나, 데이터 형식이 틀리거나, 중복된 사람이 포함되어 있거나. 이런 상황들을 시스템이 전부 막아줄 수 있을까? 개발자의 걱정은 단순한 반대가 아니라, 실질적인 리스크에 대한 경고였다.
의견이 부딪히면 나는 한 발 물러서서 이 질문을 던진다.
이 기능은 뭘 위해 존재하는가?
메이커들끼리 다시 싱크를 맞추는 시간을 가졌다. 내가 이 기능을 왜 넣으려고 하는지 구체적으로 이야기하고, 트레이드오프를 함께 따졌다. 이게 그만큼 중요한 기능인가? 지금 우리 일정에서 감당할 수 있는 범위인가? 이걸 만드는 동안 놓치게 되는 다른 기능은 없는가?
결론은 벌크를 버리는 것이었다.
하지만 운영진의 고통을 무시할 수는 없었다. 그래서 나는 다른 방향으로 고민했다. 벌크가 아니라, 한 팀을 어떻게 하면 더 쉽게 넣을 수 있을까?
운영진은 이미 교육생 목록을 정리해 둔 시트가 있을 거라는 생각이 들었다. 그래서 운영진 중 한 명을 불러다가 교육생 팀매칭 기능을 실제로 어떻게 쓰는지 직접 옆에서 지켜봤다.
관찰 결과는 놀라울 정도로 단순했다.
복사 붙여 넣기.
운영진은 시트에서 여러 명의 교육생 이름을 한 번에 복사한 다음, 백오피스 검색창에 하나씩 붙여 넣고 있었다. 벌크 업로드가 필요한 게 아니었다. 복사한 여러 개의 이름을 한 번에 검색할 수 있으면 충분했던 거다.
그래서 결론을 내렸다. 벌크 업로드 대신 다중검색을 지원하자. 검색창에 여러 이름을 한 번에 붙여 넣으면, 해당하는 교육생들이 한꺼번에 검색 결과로 나오는 방식.
개발자들의 반응은 정말 좋았다. 운영진은 기존 습관대로 복사 붙여 넣기로 여러 명을 한 번에 검색할 수 있게 됐다. 개발자는 검색된 개별 건에 대해 검증 절차를 확실히 돌릴 수 있으니 데이터 정합성도 지킬 수 있었다.
운영진의 효율성 문제와 개발자의 안정성 걱정, 양쪽을 모두 해결한 셈이다. 그리고 개발 공수는 벌크 업로드에 비해 훨씬 적었다.
이 경험에서 내가 가장 크게 배운 건 이거다.
솔직히 말하면, 벌크 업로드를 처음 기획할 때 나도 내 포지션에 갇혀 있었다. "운영진이 편해야 해"라는 생각에만 꽂혀서, 그 기능이 시스템에 어떤 부담을 주는지는 깊이 생각하지 못했다. 개발자가 리스크를 이야기했을 때 처음에는 "왜 안 된다고만 하지?"라는 생각이 먼저 들었던 것도 사실이다.
대화를 하다 보면 자기 포지션에만 집중해서 주장하게 된다. 디자이너는 "사용자한테 이게 더 편해요"를 반복하고, 개발자는 "이건 기술적으로 리스크가 커요"를 반복한다. 둘 다 맞는 말이다. 그런데 각자의 관점만 반복하면 대화는 평행선을 달린다.
그리고 그게 병목이 된다. 기능 하나를 놓고 몇 번이고 같은 논의를 반복하고, 결론은 나지 않고, 시간만 흘러간다.
그럴 때 돌아가야 할 질문이 있다.
우리 팀의 목표는 무엇이며, 얼마의 시간이 남았는가? 이 기능을 고집했을 때 어떤 이점이 있는가?
이 질문 앞에서 포지션은 중요하지 않다. 디자이너의 관점도, 개발자의 관점도 팀의 목표 아래에서 재정렬된다. 그리고 대부분의 경우, 이 질문을 던지는 순간 "그러면 이렇게 하면 되지 않을까?"라는 대안이 자연스럽게 나온다.
벌크 업로드를 버리고 다중검색으로 갈 수 있었던 것도, 결국 "우리의 목표는 운영진이 팀매칭을 빠르게 할 수 있게 하는 것이지, 벌크 업로드를 만드는 것이 아니다"라는 데 합의했기 때문이다.
나도 아직 배우는 중이다. 매번 완벽하게 소통하는 건 아니고, 여전히 내 관점에 꽂혀서 대화가 꼬일 때도 있다.
그래도 한 가지 확실히 달라진 건 있다. 개발자가 "안 된다"라고 할 때, 예전에는 벽처럼 느껴졌는데 지금은 다르게 들린다. 그건 거부가 아니라 경고인 경우가 많다. "이렇게 하면 이런 리스크가 있어요"라는 뜻이다. 그 경고를 무시하지 말고, 왜 그렇게 느끼는지를 물어보자. 그러면 진짜 문제가 보인다.
개발자와의 소통이 어렵게 느껴진다면, 먼저 하나만 인정하자. 우리는 같은 화면을 보고 있지만, 서로 다른 걸 보고 있다. 그게 당연한 거다. 역할이 다르니까.
그리고 의견이 부딪힐 때마다 이 한 가지를 떠올리자.
"이 기능은 뭘 위해 존재하는가?"
이 질문으로 돌아가면, 놀랍게도 대부분의 논의는 풀린다. 왜냐하면 우리는 결국 같은 목표를 향해 가고 있으니까.