소통의 중요성

소통은 업무이자 태도다

Oct 24. 2025

개발은 협력하는 부서가 많다. 기획팀, 디자인팀, 테스트팀, 그리고 때로는 솔루션 업체나 다른 협력사들까지. 대규모 프로젝트라면 여러 회사가 모여 하나의 시스템을 만든다. 서로 다른 조직, 다른 입장, 다른 목표를 가진 사람들이 한 방향을 바라보려면 소통밖에 없다.

소통이 얼마나 중요한지 몸으로 느껴보려면 실패를 겪어봐야 안다.

관공서 프로젝트였다. 요구사항을 정리하고 고객에게 확인을 요청했지만 답이 없었다. 재차 문의해도 마찬가지였다. 일정은 흘러가고 있었다. 더 기다릴 수 없어 그대로 화면 설계서 작업을 시작했다.

화면 설계서를 완료하고 설계팀으로 넘기기 직전, 마지막으로 점검하던 중이었다. 오류 문구 하나가 누락된 게 보였다. 사용자가 잘못된 값을 입력했을 때 띄워줘야 할 메시지였다. 큰 문제는 아니었다. 다른 화면의 비슷한 케이스를 참고해서 적절한 문구를 작성했다. 확인하지 않는 고객 확인은 생략했다. 이미 여러 번 연락했지만 응답이 없었고, 설계 일정은 늦출 수 없었다.

개발이 대부분 완료되고 테스트가 진행될 때였다. 고객으로부터 연락이 왔다. 처음 보는 오류 문구가 있다는 것이었다.

고객에게 사정을 설명했다. 오류 문구가 누락되어 추가했고, 여러 번 확인을 요청했지만 답변이 없어 그대로 진행했다고. 하지만 이미 신뢰는 떨어진 뒤였다. 고객은 모든 오류 문구에 대한 전수 조사를 요청했다. 시스템과 코드에서 오류가 날 수 있는 모든 부분을 찾아내고, 각각의 오류 메시지를 문서화해서 확인받아야 했다.

일주일이 걸렸다. 개발은 멈췄고, 팀 전체가 오류 케이스를 찾아내는 작업에 매달렸다. 입력 값 검증, 서버 통신 오류, 권한 체크, 데이터 누락 등 모든 시나리오를 추출하고 정리했다. 고객과 기획자는 하나하나 리뷰하며 문구를 수정했다.

작은 소통 실수 하나가 더 큰 문제를 만들었다.

고객의 확인은 끝까지 기다리고 받아 내야 한다. 일정이 지연돼도 기다려야 한다. 확인-승인 없이 진행되는 프로젝트가 막판에 지옥으로 던져지는 걸 여러 번 경험했다.

한 줄의 오류 메시지가 일주일의 시간을 가져갔다. 고객 확인 없이 진행하면 어떤 일이 벌어지는지 뼈저리게 배웠다.

쇼핑몰 프로젝트의 PL(Project Leader)로 투입됐다. 화면 설계서를 보며 기능을 설계하고 개발을 이끌어 가는 역할이었다. 설계는 전체 시스템의 골격을 만드는 작업이다. 어떤 데이터를 어떻게 처리할지, 공통으로 사용할 코드는 무엇인지, 각 기능이 어떻게 연결될지를 정한다.

화면 설계서를 검토하던 중, 이상한 기능이 눈에 들어왔다. 사용자가 특정 버튼을 누르면 로그를 기록하는 단순한 동작이었다. 다른 곳에서는 쓰이지 않는 독립적인 기능이었고, 실제 서비스 로직과도 연결되지 않았다. 무의미해 보였다. 설계에서 제외했다.

개발자가 해당 화면을 개발하다가 물었다. 화면 설계서에는 있는데 기능 설계서에는 없다고. 무의미한 기능이라고 답했다. 개발자는 더 이상 묻지 않았다. 그렇게 넘어갔다.

