중소기업이 맞춤형 소프트웨어를 구매할 때 저지르는 7가지 실수
맞춤형 소프트웨어는 중소기업이 쓰는 가장 현명한 돈이 될 수도, 가장 뼈아픈 돈이 될 수도 있습니다. 그 차이는 코드에 있는 경우가 거의 없습니다. 한 줄도 작성되기 전에 사람들이 저지르는, 피할 수 있는 일곱 가지 실수에 있습니다.

맞춤형 소프트웨어 프로젝트로 데인 중소기업 대부분은 형편없는 프로그래머 때문에 데인 것이 아닙니다. 그들은 어떤 프로그래밍이 시작되기 몇 주 전에 이미 데었습니다. 킥오프 회의에서, 이메일 스레드에서, 악수를 나누면서, 그 당시에는 사소해 보였던 한 가지 결정으로 말입니다. 코드가 도착할 무렵이면 실수는 이미 그 안에 박혀 있습니다. 다행인 점은 이 실수들이 지루할 만큼 반복적이라는 것입니다. 즉, 그것들이 어떤 모습인지 알기만 하면 피할 수 있습니다.
저는 이런 프로젝트를 양쪽 입장 모두에서, 안쪽에서 많이 지켜봤습니다. 어떤 것은 한 회사가 그것 없이 일하는 모습을 상상조차 할 수 없는 도구가 되었습니다. 어떤 것은 절반만 완성된 로그인 화면, 팽팽한 청구서 분쟁, 그리고 다시는 맞춤 개발에 손대지 않겠다고 다짐하는 대표가 되었습니다. 답답한 점은 이 두 결과를 가른 것이 얼마나 작았는가입니다. 기술이 문제인 경우는 드물었습니다. 기술을 둘러싼 결정이 거의 언제나 문제였습니다.
그래서 중소기업이 주문제작 소프트웨어를 발주할 때 제가 거듭 목격하는 일곱 가지 실수를 소개합니다. 어느 것도 피하는 데 기술적 배경이 필요하지 않습니다. 무언가에 서명하기 전에 그것들이 존재한다는 사실을 아는 것만으로 충분합니다.
실수 1: 문제를 이해하기 전에 해결책을 사는 것
가장 값비싼 실수는 맨 먼저 일어나며, 무해하게 들립니다. “X를 하는 앱이 필요해요.” 누군가 그 말을 입 밖에 낼 무렵이면, 보통 이미 해결책의 형태—대시보드, 포털, 모바일 앱—를 정해 둔 상태이고, 정작 실제 문제를 평이한 말로 적어 둔 사람은 아무도 없습니다. 그러면 개발은 잘못된 것을, 충실하게, 아름답게 만들어 냅니다.
좋은 소프트웨어는 기능 목록이 아니라 문제 진술에서 출발합니다. “우리 사무팀은 이메일로 온 주문을 회계 시스템에 일일이 다시 입력하는데, 두 사람이 반나절이 걸립니다”는 문제입니다. “맞춤형 CRM이 필요해요”는 아무도 이름 붙일 수고를 하지 않은 문제에 대한 해결책의 추측입니다. 앞엣것은 저렴하게 해결하고 측정할 수 있습니다. 뒤엣것은 돈을 쓰라는, 끝이 정해지지 않은 초대장입니다.

