개발 진행 상황을 어떻게 모니터링하나요?
외주로 개발을 맡기면 "개발이 제대로 진행되고 있는지 어떻게 알 수 있을까?"가 가장 큰 고민입니다. 특히 비개발자 창업자는 코드를 볼 수 없으니 더욱 막막합니다. 하지만 코드를 모르더라도 개발 진행 상황을 충분히 관리할 수 있습니다.
코드가 아닌 사용자 경험으로 관리하세요
개발자가 작업하고 있는지 여부를 코드 레벨에서 확인하는 것은 비개발자에게 어렵습니다. 코드를 본다 해도 그것이 잘 작성된 것인지, 얼마나 진행된 것인지 판단하기 어렵습니다.
스타트업이나 비개발자 발주자는 사용자 경험(User Experience)으로 관리할 수 있습니다. 사용자가 서비스를 어떻게 사용하는지, 버튼을 누르면 어떻게 작동하는지, 데이터가 제대로 표시되는지를 직접 경험하면서 확인하는 것입니다.
이것은 오히려 개발자보다 더 중요한 관점일 수 있습니다. 코드가 아무리 잘 짜여 있어도, 실제 사용자가 불편하다면 의미가 없습니다. 발주자는 사용자의 입장에서 서비스를 평가할 수 있는 최적의 위치에 있습니다.
서비스 오픈 기준으로 일정을 관리하세요
서비스는 사용자가 정상적으로 사용할 수 있는 수준이 되어야 오픈할 수 있습니다. 이 기준에 맞춰 일정을 관리하면 됩니다.
"데이터베이스 설계 완료", "API 80% 완성" 같은 개발 용어보다는, "회원가입 화면 완성", "로그인 후 프로필 조회 가능" 같은 사용자 관점의 마일스톤으로 일정을 잡으세요.
화면 단위로 일정을 관리하면, 매주 "이번 주에 약속한 화면이 작동하나?"를 직접 확인할 수 있습니다.
화면 단위로 확인하세요
확인 일정에 맞춰 어떤 화면까지 사용할 수 있는지를 점검하세요. "로그인 화면이 완성됐습니다"라는 말을 듣는 것이 아니라, 실제로 테스트 환경에 접속해서 직접 로그인을 해보는 것입니다.
회원가입 화면이 완성됐다면:
- 실제로 계정을 만들어보세요
- 이메일 인증이 작동하나요?
- 필수 항목을 빼고 가입하면 오류 메시지가 나오나요?
- 이미 가입된 이메일로 시도하면 막히나요?
이렇게 사용자가 할 수 있는 모든 행동을 직접 해보면서 확인하세요. 작업을 했는지 보여주지 않는 경우는 없으며, 제대로 작동되지 않는 것을 작업했다고 할 수 없습니다.
사용자 입장에서 직접 사용해보세요
사용자 화면은 사용자의 입장에서 사용해보면서 확인하세요. 개발자가 "여기 클릭하시면 이렇게 됩니다"라고 설명하는 것을 듣는 것이 아니라, 혼자서 직접 써보는 것입니다.
처음 사용하는 사람처럼 행동해보세요:
- 메뉴 이름만 보고 어디로 가야 할지 알겠나요?
- 버튼을 누르면 즉각 반응하나요?
- 로딩이 너무 오래 걸리지는 않나요?
- 오류가 생기면 무슨 문제인지 알 수 있나요?
개발자는 내부 구조를 알기 때문에 자연스럽게 사용할 수 있지만, 실제 사용자는 그렇지 않습니다. 발주자가 직접 써보면서 불편한 점을 찾아내는 것이 중요합니다.
관리자 화면은 양쪽을 동시에 확인하세요
서비스에 관리자 기능이 있다면, 사용자와 관리자 화면을 띄워놓고 양쪽을 함께 확인하세요.
예를 들어:
- 사용자가 문의를 남기면 → 관리자 화면에 즉시 표시되나요?
- 관리자가 공지사항을 등록하면 → 사용자 화면에 바로 보이나요?
- 관리자가 사용자를 정지시키면 → 해당 사용자가 로그인할 수 없나요?
두 개의 브라우저 창이나 탭을 열어서, 한쪽에서 변경하고 다른 쪽에서 새로고침해보세요. 사용자의 변화가 관리자에 적용되는지, 관리자의 처리가 사용자에 반영되는지 확인하는 것입니다.
이렇게 하면 개발 작업 여부를 확인할 수 있습니다.
백엔드 작업은 데이터로 확인하세요
백엔드(서버, 데이터베이스) 작업은 눈에 보이지 않아서 확인하기 어렵습니다. 하지만 백엔드 작업의 결과는 사용자와 관리자 화면에 드러나는 데이터로 알 수 있습니다.
예를 들어:
- 회원가입을 하면 → 관리자 화면의 회원 목록에 추가되어야 합니다
- 상품을 장바구니에 담으면 → 다시 접속해도 장바구니에 남아있어야 합니다
- 검색어를 입력하면 → 관련 상품이 정확하게 필터링되어야 합니다
"데이터베이스 작업 완료"라는 말보다, 실제로 데이터가 저장되고 불러와지고 수정되고 삭제되는지 직접 테스트해보세요. 회원 가입을 하고, 상품을 등록하고, 주문을 해보면서 데이터가 제대로 처리되는지 확인하세요.
절대 시연을 구경하는 것으로 작업 여부를 판단해서는 안됩니다.
개발 품질은 외주사 실력만큼 나옵니다
개발 품질에 대해서는 외주사의 실력만큼 나옵니다.
코드의 내부 품질(깔끔한 구조, 효율적인 알고리즘, 확장 가능한 설계)은 개발자의 역량에 달려 있습니다. 발주자가 "코드를 더 잘 짜주세요"라고 해도, 그 개발자의 수준 이상으로는 만들어지지 않습니다.
외주사는 보유 인력이 가장 안전하고 잘 만들 수 있는 방식으로 서비스를 만듭니다. 그들의 평소 실력이 결과물의 천장입니다.
"더 잘 만들어주세요"라고 압박하면, 익숙하지 않은 방식을 시도하다가 오류가 생기거나, 일정에 쫓기면서 평소 실력보다 못한 결과물이 나올 수 있습니다.
작업자는 갑자기 더 잘하게 되지 않습니다
프로젝트 중간에 작업자가 갑자기 더 실력이 좋아지는 경우는 없습니다. 시니어 개발자가 투입됐다면 처음부터 좋은 품질이 나왔을 것이고, 주니어 개발자가 투입됐다면 끝까지 그 수준일 가능성이 높습니다.
그래서 계약 전에 인력의 이력으로 실력을 가늠하는 것이 중요합니다. "이 프로젝트에 누가 투입되나요?", "그분의 경력은 어떻게 되나요?", "비슷한 프로젝트 경험이 있나요?" 같은 질문을 해야 합니다.
가능하다면 이력서나 포트폴리오를 요청하세요. 대표나 영업 담당자가 아니라, 실제로 코드를 작성할 개발자의 이력을 확인해야 합니다.
실제 작업자를 미팅에 참석시키세요
계약 후에도 프로젝트를 주도하는 인력이 미팅에 참가하게 해서 지속적으로 확인하세요. 매번 다른 사람이 미팅에 나온다면, 실제 작업자와 소통이 단절될 수 있습니다.
미팅에서 "이 기능은 어떻게 구현하셨나요?", "이 부분은 왜 이렇게 만드셨나요?" 같은 질문을 하면, 실제로 작업한 사람만 정확하게 답변할 수 있습니다.
만약 담당자가 계속 바뀐다면, 프로젝트 관리가 제대로 안 되고 있다는 신호일 수 있습니다. "이번 주는 김 개발자가, 다음 주는 이 개발자가" 이렇게 되면 일관성이 떨어지고 품질도 낮아집니다.
정기적인 데모로 진행 상황을 확인하세요
3주에 한 번은 실제 작동하는 버전을 보여달라고 하세요. "작업 중입니다"라는 말만 듣지 말고, 실제로 링크를 받아서 접속해보고 기능을 테스트해보세요.
데모 시점에는:
- 약속한 기능이 작동하나요?
- 이전 주에 지적했던 오류가 수정됐나요?
- 새로운 기능이 추가되면서 기존 기능이 깨지지는 않았나요?
이런 것들을 체크리스트로 만들어서 매번 확인하세요. 시간이 지날수록 체크리스트가 길어지지만, 그만큼 서비스가 완성되어 가는 것입니다.
품질은 계약 전 선택의 결과입니다
결국 개발 품질은 어떤 외주사를 선택했느냐에서 결정됩니다. 좋은 외주사를 선택했다면 좋은 결과물이 나오고, 그렇지 않다면 아무리 모니터링해도 한계가 있습니다.
프로젝트가 진행 중일 때 할 수 있는 것은 방향을 잡아주고, 오류를 빨리 발견하고, 요구사항을 명확히 전달하는 것입니다. 하지만 개발자의 근본적인 실력을 끌어올릴 수는 없습니다.
그래서 계약 전 업체 선정 단계에서 신중하게 평가하고, 실제 작업자의 역량을 확인하는 것이 가장 중요합니다.