화려한 PPT와 유창한 언변에 속아 수천만 원을 날리는 IT 외주 실패 사례는 생각보다 훨씬 흔합니다. 전 세계 IT 프로젝트의 약 70%가 예산 초과·일정 지연·기대 이하 결과물로 끝난다는 조사 결과가 이를 방증합니다. 경쟁 PT의 질의응답 세션은 단순한 형식이 아니라, 대행사의 '진짜 기술력'을 검증할 수 있는 유일한 실전 무대입니다. 이 글에서는 발주 담당자라면 반드시 던져야 할 테크니컬 QA 질문 5가지와, 계약 전후로 적용할 수 있는 단계별 실행법을 구체적으로 안내합니다.
대행사 경쟁 PT(프레젠테이션)는 본질적으로 '영업 행위'입니다. 제안서에 담긴 포트폴리오와 인력 소개는 가장 좋은 조건을 보여주도록 설계되어 있습니다.
실제 구축 단계에 들어가면 상황이 달라지는 경우가 많습니다. 제안서에 올라온 시니어 개발자 대신 경력이 짧은 개발자나 프리랜서 하청이 투입되는 '미끼 인력(Bait-and-Switch)' 문제가 대표적입니다.
테크니컬 QA(Technical Quality Assurance)란? 제안서에 적힌 내용이 실제 기술 역량과 일치하는지를 검증하기 위해 던지는 구체적이고 날카로운 기술 검증 질문을 말합니다.
국내 소프트웨어 용역 시장은 연간 20조 원 규모에 달하며, 이 중 상당수 프로젝트가 재작업과 분쟁으로 이어집니다. 발주처가 기술 질문을 제대로 하지 않았기 때문입니다.
이 질문은 미끼 인력 문제를 정면으로 차단합니다. 제안서에 등장하는 고연차 아키텍트가 실제로 몇 퍼센트 참여하는지, 예상치 못한 퇴사나 교체 발생 시 코드 인수인계(Knowledge Transfer) 절차가 체계적으로 갖춰져 있는지를 확인하는 것이 핵심입니다.
좋은 답변의 예시: "핵심 아키텍트는 설계 단계 100%, 개발 단계 60% 이상 직접 참여하며, 교체 시 2주간 페어 코딩 및 위키 문서 인계 프로세스가 표준화되어 있습니다."
경계해야 할 답변: "저희 팀 전체가 함께합니다"처럼 구체적인 수치가 없는 모호한 답변은 위험 신호입니다.
포트폴리오의 외형이 아니라 유사 도메인 구현 경험의 깊이를 검증하는 질문입니다. 모든 분야를 다 잘하는 대행사는 존재하지 않습니다.
예를 들어 외부 결제 API 연동, 대용량 트랜잭션 처리, 실시간 데이터 동기화 등 여러분 프로젝트의 핵심 기능과 유사한 경험이 있는지 구체적인 트러블슈팅 과정으로 확인해야 합니다.
실제로 A사와 개발사 간 계약에서 '실시간 위치 공유 기능'이라는 모호한 표현이 소송으로 비화한 사례가 있습니다. 개발사는 5분 간격 갱신으로 설계했고, 발주처는 초 단위 공유를 기대했기 때문입니다. 사전에 기술 QA 질문으로 짚었다면 충분히 예방 가능한 비극이었습니다.
이 질문은 비기능적 요구사항(Non-functional Requirements), 즉 겉으로 보이지 않는 시스템의 체력을 검증합니다. 서비스가 성장할 때 서버가 버텨줄 수 있는지, 개인정보 유출 방지를 위한 암호화 설계가 제대로 되어 있는지가 핵심입니다.
최근에는 구글의 서드파티 쿠키 제한 등 프라이버시 정책 변화에 따라, 1st-party 데이터와 CRM을 안정적으로 연동하는 프라이버시 중심 아키텍처 설계 능력이 핵심 경쟁력으로 급부상하고 있습니다.
체크 포인트:
AES-256 등)Auto Scaling) 지원 여부프로젝트가 끝난 뒤에도 해당 대행사에만 의존해야 하는 상황, 즉 벤더 종속(Vendor Lock-in)은 장기적으로 가장 비싼 비용을 치르게 만드는 함정입니다.
B사는 저가 대행사를 선택했다가 이미 시장에서 도태된 노후 언어로 시스템이 구축되어, 유지보수 개발자를 구하지 못해 전면 폐기 후 React/Node.js 스택으로 재구축하며 수천만 원의 이중 비용을 감당해야 했습니다.
반드시 확인할 것:
React, Next.js, Node.js 등 대중적 오픈 표준 기술 스택 사용 여부Git 리포지토리 권한 이양 포함 여부제품의 최종 완성도와 사후 생존 전략을 한 번에 확인하는 질문입니다. Selenium이나 Appium 같은 테스트 자동화 도구를 Jenkins 같은 CI/CD 파이프라인에 연동하여 버그를 사전에 차단하는 것이 현재 업계 표준입니다.
수동 테스트만 진행하는 대행사는 일정 지연과 버그 잔존 리스크가 구조적으로 높을 수밖에 없습니다.
SLA(서비스 수준 계약)란 장애 발생 시 몇 시간 안에 대응하겠다는 약속을 문서화한 것입니다. 무상 유지보수 기간(통상 1~3개월)과 장애 대응 수준이 계약서에 명문화되어 있는지 반드시 확인하세요.
"쿠팡처럼 빠른 배송 추적 기능"처럼 모호한 표현은 절대 금물입니다. A4 2~3장 분량으로 다음을 명시한 문서를 대행사에 사전 제공하세요.
요구사항이 구체적일수록 대행사의 기술 제안서 퀄리티도 급격히 상승합니다.
발표 현장에 영업 대표만 오는 것을 허용하지 마세요. 실제 프로젝트를 리드할 PM 또는 테크 리더가 반드시 배석하도록 사전에 못 박아야 합니다.
질의응답 세션에서 위 5가지 질문을 던질 때, "영업 담당자가 아닌 실제 개발 책임자가 직접 답변해 달라"고 요구하세요. 기술 답변의 일관성과 깊이가 대행사의 실력을 그대로 드러냅니다.
계약금·중도금·잔금 지급 시점을 날짜가 아닌 '마일스톤 완료 시점' 기준으로 설정하세요.
중간 산출물 검수 없이 끝까지 가다가 막판에 개발이 엎어지는 최악의 상황을 원천 차단할 수 있습니다.
Q. 테크니컬 QA 질문을 하면 대행사 관계가 불편해지지 않을까요? A. 오히려 반대입니다. 기술력이 탄탄한 대행사일수록 구체적인 질문을 환영합니다. 명확한 답변을 회피하거나 모호하게 넘어가려는 대행사가 있다면, 그 자체가 중요한 위험 신호입니다.
Q. 기술을 잘 모르는 담당자도 이 질문들을 활용할 수 있나요? A. 네, 가능합니다. 질문 자체를 그대로 읽어도 됩니다. 중요한 것은 답변을 들을 때 수치와 구체적 사례가 포함되어 있는지를 확인하는 것입니다. 모호하고 추상적인 답변은 기술력 부족의 신호일 수 있습니다.
Q. 저가 대행사는 무조건 피해야 하나요? A. 가격보다 '공수(M/M) 대비 투입 인력의 실질 경력'을 함께 비교해야 합니다. 터무니없이 저렴한 견적은 투입 인력의 연차를 극도로 낮추거나 다단계 하청을 의미할 가능성이 높습니다. 가장 저렴한 견적이 결국 가장 비싼 청구서가 되는 경우가 많습니다.
Q. AI 기반 프로젝트 외주 시 추가로 확인해야 할 것이 있나요?
A. AI·LLM 프로젝트는 일반 개발과 달리 데이터 변화에 따른 결과물 보정이 필수입니다. 대행사가 '학습-검증-수정'의 피드백 루프와 지속적 운영 파이프라인(MLOps) 역량을 갖추고 있는지 별도로 확인하세요.
Q. 무상 유지보수 기간은 얼마가 적정한가요? A. 업계 통상 기준은 1~3개월입니다. 이 기간 내에 발생하는 버그 수정과 추가 개발 요청의 경계를 계약서에 명확히 정의해야 합니다. '단순 디자인 수정'이 버그인지 추가 개발인지를 사전에 합의해 두는 것이 분쟁 예방의 핵심입니다.
경쟁 PT는 대행사를 궁지로 몰아넣는 자리가 아닙니다. 우리 프로젝트를 안전하게 완수할 파트너인지를 확인하는 체크포인트입니다.
오늘 소개한 테크니컬 QA 질문 5가지를 정리하면 다음과 같습니다.
그리고 계약 전 3단계(요구사항 정의서 제공 → 테크 리더 배석 요구 → 마일스톤 연계 대금 지급)를 실행하면 실패 확률을 구조적으로 낮출 수 있습니다.
디지털 마케팅 대행사 선정이나 IT 외주 프로젝트 발주를 앞두고 있다면, 에이달(ADALL)에 프로젝트 문의를 남겨주세요. 제안서 검토부터 기술 검증 기준 설정까지, 발주처 입장에서 함께 고민해 드립니다.
📞 02-2664-8631 | 📧 master@adall.co.kr
무료 컨설팅 받아보고 싶다면?
무료 컨설팅 신청하기