애자일 프로젝트에서 구성원의 역할

실제 SI 프로젝트에 Scrum을 적용한다면?

PM·PL·기획자·개발자·고객의 역할과 Sprint 운영 방법

지난 글에서는 애자일의 12가지 원칙과 함께 Scrum, 경험주의, 페어워크 등의 개념을 살펴보았습니다.

그렇다면 실제 SI 프로젝트에서는 애자일을 어떻게 적용할 수 있을까요?

특히 SI 프로젝트에는 일반적인 제품 개발과 다른 특징이 있습니다.

계약 기간이 정해져 있고, 고객사가 있으며, 정해진 예산과 범위가 존재합니다. 또한 분석·설계·개발·테스트와 같은 단계별 산출물도 요구됩니다.

따라서 현실적인 방법은 기존 SI 프로젝트의 틀을 완전히 버리는 것이 아니라, 그 안에 Scrum의 장점을 집어넣는 것입니다.

이번 글에서는 가상의 SI 프로젝트를 하나 만들어 실제 적용 방법을 살펴보겠습니다.

1. 가상의 SI 프로젝트를 만들어 보자

예를 들어 한 기업에서 다음과 같은 프로젝트를 발주했다고 가정해보겠습니다.

프로젝트명 : 차세대 고객관리 시스템 구축

프로젝트 기간은 6개월입니다.

주요 기능은 다음과 같습니다.

• 로그인

• 사용자 관리

• 고객 정보 관리

• 상품 관리

• 주문 관리

• 결제

• 통계 및 리포트

• 관리자 시스템

• 외부 시스템 연계

전통적인 SI 방식이라면 대략 다음과 같이 진행할 수 있습니다.

분석 → 설계 → 개발 → 테스트 → 오픈

하지만 애자일 방식을 일부 적용하면 프로젝트 전체를 작은 개발 단위로 나누어 진행할 수 있습니다.

예를 들어 2주를 하나의 Sprint로 운영합니다.

2. 먼저 프로젝트의 역할을 정의한다

Scrum에는 Product Owner, Scrum Master, Developers라는 핵심 역할이 있습니다.

하지만 실제 SI 프로젝트에서는 회사마다 PM, PL, 기획자, 개발자, 고객 담당자 등 다양한 직책이 존재합니다.

따라서 Scrum의 역할과 기존 SI의 역할을 적절하게 연결할 필요가 있습니다.

예를 들어 다음과 같이 구성할 수 있습니다.

기존 SI 역할	Scrum 관점에서의 역할
고객 업무 담당자	Product Owner 역할
PM	프로젝트 전체 관리 및 조정
PL	개발팀 리딩 및 기술적 의사결정
기획자/분석가	요구사항 정리 및 Backlog 관리 지원
개발자	Developers
QA	품질 검증 및 테스트
Scrum Master	PM 또는 별도 담당자가 수행 가능

여기서 중요한 것은 직책과 Scrum 역할이 반드시 1:1로 일치할 필요는 없다는 것입니다.

3. Product Owner는 누가 해야 할까?

SI 프로젝트에서 가장 어려운 부분 중 하나입니다. Product Owner는 단순히 요구사항을 전달하는 사람이 아닙니다.

무엇을 먼저 만들 것인지 결정하고, 제품의 가치를 극대화하는 역할을 해야 합니다.

따라서 이상적인 Product Owner는 개발업체 직원보다는 고객사의 실제 업무를 잘 알고 있는 사람이 맡는 것이 좋습니다.

예를 들어 고객사의 고객관리팀 팀장이 Product Owner 역할을 맡을 수 있습니다.

개발팀에서 “A 기능과 B 기능 중 무엇을 먼저 개발할까요?”라고 질문했을 때,

Product Owner가 “A 기능이 이번 달 업무에 반드시 필요하므로 A를 먼저 개발해 주세요.”라고 우선순위를 결정할 수 있어야 합니다.

4. Backlog를 만든다

프로젝트 초기에 모든 기능을 지나치게 상세하게 확정하는 대신, 전체 요구사항을 Product Backlog로 관리합니다.

예를 들어 다음과 같습니다.

Product Backlog

1. 로그인

2. 회원가입

3. 사용자 관리

4. 고객 등록

5. 고객 조회

6. 고객 수정

7. 상품 등록

8. 상품 조회

