Blog·인사이트

프로덕트 메이커는 프로젝트를 어떻게 관리하나

··5분 읽기
요약

외주 개발을 맡기면서 가장 불안한 건 "지금 어디까지 진행됐는지 모르겠다"입니다. 돈은 지불했는데, 중간 과정이 보이지 않고, 완성될 때까지 기다려야 하는 구조.

외주 개발을 맡기면서 가장 불안한 건 "지금 어디까지 진행됐는지 모르겠다"입니다. 돈은 지불했는데, 중간 과정이 보이지 않고, 완성될 때까지 기다려야 하는 구조. 웹이든 앱이든 소프트웨어든, 이 불안은 동일합니다. 프로덕트 메이커는 이 불안을 구조적으로 없앱니다.

일정 관리: 격주 스프린트

프로젝트를 2주 단위 스프린트로 나눕니다. 3개월짜리 프로젝트라면 6개의 스프린트. 웹 서비스, 모바일 앱, 디바이스 연동 소프트웨어 — 프로젝트 종류와 관계없이 동일한 리듬으로 진행합니다.

초기 스프린트 (기획·디자인)

프로젝트 첫 1~2 스프린트는 기획과 디자인에 집중합니다.

  • 요구사항 정리, 화면 설계, UI/UX 디자인 진행
  • 클라이언트 피드백을 받아 디자인 확정
  • 이 기간 동안 인프라 구성, 인증 체계, DB 설계 등 필수 개발을 병렬로 진행합니다

디자인이 확정되지 않은 상태에서 화면 개발에 들어가면 "이게 아닌데"가 반복됩니다. 기획·디자인을 먼저 잡고, 합의된 설계 위에서 개발하는 것이 결과적으로 더 빠릅니다.

개발 스프린트

디자인이 확정된 이후의 스프린트는 개발에 집중합니다.

  • 시작: 이번 2주간 개발할 기능 범위를 확정
  • 진행: 확정된 디자인 기반으로 기능 개발
  • 완료: 동작하는 결과물을 클라이언트에게 공유
  • 피드백: 클라이언트가 직접 클릭하고 만져보면서 피드백. 실제로 사용해본 뒤 다음 스프린트 방향을 함께 조정합니다

2주마다 동작하는 결과물이 나오기 때문에, "3개월 뒤에 완성품을 보고 깜짝 놀라는" 상황이 발생하지 않습니다. 방향이 틀어져도 2주치만 수정하면 됩니다.

결과물의 형태는 프로젝트에 따라 다릅니다. 웹 서비스라면 테스트 가능한 URL, 앱이라면 TestFlight(iOS)이나 내부 배포 빌드(Android), 디바이스 연동 소프트웨어라면 실제 기기에서 동작하는 빌드를 공유합니다.

고객사와 업무 공유

소통 채널

  • 정기 미팅: 격주 1회, 스프린트 리뷰 겸 다음 스프린트 계획
  • 실시간 소통: 슬랙 또는 카카오톡. 급한 이슈는 바로 공유
  • 대표가 직접 소통: 중간 전달자가 없습니다. 기획 의도가 왜곡되지 않고, 기술적 판단이 즉시 이루어집니다

공유하는 것들

  • 동작하는 결과물: 매 스프린트마다 실제로 사용해볼 수 있는 빌드를 공유합니다. 웹은 URL, 앱은 테스트 빌드, 소프트웨어는 실행 파일 형태로 전달합니다
  • 진행 상황: 무엇이 완료됐고, 무엇이 진행 중이고, 무엇이 남았는지
  • 이슈: 기술적 제약, 일정 리스크, 변경이 필요한 부분 — 문제가 생기면 먼저 이야기합니다. 클라이언트가 물어보기 전에

"알아서 잘 하고 있겠지"가 아니라, "지금 이 상태입니다"를 계속 보여드리는 구조입니다.

개발 관리

