[SW Engineering] 02. Software Project Management

이번 포스팅에서는 소프트웨어 프로젝트 관리와 최신 트렌드인 LLM(거대언어모델)을 활용한 개발 방법에 대해 정리해 봅니다.

1. 소프트웨어 프로젝트 관리란? (Software Project Management)

• 정의: 소프트웨어가 정해진 시간 내에(on time), 일정에 맞춰(on schedule), 그리고 소프트웨어를 개발하고 조달하는 조직의 요구사항에 맞춰 전달되도록 보장하는 활동입니다
• 필요성: 소프트웨어 개발은 항상 개발 조직이 설정한 예산과 일정의 제약을 받기 때문에 프로젝트 관리가 필수적입니다

1) 프로젝트 성공 기준 (Success Criteria)

성공적인 프로젝트 관리를 위해서는 다음 네 가지 기준을 충족해야 합니다.

• 고객과 합의한 시간에 소프트웨어를 인도해야 합니다
• 전체 비용을 예산 범위 내로 유지해야 합니다
• 고객의 기대를 충족하는 소프트웨어를 제공해야 합니다
• 일관성 있고 기능이 잘 작동하는 개발 팀을 유지해야 합니다

2) 소프트웨어 관리의 특수성

소프트웨어 관리는 다른 공학 프로젝트와 구별되는 특징이 있습니다.

• 무형성(Intangible): 소프트웨어는 눈으로 보거나 만질 수 없으며, 관리자가 단순히 결과물을 보는 것만으로는 진행 상황을 파악하기 어렵습니다
• 일회성(One-off): 많은 프로젝트가 일회성으로 진행되며, 대규모 프로젝트는 이전 프로젝트와 다른 양상을 띠기 때문에 경험 많은 관리자도 문제를 예측하기 어려울 수 있습니다
• 가변적인 프로세스: 소프트웨어 프로세스는 가변적이고 조직마다 특성이 달라, 특정 프로세스가 언제 문제를 일으킬지 예측하기 어렵습니다.

3) 편적인 관리 활동

모든 프로젝트 관리자가 수행해야 할 핵심 활동은 다음과 같습니다.

• 위험 관리(Risk Management): 프로젝트에 영향을 줄 수 있는 위험을 평가하고 모니터링하며, 문제 발생 시 조치를 취합니다
• 프로젝트 계획(Project Planning): 프로젝트 개발을 추정 및 일정을 수립하고, 사람들에게 작업을 할당합니다
• 인적 자원 관리(People Management): 팀원을 선발하고 효과적인 팀 성과를 낼 수 있는 업무 방식을 수립합니다

2. 위험 관리 (Risk Management)

위험 관리는 위험을 식별하고 그 영향을 최소화하기 위한 계획을 세우는 활동입니다

1) 소프트웨어 개발의 불확실성

소프트웨어 개발은 다음과 같은 이유로 내재적인 불확실성을 가집니다.

• 느슨하게 정의된 요구사항
• 고객 요구의 변화로 인한 요구사항 변경
• 개발 시간 및 자원 추정의 어려움
• 개인별 기술 역량의 차이

2) 위험의 분류 (Risk Classification)

위험은 유형(기술적, 조직적 등)과 영향을 받는 대상에 따라 분류됩니다

• 프로젝트 위험(Project risks): 일정이나 자원에 영향을 미칩니다
• 제품 위험(Product risks): 개발되는 소프트웨어의 품질이나 성능에 영향을 미칩니다
• 비즈니스 위험(Business risks): 소프트웨어를 개발하거나 조달하는 조직에 영향을 미칩니다

[주요 위험 예시]

위험(Risk)	영향(Affects)	설명(Description)
직원 이직	프로젝트	숙련된 직원이 프로젝트가 완료 되기 전 떠나는 경우
요구사항 변경	프로젝트 및 제품	예상했던 것보다 훨신 더 많은 요구사항 변경이 발생하는 경우
규모 과소평가	프로젝트 및 제품	시스템 규모를 실제보다 작게 잘못 추정한 경우
기술 변화	비즈니스	시스템이 기반으로 하는 기술이 새로운 기술로 대체되어 구식이 되는 경우
제품 경쟁	비즈니스	시스템이 완성되기 전에 경쟁 제품이 시장이 먼저 출시되는 경우

3) 위험 관리 프로세스

위험 관리는 다음 4단계로 진행됩니다

1. 위험 식별 (Risk Identification):
   • 프로젝트, 제품, 비즈니스 위험을 식별합니다
   • 예: 시간 과소평가, 예산 삭감, 핵심 인력의 질병, 요구사항 변경의 영향 이해 부족, 재사용 컴포넌트 결함 등