9. 주문 생성

10. 주문 조회

11. 결제

12. 통계

13. 관리자 기능

14. 외부 시스템 연계

이 상태에서 중요한 것은 우선순위입니다. 모든 기능이 똑같이 중요한 것은 아니기 때문입니다.

예를 들어 고객이 “통계 화면도 중요하지만 고객 등록과 조회가 가장 급합니다.”라고 한다면 고객 등록과 조회의 우선순위를 높입니다.

5. Sprint Planning을 한다

이제 첫 번째 Sprint를 시작합니다. Sprint 기간을 2주로 정했다고 가정하겠습니다.

첫 번째 Sprint에서 개발팀이 다음 기능을 선택합니다.

Sprint 1

• 로그인

• 회원가입

• 기본 사용자 정보

• 기본 화면 구성

여기서 중요한 점은 개발자가 할 일을 PM이 일방적으로 배정하는 것이 아니라 팀이 Sprint에서 처리할 수 있는 업무량을 판단한다는 것입니다.

예를 들어 PL이 “이번 Sprint에서 이 정도까지는 충분히 가능하겠습니다.”라고 판단하고 개발팀이 Sprint Backlog를 구성합니다.

6. 개발은 Sprint 안에서 진행한다

Sprint가 시작되면 개발팀은 선택한 기능을 개발합니다.

예를 들어

1일차

개발 환경 및 DB 구성

2~3일차

로그인 API 개발

4~5일차

로그인 화면 개발

6일차

회원가입 개발

7~8일차

사용자 정보 개발

9일차

통합

10일차

테스트 및 수정

이런 식으로 진행할 수 있습니다.

여기서 중요한 것은 단순히 코드를 작성하는 것이 아닙니다.

Sprint가 끝났을 때 실제로 동작하는 기능을 만들어야 합니다.

7. Daily Scrum은 ’업무보고’가 아니다

매일 10~15분 정도 짧은 Daily Scrum을 진행합니다.

개발자가 PM에게 보고하는 회의가 아니라 팀이 현재 상황을 공유하는 자리입니다.

예를 들어 개발자 A가 “로그인 기능을 개발하고 있습니다.”라고 말하는 것보다

“로그인 API는 완료됐지만 외부 인증 서버 연동에서 문제가 발생했습니다. 이 문제가 해결되지 않으면 Sprint 목표에 영향을 줄 수 있습니다.”라고 공유하는 것이 훨씬 중요합니다.

문제를 빨리 발견하면 팀이 즉시 대응할 수 있기 때문입니다.

8. 어려운 기능은 Pair Work를 활용한다

모든 개발을 두 명이 함께할 필요는 없습니다.

하지만 중요한 기능에서는 페어워크를 활용할 수 있습니다.

예를 들어 결제 기능을 개발한다고 가정해 보겠습니다.

개발자 A가 혼자 개발하는 대신

A + B

두 명이 함께 설계하고 개발합니다.

한 명이 코드를 작성하고 다른 한 명이 옆에서 검토합니다. 이 방식의 장점은 단순히 오류를 줄이는 것만이 아닙니다.

특정 기능에 대한 지식이 한 명의 개발자에게만 집중되는 것을 막을 수 있습니다.

예를 들어 A가 휴가를 가더라도 B가 해당 코드를 이해하고 대응할 수 있습니다.

특히 다음과 같은 기능에 선택적으로 적용하면 효과적입니다.

• 결제

• 보안

• 핵심 업무 로직

• 복잡한 SQL

• 대규모 데이터 처리

• 외부 시스템 연계

• 공통 모듈

9. Sprint Review에서는 고객에게 실제 시스템을 보여준다

2주가 지나면 Sprint가 종료됩니다. 이때 중요한 것이 Sprint Review입니다.

개발팀이 문서를 보여주면서 “로그인 기능 개발이 완료되었습니다.”라고 설명하는 것보다,

실제 시스템을 보여주는 것이 좋습니다.

예를 들어 고객 담당자가 직접

회원가입 → 로그인 → 회원정보 조회 → 회원정보 수정

을 해봅니다.

그 과정에서 고객이 “회원가입할 때 이 항목은 필요하지 않은 것 같습니다.”라고 이야기할 수도 있습니다.

또는 “우리 직원들은 이 화면보다 이런 방식으로 사용하는 경우가 많습니다.”라고 할 수도 있습니다.