실수 2: 모든 것을 한꺼번에 만들려는 것
맞춤형 소프트웨어는 십 년에 한 번 하는 구매처럼 느껴지기에, 사람들은 십 년치 바람을 버전 1에 욱여넣으려 합니다. 모든 부서가 요청을 보탭니다. “하는 김에”라는 말마다 예스가 떨어집니다. 범위는 부풀고, 일정은 세 배가 되며, 누군가 써 보기도 훨씬 전에 프로젝트는 제 야심의 무게에 무너집니다.
성공하는 기업은 그 반대로 합니다. 문제 중 가장 고통스러운 한 조각만 골라 그것을 먼저 만듭니다—몇 달 안에, 운영 환경에서 실제로 돌아가는 무언가를. 그런 다음 실제 사용이 다음에 무엇을 할지 말하게 둡니다. 이는 단지 더 저렴한 것이 아니라 더 안전합니다. 판돈이 아직 작을 때 아이디어가 통하는지 배우게 됩니다. 반년과 큰 청구서가 지난 뒤에야 잘못된 것을 설계했음을 깨닫는 대신에 말입니다.
“완성되어 매일 쓰이는 작은 것이, 80% 완성된 채 스테이징 서버에서 조용히 죽어 가는 거창한 것을 이깁니다.”
그 아래에는 냉정한 진실이 깔려 있습니다. 당신은 사실 아직 무엇이 필요한지 모릅니다. 시작 시점에는 아무도 모릅니다. 문제에 대한 당신의 이해는 실제 사람들이 실제 도구를 만지는 순간 바뀝니다. 모든 것을 미리 만드는 것은 가장 이르고 가장 정보가 빈약했던 추측을 못 박아 버립니다. 조각으로 나눠 만드는 것은 유연함을 지키고—아직 배우는 동안 예산을 통제 아래 둡니다.
실수 3: 가격만 보고 고르는 것
견적을 셋 받습니다. 하나가 나머지보다 극적으로 쌉니다. 안도하며 그것을 택합니다. 이는 작은 프로젝트를 값비싼 것으로 바꾸는 가장 확실한 방법 중 하나입니다. 싼 견적이 작업이 더 싸다는 뜻인 경우는 거의 없기 때문입니다. 보통은 양측이 그 일을 서로 다르게 이해했다는 뜻입니다.
낮은 숫자는 흔히 몇 가지 중 하나를 신호합니다. 업체가 질문을 충분히 하지 않아 범위를 낮게 잡았거나, 나중에 변경 요청으로 마진을 챙길 작정이거나, 경험이 적어 자신이 무엇을 모르는지 아직 모르는 것입니다. 어느 쪽도 당신에게 좋게 끝나지 않습니다. 표면에 적힌 가격은 제안서에서 가장 쓸모없는 숫자입니다. 중요한 것은 업체가 당신의 문제를 분명히 이해하는지, 껄끄러운 질문을 하는지, 그리고 무엇이 포함되지 않았는지에 대해 솔직한지입니다.
실수 4: 소프트웨어가 일회성 구매가 아님을 잊는 것
맞춤형 소프트웨어는 흔히 가구처럼 제안되고 구매됩니다. 한 번 내면 영원히 내 것, 이라는 식으로요. 그렇지 않습니다. 소프트웨어는 움직이는 세상 속에 삽니다—운영체제가 업데이트되고, 브라우저가 바뀌고, 보안 패치가 떨어지고, 사업이 변하고, 연동된 도구가 규칙을 바꿉니다. 아무도 유지보수하지 않는 도구는 서서히 작동을 멈추다가, 가장 나쁜 순간에 고장 납니다.
이는 중소기업을 호되게 칩니다. 계약 시점에 유지보수 비용이 보이지 않기 때문입니다. 당신은 두 견적을 개발 가격으로 비교하면서, 정작 더 중요한 질문은 결코 하지 않습니다. 이것을 해마다 살아 있고 건강하게 유지하는 데 비용이 얼마나 드는가? 호스팅, 업데이트, 자잘한 수정, 사업이 발전함에 따른 이따금의 변경—이것을 보험이나 회계처럼 정상적이고 지속되는 비용 항목으로 계획하십시오. 대개 액수는 크지 않지만, 그것도 당신이 예상하고 있을 때뿐입니다.
| 비용 | 계약 시 명백한가? | 계획에 넣기 |
|---|---|---|
| 초기 개발 | 예 | 당연히 |
| 호스팅과 인프라 | 때때로 | 매월, 지속적으로 |
| 보안 업데이트와 수정 | 드물게 | 연간으로 예산화 |
| 성장에 따른 변경 | 드물게 | 예상하기 |
| 온보딩과 교육 | 거의 없음 | 첫날부터 반영 |
| 코드와 데이터 소유 | 거의 없음 | 시작 전에 합의 |
실수 5: 요구사항을 모호하게, 주인 없이 내버려 두는 것
"당신들이 전문가니 그냥 좋은 걸 만들어 주세요"는 너그럽게 들립니다. 사실 이것이 프로젝트가 표류하는 방식입니다. 당신의 사업을 가장 잘 아는 사람은 당신과 당신의 팀이지 개발자가 아닙니다. 흐릿한 의뢰서를 넘기고 사라지면, 업체는 빈틈을 자신들의 최선의 추측으로 메우고, 당신은 그 추측을 가장 나쁜 때—납품 시점, 바꾸기가 가장 비싼 때—에 알게 됩니다.
당신 쪽에서 채워야 할 역할이 둘 있는데, 중소기업은 으레 둘 다 채우지 않습니다. 첫째는 단일 의사결정자—예라고 말할 수 있고, 부서 간 이견을 가려 줄 수 있으며, 몇 주씩 질문에 답하지 못할 만큼 바쁘지 않은 한 사람입니다. 둘째는 중요한 부분에 대해 구체적이려는 의지입니다. 예외 사례, 사업이 늘 수작업으로 처리해 온 별난 예외, 모두가 알지만 아무도 적어 두지 않은 규칙. 바로 그것이야말로 소프트웨어가 제대로 다뤄야 하는 것입니다.

