변경을 주저하는 개발자에게

2018년, '애자일', '리팩터링'이라는 용어가 이미 익숙한 용어였던 시기에 개발을 시작했습니다. 얼마 지나지 않아 '애자일', '리팩터링'의 정의와 개발자들이 말하는 뉘앙스가 차이가 있다는 것을 알게 되었고, 오히려 '애자일'과 '리팩터링'을 개발자들에게 유리한(?) 방향으로 왜곡하여 사용하는 모습들도 목격하기도 했습니다. 소프트웨어 산업의 가장 중요한 특성이자 특징 중에 하나인 '변화'에 초점을 맞춰 '애자일'과 '리팩터링'의 본질을 책 '리팩터링'의 2장의 주장을 곁들여 서술해봅니다.

 

변화(변경)에 주저하는 당신(개발자)에게

 

과거의 개발 프로세스와 현대 SW 의 특성인 변화

책 [리팩터링] 에서는 완벽한 설계 이후에 코딩(구현)을 하는 방식은 20년 전의 방식이라고 말합니다. 책의 쓰여진 연도(2000년대 초반)를 고려하면 지금부터 약 40년 전 이야기라고 볼 수 있죠. IT 업계는 지속적인 변화에 대응하며 발전해왔습니다. CI/CD, TDD, semver, 엘라스틱 등의 용어가 대변하듯이, SW 업계는 불확실한 미래에 대응하기 위한 적합한 솔루션을 제안하고 시장은 이를 수용해왔습니다. 변화에 유연히 대응했던 프로덕트들만이 살아남았습니다.

 

SW 의 본질적인 속성이 ‘변화’라는 점을 강조하고 싶습니다. 요구사항의 변경은 자주 있는 일이며, 기존 코드에 변화를 가하는 요구는 프로덕트의 생존을 위해 받아들여져야 합니다. 리팩터링은 그러한 맥락 위에서 제안되었습니다. 리팩터링의 정의는 다음과 같습니다.

소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법

(2.1. 리팩터링의 정의)

 

 

리팩터링의 목표

그렇다면 코드는 왜 이해하기 쉽고 수정하기 쉬워야 할까요? 변화에 대응하여 빠르게 요구사항을 프로덕트에 반영하기 위해서입니다. 이것이 리팩토링을 하는 궁극적인 목적이어야 합니다.

소프트웨어 개발자는 프로다. 프로 개발자의 역할은 효과적인 소프트웨어를 최대한 빨리 만드는 것이다. (…중략) 프로 개발자에게 주어진 임무는 새로운 기능을 빠르게 구현하는 것이고, 가장 빠른 방법은 리팩터링이다. 그래서 리팩터링부터 한다.

(2.4. 언제 리팩터링해야 할까?)

이터레이션 기반 개발 프로세스와 리팩터링의 관계

여기서 요구사항의 변경을 얼마나 자주 감지해야 할까요? 아마, 고객은 하루에도 수십번씩 요구사항을 변경하고 싶을 겁니다. 그렇지만, 보통 개발팀은 그 반대입니다. 이에 대해 나름의 균형 잡힌 기준을 잡아준 방법론이 애자일, XP 이며 이를 구체화한 프레임워크가 스크럼입니다. 보통 2주를 반복 주기로 하는 프로세스를 제안하죠(스프린트). 이 기간은 요구사항이 변경되는 주기라고 봐도 무방합니다. 스프린트 리뷰 시간에 고객의 의견을 들으라는 것이 스크럼의 기조입니다. CEO(또는 사장, 또는 고객)의 변덕에 따라 날마다 프로덕트를 변경하고 싶은 욕구도 억제해줍니다.

스프린트 리뷰 동안 스크럼 팀과 이해관계자는 이번 스프린트에 성취한 것과 그동안 비즈니스 환경에서 변한 것이 무엇인지를 검토한다. 이 정보에 기초하여 참여자들은 다음으로 무엇을 할 것인지 협력하여 논의한다.

