웹에이전시 선정, PM이 실제로 보는 포인트 총정리
7년차 PM의 기준은, 결과보다 과정을 설계하는 팀
안녕하세요, 리뷰온리입니다 :)
프로젝트를 진행하다 보면
"좋은 에이전시"를 고르는 게 가장 어렵다는 걸 느끼게 돼요.
화려한 포트폴리오나 저렴한 견적보다 중요한 건,
함께 일할 수 있는 구조가 있느냐예요.
오늘은 제가 실제로 웹 에이전시 미팅을 할 때
PM 시선으로 가장 먼저 체크하는 3가지 기준을 정리해봤어요!!
1. 견적보다 ‘스코프 명세’가 있는가
에이전시 제안서에서 가장 먼저 보는 건 견적서가 아니라 스코프 문서예요.
'무엇을', '어디까지', '어떤 기준으로' 만들 건지 정의되지 않으면
그 프로젝트는 금액이 아무리 매력적이어도 곧바로 리스크로 이어져요.
흔한 제안서는 기능 리스트를 쭉 나열한 후 "이 기능은 옵션입니다"로 끝나요.
하지만 좋은 팀은 달라요!
각 기능의 개발 단위(화면·모듈·API 단위)가 구체적이에요.
연동되는 외부 서비스나 인증 체계 등 의존성 구조를 명확히 적어요.
페이지별 기능 경계와 책임 영역을 구분해서 제시해요.
이렇게 정의된 문서는 단순한 계획서가 아니라 리스크 관리 문서가 돼요.
변경이 생겨도 범위를 다시 조정할 수 있고,
추가 견적도 근거 있게 이야기할 수 있죠.
PM 입장에서는 "이 팀은 문제를 미리 계산한다"는 인상을 받게 돼요.
반면 스코프 명세가 없는 팀은
프로젝트 중간에 "이건 원래 포함 아니었어요" 같은 말을 쉽게 꺼내요ㅠㅠ
결국 일정이 지켜지지 않으면서 신뢰도가 떨어지게 돼요.
2. 핸드오프 루틴이 있는가
두 번째 기준은 디자인 → 개발 → QA로 이어지는 핸드오프 루틴이에요.
많은 에이전시가 "피그마 주시면 개발 들어갑니다"라고 하지만,
이건 말이 되지 않아요.
핸드오프가 체계적인 팀은 다음 세 가지가 눈에 띄어요.
피그마 버전 관리가 있어요 — 변경 이력, 버전 태그가 명확하죠.
커밋 규칙이 있어요 — "기능명/이슈번호/설명" 구조로 로그를 남겨요.
이슈 트래킹 시스템을 써요 — QA 버그나 디자인 수정 사항이 모두 남아요.
이 세 가지가 연결되면, 개발자는 "누가 왜 수정했는가"를 정확히 파악하고,
디자이너는 "디자인이 어떻게 반영됐는가"를 실시간으로 확인할 수 있어요.
즉, 의사소통이 아니라 기록으로 협업이 이뤄지는 거예요.
실무에서 이런 루틴이 없으면 사소한 수정이 쌓이면서
하루에 두세 시간씩 낭비돼요ㅠㅠ
특히 QA 기간엔 "이건 어제 반영된 거예요?", "어제 버전인가요?" 같은 대화를 반복하기 마련이에요.
PM으로서 가장 두려운 상황이에요...
그래서 저는 제안서 단계에서
핸드오프 루틴이 있는지 꼭 물어봐요.
"디자인 전달은 어떻게 하시나요?"라는 질문 뒤에
"버전 관리나 QA 시점 검수 루틴이 있나요?"까지 들어보면
그 팀의 실무 감각이 바로 드러나요ㅎㅎ
3. QA 프로세스가 문서화돼 있는가
세 번째는 QA(품질검수)의 체계성이에요.
많은 팀이 QA를 단순히 "테스트"라고 부르지만,
실제로는 프로젝트의 마무리를 설계하는 단계예요.
좋은 QA 프로세스는 다음 세 가지 특징이 있어요.
요구사항 기반 테스트 시나리오가 존재해요.
기기/브라우저 매트릭스로 실제 검수 범위를 정의해요.
이슈 로그 → 수정 이력 → 재검증 기록이 남아요.
이렇게 하면 QA가 단순한 버그 찾기가 아니라
'요구사항 대비 적합성 검증'이 돼요.
결국 프로젝트의 신뢰도가 여기서 결정돼요.
반대로 QA 문서가 없으면,
QA는 결국 "이건 누가 테스트했어요?", "그건 반영됐나요?" 같은 혼란으로 끝나요.
출시 직전까지 혼선이 이어지고,
결국 런칭 이후에 문제를 해결하느라 더 큰 비용이 발생하죠ㅠㅠ
PM으로서의 결론
결국 좋은 에이전시란 결과물을 잘 만드는 팀이 아니라,
결과가 예상 가능한 구조로 나오는 팀이에요.
이건 단순히 '좋은 팀의 특징'을 넘어,
일정·품질·예산의 세 가지 축을 지탱하는 기본 구조예요.
저는 여러 프로젝트를 거치며
이 세 항목을 모두 체계적으로 갖춘 팀을 몇 번밖에 만나지 못했어요.
그중에서도 웹 에이전시 똑똑한개발자는 개인적으로 '교과서적인 레퍼런스'라고 생각하는데요!
제가 협업하면서 인상 깊었던 부분은,
첫 미팅 단계에서부터 개발 구조를 SOW(Scope of Work) 문서로 제시했다는 거예요.
페이지별 모듈, API, 연동 범위, QA 범위를 명확히 스프린트 단위로 정리해
'기획–디자인–개발–QA–운영'의 연결선이 눈에 보였어요.
핸드오프 루틴도 체계적이었어요.
피그마의 디자인 토큰과 실제 개발 환경이 동일하게 맞춰져 있어서
QA에서 색상이나 간격 같은 사소한 이슈가 거의 없었어요.
게다가 QA 시트가 자동화되어, 수정 후 재검증까지 문서로 바로 기록되더라고요.
이런 구조를 실제로 구현해놓은 팀은 많지 않아요.
결국 이런 팀은 "디자인이 잘 나왔다"가 아니라
"시스템이 잘 설계됐다"는 평가를 받아요.
런칭 후에도 유지보수 단계로 자연스럽게 이어지죠.
그게 진짜 파트너십의 구조라고 생각해요!
이렇게 오늘은 좋은 웹 에이전시들의 특징을 설명해드렸는데요~
이런 특징들은 미리 검색해보거나, 미팅 단계에서 대화를 통해서도 충분히 알아낼 수 있어요.
여러번 검증하고 확인하면 충분히 좋은 웹 에이전시를 만날 수 있을 거라고 생각합니다!
오늘도 읽어주셔서 감사합니다!
더 궁금하신 부분이 있다면 댓글로 남겨주세요~