2. 위험 분석 (Risk Analysis):
   • 식별된 위험의 발생 가능성(Likelihood)과 결과(Consequences)를 분석합니다.
   • 가능성은 '낮음~높음'으로, 영향은 '재앙적(Catastrophic), 심각함(Serious), 허용 가능(Tolerable), 미미함(Insignificant)'으로 범주화합니다
3. 위험 계획 (Risk Planning):
   • 각 위험을 관리하기 위한 전략을 수립합니다
   • 회피 전략(Avoidance): 위험 발생 확률을 줄입니다 (예: 하드웨어 고장 방지를 위한 정기 점검)
   • 최소화 전략(Minimization): 위험의 영향을 줄입니다 (예: 변경 영향을 줄이기 위한 정보 은닉 극대화)
   • 비상 계획(Contingency): 위험 발생 시 대처할 계획을 세웁니다 (예: 화재 시 트래픽 우회).
4. 위험 모니터링 (Risk Monitoring):
   • 위험의 발생 가능성이나 영향이 변했는지 정기적으로 평가합니다.
   • 주요 위험은 관리 회의에서 논의되어야 합니다

---

3. 프로젝트 계획 (Project Planning)

프로젝트 계획은 작업을 세분화하여 팀원에게 할당하고, 발생 가능한 문제를 예측하여 해결책을 준비하는 과정입니다

• 이 계획은 팀과 고객에게 작업 수행 방식을 알리고 진행 상황을 평가하는 데 사용됩니다

계획 수립 단계

• 제안 단계: 계약 입찰 시 수행
• 프로젝트 시작 단계: 인력 배치, 작업 분할, 자원 할당 등을 계획
• 개발 중 주기적 계획: 경험과 모니터링 정보를 바탕으로 계획을 수정

---

4. 프로젝트 일정 관리 (Project Scheduling)

일정 관리는 작업을 개별 태스크로 조직화하고 실행 시기와 방법을 결정하는 과정입니다

• 각 태스크의 소요 시간(calendar time), 노력(effort), 담당자를 추정합니다
• 서버 디스크 공간, 시뮬레이터 시간, 출장비 등 필요한 자원도 추정해야 합니다

1) 일정 수립 프로세스

1. 활동 식별 (Identify activities)
2. 활동 간 의존성 파악 (Identify activity dependencies)
3. 활동에 필요한 자원 추정 (Estimate resources for activities)
4. 활동에 인력 할당 (Allocate people to activities)
5. 프로젝트 차트 작성 (Create project charts)

2) 일정 관리의 어려움

• 문제의 난이도와 비용을 추정하기 어렵습니다
• 생산성은 투입 인원에 비례하지 않습니다. 늦어진 프로젝트에 인력을 추가하면 의사소통 비용으로 인해 더 늦어질 수 있습니다
• 예상치 못한 일이 항상 발생하므로 비상시를 대비한 여유(contingency)를 두어야 합니다

3) 주요 용어

• 프로젝트 활동(Activities): 기본 계획 요소로 기간(duration), 노력 추정치(effort estimate), 마감일(deadline), 정의된 종료점(end-point)을 가집니다
• 마일스톤(Milestones): 진행 상황을 평가할 수 있는 일정상의 지점 (예: 테스트를 위한 시스템 인도)
• 산출물(Deliverables): 고객에게 전달되는 작업 결과물 (예: 요구사항 문서)

4) 시각화 도구

• 활동 바 차트 (Activity bar chart): 태스크의 시작과 끝, 마일스톤을 주 단위로 보여줍니다
• 간트 차트 (Gantt Chart): 요구사항 수집부터 배포까지 전체 타임라인을 시각화합니다
• 인력 할당 차트 (Staff allocation chart): 각 팀원이 언제 어떤 작업을 수행하는지 보여줍니다

이런 시각화 도구들은 실무에서 상황에 따라 통합되어 여러 방식으로 사용됩니다.

실무에서의 사용

노션과 지라의 타임 라인

1. 활동 바 차트 & 간트 차트(Activity Bar & Gantt Chart)

실무에서는 이 둘을 엄ㄹ격히 구분하지 않고 보통 '로드맵' 또는 '타임라인' 기능으로 통칭하여 사용합니다.