이것이 바로 애자일에서 이야기하는 피드백입니다.

10. 고객의 요구사항이 변경되었다면?

여기에서 전통적인 SI 방식과 애자일 방식의 차이가 나타납니다.

고객이 “회원가입 화면의 구조를 변경하고 싶습니다.”라고 요청했다고 가정해보겠습니다.

전통적인 프로젝트에서는 “요구사항이 변경됐으므로 일정과 비용에 영향을 줍니다.”라는 문제가 먼저 발생할 수 있습니다.

애자일에서는 우선 Backlog에 변경 요구사항을 등록합니다.

그리고 Product Owner가 우선순위를 판단합니다.

예를 들어

변경 요구사항 A

회원가입 화면 변경

기존 요구사항 B

관리자 통계 기능이라면,

Product Owner가 “회원가입 화면 변경이 더 중요합니다.”라고 판단할 수 있습니다.

그러면 다음 Sprint에서 A를 먼저 개발하고 B의 우선순위를 뒤로 조정할 수 있습니다.

물론 실제 SI 계약상 범위를 벗어나는 변경이라면 별도의 변경관리, 일정 및 비용 협의가 필요합니다.

애자일이라고 해서 계약과 비용의 현실을 무시하는 것은 아닙니다.

11. Sprint Retrospective를 한다

Sprint Review가 끝났다면 팀 내부에서 회고를 진행합니다.

질문은 간단합니다.

잘된 것은 무엇인가?

예를 들어

개발자 간 소통이 빨라졌다.

문제가 있었던 것은 무엇인가?

API 명세가 늦게 확정되어 개발이 지연됐다.

다음 Sprint에서 무엇을 바꿀 것인가?

API 명세를 Sprint 시작 전에 확정한다.

이렇게 구체적인 개선 사항 하나라도 다음 Sprint에 적용하는 것이 중요합니다.

회고가 매번 “다음부터 잘하자.”로 끝난다면 애자일의 의미가 없습니다.

12. Sprint 2에서는 실제 경험을 반영한다

첫 번째 Sprint를 통해 팀은 많은 것을 알게 됩니다.

예를 들어

• 예상보다 테스트 시간이 오래 걸렸다.

• 고객의 요구사항이 문서와 달랐다.

• 특정 개발자에게 업무가 집중됐다.

• 외부 시스템 연동에 시간이 많이 필요했다.

이러한 경험을 두 번째 Sprint에 반영합니다.

이것이 바로 경험주의입니다.

처음부터 완벽한 계획을 세우는 것이 아니라,

실제로 해보고 → 결과를 확인하고 → 다음 계획을 수정하는 것

입니다.

13. 6개월 프로젝트라면 어떻게 운영할까?

예를 들어 6개월 프로젝트에서 2주 Sprint를 사용한다고 가정하면 약 12개의 Sprint를 운영할 수 있습니다.

프로젝트 초반

Sprint 0

개발환경, 아키텍처, 기본 설계

1~3 Sprint

회원/고객 관리

4~6 Sprint

상품/주문

7~9 Sprint

결제 및 외부 시스템

10~11 Sprint

통계 및 관리자 기능

Sprint 12

통합 테스트 및 안정화

물론 실제 프로젝트에서는 프로젝트 성격에 따라 Sprint 기간과 구성이 달라질 수 있습니다.

14. PM의 역할은 오히려 더 중요해진다

애자일을 도입하면 PM의 역할이 없어지는 것으로 생각하는 경우가 있습니다.

오히려 반대입니다.

SI 프로젝트에서 PM은

전체 일정 + 계약 + 비용 + 고객 + 조직 + 리스크

를 관리해야 합니다.

특히 애자일 환경에서는 “왜 계획대로 안 됐습니까?”라고 묻는 것보다

“현재 상황을 기준으로 어떻게 하면 프로젝트 목표를 달성할 수 있을까요?”를 판단해야 합니다.

즉, PM은 단순한 일정 관리자가 아니라 프로젝트 전체의 의사결정과 이해관계자를 조정하는 역할을 수행하게 됩니다.

15. PL은 개발팀의 기술적 방향을 책임진다

PL은 개발자에게 단순히 업무를 나눠주는 사람이 되어서는 안 됩니다.

특히 애자일 환경에서는

