회사 소개 - 우리의 오랜 경험을 고객의 새로운 경험으로

실력이, 평판이, 관점이 다릅니다.

대기업부터 스타트업까지, 사업을 하다 보면 크고 작은 외주를 한 번 이상 맡기게 됩니다. 대부분 외주는 갈등으로 이어집니다. 개발사는 “고객의 요구사항대로 만들었는데 뭐가 문제냐”고 하고, 고객은 “융통성 없이 딱 요구사항대로만 만든 제품을 어떻게 쓰냐”고 합니다.

이 갈등을 피하고자 고객사는 기능 정의서, 작업 계획서, 계약서를 빈틈없이 작성하고 개발사를 감시하는 데 에너지를 소비합니다.

반면 개발사는 책임을 덮어쓰는 게 두려워 기능 정의서에서 한치도 벗어나지 않으며, 고객사의 변경 요청에 방어적으로 대응합니다.

그런데 기능 정의서대로 개발하면 엉뚱한 제품이 나오기 십상입니다. 개발 과정에서 고객의 생각이 점점 발전하기 때문입니다. ‘아, 만들다 보니 우리에게 필요한 제품은 처음 예상과 다른 것이었구나’라고 깨닫는 것이죠.

이 때 개발사가 고객의 고민을 수용하지 않고 “계약대로, 기능 정의서대로 만들 뿐이다”라고 버티면 고객사는 돈과 시간을 날리는 셈이 됩니다. 한편 개발사는 고객과 장기적인 관계를 도모할 수 없습니다. 그런 개발사와 누가 다시 일하고 싶을까요.

이런 단발성, 일회성 프로젝트에서 개발사의 우월전략은 C급 인력을 투입해 기능 정의서대로 빠르게 작업을 마치고 빠져나오는 것입니다. 그래서 많은 외주사들이 프리랜서 개발자에게 재하청을 주고 있으며, 따라서 산출물의 품질이 2류에 그치게 됩니다.

고객과 개발사 간 불신이 커지면서, 국내 외주 시장은 IT 태동기 이후 수십년 간 악순환의 길을 걸어왔습니다.

다빈치는 새로운 방식을 제안합니다.

다빈치는 ‘신뢰’를 최우선 가치로 둡니다. 돈이 오가는 일에 신뢰 같은 추상적 단어는 어울리지 않게 느껴질 수 있지만, 신뢰야말로 고객사, 개발사 모두의 시간과 돈을 크게 아껴줍니다. 불신에 기인한 형식상의 절차를 생략하고 그 시간 동안 제품을 만들면 두 배, 세 배, 그 이상의 작업을 할 수 있습니다. 그래서 다빈치는 고객사가 발 뻗고 잘 수 있도록 하는 데 힘을 기울입니다.

다빈치는 고객에게 빡빡한 기능 정의서를 요구하지 않습니다. 대신 다빈치는 고객과 매일 소통합니다. 전화로, 문자로, 메일로 고객의 생각을 시시각각 물어보고, 1~2주에 한 번씩 제품을 직접 시연(데모)하면서 고객의 피드백을 받습니다.

다빈치는 수십 번의 프로젝트를 진행하면서 “계약 당시와 내용이 달라졌다”거나, “개발사가 바가지를 씌웠다”거나 하는 갈등을 전혀 겪지 않았습니다. 매 프로젝트마다 상호 신뢰를 다질 때까지 충분히 대화를 거치기 때문입니다.

개발 외주와 컨설팅의 가장 큰 차이는 ‘관점’입니다. 개발 외주의 목표가 ‘제품의 납품’이라면, 컨설팅의 핵심은 ‘고객의 성공’입니다. 고객이 성공하는 데 제품으로서 기여하겠다는 뜻이죠.

사업이 성공하는 데 있어 제품은 일부분에 불과합니다. 제품을 둘러싼 맥락은 훨씬 넓습니다. 컨설턴트는 제품 개발에 앞서 이런 질문을 합니다.

“이 제품이 고객사의 기대만큼 성공할 수 있을까?”
“고객사가 진짜 원하는 게 이 제품이 맞나?”
“고객사의 임직원 또는 고객의 고객(최종 고객)이 이 제품을 편하게 쓸 수 있을까?”
“고객사의 투자 유치에 이 제품이 도움이 될까?”
“고객사가 이 제품을 스스로 유지보수할 수 있을까?”

