애자일 12원칙과 SI 프로젝트에 적용하는 방법

-애자일은 단순히 ’빠르게 개발하는 방법’이 아니다-

소프트웨어 개발 현장에서 ’애자일(Agile)’이라는 말을 흔히 들을 수 있습니다.

하지만 애자일을 단순히

“개발을 빨리 하는 것”
“스프린트를 2주 단위로 돌리는 것”
“매일 아침 데일리 미팅을 하는 것”

정도로 이해하면 애자일의 핵심을 놓치기 쉽습니다.

애자일의 출발점은 2001년 발표된 애자일 소프트웨어 개발 선언(Agile Manifesto)입니다.

애자일 선언은 다음 네 가지 가치를 중요하게 생각합니다.

• 프로세스와 도구보다 개인과 상호작용

• 포괄적인 문서보다 작동하는 소프트웨어

• 계약 협상보다 고객과의 협력

• 계획을 따르는 것보다 변화에 대응하는 것

프로세스, 문서, 계약, 계획도 필요하지만, 그보다 사람과 소통, 실제 동작하는 결과물, 고객과의 협력, 변화에 대한 대응을 더 중요하게 생각한다는 의미입니다.

애자일의 12가지 원칙

애자일 선언에는 네 가지 가치와 함께 이를 실천하기 위한 12가지 원칙이 있습니다.

1. 고객 만족을 최우선으로 한다

가치 있는 소프트웨어를 가능한 한 빠르고 지속적으로 제공하여 고객을 만족시키는 것을 가장 중요하게 생각합니다.

2. 요구사항 변경을 받아들인다

개발 후반부라도 요구사항 변경을 받아들입니다.

변경을 무조건 프로젝트의 방해 요소로 보는 것이 아니라, 고객에게 경쟁력을 제공할 수 있는 기회로 봅니다.

3. 작동하는 소프트웨어를 자주 제공한다

몇 개월 동안 개발한 뒤 한꺼번에 보여주는 것보다 짧은 주기로 실제 동작하는 결과물을 제공합니다.

4. 비즈니스 담당자와 개발자가 함께 일한다

기획자, 현업 담당자, 개발자가 프로젝트 초기에만 만나는 것이 아니라 프로젝트 전체 과정에서 지속적으로 협력해야 합니다.

5. 동기가 부여된 사람을 중심으로 프로젝트를 구성한다

팀원에게 필요한 환경과 지원을 제공하고, 스스로 업무를 수행할 수 있도록 신뢰합니다.

6. 가장 효과적인 의사소통은 직접 대화하는 것이다

문서나 메일만 주고받기보다 필요한 경우 직접 대화하여 문제를 빠르게 해결합니다.

7. 작동하는 소프트웨어가 진척도의 가장 중요한 기준이다

“문서를 얼마나 작성했는가”보다 실제로 동작하는 기능이 얼마나 만들어졌는가를 중요하게 봅니다.

8. 지속 가능한 개발 속도를 유지한다

특정 기간 동안 야근과 초과 근무를 반복하여 속도를 내는 것이 아니라 장기적으로 유지할 수 있는 개발 속도를 추구합니다.

9. 기술적 완성도와 좋은 설계를 지속적으로 추구한다

단순히 기능을 빨리 만드는 것만으로 끝나지 않습니다.

좋은 코드와 설계, 기술적 품질을 지속적으로 개선해야 합니다.

10. 단순함을 추구한다

하지 않아도 되는 일을 최대한 줄입니다.

즉, “무엇을 더 할 것인가?”뿐만 아니라 “무엇을 하지 않을 것인가?”를 고민합니다.

11. 좋은 아키텍처와 요구사항, 설계는 자기 조직화된 팀에서 나온다

모든 것을 관리자가 일방적으로 결정하는 것이 아니라 실제 업무를 수행하는 팀이 문제를 해결하고 의사결정에 참여합니다.

12. 정기적으로 돌아보고 개선한다

프로젝트가 끝난 후에만 문제점을 분석하는 것이 아니라 일정한 주기로 팀의 업무 방식을 돌아보고 개선합니다.

