[Software Engineering] 애자일(Agile) 스크럼 기초: PO, SM, 개발팀의 명확한 실무 R&R

이전 포스팅([Software Enginnering] 애자일 선언문과 12가지 원칙)에서 강조했듯, 지라(Jira)를 쓰고 스프린트를 도입한다고 해서 곧바로 애자일 팀이 되는 것은 아니다. 시스템 구조가 바뀌려면 근본적으로 팀원들이 일하고 협업하는 구조(R&R)가 먼저 변해야 한다.

 

잦은 요구사항 변경을 전제로 하는 애자일 환경에서 전통적인 수직적 역할 분담은 병목만 유발한다. 이번 포스팅에서는 애자일의 대표적인 프레임워크인 스크럼(Scrum)의 3가지 핵심 역할과, 비즈니스 담당자와의 올바른 협업이 실제 코드와 아키텍처에 어떤 영향을 미치는지 살펴본다.

 

1. 스크럼의 3가지 핵심 역할 (Roles)

스크럼은 복잡한 문제를 해결하기 위해 고안된 경량 프레임워크다. 스크럼 팀에는 지시를 내리는 팀장이나 전통적인 PM이 존재하지 않으며, 역할과 권한이 명확히 분산되어 상호 견제와 균형을 이룬다.

 

프로덕트 오너(Product Owner, PO)

 - 핵심 역할: 무엇을 만들 것인가를 결정한다.

 - 프로덕트의 비즈니스 가치를 극대화하는 책임을 지며, 요구사항이 담긴 프로덕트 백로그(Product Backlog)의 유일한 관리자다.

 - 개발팀에게 우선순위가 높은 비즈니스 목표를 제시하지만, 그것을 어떻게 기술적으로 구현할지, 일정을 얼마나 잡을지에 대해서는 지시할 권한이 없다.

 

스크럼 마스터(Scrum Master, SM)

 - 핵심 역할: 팀이 스크럼 원칙을 잘 지키도록 돕는 서번트 리더(Servant Leader)이자 촉진자다.

 - 팀의 개발 속도를 저해하는 외부의 방해 요소를 차단하고, 매끄러운 커뮤니케이션 환경을 조성한다. 관리하는 것이 아니라 코칭하는 역할이다.

 

개발팀(Developers)

 - 핵심 역할: 어떻게 만들 것인가를 결정한다.

 - 기획, 디자인, 프론트엔드, 백엔드 등 프로덕트를 실제로 구동하게 만드는 모든 작업자를 포함한다.

 - PO가 제시한 목표를 달성하기 위한 기술적 아키텍처, 코드 품질, 데이터베이스 설계 등에 대한 절대적인 권한과 책임을 가진다. 스스로 작업량을 추정(Estimate)하고 일정을 계획한다.

 

2. 전통적 PM vs 스크럼

기존의 PM은 일정과 리소스 관리에 초점을 맞추는 탑다운 방식이 흔했다. 반면, 애자일 스크럼에서는 각자의 전문성을 바탕으로 권한이 분리된다.

 

 - PO: "비즈니스적으로 A 기능이 가장 시급하고 가치가 높습니다."

 - 개발팀: "A 기능을 안정적으로 구현하려면 레거시 테이블 분리를 포함해 1 스프린트(2주)가 필요합니다. 동시성 이슈를 막기 위해 분산 락을 적용하겠습니다."

 - SM: "PO님, 개발팀이 이번 스프린트에 온전히 집중할 수 있도록 타 부서의 갑작스러운 데이터 추출 요청은 제가 막아두겠습니다."

 

3. [Bad vs Good Code] 역할 분담이 아키텍처에 미치는 영향

스크럼 환경에서 개발팀은 기획서를 단순히 코드로 번역하는 하청업체가 아니다. 개발자는 PO와 지속적으로 소통하며 비즈니스 도메인을 깊이 이해해야 한다. PO의 비즈니스 언어가 코드에 그대로 투영되어야만 요구사항 변경에 유연하게 대처할 수 있다.

 

배송 완료 후 7일 이내에만 환불이 가능하다는 PO의 요구사항을 예로 들어보자. 도메인에 대한 고민 없이 수동적으로 코딩하는 팀과, 비즈니스 규칙을 객체에 적극적으로 녹여내는 애자일 팀의 코드는 완전히 다르다.

 

[Bad Code] 수동적인 팀의 절차지향적 서비스 스크립트