코드 관리

  • Git 기반 버전 관리: 모든 코드 변경 이력이 기록됩니다. 누가, 언제, 무엇을 바꿨는지 추적 가능
  • 브랜치 전략: 기능별로 브랜치를 나눠서 개발하고, 검증 후 병합. 하나의 기능 개발이 다른 기능에 영향을 주지 않도록
  • 코드 리뷰: PR(Pull Request) 기반 코드 리뷰를 진행하며, AI 도구를 보조적으로 활용해 코드 품질을 관리합니다

배포 관리

  • 스테이징 환경: 실서비스에 반영하기 전에 테스트용 환경에서 먼저 확인. 앱의 경우 내부 테스트 트랙(TestFlight, Firebase App Distribution)을 활용
  • 자동화된 배포: 웹은 Docker 기반, 앱은 CI 기반으로 빌드와 배포를 자동화하여 사람의 실수를 줄임
  • 롤백 가능: 배포 후 문제가 발견되면 이전 버전으로 즉시 복구

품질 관리

  • 지속적 리팩토링: 개발 도중에 코드를 꾸준히 정리합니다. 기술 부채가 쌓이지 않도록 스프린트마다 정리 시간을 확보합니다
  • 크로스 플랫폼 테스트: 웹은 PC/모바일/다양한 브라우저, 앱은 iOS/Android 주요 기종, 소프트웨어는 타겟 OS와 디바이스에서 동작 확인
  • 에러 모니터링: 런칭 후에도 에러가 발생하면 즉시 감지. 웹은 서버 모니터링, 앱은 크래시 리포팅 도구를 활용

프로젝트 유형별 차이

관리 프레임워크는 동일하지만, 프로젝트 유형에 따라 세부 프로세스가 달라집니다.

  • 웹 서비스: 스프린트마다 테스트 URL 공유, 브라우저 호환성 테스트, SEO와 성능 최적화 포함
  • 모바일 앱(iOS/Android): 테스트 빌드 배포, 기기별 호환성 테스트, 스토어 심사 일정을 스프린트에 반영
  • 디바이스 연동 소프트웨어: 실제 하드웨어와의 통신 테스트가 스프린트에 포함. BLE, USB, Wi-Fi 등 연결 방식에 따라 테스트 환경 구성
  • WebGL/3D: 다양한 기기(TV, 모바일, PC)에서의 렌더링 성능 테스트. 모델 최적화 과정이 스프린트에 포함

HUENIT 로봇 제어 소프트웨어(3년 장기 운영), LG ThinQ WebGL(MAU 150만 실서비스), 메이트 모빌리티 실시간 화상통화 시스템 — 이 모든 프로젝트가 동일한 스프린트 구조로 진행됐습니다.

왜 이렇게 하나

많은 개발사가 "내부적으로 잘 관리하고 있습니다"라고 합니다. 하지만 클라이언트에게 보이지 않는 관리는 없는 것과 같습니다.

저희가 이 모든 과정을 투명하게 공유하는 이유는 단순합니다. 숨길 것이 없기 때문입니다. 코드를 보여드리고, 진행 상황을 공유하고, 문제를 먼저 이야기하는 것. 이게 화이트박스 개발의 본질입니다.

화이트박스 개발이란, 일반적인 블랙박스 외주(돈을 내고 완성될 때까지 기다리는 구조)와 반대되는 방식입니다. Git 저장소를 클라이언트와 공유하고, 매 스프린트마다 동작하는 결과물을 직접 확인할 수 있으며, 코드와 진행 상황이 항상 열려 있습니다. 완성 후 소스코드를 받는 게 아니라, 개발 과정 자체가 투명하게 공개되는 구조입니다.

그리고 이 구조의 진짜 장점은 클라이언트의 안심이 아닙니다. 더 좋은 결과물이 나온다는 것입니다. 2주마다 방향을 확인하니까 틀어질 틈이 없고, 피드백이 바로 반영되니까 "이게 아닌데"가 쌓이지 않습니다.

*프로젝트 관리 방식에 대해 더 자세히 알고 싶으시다면, 프로젝트 상담을 통해 문의해 주세요.*