(2020 스크럼 가이드)

 

그렇기 때문에 작고 명확한 기획과 그에 대한 구현 그리고 이에 대한 피드백이 번갈아 빈번히 일어나도록 주기적인 이터레이션 기반의 개발 프로세스가 필요합니다. 이것은 리팩터링이 이루고자 하는 목표와 방향을 같이 합니다.

책 [리팩터링] 주요 본문 인용

요구사항 변경에도 기존 코드의 설계를 개선할 수 있는 기반

20년 전만 해도 설계를 잘하려면 코딩을 시작하기 전에 설계부터 완벽히 마쳐야 한다는 것이 정설이었다. 코딩 단계에 한번 들어서면 코드가 부패할 일만 남았기 때문이다. 한편 리팩터링을 하면 기존 코드의 설계를 얼마든지 개선할 수 있으므로, 설령 프로그램 요구사항이 바뀌더라도 설계를 지속해서 개선할 수 있다. 처음부터 좋은 설계를 마련하기란 매우 어렵다. 그래서 빠른 개발이라는 숭고한 목표를 달성하려면 리팩터링이 반드시 필요하다.

[2.3 리팩터링 하는 이유] 중

정말로 원하는 걸 알게 되는 시점

코딩 전에 아키텍처를 확정지으려 할 때의 대표적인 문제는 소프트웨어 요구사항을 사전에 모두 파악해야 한다는 것이다. 하지만 막상 우리는 소프트웨어를 실제로 사용해보고 업무에 미치는 영향을 직접 확인하고 나서야 정말로 원하는 바를 알게 되는 경우가 허다하다. 한 가지 방법은 향후 변경에 유연하게 대처할 수 있는 유연성 메커니즘을 소프트웨어에 심어두는 것이다. 물론 메커니즘들이 대개 그렇듯 치러야 할 비용이 있다. 당장의 쓰임에 비해 함수가 너무 복잡해지며 간혹 유연성 메커니즘을 잘못 구현할 때도 있다. 요구사항이 당초 예상과 다르게 바뀌기 때문일 수도 있고, 설계한 메커니즘 자체에 결함이 있어서일 때도 있다. 이 모든 상황을 고려하다 보면 유연성 메커니즘이 오히려 변화에 대응하는 능력을 떨어뜨릴 때가 대부분이다.

[2.6 리팩터링, 아키텍처, 애그니(YAGNI)] 중

이름만 애자일

하지만 현재 '애자일'을 내세우는 프로젝트 중에는 이름만 애자일인 경우가 대부분이다. 애자일을 제대로 적용하려면 리팩터링에 대한 팀의 역량과 열정이 뒷받침되어 프로세스 전반에 리팩터링이 자연스럽게 스며들도록 해야 한다.

[2.7 리팩터링과 소프트웨어 개발 프로세스] 중

리팩터링과 잦은 이터레이션 (ft. 지속적 통합)

팀으로 개발하면서 리팩터링을 하려면 각 팀원이 다른 사람의 작업을 방해하지 않으면서 언제든지 리팩터링할 수 있어야 한다. 지속적 통합을 적극 권장하는 이유도 바로 이 때문이다. 지속적 통합을 적용하면 각자가 수행한 리팩터링 결과를 빠르게 동료와 공유할 수 있다. 리팩터링한 결과가 다른 팀원의 작업에 문제를 일으키면 즉시 알아낼 수 있다. 자가 테스트 코드 역시 지속적 통합의 핵심 요소다. 따라서 자가 테스트 코드, 지속적 통합, 리팩터링이라는 세 기법은 서로 강력한 상승효과를 발휘한다.

[2.7 리팩터링과 소프트웨어 개발 프로세스] 중

참조 링크

리팩터링 2장 본문: https://slog2.tistory.com/40

스크럼 가이드: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Korean.pdf

리팩터링 관점에서 이터레이션 기반 개발 프로세스의 필요성