이것이 애자일의 회고(Retrospective)와 연결되는 중요한 원칙입니다.

그렇다면 SI 프로젝트에도 애자일이 가능할까?

여기서 한 가지 현실적인 문제가 있습니다.

SI 프로젝트는 일반적인 스타트업이나 제품 개발과 환경이 상당히 다릅니다.

예를 들어 SI 프로젝트에서는 다음과 같은 상황이 흔합니다.

• 계약 기간과 종료일이 정해져 있다.

• 고객사가 별도로 존재한다.

• 제안서와 계약서에 개발 범위가 명시되어 있다.

• 분석/설계/개발/테스트 등의 단계가 존재한다.

• 수많은 산출물을 제출해야 한다.

• 고객의 요구사항 변경에는 추가 비용이나 일정 변경이 필요할 수 있다.

• 여러 협력업체가 하나의 프로젝트에 참여한다.

따라서 SI 프로젝트에 애자일을 적용한다고 해서 기존의 프로젝트 관리 체계를 모두 없애고 “오늘부터 Scrum으로 하겠습니다”라고 하는 것은 현실적이지 않습니다.

오히려 SI에서는 애자일의 철학과 일부 실천 방법을 기존 프로젝트 관리 방식에 접목하는 방식이 현실적입니다.

SI 프로젝트에 적용하기 좋은 애자일 방법

① Scrum

가장 대표적인 방법이 Scrum입니다.

Scrum은 경험주의를 기반으로 하며, 복잡한 문제를 한 번에 완벽하게 계획하기보다 실제 결과를 확인하고, 점검하고, 그 결과에 따라 다음 행동을 조정하는 방식입니다.

Scrum의 경험주의는 크게 세 가지로 설명할 수 있습니다.

투명성 → 점검 → 적응

즉,

무엇을 하고 있는지 보이게 만들고
→ 실제 결과를 확인하고
→ 결과에 따라 계획과 방법을 수정한다.

는 구조입니다.

SI 프로젝트에서는 어떻게 적용할까?

예를 들어 6개월짜리 프로젝트가 있다고 가정해보겠습니다.

기존 방식이라면

요구사항 분석
↓
전체 설계
↓
전체 개발
↓
통합 테스트
↓
사용자 테스트
↓
오픈

이라는 방식으로 진행할 수 있습니다.

이 경우 개발 초기에 정의한 요구사항이 실제 사용자에게 적합한지 상당히 늦게 확인될 수 있습니다.

Scrum 방식을 일부 적용한다면 이를 작은 단위로 나눕니다.

예를 들어 2주를 하나의 Sprint로 설정합니다.

Sprint 1

회원가입 + 로그인

Sprint 2

회원정보 조회 + 수정

Sprint 3

상품 조회

Sprint 4

주문

Sprint 5

결제

이렇게 개발하고 각 Sprint가 끝날 때마다 실제 동작하는 결과물을 고객 또는 현업 담당자에게 보여줍니다.

그러면 고객은

“생각했던 화면과 조금 다른데요?”

라고 말할 수 있습니다.

바로 이 시점에서 수정합니다.

프로젝트 후반부에 발견하는 것보다 훨씬 저렴한 비용으로 수정할 수 있습니다.

② 경험주의(Empiricism)를 SI 프로젝트에 적용하기

개인적으로 SI 프로젝트에서 가장 중요한 애자일 개념 중 하나가 경험주의라고 생각합니다.

경험주의란 간단하게 말하면

계획이나 추측만 믿지 말고 실제 경험과 관찰을 통해 판단하자

는 것입니다.

Scrum에서도 복잡한 업무는 사전에 모든 것을 완벽하게 예측하기 어렵기 때문에 실제 결과를 관찰하고 그 결과를 바탕으로 다음 행동을 결정하는 방식을 사용합니다.

예를 들어 고객이 다음과 같이 요구했다고 가정해보겠습니다.

“사용자가 쉽게 사용할 수 있는 주문 화면을 만들어 주세요.”