프로젝트관리,일정관리,화이트박스,개발프로세스,커뮤니케이션
다른 포스팅
Blog·인사이트

프로덕트 메이커는 프로젝트를 어떻게 관리하나

··5분 읽기

외주 개발을 맡기면서 가장 불안한 건 "지금 어디까지 진행됐는지 모르겠다"입니다. 돈은 지불했는데, 중간 과정이 보이지 않고, 완성될 때까지 기다려야 하는 구조. 웹이든 앱이든 소프트웨어든, 이 불안은 동일합니다. 프로덕트 메이커는 이 불안을 구조적으로 없앱니다.

일정 관리: 격주 스프린트

프로젝트를 2주 단위 스프린트로 나눕니다. 3개월짜리 프로젝트라면 6개의 스프린트. 웹 서비스, 모바일 앱, 디바이스 연동 소프트웨어 — 프로젝트 종류와 관계없이 동일한 리듬으로 진행합니다.

초기 스프린트 (기획·디자인)

프로젝트 첫 1~2 스프린트는 기획과 디자인에 집중합니다.

  • 요구사항 정리, 화면 설계, UI/UX 디자인 진행
  • 클라이언트 피드백을 받아 디자인 확정
  • 이 기간 동안 인프라 구성, 인증 체계, DB 설계 등 필수 개발을 병렬로 진행합니다

디자인이 확정되지 않은 상태에서 화면 개발에 들어가면 "이게 아닌데"가 반복됩니다. 기획·디자인을 먼저 잡고, 합의된 설계 위에서 개발하는 것이 결과적으로 더 빠릅니다.

개발 스프린트

디자인이 확정된 이후의 스프린트는 개발에 집중합니다.

  • 시작: 이번 2주간 개발할 기능 범위를 확정
  • 진행: 확정된 디자인 기반으로 기능 개발
  • 완료: 동작하는 결과물을 클라이언트에게 공유
  • 피드백: 클라이언트가 직접 클릭하고 만져보면서 피드백. 실제로 사용해본 뒤 다음 스프린트 방향을 함께 조정합니다

2주마다 동작하는 결과물이 나오기 때문에, "3개월 뒤에 완성품을 보고 깜짝 놀라는" 상황이 발생하지 않습니다. 방향이 틀어져도 2주치만 수정하면 됩니다.

결과물의 형태는 프로젝트에 따라 다릅니다. 웹 서비스라면 테스트 가능한 URL, 앱이라면 TestFlight(iOS)이나 내부 배포 빌드(Android), 디바이스 연동 소프트웨어라면 실제 기기에서 동작하는 빌드를 공유합니다.

고객사와 업무 공유

소통 채널

  • 정기 미팅: 격주 1회, 스프린트 리뷰 겸 다음 스프린트 계획
  • 실시간 소통: 슬랙 또는 카카오톡. 급한 이슈는 바로 공유
  • 대표가 직접 소통: 중간 전달자가 없습니다. 기획 의도가 왜곡되지 않고, 기술적 판단이 즉시 이루어집니다

공유하는 것들

  • 동작하는 결과물: 매 스프린트마다 실제로 사용해볼 수 있는 빌드를 공유합니다. 웹은 URL, 앱은 테스트 빌드, 소프트웨어는 실행 파일 형태로 전달합니다
  • 진행 상황: 무엇이 완료됐고, 무엇이 진행 중이고, 무엇이 남았는지
  • 이슈: 기술적 제약, 일정 리스크, 변경이 필요한 부분 — 문제가 생기면 먼저 이야기합니다. 클라이언트가 물어보기 전에

"알아서 잘 하고 있겠지"가 아니라, "지금 이 상태입니다"를 계속 보여드리는 구조입니다.

개발 관리

코드 관리

  • Git 기반 버전 관리: 모든 코드 변경 이력이 기록됩니다. 누가, 언제, 무엇을 바꿨는지 추적 가능
  • 브랜치 전략: 기능별로 브랜치를 나눠서 개발하고, 검증 후 병합. 하나의 기능 개발이 다른 기능에 영향을 주지 않도록
  • 코드 리뷰: PR(Pull Request) 기반 코드 리뷰를 진행하며, AI 도구를 보조적으로 활용해 코드 품질을 관리합니다