테스트 단계에서 기획자가 찾아왔다. 그 기능이 왜 빠졌냐고 물었다. 무의미하다고 판단했다고 설명했다. 기획자는 고개를 저었다. 그 기능은 다른 시스템과 연계되어 있었다. 사용자 행동 패턴을 분석하는 별도의 모니터링 시스템에 데이터를 전송하는 역할이었다. 화면 설계서에는 그 맥락이 나와있지 않았지만, 요구사항 문서에는 명시되어 있었다. 기획자도 자신의 실수를 인정하면서도 물어봤어야 하지 않았냐고 따졌다.

결국 해당 기능을 제외하는 방향으로 고객을 설득해야 했다. 테스트 일정이 얼마 남지 않았고, 다른 시스템과의 연동까지 개발하려면 전체 일정이 지연될 수밖에 없었다. 대신 다음 프로젝트에서 페널티를 받았다. 없던 기능 하나를 무상으로 추가 개발하기로 했다.

무의미하다는 판단은 착각이었다. 전체 맥락을 보지 못하고, 기획자와 소통하지 않은 결과였다.

체험관의 인터렉티브 개발을 맡았을 때였다. 바닥에 빔 프로젝터로 영상을 쏘고, 사람이 지나가면 움직임에 따라 영상이 반응하는 시스템이었다. 클라이언트는 아이디어를 설명했고, 비슷한 사례 영상을 보여줬다. 대화를 나누며 요구사항을 정리했다.

개발을 시작했다. 클라이언트가 보여준 영상을 참고해서 움직임 인식 알고리즘을 구현하고, 반응하는 그래픽 효과를 만들었다. 중간 점검도 없이 일정대로 개발을 진행했다. 완료 후 원청사 고객에게 시연했다. (원청사가 발주하고 중간 클라이언트가 수주해서 하드웨어를 진행하고 소프트웨어는 나에게 요청한 관계이다.)

원청사 고객의 표정이 굳었다. 원하는 게 아니었다. 원청사 고객이 생각한 것은 사람의 발이 닿는 지점에서 파문이 퍼지는 효과였는데, 만들어진 건 사람의 실루엣을 인식해서 전체 화면이 변하는 방식이었다. 같은 '인터렉티브'라는 단어를 듣고도 전혀 다른 결과물을 만든 것이었다.

처음부터 다시 개발해야 했다. 원청사 고객이 원하는 정확한 효과를 확인하기 위해 여러 번 미팅을 했다. 간단한 프로토타입을 만들어 보여주고, 수정하고, 다시 확인받는 과정을 반복했다. 그제야 원청사 고객이 원하는 방향이 명확해졌다.

그 이후로는 습관이 생겼다. 대화를 나눈 후에는 반드시 재확인한다. "제가 이해한 게 맞는지 확인하고 싶은데요"라고 운을 떼고, 상대방이 말한 내용을 내 언어로 다시 설명한다. 작은 차이라도 그 자리에서 바로잡는다.

개발에서 문서는 방패다. 요구사항 정리서, 화면 설계서, 기능 명세서. 이 문서들은 단순한 기록이 아니라 고객과의 합의 내용이다. 개발자는 이 문서를 기준으로 개발하고, 고객은 이 문서를 기준으로 검수한다.

요구사항을 고객과 함께 정리하는 과정은 끝이 없다. 한 번의 회의로 끝나지 않는다. 정리하고, 확인하고, 수정하고, 다시 확인한다. 추가될 수도 있고, 삭제될 수도 있다. 이 반복을 거쳐야 고객이 진짜 만들고 싶은 게 무엇인지 드러난다.

화면 설계서도 마찬가지다. 한 화면 한 화면을 고객과 함께 리뷰한다. 안내 문구, 버튼 위치, 오류 메시지까지 토씨 하나 빠짐없이 확인한다. 리뷰가 끝난 설계서는 수정하면 안 된다. 별도의 파일을 만들어 버전을 올리고, 수정 이력을 남긴다. 마치 앱 업데이트처럼.

