PnP(Project in Project) 개념 도입

2026-02-15 hit count image

프로젝트 안에서 또 다른 프로젝트를 만들어 운영하는 PnP 개념과 도입 방법에 대해 알아봅시다.

development_process

개요

회사의 평가 항목에 프로젝트 관리라는 항목이 있지만, 실제로 프로젝트를 관리하는 업무가 적은 경우가 많습니다. 일부 멤버만 프로젝트 관리를 담당하고 있어, 다른 멤버들도 프로젝트 관리 측면에서 평가할 수 있는 구조가 필요하게 되었습니다.

이번 블로그 포스트에서는 이 문제를 해결하기 위한 PnP(Project in Project) 개념과 도입 방법에 대해 소개하겠습니다.

PnP란

PnP는 Project in Project의 약자로, 현재 진행 중인 프로젝트의 태스크를 별도의 프로젝트로 만들어 운영하는 개념입니다.

PnP - Agile의 Theme, Epic, Story, Task 구조

  • 메인 프로젝트(Main Project): 팀이 관리하는 서비스 레벨의 프로젝트입니다. Agile에서는 테마(Theme) 레벨에 해당합니다.
  • PnP: 메인 프로젝트 안에서 프로젝트화하여 관리할 수 있는 큰 태스크입니다. Agile에서는 에픽(Epic) 레벨에 해당합니다.

예를 들어, 메인 프로젝트가 서비스 A라면, PnP로 관리할 수 있는 태스크는 다음과 같습니다.

  • Google Analytics 도입 (데이터 분석, A/B 테스트)
  • 테스트 도입 (Unit 테스트, E2E 테스트)
  • Sentry 적용 (에러 및 예외 처리)

이처럼 PnP를 활용하면 프로젝트 안에서 또 다른 프로젝트를 만들어 운영할 수 있습니다.

도입 이유

PnP 개념을 도입하는 이유는 멤버들의 인식을 맞추고, 개발 프로세스의 일부로 체계화하기 위해서입니다. PnP를 통해 더 많은 멤버가 프로젝트 관리 경험을 쌓을 수 있고, 평가에도 반영할 수 있는 구조를 만들 수 있습니다.

진행 방법

PnP를 도입하기로 했다면, 팀 차원에서 PnP 담당자로써 다음과 같은 방식으로 진행할 수 있습니다.

팀 차원

  1. PnP로 진행할 수 있는 프로젝트를 목록화합니다.
  2. 그 중에서 PnP 프로젝트를 선정합니다.
  3. 멤버에게 할당합니다.
  4. 플래닝 시 PnP 태스크도 함께 포함시킵니다.

PnP 담당자

  1. 프로젝트의 목표를 설정합니다.
    1. 프로젝트 개요
    2. 프로젝트 목표
    3. 범위
    4. 방침 결정이나 검토가 필요한 사항
    5. 스케줄
  2. 목표를 멤버에게 공유하여 인식을 맞춥니다.
  3. 프로젝트를 세분화합니다. Agile에서는 유저 스토리(User Story) 레벨로 분리합니다.
  4. 백로그에 티켓을 생성합니다.
  5. 플래닝 시, 생성한 티켓 중 필수 티켓과 긴급하지 않은 티켓을 구분하여 스프린트에 넣습니다.
  6. 개발을 진행합니다.

별도의 PnP 전용 아침 회의나 정기 미팅을 만들 필요 없이, 메인 프로젝트에 포함시키는 형태로 진행합니다.

주의사항

  • PnP를 담당하는 멤버도 메인 프로젝트의 티켓을 처리합니다.
  • 메인 프로젝트와 PnP 태스크의 양과 스케줄을 잘 관리해야 합니다.
  • PnP는 프로젝트 관리 스킬 향상과 평가를 위한 것이므로, 너무 많은 시간을 투자하지 않도록 합니다.
  • 메인 프로젝트에 필수적인 기능은 반드시 처리해야 하므로, 우선순위 조절을 잘 해야 합니다. 메인 프로젝트 담당자와 PnP 담당자가 인식을 맞추는 것이 중요합니다.

PnP의 예

서비스 A에 테스트(Unit, E2E 테스트)를 도입하는 PnP 예시입니다.

  1. 프로젝트 개요
    1. 서비스의 버그를 사전에 발견하여 버그 발생률을 줄인다.
    2. 추가 개발로 인한 리그레이션(regression)을 줄인다.
  2. 프로젝트 목표
    1. Unit 테스트와 E2E 테스트의 방침을 정한다.
    2. Unit 테스트와 E2E 테스트를 작성한다.
  3. 범위
    1. 복잡한 로직을 가진 컴포넌트나 함수에 대해 Unit 테스트를 작성한다.
    2. 페이지 단위의 테스트 케이스를 참고하여 E2E 테스트를 작성한다.
    3. GitHub Actions에서 테스트 코드를 실행한다.
  4. 방침 결정 및 검토 사항
    1. 버그나 디그레이션이 발생하면 반드시 테스트 케이스를 작성한 후 수정한다.
    2. 테스트 케이스를 기반으로 E2E를 작성한다.
    3. 복잡한 컴포넌트나 함수를 선별하여 추가한다.
    4. 개발 시 복잡하거나 조건이 많은 경우 테스트 케이스를 작성한다.
    5. 코드에 주석을 달아야 하는 경우, 해당 부분에 대한 테스트 케이스를 작성한다.
  5. 스케줄
    1. 26페이지, 6개월(24주) = 1 스프린트: 2~3페이지
    2. 버그, 디그레이션 발생 시 테스트 코드 작성
    3. 복잡한 컴포넌트나 함수: 1 스프린트당 1~2개

PnP 도입의 기대 효과

PnP를 도입하면 다음과 같은 효과를 기대할 수 있습니다.

  • PnP를 통해 더 많은 멤버가 프로젝트 관리 스킬을 배울 수 있습니다.
  • 멤버의 프로젝트 관리 역량을 평가하기 쉬워집니다.
  • PnP를 담당한 멤버는 해당 프로젝트를 더 깊이 있게 살펴볼 수 있어, 더 높은 품질의 기능과 제품이 만들어집니다.

완료

이것으로 PnP(Project in Project) 개념과 도입 방법에 대해 알아보았습니다. PnP를 활용하면 메인 프로젝트를 진행하면서도 팀 멤버들이 프로젝트 관리 경험을 쌓을 수 있고, 개발 프로세스도 체계화할 수 있습니다. 팀에 맞는 PnP 프로젝트를 선정하여 도입해 보시기 바랍니다.

제 블로그가 도움이 되셨나요? 하단의 댓글을 달아주시면 저에게 큰 힘이 됩니다!

앱 홍보

책 홍보

블로그를 운영하면서 좋은 기회가 생겨 책을 출판하게 되었습니다.

아래 링크를 통해 제가 쓴 책을 구매하실 수 있습니다.
많은 분들에게 도움이 되면 좋겠네요.



SHARE
Twitter Facebook RSS