The best e-business partner
BRUNCH
시스템 개발은
기술로 이루어집니다.
코드로 만들고,
구조로 설계하고,
데이터로 움직입니다.
그래서 처음에는
기술이 전부인 것처럼 느껴집니다.
어떤 언어를 쓰는지,
얼마나 빠르게 만드는지,
얼마나 복잡한 구조를 다룰 수 있는지.
그 기준으로 개발사를 보게 됩니다.
하지만 프로젝트를 진행하다 보면
한 번쯤은 이런 순간을 겪게 됩니다.
분명 문제는 아닌데
어딘가 계속 어긋나는 느낌.
기술적으로는 문제가 없는데
이야기가 잘 통하지 않는 순간들입니다.
같은 기능을 두고 이야기하고 있는데
서로 이해하고 있는 내용이
조금씩 다를 때입니다.
현장에서 자주 듣는 말이 있습니다.
“설명을 듣긴 했는데…
무슨 말인지 잘 모르겠습니다.”
개발자는 충분히 설명했다고 생각하지만
의뢰자는 이해하지 못한 채
고개만 끄덕이고 있는 경우입니다.
그 상태로
프로젝트는 계속 진행됩니다.
그리고 시간이 지나면
그 작은 어긋남이
조금씩 커지기 시작합니다.
개발자는 구조로 생각합니다.
효율과 안정성,
확장성과 성능.
같은 기능을 보더라도
그 안에서 어떻게 만들어질지를 먼저 봅니다.
반면 의뢰자는 결과로 생각합니다.
이게 어떻게 보일지,
사용자가 어떻게 쓸지,
매출과 연결될 수 있을지.
같은 이야기를 하고 있지만
보고 있는 방향이 조금씩 다릅니다.
그래서
문제는 기술이 아니라 설명이 됩니다.
개발자는
“가능합니다.”라고 말했는데
의뢰자는
“생각한 것과 다릅니다.”라고 느끼게 됩니다.
틀린 말은 아니지만 같은 말도 아닙니다.
그 사이 어딘가에서
이해가 어긋나기 시작합니다.
현장에서 자주 느끼는 것은
이 부분입니다.
기술을 잘하는 것과
기술을 잘 전달하는 것은
다른 능력이라는 점입니다.
잘 만든 구조도
설명되지 않으면
이해되지 않고
이해되지 않은 시스템은
결국 신뢰로 이어지지 않습니다.
그래서 어느 순간부터
기준이 조금 달라집니다.
얼마나 잘 만드는가보다
얼마나 잘 설명하는가를
함께 보게 됩니다.
복잡한 것을
단순하게 풀어낼 수 있는지,
상대의 언어로
이야기할 수 있는지.
그 능력이
프로젝트의 흐름을
생각보다 크게 바꿉니다.
기술은
정답이 있는 영역이지만
소통은
정답이 없는 영역에 가깝습니다.
그래서 더 어렵습니다.
상대가 이해할 수 있는 방식으로
같은 이야기를
다르게 풀어야 하기 때문입니다.
생각해 보면
좋은 개발사는
단순히 잘 만드는 사람이 아니라
같이 이해할 수 있도록
설명해 주는 사람에
더 가까운 것 같습니다.
기술을 보여주는 것이 아니라
기술을 이해하게 만드는 사람.
그래서 어떤 프로젝트는
같은 기술로도
조금 더 편안하게 흘러갑니다.
이해가 쌓이고,
기대가 맞춰지고,
방향이 자연스럽게 이어지기 때문입니다.
돌이켜 보면
소통은
부가적인 능력이 아니라
기술을
현실로 연결하는
과정에 더 가깝습니다.
그리고 그 과정이
잘 이어질 때
비로소 기술은
결과로 남습니다.
결국 결과는 기술이 아니라, 얼마나 함께 이해했는지에서 결정됩니다.
출처 : 브런치,[by 박민정] – [좋은 개발사는 기술을 설명할 줄 아는 사람이다] [원문 링크]
