방법론과 반복 개발

반복해서 개발하기로 정한 팀도, 기능을 어떻게 나누고 무엇을 모델로 그리며 언제 검토할지는 따로 정해야 합니다. 개발에 쓰는 절차, 모델, 역할, 기법을 하나로 묶은 접근을 방법론(methodology)이라고 하며, 특정한 도구 하나나 회의의 이름을 가리키는 말이 아닙니다. 이 글에서는 분석과 설계의 대표적인 관점을 비교하고, 애자일과 스크럼의 작업 단위를 이 교재의 모임 앱에 연결한 뒤, 반복 하나를 직접 기록해 봅니다.

분석과 설계의 관점

구조적 방법(structured method)은 시스템이 하는 일을 기능 단위로 나누고, 데이터가 기능 사이를 어떻게 흘러가는지 살핍니다. 신청 입력에서 아이디 검사, 명단 변경, 결과 출력으로 이어지는 흐름을 자료 흐름도(data flow diagram)로 그려 보면 빠진 처리 단계를 찾기 쉽습니다. 정보공학(information engineering) 방법론은 업무에서 다루는 데이터와 그 관계를 중심에 두고 개발을 조직합니다. 모임, 회원, 신청의 관계를 출석이나 회비 같은 다른 업무에서도 쓴다면, 데이터의 정의를 먼저 맞추어 두는 이 관점이 도움이 됩니다.

객체 지향(object-oriented) 방법론은 상태와 책임을 가진 객체들이 서로 협력하는 모습으로 시스템을 모델링하며, 예를 들어 모임 객체가 어떤 상태 전이를 허용하는지를 묻습니다. 그렇다고 모든 함수를 클래스로 감싸는 것이 목적은 아닙니다. 컴포넌트 기반 개발(component-based development, CBD)은 제공하는 인터페이스와 필요로 하는 인터페이스가 분명한 부품을 재사용해 조립하는 방식으로, 바깥의 저장 부품을 가져다 쓴다면 오류 처리 방식, 버전, 지원 기간까지 확인해야 합니다.

이 관점들은 하나만 골라야 하는 선택지가 아닙니다. 한 앱에서도 데이터의 관계, 처리의 흐름, 모듈의 인터페이스를 서로 다른 질문에 맞추어 함께 씁니다. 이 교재에서는 유스케이스와 사용자 흐름에서 처리의 흐름을, 상태와 데이터 모델에서 데이터의 관계와 모임의 상태 전이를, 책임을 나누는 모듈에서 모듈의 인터페이스를 실제로 표현해 보았습니다.

애자일과 그 실천

애자일(agile)은 짧은 주기로 동작하는 소프트웨어를 전달하고, 고객과 협력하며, 변화에 대응하는 것을 중시하는 개발 철학입니다. 애자일 선언의 원칙에는 지속적인 전달과 정기적인 검토, 그에 따른 조정이 들어 있습니다. 이를 "문서를 쓰지 않는다"거나 "요구 변경을 끝없이 받아 준다"는 뜻으로 읽어서는 안 됩니다.

스크럼(Scrum)은 애자일을 실천하는 대표적인 프레임워크로, 목표와 백로그, 한 달 이내의 정해진 기간인 스프린트(sprint), 그리고 검토와 회고를 갖추고 있습니다. 스프린트의 기간을 정해 두더라도 끝에 실행해 볼 수 있는 결과가 없으면 피드백을 받을 수 없습니다. XP(extreme programming)는 테스트를 먼저 작성하는 개발, 변경을 자주 합치고 확인하는 지속적 통합, 두 사람이 한 화면에서 함께 작업하는 짝 프로그래밍 같은 실천을 강조하며, 이 실천들은 변경을 자주 확인하는 데 도움이 됩니다. 다만 두 사람이 키보드를 번갈아 잡는다고 검토의 질이 저절로 좋아지지는 않습니다.