실수 6: 코드와 데이터의 소유자를 묻지 않는 것
이것은 조용한 실수이며, 몇 년 뒤에 가장 아픈 실수입니다. 맞춤형 소프트웨어에 돈을 내고는 그것이 내 것이라 여깁니다. 그러다 업체와의 관계가 틀어지거나, 가격을 올리거나, 그저 사라집니다—그리고 당신은 옴짝달싹할 수 없음을 알게 됩니다. 소스 코드가 없습니다. 데이터는 그들만 접근할 수 있는 시스템 안에 있습니다. 당신의 사업 전체가 이제 더는 믿지 못할 회사에 달려 있고, 협상력은 하나도 없습니다.
이 가운데 어느 것도 막는 데 변호사가 필요하지 않습니다. 필요한 것은, 아직 모든 협상력을 쥐고 있는 시작 전에 던지는 세 가지 평이한 질문입니다. 이것이 끝나면 소스 코드는 누구의 것이 됩니까? 제 데이터 전부를, 쓸 수 있는 형식으로, 원할 때 언제든 내보낼 수 있습니까? 그리고 우리가 갈라선다면, 저는 정확히 무엇을 가지고 떠납니까? 평판 좋은 파트너는 이런 질문에 눈 하나 깜짝하지 않고 답합니다. 여기서의 머뭇거림은 전 과정에서 가장 큰 위험 신호입니다.
- 소스 코드를 소유하거나, 그에 대한 명확하고 공정한 라이선스를 가진다는 점을 서면으로 받아 두십시오.
- 자신의 데이터를 표준 형식으로, 요청 시, 허락 없이 내보낼 수 있음을 확인하십시오.
- 다른 개발자가 이어받을 수 있을 만큼 작업이 충분히 문서화되어 있는지 확인하십시오.
- 흔하고 잘 알려진 기술로 같은 일을 할 수 있는 곳에서는 독점 기술에 묶이는 것을 피하십시오.
- 언젠가 업체를 바꿀 경우 호스팅과 계정이 어떻게 되는지 미리 합의하십시오.
실수 7: 출시를 결승선으로 여기는 것
소프트웨어가 납품되고, 작동하고, 모두 안도합니다. 프로젝트는 완료로 선언됩니다. 여섯 달 뒤, 팀의 절반은 슬그머니 옛 스프레드시트로 돌아가 있고, 값비싼 새 도구는 두 사람이 한 가지 용도로만 씁니다. 개발은 성공했습니다. 정착은 실패했습니다—그리고 이 둘은 완전히 다른 문제입니다.
사람들이 새 도구에 저항하는 것은 어리석거나 고집스러워서가 아닙니다. 새 방식이 낯설고 옛 방식이 그런대로 아직 통하기 때문에 저항합니다. 그것을 이겨 내려면 아무도 예산에 넣지 않은 의도적인 노력이 듭니다. 약간의 교육, 그 변화가 그들 자신에게 어떻게 도움이 되는지에 대한 분명한 이유, 처음 몇 주 동안 핀잔 없이 어리석은 질문에 답해 줄 사람, 그리고 미끄러져 돌아갈 도피처가 없도록 옛 방식을 퇴역시키는 단호한 결정.
- 1먼저 소규모 그룹에 출시하기전 직원에 앞서, 의향 있는 몇 사람에게 도구를 풀어 보십시오. 그들이 거친 부분을 찾아내고 사내 옹호자가 되어 줍니다.
- 2회사의 이득이 아니라 개인의 이득을 보여 주기"이건 회사 비용을 아껴 줍니다"는 아무도 움직이지 못합니다. "이건 당신이 주소를 두 번 입력하지 않게 해 줍니다"가 사람들을 끌어들입니다.
- 3질문 창구가 될 사람을 정하기첫 한 달은 누군가가 어리석은 질문을 떠맡습니다. 첫째 주의 마찰이 정착을 영영 죽입니다.
- 4옛 방식을 정말로 꺼 버리기옛 스프레드시트가 존재하는 한, 사람들은 계속 그것을 씁니다. 새 도구가 돌아가면 도피처를 퇴역시키십시오—부드럽되 분명하게.