다빈치는 고객이 주문한 대로 제품을 만들지 않습니다. 오히려 고객에게 적극적으로 질문하면서, 고객의 성공에 실제로 기여할 수 있는 방법을 찾습니다. 심지어 그 과정에서 프로젝트를 연기하거나 무산시키기도 합니다(!). 고객이 불필요하게 큰 예산을 잡은 경우, 상대적으로 저렴한 프리랜서 플랫폼으로 유도하기도 하지요.

일례로 엑셀로 하던 작업을 웹 어드민으로 바꾸고 싶다고 한 어느 고객의 경우, 화면을 띄워놓고 한참 대화한 후 무료로 엑셀 매크로(VBA)를 만들어드렸습니다. 웹 제품이 필요할 정도로 고충이 크지 않고, 니즈가 불명확했기 때문입니다.

개발의 고수가 될수록 코드가 짧아진다는 말이 있습니다. 가장 짧은 코드는 0줄입니다. 즉 불필요한 개발을 하지 않고 문제를 해결하는 것이야말로 가장 뛰어난 방식이라는 말이죠.

우리는 개발자이면서 동시에 컨설턴트입니다. 우리는 컨설턴트이기 때문에 더 나은 개발자가 되고, 개발자이기 때문에 더 나은 컨설턴트가 됩니다.

개발을 잘한다는 표현은 단순히 코드 작성 능력에 국한되지 않습니다. 개발자의 일은 문제 해결의 연속이며, 그 과정에서 발생하는 다양한 상황과 요구에 효과적으로 대응하는 능력을 요구합니다. 따라서 개발을 잘한다는 표현은 기술, 소통, 이해, 그리고 문제 해결 능력을 아우릅니다. 그런 점에서 다빈치는 개발을 대한민국에서 가장 잘하는 회사라고 확신합니다.

개발을 잘한다는 것은 단순히 새로운 프로그래밍 언어나 프레임워크를 빠르게 익히는 능력을 의미하지 않습니다. 초보 개발자는 흔히 새로운 기술을 배우는 데 집중하며 이를 통해 역량을 과시하려 하지만, 진정한 고수는 익숙한 기술을 활용해 문제를 해결하는 데 집중합니다. 다빈치는 기술을 도구로써 인식하며, 문제 해결 수단으로서의 기술을 사용합니다. 다빈치는 사업자의 관점에서 기술을 바라봅니다.

더불어 소통 능력은 개발을 잘하는 데 필수적입니다. 소프트웨어 개발은 혼자서 이루어지는 작업이 아니며, 협업이 필수적입니다. 숙련된 개발자는 자신의 아이디어를 명료하게 전달하고, 팀의 위력을 이해합니다. 이들은 기술적인 문제를 개발과 무관한 이해관계자에게도 쉽게 설명합니다. 다빈치는 늘 고객의 언어를 사용하며, 고객의 지식 범위 내에서 탁월한 소통 방법을 찾아냅니다.

개발을 잘한다는 것은 또한 문제 해결에 대한 깊은 이해를 의미합니다. 다빈치 개발자들은 개발자이면서 동시에 컨설턴트로서, 문제를 해결함에 있어 코드 작성이 유일한 방법이 아니라는 것을 알고 있습니다. 때로는 코드 작성 대신 기존 시스템을 재구성하거나, 프로세스를 변경하거나, 혹은 단순한 설정 변경을 통해 문제를 해결할 수도 있습니다. 다빈치는 문제의 본질을 이해하고, 그에 맞는 최적의 해결책을 찾는 데 초점을 둡니다.

끝으로, 개발을 잘한다는 것은 맥락을 살피는 태도를 가지는 것을 의미합니다. 소프트웨어는 고객의 사업과 고객사 구성원의 삶에 지대한 영향을 미칠 수 있으며, 따라서 개발자는 자신의 코드가 어떤 영향을 미칠지 숙고해야 합니다. 이는 단순히 버그를 최소화하는 것이 아니라, 사용자의 일상과 업무 흐름을 예상하는 것을 포함합니다. 다빈치는 소프트웨어의 범위를 넘어 고객이 일하는 방식 전체를 연구합니다.

다빈치 고객들은 예외 없이 다빈치를 칭찬합니다. 적잖은 비용에도 불구하고 62.5%의 고객들이 2차, 3차 프로젝트로 다빈치를 재고용했으며, 프로젝트가 끝난 후에도 좋은 관계를 맺고 있습니다.