이 교재에서는 간단한 반복 규칙을 씁니다. 예를 들어 반복의 목표를 "취소한 자리에 새 참가자를 받을 수 있다"로 정하고, 코드와 수락 사례, 회귀 결과, 사용 안내가 함께 준비되었을 때 완료로 봅니다. 목표를 한 번에 너무 크게 잡으면 무엇을 확인했는지가 흐려지므로, 반복 하나에는 확인할 수 있을 만큼의 목표를 둡니다. 아래 그림은 반복 하나가 목표를 정하고, 만들고 확인한 뒤, 검토에서 드러난 질문을 다음 목표로 돌려보내는 과정을 보여 줍니다.

스크럼의 용어를 작은 결과에 연결한다

스크럼 가이드는 세 가지 책임(accountability)을 나눕니다. 제품 책임자(Product Owner)는 제품의 가치를 높이도록 제품 백로그의 내용과 순서를 정하고, 개발자(Developers)는 쓸 수 있는 증분을 만들기 위해 계획과 품질, 매일의 조정을 맡으며, 스크럼 마스터(Scrum Master)는 팀이 스크럼을 이해하고 효과적으로 일하도록 돕습니다. 이 셋을 단순히 지시하는 사람, 코드를 짜는 사람, 회의를 진행하는 사람으로 바꾸어 읽지 않습니다.

스크럼의 산출물은 저마다 지향하는 목표나 기준과 짝을 이룹니다.

수락 조건은 취소라는 특정 기능의 요구를 만족했는지 판단하는 조건이고, 완료 정의(definition of done)는 모든 증분이 공통으로 갖추어야 할 품질의 상태입니다. 버튼 하나를 시연했다고 이 둘을 대신할 수는 없습니다. 스프린트 계획(sprint planning)에서는 이번 목표와 할 일, 만드는 방법을 정하고, 일일 스크럼(daily scrum)에서는 개발자들이 목표를 향한 진행 상황과 다음 행동을 조정합니다. 스프린트 리뷰(sprint review)에서는 이해관계자와 함께 결과를 살피고 다음에 무엇을 할지 의논하며, 스프린트 회고(sprint retrospective)에서는 일하는 방식을 어떻게 고칠지 정합니다.

이 글에서 다루는 한 사람의 반복 기록은 이런 질문을 연습하는 자습 도구일 뿐, 팀과 이벤트와 산출물을 모두 갖춘 스크럼을 실행한 것은 아닙니다. 팀 운영과 이벤트의 시간 제한 같은 자세한 규칙은 공식 스크럼 가이드에서 이어서 공부할 수 있습니다. 완료 정의를 만족하지 못한 작업은 쓸 수 있는 증분에 포함되었다고 표시하지 않습니다.

더 깊이: 2020년판 스크럼 가이드에서 바뀐 것

이 글의 용어는 2020년 11월에 나온 스크럼 가이드를 따릅니다. 공식 사이트의 개정 내역에 따르면 2020년판은 이전 판과 몇 가지가 다르므로, 오래된 자료를 읽을 때 주의해야 합니다. 예전에는 스크럼 팀 안에 개발 팀(Development Team)이 따로 있었는데, Product Owner와 개발 팀 사이에 '우리와 그들'처럼 나뉘는 일을 없애려고 2020년판은 팀 안의 팀을 없애고 하나의 스크럼 팀 안에 Product Owner, 개발자, 스크럼 마스터를 함께 두었습니다. 개발 팀이라는 이름 대신 개발자(Developers)라고 부르는 것이 이 때문입니다.

제품 목표(Product Goal)도 2020년판에서 처음 생겼습니다. 그와 함께 제품 백로그는 제품 목표를, 스프린트 백로그는 스프린트 목표를, 증분은 완료 정의를 각자의 약속(commitment)으로 갖게 되어, 위의 표처럼 산출물마다 짝이 정해졌습니다. 이 밖에도 일일 스크럼에서 세 가지 질문에 답하던 규정이 빠졌고, 스스로 조직하는(self-organizing) 팀 대신 누가 어떻게 무엇을 할지까지 정하는 자기 관리(self-managing) 팀을 말하며, 스프린트 계획에서 무엇을, 어떻게에 더해 왜를 다루도록 했습니다. 2026년 11월 현재 공식 사이트가 내놓은 최신판도 이 2020년판입니다.