도메인 지식을 서비스 계층에 if문으로 흩뿌려 놓은 상태다. PO가 7일이 아니라 14일로 늘려주시고, VVIP 회원은 30일까지 가능하게 해주세요 라고 정책변경을 요청하면, 개발자는 이 거대한 OrderSerivce를 뒤져서 로직을 뜯어고쳐야 한다.

 

@Service
@RequiredArgsConstructor
public class OrderService {
    
    private final OrderRepository orderRepository;

    // 비즈니스 룰이 서비스 로직에 절차적으로 노출되어 있음
    @Transactional
    public void processRefund(Long orderId) {
        Order order = orderRepository.findById(orderId).orElseThrow();
        
        // 데이터만 가져와서 서비스 계층에서 직접 상태와 날짜를 계산 (응집도 하락)
        if (order.getStatus() != OrderStatus.SHIPPED) {
            throw new IllegalStateException("배송 완료 상태가 아닙니다.");
        }
        
        long daysBetween = ChronoUnit.DAYS.between(order.getShippedDate(), LocalDateTime.now());
        if (daysBetween > 7) {
            throw new IllegalStateException("환불 가능 기간(7일)이 지났습니다.");
        }
        
        order.setStatus(OrderStatus.REFUNDED);
    }
}

 

[Good Code] 능동적인 애자일 팀의 도메인 주도 설계(DDD)

건강한 스크럼 팀의 개발자는 PO와 소통하여 환불 가능 여부 라는 핵심 비즈니스 규칙을 Order라는 도메인 객체 내부로 캡슐화 한다. 서비스 계층은 그저 도메인 객체에게 메시지를 던질 뿐이다. 정책이 변경되어도 Order 객체 내부만 수정하면 되므로 안전하다.

 

// 1. 핵심 비즈니스 규칙을 품고 있는 풍부한 도메인 모델 (Rich Domain Model)
@Entity
public class Order {
    @Enumerated(EnumType.STRING)
    private OrderStatus status;
    private LocalDateTime shippedDate;

    // PO와 정의한 비즈니스 언어를 메서드명과 로직으로 정확히 표현
    public void refund() {
        if (!isRefundable()) {
            throw new IllegalStateException("환불이 불가능한 주문입니다.");
        }
        this.status = OrderStatus.REFUNDED;
    }

    // 환불 정책이 변경되면 이 메서드 내부만 수정하면 됨 (OCP 준수)
    private boolean isRefundable() {
        if (this.status != OrderStatus.SHIPPED) return false;
        long daysAfterShipping = ChronoUnit.DAYS.between(this.shippedDate, LocalDateTime.now());
        return daysAfterShipping <= 7; 
    }
}

// 2. 도메인 객체를 호출하기만 하는 깔끔한 서비스 계층
@Service
@RequiredArgsConstructor
public class OrderService {
    
    private final OrderRepository orderRepository;

    @Transactional
    public void processRefund(Long orderId) {
        Order order = orderRepository.findById(orderId)
                .orElseThrow(() -> new IllegalArgumentException("주문을 찾을 수 없습니다."));
        
        // 캡슐화된 도메인 로직(비즈니스 룰)을 호출하기만 함. "환불해라!"
        order.refund(); 
    }
}

 

결국, 스크럼에서 PO와 개발팀이 밀접하게 소통해야 하는 이유는 단순히 친해지기 위해서가 아니다. 비즈니스의 복잡성을 기술적인 도메인 모델로 완벽하게 매핑하여, 향후 쏟아질 요구사항 변경에 흔들리지 않는 견고한 아키텍처를 만들기 위함이다.

 

결론

스크럼을 도입했다고 해서 갑자기 모든 문제가 마법처럼 해결되지는 않는다. 개발자가 과거 워터폴 시절처럼 PO가 시키는 대로 코드만 짰습니다 라며 수동적인 태도를 취하거나, 반대로 기획적인 영역까지 개발팀이 독단적으로 결정하려 한다면 그 팀은 무너질 수 밖에 없다.

 

 - PO의 권한을 존중하라: 어떤 기능이 사용자에게 더 큰 가치를 주는가에 대한 우선순위 결정은 전적으로 PO의 영역이다.

 - 기술의 통제권을 사수하라: 비즈니스 목표를 이루기 위한 테이블 설계 구조, 객체지향 패턴의 적용, 기술 부채를 해결하기 위한 리팩토링 일정 분배는 철저히 개발팀이 주도하고 책임져야 한다.

 

직급이나 호칭이 바뀌는 것이 애자일이 아니다. 각자의 역할과 책임에 맞게 전문가로서 권한을 행사하고 책임을 지는 구조, 그것이 진짜 폭발적인 퍼포먼스를 내는 스크럼 팀의 모습이다.