문서만 가지고 개발하면 개발자는 ’쉽게’라는 말을 각자 다르게 해석할 수 있습니다.

하지만 실제 화면을 하나 만들어 사용자에게 보여주면 이야기가 달라집니다.

사용자가 직접 사용해 보고

“이 버튼은 잘 안 보입니다.”

“이 단계는 굳이 필요 없는 것 같습니다.”

“모바일에서는 이렇게 사용하는 것이 더 편합니다.”

라고 이야기할 수 있습니다.

이것이 바로 경험 → 관찰 → 피드백 → 개선입니다.

SI 프로젝트에서 경험주의를 적용한다는 것은 결국

문서로만 요구사항을 확정하지 않고 가능한 한 빨리 실제 결과물을 만들어 확인하는 것

이라고 볼 수 있습니다.

③ 페어워크(Pair Work)를 활용한다

애자일 개발에서 활용할 수 있는 또 하나의 방법이 페어 프로그래밍(Pair Programming)입니다.

두 명의 개발자가 하나의 작업을 함께 수행하는 방식입니다.

한 명이 코드를 작성하고 다른 한 명이 이를 실시간으로 검토하면서 함께 개발합니다.

물론 SI 프로젝트에서 모든 개발 업무를 항상 페어로 진행할 필요는 없습니다.

오히려 인력과 비용 측면에서 비효율적일 수 있습니다.

따라서 중요하거나 위험도가 높은 업무에 선택적으로 적용하는 방식이 현실적입니다.

예를 들어 다음과 같은 업무입니다.

• 핵심 업무 로직

• 결제 모듈

• 보안 관련 기능

• 복잡한 SQL

• 대규모 데이터 변환

• 공통 프레임워크

• 장애 가능성이 높은 기능

• 경험이 부족한 개발자의 핵심 기능 개발

예를 들어 개발자 A가 결제 모듈을 개발하고 개발자 B가 나중에 코드 리뷰를 하는 기존 방식 대신,

A + B가 처음부터 함께 설계하고 개발하는 것입니다.

이렇게 하면 지식이 특정 개발자 한 명에게 집중되는 것을 줄일 수 있습니다.

④ 데일리 미팅을 짧게 운영한다

SI 프로젝트에서 애자일을 적용할 때 가장 쉽게 시작할 수 있는 것이 Daily Scrum입니다.

다만 여기서 주의해야 할 것이 있습니다.

데일리 미팅이 팀장의 업무 보고 시간이 되어서는 안 됩니다.

좋은 데일리 미팅은

“어제 무엇을 했습니까?”

“오늘 무엇을 할 겁니까?”

만 반복하는 회의가 아닙니다.

핵심은 Sprint Goal을 향해 진행되고 있는지 확인하고 필요한 경우 계획을 조정하는 것입니다.

예를 들어 개발자가

“API 개발이 80% 정도 됐습니다.”

라고 보고하는 것보다,

“A 화면과 B 화면은 완료됐는데 C API에서 외부 시스템 연동 문제가 발생했습니다. 이 문제가 해결되지 않으면 이번 Sprint의 결제 기능 완료가 어렵습니다.”

라고 공유하는 것이 훨씬 유용합니다.

즉, 데일리 미팅은 보고회가 아니라 문제를 조기에 발견하는 자리가 되어야 합니다.

⑤ Sprint Review를 고객과 함께한다

SI 프로젝트에서 특히 중요한 부분입니다.

Sprint가 끝날 때 개발팀 내부에서만 결과물을 확인하지 말고 가능하면 고객 또는 현업 담당자에게 실제 동작하는 시스템을 보여주는 것입니다.

예를 들어

“회원 관리 기능 개발 완료”

라고 문서로 보고하는 것이 아니라,

실제 시스템에서

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

을 직접 시연합니다.

그리고 고객에게 묻습니다.

“실제 업무에서 이 화면을 사용한다고 생각했을 때 불편한 부분이 있습니까?”

이렇게 하면 요구사항과 실제 업무 사이의 차이를 빠르게 발견할 수 있습니다.