• 기술적 의사결정

• 아키텍처

• 코드 품질

• 기술적 리스크

• 개발자 간 협업

• 기술부채

등을 관리해야 합니다. 그리고 필요한 경우 Pair Work나 Code Review를 통해 개발자 간 지식을 공유하도록 해야 합니다.

16. 기획자의 역할도 달라진다

애자일 프로젝트에서 기획자는 모든 화면을 처음부터 완벽하게 만들어 개발자에게 전달하는 역할에서 조금 달라질 수 있습니다.

기획자는 고객의 요구사항을 이해하고 이를 개발 가능한 작은 단위로 나누는 역할이 중요합니다.

예를 들어

“고객관리 시스템을 만들어 주세요.”라는 큰 요구사항을

• 고객 등록

• 고객 조회

• 고객 상세

• 고객 수정

• 고객 삭제

• 고객 검색

• 고객 이력

등의 작은 기능으로 분리합니다. 그리고 각각의 우선순위를 결정합니다.

17. 개발자의 역할도 달라진다

전통적인 SI에서는 개발자가 “내가 맡은 화면은 이것입니다.”라고 생각하기 쉽습니다.

하지만 애자일에서는

“이번 Sprint에서 팀이 달성해야 하는 목표는 무엇인가?”를 생각해야 합니다.

따라서 개발자 간 업무 경계를 조금 넘어서는 협업이 필요합니다.

A 개발자의 업무가 끝났다고 해서 프로젝트에 대한 책임이 끝나는 것이 아니라,

다른 개발자의 작업을 지원하거나 테스트를 도와줄 수도 있습니다.

이것이 개인보다 팀을 중심으로 일하는 방식입니다.

18. SI에서 애자일을 적용할 때 가장 중요한 세 가지

실제 SI 프로젝트에서 애자일을 적용한다면 저는 다음 세 가지가 가장 중요하다고 생각합니다.

첫 번째. 짧은 주기로 실제 결과물을 보여줄 것

문서만 만들지 말고 실제 동작하는 시스템을 보여줘야 합니다.

분석 → 개발 → 검증 → 피드백

이라는 사이클을 최대한 짧게 만드는 것입니다.

두 번째. 고객을 프로젝트에 참여시킬 것

고객이 프로젝트 시작할 때 요구사항을 전달하고 마지막에 결과물을 받는 구조라면 애자일을 적용하기 어렵습니다.

고객이 지속적으로

보고 → 사용하고 → 의견을 주고 → 우선순위를 결정

해야 합니다.

세 번째. 회고를 통해 실제로 바꿀 것

애자일의 핵심은 Sprint를 반복하는 것이 아닙니다.

Sprint를 반복하면서 팀이 점점 더 나아지는 것입니다.

따라서 회고에서 나온 개선사항을 다음 Sprint에 실제로 적용해야 합니다.

마무리

SI 프로젝트에 애자일을 적용한다고 해서 기존의 PM 방식이나 산출물, 계약, 일정 관리 등을 모두 없애야 하는 것은 아닙니다.

오히려 현실적인 방법은 기존 SI 프로젝트의 장점을 유지하면서 애자일의 장점을 결합하는 것입니다.

예를 들면 다음과 같습니다.

PM

→ 프로젝트 전체 일정·비용·계약·리스크 관리

Product Owner

→ 고객의 요구사항과 우선순위 결정

PL

→ 기술적 방향과 개발팀 관리

기획자

→ 요구사항을 작은 개발 단위로 구체화

개발자

→ Sprint 목표를 달성하기 위한 협업

고객

→ 실제 결과물을 확인하고 지속적으로 피드백

그리고 이 모든 과정은 다음과 같은 사이클로 반복됩니다.

Backlog

↓

Sprint Planning

↓

개발

↓

Daily Scrum

↓

Working Software

↓

Sprint Review

↓

고객 Feedback

↓

Retrospective

↓

개선

↓

다음 Sprint

결국 애자일의 핵심은

“처음부터 완벽한 계획을 세우는 것”이 아니라
“빠르게 실행하고, 실제 결과를 통해 배우고, 계속 개선하는 것”이라고 할 수 있습니다.

특히 변화가 많고 이해관계자가 복잡한 SI 프로젝트일수록 이러한 방식은 더욱 의미가 있습니다.

Luke