반복 하나를 기록한다

반복 하나를 마칠 때는 다음과 같은 기록을 남깁니다. reading-lab/iteration-2.md로 만들어 봅니다.

# 반복 2: 취소와 자리 재사용

목표: 열린 모임에서 취소한 자리를 새 아이디가 쓸 수 있다.
수락 사례: min 신청, min 취소, hana 신청의 결과가 REGISTERED이다.
회귀 사례: 잘못된 아이디의 거절, 정원이 찬 모임의 중복 안내.
남은 질문: 마감 뒤 취소로 생긴 자리를 다시 열 것인가?
확인한 것: 예제 실행 결과, 진행자의 정책 확인.
다음 선택: 마감 정책을 확정한 뒤 마감 흐름을 더한다.

수락 사례는 개발 프로세스 모델의 선택에서 만든 examples/ch6-1.mjs의 둘째 증분이 그대로 확인해 줍니다. 다만 코드를 실행해 통과한 것은 자동 단언이 확인한 결과이고, 진행자가 정책을 확인한 것은 사람이 판단한 별도의 기록이므로 둘을 나누어 적습니다. 회고(retrospective)는 이번 반복에서 일하는 방식의 어디가 막혔는지 보고 다음 반복에서 고칠 작은 개선을 정하는 활동으로, 결함 목록을 훑는 회의와는 다릅니다.

정리

• 방법론은 개발의 절차, 모델, 역할, 기법을 묶은 접근이며, 구조적 방법, 정보공학, 객체 지향, 컴포넌트 기반 개발은 서로 다른 질문에 답합니다.
• 애자일은 짧은 주기의 전달과 협력, 변화에 대한 대응을 중시하며, 문서를 없애거나 끝없는 변경을 받아들이라는 뜻이 아닙니다.
• 스크럼은 세 가지 책임, 목표와 짝을 이룬 산출물, 계획과 일일 스크럼과 리뷰와 회고라는 이벤트로 이루어집니다.
• 수락 조건은 특정 기능의 요구를, 완료 정의는 모든 증분이 갖추어야 할 공통의 품질 상태를 판단합니다.
• 반복 기록에는 목표, 수락 사례, 회귀 사례, 남은 질문, 확인한 것, 다음 선택을 남기고, 자동 단언의 결과와 사람의 확인을 구분합니다.

연습 문제

1. 완료라고 할 수 있을까

취소 기능은 구현했는데, 마감된 모임에서 취소하면 화면에 "모임이 다시 열렸습니다"라는 안내가 나오고 실제 상태는 CLOSED입니다. 팀은 일정 때문에 이 작업을 완료로 처리하려 합니다. 이 상황이 수락 조건과 완료 정의 가운데 무엇과 어긋나는지, 리뷰와 회고에서 각각 무엇을 다룰지 설명하세요.

2. 수락 조건인가 완료 정의인가

다음 네 문장을 수락 조건과 완료 정의로 나누세요. ㉠ 취소하면 그 아이디만 명단에서 빠진다. ㉡ 모든 자동 테스트가 통과한다. ㉢ 바뀐 안내 문구를 진행자가 검토했다. ㉣ 마감 뒤에 취소해도 모집이 다시 열리지 않는다.

3. 질문에 맞는 관점

다음 세 질문에 가장 어울리는 분석과 설계의 관점을 고르세요. ㉠ 모임, 회원, 신청의 관계를 출석과 회비 업무에서도 함께 쓰려면 데이터를 어떻게 정의해야 할까? ㉡ 신청이 처리되는 흐름에서 빠진 단계는 없을까? ㉢ 모임의 상태 전이 규칙은 어느 객체가 지켜야 할까?

방법론을 도입할 때는 그 원칙과 필요한 산출물, 역할, 그리고 실제로 확인한 결과를 서로 연결해야 하며, 스크럼의 용어를 실제 적용 없이 이름으로만 붙이지 않습니다. 다음 장의 아키텍처와 관점에서는 시스템 전체의 구조를 여러 관점에서 나누어 보는 방법을 다룹니다.