같은 화면을 보고도 다르게 상상하는 발주자와 개발자

"그냥 간단하게 만들어 주세요."

발주자 입장에서는 더없이 명확한 한마디입니다. 그런데 개발자가 내놓은 결과물을 보는 순간 이런 생각이 드는 경우가 있습니다.

"…제가 원한 건 이게 아닌데요?"

이 당혹스러운 장면, 사실 누구의 잘못도 아닙니다. 발주자와 개발자는 같은 단어를 듣고도, 각자의 경험과 맥락으로 전혀 다른 그림을 머릿속에 그리기 때문입니다.

왜 같은 말이 다르게 들릴까요?

우리는 모두 자신의 경험을 기준으로 세상을 이해합니다. 발주자는 지금 해결하고 싶은 비즈니스 문제를 떠올리며 말하고, 개발자는 그 말을 기술적 구현 단위로 해석합니다. 두 사람 사이에는 직업적 언어, 업계 관행, 그리고 수십 개의 암묵적 전제가 조용히 쌓여 있습니다.

결정적으로, 소프트웨어는 건물과 달리 눈에 보이는 설계도 없이 말로 시작됩니다. 벽돌 한 장도 쌓기 전에 도면을 펼쳐 보이는 건축과 달리, 소프트웨어 개발은 종종 말 몇 마디로 수개월짜리 작업이 시작됩니다. 그러니 출발점에서의 작은 오해가 완성 시점에는 아주 큰 거리로 벌어지는 것입니다.

'간단한 게시판'이라는 단어 하나의 거리

이런 장면을 상상해 보세요.

발주자가 말합니다. "간단한 게시판 하나만 넣어 주세요."

발주자의 머릿속에는 직원들이 공지사항을 올리고 내려받는, 딱 그 정도의 메모장이 그려집니다. 카테고리도 없고, 댓글도 굳이 필요 없고, 핵심은 '올리고 보는 것'입니다.

개발자의 머릿속에는 조금 다른 그림이 펼쳐집니다. '게시판'이라는 단어는 경험상 회원 가입, 로그인, 글쓰기·수정·삭제, 댓글, 페이지 나누기, 관리자 권한까지 갖춘 작은 커뮤니티를 의미했기 때문입니다. 어쩌면 네이버 카페 수준을 기본값으로 떠올릴 수도 있습니다.

둘 다 틀리지 않았습니다. 둘 다 자신의 경험에서 나온 **'간단한 게시판'**이니까요. 문제는 이 간극이 확인되지 않은 채 개발이 시작된다는 것입니다.

상상의 간극을 좁히는 두 가지 도구

다행히 이 간극을 줄이는 방법은 있습니다. 바로 화면 설계(와이어프레임) 와 구체적인 예시입니다.

와이어프레임은 정교한 디자인이 아니어도 됩니다. 어느 위치에 어떤 버튼이 있고, 클릭하면 어떤 화면으로 이동하는지를 손으로 그린 스케치 수준이라도 충분합니다. 글로는 천 마디가 필요한 설명이 화면 한 장으로 정리됩니다.

예시도 강력한 도구입니다. "저희가 원하는 건 요 사이트처럼요"라고 URL 하나를 보여주는 것만으로도 수십 분의 회의를 대신할 수 있습니다. 반대로 "이건 원하지 않아요"라고 말할 수 있어도 좋습니다.

좋은 개발사라면 이 과정을 개발 전에 반드시 거칩니다. 기획 단계에서 와이어프레임을 함께 그리며 "이렇게 이해했는데 맞나요?" 라고 먼저 묻는 개발사, 그것이 발주자 입장에서 신뢰할 수 있는 파트너의 첫 번째 기준입니다.

맞춰보지 않으면, 만들어 봐야만 알게 됩니다

소프트웨어 개발에서 가장 비싼 오해는 완성 직전에 발견되는 오해입니다. 이미 수개월의 시간과 비용이 쌓인 뒤에야 "제가 원한 건 이게 아니었어요"라는 말이 나오면, 양쪽 모두 지칩니다.

처음에 조금 더 시간을 내어 서로의 머릿속 그림을 꺼내 놓고 맞춰보는 것, 그게 성공하는 개발 프로젝트의 시작입니다.

혹시 지금 기획 중인 서비스가 있으신가요? 요구사항을 함께 들여다보며, 발주자와 개발자 사이에 상상의 간극이 없는지 같이 맞춰보고 싶습니다. 먼저 이야기 나눠보세요.