많은 조직에서 개발자를 평가할 때 흔히 이런 기준을 사용합니다.
“주어진 기능을 얼마나 빠르게, 얼마나 정확히 구현하는가?”
맞는 말입니다. 하지만 그것만으로는 좋은 개발자를 설명하기 어렵습니다.
회사의 관점에서 보면, 소프트웨어 개발은 그 자체가 목적이 아니라 비즈니스 목적을 달성하기 위한 수단입니다. 예를 들어, 쇼핑몰에서 검색 기능을 개발했다면 그 기능의 본질은 “검색창이 잘 작동하는가”가 아니라 “사용자가 원하는 상품을 빠르게 찾고, 구매 전환율이 높아졌는가”가 되어야 합니다.
이 말은 곧 “개발을 잘한다”는 것은 디폴트(기본값)이며, 좋은 개발자는 ‘일을 되게 만드는 사람’이라는 의미입니다. 기술적인 완성도는 물론, 그것이 비즈니스에 어떤 임팩트를 주는지를 함께 고민하고, 필요한 경우 다른 대안을 제안하며, 목표를 이루는 방향으로 팀을 이끄는 사람이 바로 좋은 개발자입니다.
우리는 종종 “소프트웨어 개발이 목적”이라는 오해에 빠집니다. 그러나 실제로는 소프트웨어는 회사의 목적을 실현하기 위한 하나의 도구일 뿐입니다. 좋은 개발자는 그 도구를 ‘잘’ 쓰는 사람이고, 더 좋은 개발자는 왜 그 도구를 써야 하는지를 아는 사람입니다.
비즈니스 조직이 주체적으로 이 일을 하고 있고 개발자는 그들의 요구사항을 달성해주는 것이 기능조직으로서 목적은 맞습니다. 그러나 그 요구사항을 달성하는 것을 더 잘하기 위해서 개발자는 개발만 하면 안됩니다. 그들의 생각을 이해하고 요구사항의 맥락을 파악해야 합니다. 그래서 올바른 리소스 투입 방향을 결정할 수 있어야 합니다.
어떤 일이든 지연되기 시작하면 원인을 기술과 리소스에서만 찾기 쉽습니다.
“요청이 많다”, “개발자가 부족하다”, “우선순위가 밀렸다”
하지만 정말 그게 전부일까요? 한 가지 사례를 보겠습니다.
어느 날 비즈니스팀에서 운영 DB 접근 권한을 요청해왔습니다. 실제 운영 데이터를 직접 조회할 수 있게 해달라는 요청이었죠. 하지만 운영 DB 접근은 보안상 매우 제한적인 권한이었고, 요청은 계속 ‘대기’ 상태로 머물렀습니다.
1주일이 넘도록 이 요청은 해결되지 않았습니다. 그런데, 정말 문제는 ‘접근 권한’이었을까요?
이 요구의 배경을 물어보니, 실무자는 단지 상품에 남겨진 메모 필드를 주문 데이터와 함께 보고 싶었을 뿐이었습니다. 어드민에 기능이 없으니 직접 DB에서 쿼리하려 했고, 개발팀은 이 요청이 얼마나 간단한지 몰랐고, 실무자는 개발팀이 바빠 보여 말을 꺼내지 않았습니다.
“왜 필요한가요?”라는 질문 하나가 없어서, 단 20분이면 끝날 일을 1주일 넘게 붙들고 있었던 것입니다.
이게 바로 ‘요구사항 뒤에 숨은 맥락’입니다. 요청 뒤에 숨어 있는, 진짜 원하는 해결책은 다른 방식일 수 있습니다. 개발자와 실무자 사이에는 언제나 정보의 비대칭이 존재합니다. 서로가 상대의 업무 맥락을 정확히 알지 못합니다.
이 간극을 줄이는 가장 빠르고 정확한 방법은 질문입니다.
“왜 필요하세요?”, “이걸 통해 어떤 효과를 기대하시나요?”
이 질문은 단지 커뮤니케이션을 위한 질문이 아닙니다.
더 나은 해결책을 찾기 위한 질문, 낭비를 줄이고 비즈니스 임팩트를 높이기 위한 질문입니다. 그리고 그 질문을 하지 않은 채 시간을 흘려보냈다면, 그건 ‘개발이 늦은’ 문제가 아니라 문제를 해결하려는 태도가 없었던 것일지도 모릅니다.
비즈니스 전략팀에서 하나의 요청이 들어왔습니다. “상품 노출을 트래킹할 수 있는 로직을 만들어 주세요.”
기존에 쓰던 앰플리튜드는 호출이 잦아 비용이 높았고, 그래서 내부에서 직접 이벤트 트래킹 시스템을 개발하자는 안이 검토되고 있었습니다. 프론트엔드에서 이벤트를 발생시키고, 이를 백엔드에서 수집해 데이터웨어하우스에 적재한다는 계획이었습니다.
문제는 개발 공수가 상당히 크고, 해당 프로젝트의 비즈니스 우선순위는 상대적으로 낮았다는 점입니다. 개발팀은 요청된 대로 공수를 산정했고, 일정은 길어졌습니다.
그 결과, “이걸 정말 지금 해야 할까?” 하는 분위기가 형성되었습니다. 그때, 누군가 질문했습니다.
“기존에 쓰던 GA4로는 불가능한가요?”
알고 보니 GA4에도 이미 기본적인 이벤트 로직이 일부 심어져 있었고, 여기에 상품 노출 이벤트 하나만 추가하면 트래킹이 충분히 가능했습니다. 심지어 GA4는 퍼널 분석도 지원하며, 무료로 사용 가능합니다.
결국 이 프로젝트는 GA4를 활용하는 쪽으로 전환되었고, 불필요한 시스템 개발은 하지 않아도 되었습니다.
이 사례는 다음을 말해 줍니다
공수 산정은 중요한 일입니다. 하지만 그것만으로 ‘좋은 결정’을 할 수는 없습니다.
개발자도 비즈니스의 우선순위를 이해하고, 기존 자원의 활용 가능성을 고려해야 합니다.
기술은 목적이 아니라 수단입니다. 우리가 ‘만들 수 있다’고 해서 반드시 ‘만들어야 하는 것’은 아닙니다. 좋은 개발자는 더 빠르고, 더 가볍고, 더 현실적인 길을 찾아냅니다. 그리고 그 시작은 비즈니스 맥락에 대한 이해에서 비롯됩니다.
소프트웨어 개발자는 제품을 만드는 사람입니다. 하지만 좋은 개발자는 단지 ‘제품’이 아니라 ‘일’을 완성합니다. 코드를 잘 짜는 건 이제 기본값입니다.
실력은 언제나 그 이상에서 갈립니다. 요구사항 뒤에 있는 비즈니스 맥락을 이해하고, 공수보다 더 중요한 우선순위와 대안의 가능성을 스스로 검토합니다.
지금 꼭 개발해야 할까?
기존 도구로 해결할 수 있는가?
기능보다 더 필요한 건 오히려 방향 조정이 아닐까?
이렇게 생각하고 말하는 개발자는 단순히 요구사항을 ‘잘 구현하는 사람’이 아니라 함께 목표를 완성하는 동료로 인식됩니다. 좋은 개발자란, 기술을 넘어 맥락을 이해하고 일을 완성하는 사람입니다. 조직은 그런 개발자에게 더 큰 신뢰를 보냅니다.
그리고 그 신뢰는 결국 더 나은 제품, 더 빠른 실행력, 더 효율적인 협업으로 이어집니다.
개발자들은 흔히 기능명세서를 통해 요청을 받습니다. 하지만 정말 좋은 소통은, 단순한 기능 나열이 아니라
“왜 이게 필요한가?”가 담긴 문서에서 시작됩니다. 기획자나 실무자가 다음과 같이 말하는 경우가 있습니다.
“상품이 노출될 때마다 트래킹이 되어야 해요.”
하지만 그 뒤에 이렇게 말이 덧붙여지면 이야기는 달라집니다.
“이 데이터가 있어야 프로모션 효과를 분석할 수 있고, 이게 없으면 다음 캠페인 기획에 어려움을 겪게 됩니다. 사실 앰플리튜드는 비용이 부담이라… 다른 방법이 없을까요?”
이렇게 기능 설명 + 비즈니스 맥락 + 우선순위가 담긴 요청은 단순한 ‘할 일’이 아닌 ‘함께 고민해야 할 문제’로 바뀝니다. 개발자는 기능 구현이 아닌 대안 제시자가 될 수 있고, 실무자는 개발자에게 미안한 요청자가 아니라 같은 목표를 향해 고민하는 동료가 됩니다.
결국 소통의 핵심은 서로의 언어를 배우는 것입니다. 개발자는 비즈니스 언어를, 실무자는 기술 언어를 조금씩 배워야 합니다. 그 사이를 연결해 주는 건, 결국 맥락이 담긴 설명입니다.
시작은 언제나 “왜 이 기능이 필요한가요?“라는 질문에서 시작됩니다.
좋은 개발자는 단순히 기능을 구현하는 사람이 아닙니다. 그들은 일을 되게 만드는 사람입니다.
그 차이는 어디에서 시작될까요? 바로 이 질문 하나에서 시작됩니다.
“이 기능이 왜 필요한가요?”
이 질문을 던지는 순간, 요구사항은 ‘할 일’이 아닌 ‘이해해야 할 일’이 됩니다. 개발자는 단순한 전달자가 아니라, 맥락을 구현하고 문제를 해결하는 주체로 바뀝니다. 그리고 그 질문은 1주일을 단축시키기도 하고, 불필요한 시스템 개발을 막기도 하며, 더 나은 협업을 가능하게 합니다.
비즈니스의 목적을 이해하고, 우선순위를 판단하며, 대안을 제시할 수 있는 개발자. 그런 개발자가 결국 진짜 실력자입니다. 좋은 코드는 기본입니다. 하지만 좋은 질문이 만들어 내는 결과는 그보다 훨씬 가치 있습니다.