⑥ Retrospective, 즉 회고를 한다

애자일에서 또 하나 중요한 것이 회고(Retrospective)입니다.

Sprint가 끝날 때 팀이 함께 질문합니다.

잘된 것은 무엇인가?

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

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

예를 들어 첫 번째 Sprint에서

개발 환경 구축에 3일이 걸렸다.

면 다음 Sprint에서는

공통 개발 환경을 미리 템플릿화한다.

라는 개선 사항을 정할 수 있습니다.

중요한 것은 회고가 단순한 반성회가 되어서는 안 된다는 것입니다.

“누가 잘못했는가?”가 아니라 “다음에는 어떻게 하면 더 잘할 수 있는가?”를 이야기해야 합니다.

애자일의 12번째 원칙도 일정한 주기로 팀이 자신의 업무 방식을 돌아보고 더 효과적인 방법으로 조정할 것을 강조합니다.

SI 프로젝트에 적용한다면 이렇게 조합할 수 있다

결국 SI 프로젝트에서 애자일을 적용하는 현실적인 방법은 다음과 같이 정리할 수 있습니다.

애자일 방법	SI 프로젝트 적용
Scrum	2~3주 단위 Sprint 운영
경험주의	실제 결과물을 빠르게 만들어 검증
Daily Scrum	짧은 진행 상황 및 장애 요인 공유
Sprint Review	고객·현업에게 실제 기능 시연
Retrospective	Sprint 종료 후 업무 방식 개선
Pair Work	핵심·고난도 업무에 선택적으로 적용
Backlog	요구사항을 우선순위별로 관리
Increment	매 Sprint마다 동작하는 결과물 확보
Self-Organizing Team	개발팀이 세부 작업 방법을 스스로 결정

애자일 SI 프로젝트의 핵심은 ‘애자일하게 생각하는 것’

SI 프로젝트에 애자일을 적용한다고 해서 반드시 모든 프로젝트를 Scrum으로 운영해야 하는 것은 아닙니다.

오히려 중요한 것은 애자일의 사고방식을 프로젝트에 적용하는 것입니다.

예를 들어 다음과 같은 차이가 있습니다.

전통적인 방식

“요구사항을 먼저 완벽하게 확정한 뒤 개발한다.”

애자일 방식

“가능한 한 빨리 만들어 보고 실제 결과를 통해 요구사항을 구체화한다.”

전통적인 방식

“일정이 변경되면 프로젝트가 실패한 것이다.”

애자일 방식

“변경이 발생했다면 우선순위를 조정해서 더 가치 있는 결과를 만드는 방법을 찾는다.”

전통적인 방식

“개발자가 작업을 완료했는지가 중요하다.”

애자일 방식

“사용자가 실제로 사용할 수 있는 기능이 만들어졌는지가 중요하다.”

마무리

애자일은 단순히 Scrum을 도입하거나 Jira에 Backlog를 만드는 프로젝트 관리 기법이 아닙니다.

핵심은 다음 네 가지로 요약할 수 있습니다.

빠르게 만들고

↓

실제로 확인하고

↓

고객의 피드백을 받고

↓

다음 개발에 반영한다.

그리고 이 과정을 반복하면서 프로젝트가 조금씩 더 좋은 방향으로 나아가도록 만드는 것입니다.

특히 SI 프로젝트에서는 계약, 일정, 산출물, 고객사 등 여러 가지 제약 때문에 애자일의 모든 요소를 그대로 적용하기 어렵습니다.

따라서 현실적인 접근은 SI의 기존 관리 체계를 유지하면서 Scrum, 경험주의, 짧은 개발 주기, 고객 피드백, 회고, 페어워크와 같은 애자일 실천 방법을 필요한 부분부터 선택적으로 적용하는 것입니다.

결국 애자일의 핵심 질문은

“처음에 세운 계획을 얼마나 잘 지켰는가?”

가 아니라,

“프로젝트가 진행되는 동안 우리가 얼마나 빨리 배우고, 변화하고, 고객에게 가치를 전달했는가?”

에 있다고 할 수 있습니다.

Luke