외주 개발, 미팅은 몇 번이 적당한가

"미팅을 자주 해야 하나요, 아니면 맡기고 기다리는 게 낫나요?"

외주 개발에서 미팅 빈도는 의외로 프로젝트 성패에 큰 영향을 줍니다. 너무 많아도 문제, 너무 적어도 문제입니다. 적정선이 어디인지 정리합니다.

미팅이 너무 많으면

개발 시간이 줄어든다

매일 30분씩 미팅을 하면, 일주일에 2.5시간이 미팅에 소비됩니다. 미팅 전후 준비와 정리 시간까지 포함하면 실질적으로 하루에 1시간 이상을 빼앗깁니다. 개발자가 집중해서 코드를 작성할 수 있는 시간이 그만큼 줄어듭니다.

보여줄 것이 없는 미팅

매일 미팅을 하면 "어제와 달라진 것"을 보여줘야 하는데, 개발은 하루 만에 눈에 보이는 변화가 생기지 않는 경우가 많습니다. 결국 "진행 중입니다"만 반복하는 미팅이 됩니다. 양쪽 모두 시간 낭비입니다.

미팅이 너무 적으면

방향이 틀어진다

한 달에 한 번만 미팅하면, 그 한 달 동안 개발사는 자기 해석대로 만듭니다. 한 달 후에 결과물을 보고 "이게 아닌데"라고 하면, 한 달치 작업을 되돌려야 합니다. 비용과 시간 모두 낭비됩니다.

문제를 늦게 발견한다

기술적 이슈, 요구사항의 모호함, 디자인과 실제 구현의 차이 — 이런 문제는 빨리 발견할수록 해결 비용이 적습니다. 한 달에 한 번 미팅으로는 문제가 커진 후에야 발견합니다.

적정 빈도: 격주 1회

대부분의 외주 개발 프로젝트에서 격주 1회 정기 미팅이 적절합니다.

왜 격주인가

  • 2주면 눈에 보이는 결과물이 나옵니다
  • 방향이 틀어져도 2주치만 수정하면 됩니다
  • 개발자가 집중할 수 있는 충분한 시간이 확보됩니다
  • 클라이언트도 피드백을 준비할 시간이 있습니다

미팅에서 확인할 것

  • 동작하는 결과물: 스크린샷이 아니라 직접 클릭해보는 것
  • 이번 스프린트에서 완료한 것: 계획 대비 진행률
  • 다음 스프린트 계획: 향후 2주간 무엇을 만들 것인지
  • 이슈 공유: 막히는 것, 확인이 필요한 것

문서나 구두 보고가 아니라, 실제로 동작하는 것을 보면서 이야기하는 것이 핵심입니다.

Product Maker의 화이트박스 방식

프로덕트 메이커는 격주 스프린트 리뷰를 기본으로 진행합니다. 2주마다 동작하는 결과물을 공유하고, 해당 범위 내에서 피드백은 무제한입니다.

미팅 외에 긴급한 사항은 슬랙이나 메신저로 바로 소통합니다. 하지만 정기 미팅의 리듬이 있기 때문에, 급한 것과 급하지 않은 것이 자연스럽게 구분됩니다. "다음 미팅 때 이야기하면 될 것"과 "지금 바로 확인해야 할 것"을 나누는 기준이 생기는 것입니다.

다만 "피드백 무제한"이 "범위 변경 무제한"은 아닙니다. 자전거를 만들기로 한 프로젝트에서 피드백을 반영하다 보니 자동차가 되어가는 건, 피드백이 아니라 새로운 프로젝트입니다. 스프린트 범위 안에서의 수정과 방향 조정은 얼마든지, 하지만 목적지 자체를 바꾸는 건 별도 협의가 필요합니다.

미팅은 많이 하는 것이 아니라, 제대로 하는 것이 중요합니다.


*외주 개발 프로젝트 진행 방식에 대해 궁금하시다면, 프로젝트 상담을 통해 문의해 주세요.*


미팅,커뮤니케이션,프로젝트관리,외주개발
다른 포스팅