디자인도 화면 설계서를 따라야 한다. 디자이너가 버튼 위치를 바꾸고 싶다면 기획자와 소통해서 변경해야 한다. 아무리 시각적으로 더 나아 보여도, 고객과 합의된 화면 구성을 임의로 바꾸면 문제가 생긴다.

아키텍처가 기능을 설계할 때도 기획자와 계속 소통한다. 설계된 기능 리스트를 작성하고, 해당 기능이 맞는지 확인받는다. 기한 내에 불가능한 기능이 있다면 그 자리에서 이야기해서 고객에게 전달되도록 한다.

개발자도 마찬가지다. 자신에게 할당된 기능만 보고 개발하면 안 된다. 화면 설계서 전체를 읽고, 전후 맥락을 이해해야 한다. 로그인 기능을 개발한다면 회원 가입에서 어떤 데이터가 오는지 확인해야 한다. 혼자 판단하지 말고, 애매하면 물어야 한다.

소통을 위해서는 잘 들어야 한다. 선천적으로 내성적인 편이라 듣기에는 자신이 있다. 일상에서도 상대방 말에 집중하려고 노력한다. 무엇을 말하려는 것인지, 요점이나 핵심을 읽으려고 한다.

섣부른 판단을 하지 않으려 한다. 서두만 듣고 이해하는 척하지 않는다. 한국말은 끝까지 들어봐야 한다는 말이 있다. 상대방이 문장을 끝맺을 때까지 기다린다.

대화를 마치고 나서는 재확인한다. 내가 제대로 이해하고 있는지 상대방에게 다시 물어본다. 이 습관은 사회생활 초년생 때는 없었다. 체험관 개발을 다시 해야 했던 경험 이후로 생긴 습관이다.

책도 많이 읽으려 한다. 소설, 에세이, 인문학, 철학, 과학. 분야를 가리지 않는다. 책을 많이 읽을수록 이해력이 올라가고, 핵심을 정리하는 능력이 생기고, 대화의 질이 풍성해진다. 개인적인 경험이지만 확실하다.

정리하는 기술도 필요하다. 대화 후에 종합적으로 어떤 이야기를 했는지 정리하고, 다시 확인한다. 회의록을 작성하는 것도 같은 맥락이다. 회의나 인터뷰 중에 나오는 아이디어, 이슈, 정책은 메모한다. 나와 직접 관계없는 내용이라도 습관적으로 적는다. 그 자리에 있었다는 것 자체가 나와 관련이 있다는 뜻이다.

프로젝트는 혼자 하는 작업이 아니다. 영화 속 개발자들은 컴퓨터만 들여다보고 혼자 개발하는 이미지지만, 현실은 다르다. 혼자서 아이디어를 생각하고, 기획하고, 디자인하고, 개발하고, 출시하고, 고객을 직접 상대하며 유지보수까지 한다면 혼자 해도 된다. 하지만 그런 경우는 거의 없다.

돈은 클라이언트 고객으로부터 나온다. 클라이언트가 정한 출시일을 지켜야 한다. 클라이언트가 생각하는 방향으로 개발되어야 한다. 그래서 소통이 필수다.

고객의 시스템을 만드는 것이지 자신의 시스템을 만드는 게 아니다. 고객의 아이디어에 대해 기술적 조언은 할 수 있어도 평가해서는 안 된다. 잘 듣는다는 건 듣고 나서 상대방이 무엇을 말하는지 이해하는 것이다. 이해가 되지 않는 부분은 재차 물어야 한다. 상대방의 생각과 내 생각이 거의 일치하고 이해할 수 있을 때까지 소통해야 한다.

기획자는 고객과 수많은 소통을 통해 요구사항을 문서화한다. 디자이너는 기획자와 소통하며 화면을 만든다. 아키텍처는 기획자와 소통하며 시스템을 설계한다. 개발자는 모든 문서를 읽고, 필요하면 질문하며 코드를 작성한다. 테스터는 기획자, 개발자와 소통하며 오류를 찾아낸다.