정리하며: 구매자의 마음가짐
이 일곱 가지를 다시 읽어 보면 하나의 실이 관통합니다. 거의 어느 것도 기술적이지 않습니다. 그것들은 명료함, 소유, 그리고 절제에 관한 것입니다—사러 나서기 전에 자신의 문제를 알기, 작은 걸음으로 만들기, 가격이 아니라 이해도로 업체를 판단하기, 도구의 탄생만이 아니라 일생을 계획하기, 계속 관여하기, 자신의 출구를 지키기, 그리고 출시를 진짜 일의 시작으로 여기기.
맞춤형 소프트웨어는, 모두가 함께 쓰는 기성 도구를 졸업한 중소기업에게 정말로 할 수 있는 최고의 투자 중 하나입니다. 사업을 남의 제품에 맞춰 비틀게 하는 대신 당신이 일하는 방식에 정확히 맞춰 빚어진 시스템은 현실적이고 오래가는 강점입니다. 거기에 다다르는 기업은 가장 큰 예산을 가진 기업이 아닙니다. 위의 일곱 가지 실수를 피한 기업입니다—그리고 그것은 돈이 아니라 판단의 문제입니다.
맞춤형 소프트웨어를 고민하고 계신가요?
가장 값진 대화는 보통 무언가가 만들어지기 전에 이루어집니다—애초에 맞춤형 소프트웨어가 필요한지, 필요하다면 시작할 가치가 있는 가장 작은 버전이 무엇인지 함께 가려낼 때입니다. 압박도, 전문 용어도 없습니다.
우리가 맞춤형 소프트웨어를 만드는 방식 보기자주 묻는 질문
중소기업용 맞춤형 소프트웨어 비용은 얼마나 드나요?
맞춤형 소프트웨어가 기성 도구보다 더 나은가요?
소프트웨어 업체가 괜찮은지 어떻게 알 수 있나요?
맞춤형 소프트웨어 프로젝트에서 코드는 누구의 것이 되나요?
왜 그렇게 많은 맞춤형 소프트웨어 프로젝트가 실패하나요?

Have a nice day는 중소기업의 디지털 전환을 돕는 소프트웨어 스튜디오입니다. 슬라이드에서만이 아니라 일상 업무에서 실제로 작동하는 자동화, AI, 맞춤형 소프트웨어를 만듭니다.