외주 개발, 미팅은 몇 번이 적당한가

"미팅을 자주 해야 하나요, 아니면 맡기고 기다리는 게 낫나요?"

외주 개발에서 미팅 빈도는 의외로 프로젝트 성패에 큰 영향을 줍니다. 너무 많아도 문제, 너무 적어도 문제입니다. 적정선이 어디인지 정리합니다.

미팅이 너무 많으면

개발 시간이 줄어든다

매일 30분씩 미팅을 하면, 일주일에 2.5시간이 미팅에 소비됩니다. 미팅 전후 준비와 정리 시간까지 포함하면 실질적으로 하루에 1시간 이상을 빼앗깁니다. 개발자가 집중해서 코드를 작성할 수 있는 시간이 그만큼 줄어듭니다.

보여줄 것이 없는 미팅

매일 미팅을 하면 "어제와 달라진 것"을 보여줘야 하는데, 개발은 하루 만에 눈에 보이는 변화가 생기지 않는 경우가 많습니다. 결국 "진행 중입니다"만 반복하는 미팅이 됩니다. 양쪽 모두 시간 낭비입니다.

미팅이 너무 적으면

방향이 틀어진다

한 달에 한 번만 미팅하면, 그 한 달 동안 개발사는 자기 해석대로 만듭니다. 한 달 후에 결과물을 보고 "이게 아닌데"라고 하면, 한 달치 작업을 되돌려야 합니다. 비용과 시간 모두 낭비됩니다.

문제를 늦게 발견한다

기술적 이슈, 요구사항의 모호함, 디자인과 실제 구현의 차이 — 이런 문제는 빨리 발견할수록 해결 비용이 적습니다. 한 달에 한 번 미팅으로는 문제가 커진 후에야 발견합니다.

적정 빈도: 격주 1회

대부분의 외주 개발 프로젝트에서 격주 1회 정기 미팅이 적절합니다.

왜 격주인가

  • 2주면 눈에 보이는 결과물이 나옵니다
  • 방향이 틀어져도 2주치만 수정하면 됩니다
  • 개발자가 집중할 수 있는 충분한 시간이 확보됩니다
  • 클라이언트도 피드백을 준비할 시간이 있습니다

미팅에서 확인할 것

  • 동작하는 결과물: 스크린샷이 아니라 직접 클릭해보는 것
  • 이번 스프린트에서 완료한 것: 계획 대비 진행률
  • 다음 스프린트 계획: 향후 2주간 무엇을 만들 것인지
  • 이슈 공유: 막히는 것, 확인이 필요한 것

문서나 구두 보고가 아니라, 실제로 동작하는 것을 보면서 이야기하는 것이 핵심입니다.

Product Maker의 화이트박스 방식

프로덕트 메이커는 격주 스프린트 리뷰를 기본으로 진행합니다. 2주마다 동작하는 결과물을 공유하고, 해당 범위 내에서 피드백은 무제한입니다.

미팅 외에 긴급한 사항은 슬랙이나 메신저로 바로 소통합니다. 하지만 정기 미팅의 리듬이 있기 때문에, 급한 것과 급하지 않은 것이 자연스럽게 구분됩니다. "다음 미팅 때 이야기하면 될 것"과 "지금 바로 확인해야 할 것"을 나누는 기준이 생기는 것입니다.

다만 "피드백 무제한"이 "범위 변경 무제한"은 아닙니다. 자전거를 만들기로 한 프로젝트에서 피드백을 반영하다 보니 자동차가 되어가는 건, 피드백이 아니라 새로운 프로젝트입니다. 스프린트 범위 안에서의 수정과 방향 조정은 얼마든지, 하지만 목적지 자체를 바꾸는 건 별도 협의가 필요합니다.

미팅은 많이 하는 것이 아니라, 제대로 하는 것이 중요합니다.


*외주 개발 프로젝트 진행 방식에 대해 궁금하시다면, 프로젝트 상담을 통해 문의해 주세요.*


미팅,커뮤니케이션,프로젝트관리,외주개발
다른 포스팅