• 실무에서의 역할: 프로젝트 매니저(PM)나 팀장이 **"우리가 언제 이 기능을 배포할 수 있는가?"**를 경영진이나 타 부서에 보여줄 때 주로 씁니다.
• 사용 도구 및 예시:
  • Jira (Advanced Roadmaps):
    • Jira에서는 'Epic(큰 기능 덩어리)' 단위로 바(Bar)를 생성합니다.
    • 예시: "회원가입 기능"이라는 긴 막대(Bar) 안에 "UI 디자인", "DB 설계", "API 개발"이라는 세부 막대를 넣습니다.
    • 각 막대를 화살표로 연결하여 **의존성(Dependency)**을 표시합니다. ("DB 설계가 끝나야 API 개발을 시작할 수 있음"을 시각화)
  • Notion (타임라인 뷰):
    • 데이터베이스를 만들고 보기를 '타임라인'으로 설정하면 바로 간트 차트가 됩니다.
    • 예시: 스타트업이나 소규모 팀에서 "이번 달 마케팅 일정"과 "개발 배포 일정"을 한눈에 볼 때 직관적으로 날짜를 드래그해서 조정합니다.
• 인력 할당 차트(staff Allocation Chart)

이론에서는 별도의 표로 그리지만, 실무에서는 '리소스 관리(Resource Management)' 또는 '업무 부하(Workload)' 기능으로 구현됩니다.

• 실무에서의 역할: 팀장이 "누가 일이 너무 많아 야근을 하고 있는가?"(번아웃 방지) 혹은 **"누가 지금 노는 손이 있는가?"(업무 분배)**를 파악할 때 씁니다.
• 사용 도구 및 예시:
  • Jira (Dashboard / Plans):
    • 보통 칸반 보드(Kanban Board)의 상단 필터를 통해 확인합니다.
    • 예시: 검색창에 assignee = 설곽이를 입력하면 설곽이에게 할당된 티켓(Task)이 몇 개인지 쭉 나옵니다. 만약 다른 팀원은 티켓이 2개인데 똘똘이만 10개라면, 팀장이 드래그앤드롭으로 티켓을 다른 사람에게 옮깁니다.
  • Asana / Monday.com (Workload View):
    • 팀원별로 그래프가 그려집니다. 특정 주차에 할당된 업무 시간이 설정된 시간(예: 주 40시간)을 넘으면 빨간색 경고등이 뜹니다.
  • Notion (사람별 보기):
    • 보드 뷰(Board View)에서 '그룹화 기준(Group by)'을 '담당자(Person)'로 설정합니다.
    • 예시: 세로열에 '김철수', '이영희', '박민수'가 뜨고 그 아래에 각자가 맡은 카드가 나열됩니다. 카드가 한 사람에게 쏠려 있다면 시각적으로 바로 알 수 있습니다.

---

5. 개발을 위한 LLM 통합 (Large Language Model Integration)

최신 개발 환경에서는 생산성을 높이기 위해 LLM을 적극적으로 활용합니다.

1) LLM 서비스 유형

1. 챗 서비스 (Chat Service):
   • ChatGPT, Claude, Gemini 등의 챗봇과 상호작용합니다
   • 프롬프트에 정보를 입력하고 결과를 수동으로 코드에 적용해야 하므로 번거로울 수 있습니다
2. 에이전트 (Agent):
   • LLM을 내 자원과 자동으로 연결하여 작업량을 줄여줍니다
   • 더 많은 정보에 접근하여 더 나은 결과를 기대할 수 있습니다

2) 통합 방식 및 도구

• CLI (Command Line Interface): 터미널에서 모델에게 명령을 내려 작업을 수행합니다 (예: Claude Code, Gemini CLI, Codex CLI)
  • 예시: "소리 피드백이 있는 인터랙티브 ASCII 아트 도구를 만들어줘...
• GitHub 통합:
  • 코드 리뷰, 이슈 관리 등을 LLM이 보조하거나 위임받아 처리합니다 (예: Gemini의 PR 코드 리뷰, Codex Cloud로 이슈 처리)

3) 고려사항

LLM 도입 시 다음 사항을 고려해야 합니다

• 작업 유형 (Task Types): 수행하고자 하는 작업이 무엇인가?
• 모델 성능 (Performance): 해당 작업에 모델 성능이 충분한가?
• 비용 (Costs): 비용과 시간이 얼마나 소요되는가?
• 데이터 보안 (Data security): 민감한 정보를 다루어야 하는가?

4) 사용 팁 (Tips for Usage)

• LLM에게는 한 번에 하나의 작업을 명확하게 주는 것이 좋습니다
• 복잡한 작업은 더 단순한 작업들로 나누는 것이 좋습니다
• 스스로 할 수 있는 일을 요청하면 결과를 검증하기 더 쉽습니다
• "무엇을 할지"보다 "어떻게 할지(how to do)"를 설명하면 더 좋은 결과를 얻을 수 있습니다

---

요약: 이번 포스팅에서는 소프트웨어 개발의 위험을 관리하는 법, 프로젝트 계획 및 비용/일정 추정 방법, 그리고 개발 환경에 LLM을 통합하는 방법에 대해 알아보았습니다. 이 글을 바탕으로 SW Project management에 대해 도움이 되길 바랍니다.