좋은 개발사를 고르는 체크리스트

포트폴리오가 화려하다고 좋은 개발사는 아닙니다. 실제로 프로젝트가 끝난 뒤 후회하지 않으려면, 계약 전에 확인해야 할 것들이 있습니다. 저희가 실제로 권하는 확인 기준과, 계약 전 물어보면 좋은 질문들까지 정리했습니다.

1. 포트폴리오보다 "비슷한 프로젝트" 경험

포트폴리오는 결과물의 겉모습만 보여줄 뿐, 그 프로젝트에서 실제로 어떤 역할을 했는지는 알려주지 않습니다. 디자인 시안만 만들고 개발은 다른 팀이 했을 수도 있고, 개발은 했지만 오픈 이후 운영에는 관여하지 않았을 수도 있습니다.

• 보여주는 포트폴리오가 이번 프로젝트와 비슷한 규모·도메인인지
• 디자인만 참여했는지, 실제 개발·운영까지 했는지
• 완성 후 실제 서비스 중인 결과물이 있는지

가능하다면 포트폴리오에 있는 서비스를 실제로 접속해서 사용해보시는 것을 권장합니다. 지금도 운영 중인지, 업데이트가 꾸준히 이루어지고 있는지를 보면 그 개발사가 완성 이후까지 책임지는 곳인지 어느 정도 짐작할 수 있습니다.

2. 견적서의 투명성

총액만 있는 견적서보다, 항목별로(기획·디자인·개발·QA) 나뉘어 있는 견적서가 신뢰할 수 있습니다. 항목을 물어봤을 때 답변이 구체적인지도 확인 포인트입니다. 특히 "이 항목이 왜 이 금액인가요?"라는 질문에 명확히 답하지 못한다면, 산정 기준 자체가 모호할 가능성이 있습니다.

이 표처럼 항목을 나눠서 질문해보면, 견적서에 적히지 않은 부분이 나중에 "이건 추가 비용입니다"로 돌아올 가능성을 미리 줄일 수 있습니다.

3. 커뮤니케이션 방식과 담당자

프로젝트가 지연되거나 방향이 어긋나는 원인의 상당수는 기술이 아니라 소통 구조에 있습니다. 계약 전에 실제로 프로젝트 기간 동안 누구와 이야기하게 될지를 확인해두면, 진행 중 혼선을 크게 줄일 수 있습니다.

• 프로젝트 기간 동안 실제로 소통할 담당자가 누구인지
• 정기 보고나 중간 점검 일정이 있는지
• 영업 담당자와 실제 개발 담당자가 다른 경우, 개발 담당자와 직접 이야기할 수 있는지

4. 완성 이후도 확인하기

오픈만 시켜주고 끝나는 곳과, 이후 유지보수·운영까지 책임지는 곳은 완전히 다릅니다. 계약서에 유지보수 조건(기간, 대응 시간, 비용)이 명시되어 있는지 반드시 확인하세요. 특히 "오픈 후 몇 개월간 무상 하자보수"라는 문구가 있다면, 그 기간에 어떤 범위까지가 무상인지(버그 수정만인지, 사소한 기능 조정도 포함인지)를 구체적으로 확인하는 것이 좋습니다.

계약 전에 물어보면 좋은 질문들

• 이번 프로젝트를 실제로 담당할 인원은 몇 명이고, 각자 어떤 역할인가요?
• 개발 중간에 범위가 바뀌면 일정과 비용은 어떻게 재산정되나요?
• 프로젝트 종료 시 소스코드와 서버 접근 권한은 어떤 방식으로 이관되나요?
• 이 프로젝트와 비슷한 규모를 진행했을 때 평균적으로 얼마나 걸렸나요?

질문에 대한 답변이 즉각적이고 구체적일수록, 실제로 비슷한 프로젝트를 여러 번 경험한 곳일 가능성이 높습니다. 반대로 답변이 두루뭉술하거나 매번 다르게 돌아온다면 한 번 더 확인해보시는 것이 좋습니다.

이런 신호가 보이면 다시 생각해보세요

결정을 앞두고 비교가 필요하시다면, 저희 견적서와 진행 방식을 참고용으로 요청하셔도 좋습니다.