배포 관리

  • 스테이징 환경: 실서비스에 반영하기 전에 테스트용 환경에서 먼저 확인. 앱의 경우 내부 테스트 트랙(TestFlight, Firebase App Distribution)을 활용
  • 자동화된 배포: 웹은 Docker 기반, 앱은 CI 기반으로 빌드와 배포를 자동화하여 사람의 실수를 줄임
  • 롤백 가능: 배포 후 문제가 발견되면 이전 버전으로 즉시 복구

품질 관리

  • 지속적 리팩토링: 개발 도중에 코드를 꾸준히 정리합니다. 기술 부채가 쌓이지 않도록 스프린트마다 정리 시간을 확보합니다
  • 크로스 플랫폼 테스트: 웹은 PC/모바일/다양한 브라우저, 앱은 iOS/Android 주요 기종, 소프트웨어는 타겟 OS와 디바이스에서 동작 확인
  • 에러 모니터링: 런칭 후에도 에러가 발생하면 즉시 감지. 웹은 서버 모니터링, 앱은 크래시 리포팅 도구를 활용

프로젝트 유형별 차이

관리 프레임워크는 동일하지만, 프로젝트 유형에 따라 세부 프로세스가 달라집니다.

  • 웹 서비스: 스프린트마다 테스트 URL 공유, 브라우저 호환성 테스트, SEO와 성능 최적화 포함
  • 모바일 앱(iOS/Android): 테스트 빌드 배포, 기기별 호환성 테스트, 스토어 심사 일정을 스프린트에 반영
  • 디바이스 연동 소프트웨어: 실제 하드웨어와의 통신 테스트가 스프린트에 포함. BLE, USB, Wi-Fi 등 연결 방식에 따라 테스트 환경 구성
  • WebGL/3D: 다양한 기기(TV, 모바일, PC)에서의 렌더링 성능 테스트. 모델 최적화 과정이 스프린트에 포함

HUENIT 로봇 제어 소프트웨어(3년 장기 운영), LG ThinQ WebGL(MAU 150만 실서비스), 메이트 모빌리티 실시간 화상통화 시스템 — 이 모든 프로젝트가 동일한 스프린트 구조로 진행됐습니다.

왜 이렇게 하나

많은 개발사가 "내부적으로 잘 관리하고 있습니다"라고 합니다. 하지만 클라이언트에게 보이지 않는 관리는 없는 것과 같습니다.

저희가 이 모든 과정을 투명하게 공유하는 이유는 단순합니다. 숨길 것이 없기 때문입니다. 코드를 보여드리고, 진행 상황을 공유하고, 문제를 먼저 이야기하는 것. 이게 화이트박스 개발의 본질입니다.

화이트박스 개발이란, 일반적인 블랙박스 외주(돈을 내고 완성될 때까지 기다리는 구조)와 반대되는 방식입니다. Git 저장소를 클라이언트와 공유하고, 매 스프린트마다 동작하는 결과물을 직접 확인할 수 있으며, 코드와 진행 상황이 항상 열려 있습니다. 완성 후 소스코드를 받는 게 아니라, 개발 과정 자체가 투명하게 공개되는 구조입니다.

그리고 이 구조의 진짜 장점은 클라이언트의 안심이 아닙니다. 더 좋은 결과물이 나온다는 것입니다. 2주마다 방향을 확인하니까 틀어질 틈이 없고, 피드백이 바로 반영되니까 "이게 아닌데"가 쌓이지 않습니다.

*프로젝트 관리 방식에 대해 더 자세히 알고 싶으시다면, 프로젝트 상담을 통해 문의해 주세요.*


프로젝트관리,일정관리,화이트박스,개발프로세스,커뮤니케이션
다른 포스팅
WebGL프로젝트 상담