아날로그 리팩터링 게임 테이블: 레거시 코드 변경을 협력 전략 세션으로 바꾸기

레거시 리팩터링은 평판이 좋지 않습니다. 위험하고, 소모적이고, 정치적이며, 비용이 많이 드는 일로 여겨집니다. 팀은 종종 두 가지 나쁜 선택지 사이에서 고민합니다. 이 지저분한 상태를 그냥 안고 가거나, 출시될지조차 모를 대규모 리라이트에 로드맵 전체를 걸거나.

여기에는 세 번째 옵션이 있습니다. 바로 리팩터링을 협력형 테이블탑 전략 게임으로 바꾸는 것입니다.

화면에서 벗어나 물리적(또는 가상) 테이블 위에서 이야기를 나누면, 레거시 변경 작업을 더 이해하기 쉽고, 더 포용적이며, 더 저위험으로 만들 수 있습니다. 이 글에서는 팀이 함께 안전한 점진적 리팩터링을 설계하고 연습할 수 있도록 돕는 구조화된 워크숍 포맷인 **아날로그 리팩터링 게임 테이블(Analog Refactor Game Table)**을 소개합니다.

이 글에서 다룰 내용:

리팩터링을 위한 아날로그 “게임”을 세팅하는 방법
이 포맷이 협업을 개선하고 사용자를 중심에 두는 이유
리라이트 대신 점진적 리팩터링으로 접근하는 방법
안전한 변경을 이끄는 역(逆) 테스트 피라미드 활용법
“새 플레이북을 반복 연습”하여 리팩터링을 일상적인 저부채 관행으로 만드는 법
팀의 자신감이 쌓일수록 자율성을 점진적으로 회복하는 방법

왜 리팩터링을 ‘게임’으로 만들어야 할까?

대부분의 레거시 작업이 실패하는 이유는 순수하게 기술적인 문제라기보다, 사회적·커뮤니케이션 문제인 경우가 많습니다. 사람들은 무언가를 망가뜨리는 것, 통제권을 잃는 것, 프로덕션 장애가 나면 비난받는 것을 두려워합니다.

게임 테이블은 이 역학을 바꿉니다.

생각을 일부러 느리게 만듭니다. IDE에서 잠시 벗어나, 코드 줄이 아니라 플로우, 행동, 리스크 단위로 생각하게 됩니다.
더 많은 목소리를 끌어들입니다. 산출물이 클래스 다이어그램이 아니라 포스트잇, 사용자 여정, 시나리오이기 때문에 디자이너, PM, 운영 담당자도 자연스럽게 참여할 수 있습니다.
리팩터링을 영웅담이 아닌 전략 수립으로 프레이밍합니다. “레거시를 깨끗이 치운다”가 아니라, 모두가 함께 안전한 수들을 설계하는 과정이 됩니다.

“이거 누가 책임져요?” 대신, “우리의 다음 안전하고 되돌릴 수 있는 수는 무엇인가요?”가 초점이 됩니다.

아날로그 리팩터링 게임 테이블 세팅하기

이 워크숍은 오프라인에서는 포스트잇, 마커, 큰 테이블을 이용해 진행할 수 있고, 온라인에서는 화이트보드 툴로 진행할 수 있습니다. 핵심은 만질 수 있는 단계와 눈에 보이는 플로우입니다.

1. 사용자 중심 미션 정의하기

시작은 ‘코드 순수성’이 아니라, 사용자 혹은 이해관계자와 직접 연결된 구체적인 목표에서 출발합니다.

“결제 코드 구조를 단순화하면서 체크아웃 오류를 50% 줄인다.”

이 미션을 보드 맨 위에 크게 적어 둡니다. 이렇게 해야 세션이 “다 그냥 깨끗이 고치자”는 식의 막연한 성전이 되는 것을 막을 수 있습니다.

2. 현재 플로우 맵 그리기

테이블이나 보드의 왼쪽에는 시스템이 현재 어떻게 동작하는지 맵을 그립니다.

사용자 액션 (예: “결제 버튼 클릭”)
주요 시스템 단계 (예: “세금 계산”, “PG사 API 호출”, “결과 로그 기록”)
알려진 문제 지점 (예: “불안정한 외부 연동”, “중복된 계산 로직”)

각 항목은 카드나 포스트잇으로 표현합니다. 이것이 바로 **현재 현실 맵(current reality map)**입니다.

3. 목표 행동 스케치하기

오른쪽에는 목표 행동을 스케치합니다. 새로운 풀 아키텍처를 설계하자는 게 아닙니다. “무엇이 더 나은 상태인가?”를 설명할 수 있을 만큼만 그리면 됩니다.

더 명확한 경계 (예: “PaymentService가 PG사 연동을 전담”)
예외 케이스 감소
더 나은 관측 가능성(Observability)이나 에러 핸들링

여기서도 UML 같은 형식 대신 카드와 일상적인 표현을 씁니다. 같은 사용자 액션에 대해 시스템이 어떻게 반응했으면 좋겠는지를 설명하는 겁니다.

4. 점진적 ‘수(move)’ 설계하기

이제부터가 본격적인 게임입니다.

가운데 영역에는 현재에서 목표로 이동하기 위한 수(move), 즉 개별 리팩터링 단계를 순서대로 만들며 채웁니다. 예를 들면:

“새 PaymentGatewayAdapter를 도입한다. 기존 코드에서만 호출하고, 동작은 그대로 유지한다(behavior change 없음).”
“PG사 타임아웃 주변에 로깅을 추가한다.”
“위험도가 낮은 특정 플로우 하나만 어댑터를 사용하도록 전환하고, 롤백을 위한 기능 플래그(feature flag)를 둔다.”

각 수는 카드 하나에 다음 정보와 함께 적습니다.

변경 설명
사용자·이해관계자에게 예상되는 영향
위험도(낮음/중간/높음)
검증 방법 (테스트, 메트릭, 수동 점검 등)

이렇게 하면 팀이 함께 공유하는 안전하고 되돌릴 수 있는 플레이북이 만들어집니다.

설계 자체가 크로스펑셔널 협업을 유도한다

아날로그 포맷은 다음과 같은 다양한 역할이 자연스럽게 참여하도록 돕습니다.

개발자: 코드 레벨 수들을 구체화하고 리스크를 판단
QA / 테스터: 각 수가 어떻게 검증될지 정의
프로덕트 매니저(PM): 변경이 비즈니스 목표와 정렬되는지 확인
디자이너 / UX: 사용자 플로우가 여전히 자연스러운지 점검
Ops / SRE: 관측·모니터링·배포 제약 사항을 짚어냄

산출물이 자연어 카드와 플로우 중심이기 때문에, 누구나 의견을 낼 수 있습니다. 엔지니어들이 몇 주간 사라졌다가 거대한 리팩터링 결과물을 들고 오는 대신, 모든 트레이드오프가 눈에 보이고 공개적으로 논의됩니다.

이렇게 하면 작업 전체가 사용자와 이해관계자 중심으로 유지됩니다. 각 수는 코드 우아함이 아니라, 안정성·가독성·가치 향상에 어떻게 기여하는지로 정당화됩니다.

리팩터링을 지속적이고 저부채인 실천으로 만들기

게임 테이블은 이런 마인드셋 전환을 돕습니다.

리팩터링은 일회성 프로젝트가 아니라, 여유 시간에 꾸준히 연습하는 습관이다.

거대한 “Q3에 리팩터링 대장정” 같은 이니셔티브를 잡는 대신, 다음과 같이 접근합니다.

기능 작업 옆에 리팩터링 수 카드 백로그를 항상 둔다.
슬랙 타임, 버그 수정, 관련 코드 작업 중간중간에 작고 안전한 단계를 하나씩 끌어와 처리한다.
게임 테이블을 주기적으로(예: 스프린트마다 한 번) 다시 열어, 수들의 우선순위를 조정하고 플랜을 업데이트한다.

이렇게 하면 기술 부채가 한 번에 폭발하는 대신 항상 조금씩 줄어들고 이동합니다. 결국 “위험한 리라이트 말고는 답이 없다”는 상황으로 몰리지 않게 됩니다.

빅뱅 리라이트 대신 점진적으로 변경 도입하기

핵심 원칙은 거대한 도약 금지입니다.

게임 테이블 위에서 우리가 찾는 수는 대략 다음 세 가지 유형입니다.

행동 보존형(behavior-preserving) 수: 엄밀한 의미의 리팩터링, 겉보기 동작은 그대로 유지
가산형(additive) 수: 기존 경로를 유지한 채 새로운 경로나 추상화를 추가만 하는 단계
되돌릴 수 있는(reversible) 수: 기능 플래그나 설정 스위치 뒤에 숨겨 두어 쉽게 롤백 가능

예를 들면:

기존 엔드포인트를 남겨둔 채 새 API 엔드포인트를 추가하고, 클라이언트를 하나씩 점진적으로 옮긴다.
함수를 새 모듈에 복사해 옮기고, 그쪽에 테스트를 만든 다음, 호출 경로를 하나씩 새 구현으로 바꾼다.
새 설정 기반(rule-based) 룰 시스템을 도입하되, 기존 하드코딩 룰도 동시에 존중하도록 두 체계를 병행 운영한다.

각 단계가 카드로 명시되고 사전에 논의되기 때문에, 저항과 두려움이 줄어듭니다. 이해관계자들은 로드맵을 눈으로 확인하고, 어떤 리스크가 있는지 이해한 뒤, 범위를 조금씩 승인할 수 있습니다.

리팩터링을 안내하는 ‘역(逆) 테스트 피라미드’ 활용하기

전통적인 테스트 조언은 테스트 피라미드를 강조합니다. 유닛 테스트는 많고, 통합 테스트는 적고, E2E 테스트는 더 적게 가져가라는 방식입니다.

그러나 레거시 리팩터링에서는, 적어도 초기에는 그 반대에 가까운 **역(逆) 테스트 피라미드(reversed test pyramid)**가 필요할 때가 많습니다.

상위 레벨 테스트부터 시작하기

코드를 건드리기 전에 다음을 수행합니다.

변경 예정 플로우를 중심으로 엔드투엔드(E2E) 또는 저니(journey) 테스트를 정의합니다.
현재 동작(설령 불완전하더라도)을 테스트에 캡처합니다.

이 테스트들은 다음과 같은 역할을 합니다.

치명적인 회귀(regression)를 막는 안전망 역할
내부 구조를 재배치해도 괜찮다는 자신감 제공
유닛 경계가 불분명한 레거시 시스템에서도 비교적 쉽게 작성 가능

이 상위 레벨 안전망을 마련한 뒤에야 더 세밀한 테스트들을 추가해 나갑니다.

이후 통합 테스트와 유닛 테스트를 점진적으로 추가하기

리팩터링 수를 밟으면서 경계가 점점 명확해지면, 그때부터 다음을 추가합니다.

새 컴포넌트나 서비스에 대한 통합 테스트
고립되고 안정된 로직에 대한 유닛 테스트

시간이 지날수록 해당 코드 영역의 테스트 피라미드는 자연스럽게 “정상적인” 모양으로 돌아옵니다. 다만 초기에는 상위 레벨 테스트가 점진적 리팩터를 이끌고 검증하는 역할을 하는 셈입니다.

테스트 커버리지는 보드에도 표현할 수 있습니다.

각 수 카드에 태그를 붙여, 어떤 저니 테스트·통합 테스트가 그 단계를 보호하는지 나타냅니다.

새 플레이북을 몸에 익히기: 아날로그 게임 재실행

첫 번째 게임 세션은 초기 플레이북을 만들어 줍니다. 하지만 진짜 힘은 우리가 배우는 내용을 바탕으로 게임을 반복 실행할 때 나옵니다.

몇 가지 수를 실제로 배포한 뒤에는:

최근에 수행한 수를 다시 되짚어 봅니다. 계획했던 것과 실제로 일어난 일을 비교해 봅니다.
카드를 업데이트합니다. 새로운 패턴, 더 나은 수, 배운 교훈을 반영합니다.
수열을 다듬습니다. 더 이상 의미 없는 수는 폐기하고, 새로 필요한 수를 추가합니다.

스포츠 팀이 플레이북을 몸에 익히기 위해 반복 훈련을 하는 것과 비슷합니다. 시간이 지나면 패턴이 근육 기억처럼 굳어집니다.

“레거시 엔드포인트를 건드릴 땐, 먼저 어댑터와 상위 레벨 테스트로 감싼다.”
“컴포넌트를 대체할 땐 항상 기능 플래그 뒤에 병행 경로를 먼저 깐다.”

게임을 반복할수록 거창한 워크숍이 필요 없어집니다. **좋은 리팩터링 관행이 곧 ‘우리의 기본 작업 방식’**이 되는 것입니다.

자신감이 쌓일수록 자율성 회복하기

초기에는 신뢰를 쌓기 위해 강한 퍼실리테이션과 구조화된 세션이 필요할 수 있습니다. 사람들은 안전장치를 원합니다.

하지만 팀의 경험과 자신감이 쌓이면:

제약을 조금씩 완화합니다. 각 팀이 로컬 변경에 맞는 수 카드를 스스로 설계하게 합니다.
퍼실리테이션을 분산합니다. 아날로그 세션 진행자를 돌아가며 맡게 합니다.
실험을 장려합니다. 팀 상황에 맞게 포맷을 변형하고 개선하도록 유도합니다.

궁극적인 목표는 영원한 의식을 만드는 게 아니라, 더 나은 습관과 함께 자율성을 되돌려 주는 것입니다.

엔지니어는 혼자서도 안전한 점진적 리팩터링을 시도할 수 있습니다.
프로덕트와 디자인은 변경이 항상 점진적이고 검증을 거친다는 신뢰를 갖게 됩니다.
리더십은 “쌓였다 폭발하는 부채와 비상 리라이트” 대신, 지속적인 개선 흐름을 보게 됩니다.

결론: 레거시 작업을 ‘플레이’ 가능하게 만들기

레거시 시스템은 단순한 옛 코드 더미가 아니라, 제품과 조직의 살아 있는 역사입니다. 이를 “태워 없애고 새로 짓자”는 식으로만 보는 건 대부분 현실적이지 않습니다.

아날로그 리팩터링 게임 테이블은 레거시 작업을 협력 전략 문제로 다시 프레이밍합니다.

함께 현실을 맵으로 그리고,
작고 안전한 수를 설계하며,
먼저 상위 레벨 테스트로 스스로를 보호하고,
이 플레이북을 반복 연습해 문화의 일부로 만듭니다.

리팩터링이 영웅적인 이벤트가 아니라 반복 가능한 저부채 실천이 되는 순간, 팀은 회사의 운명을 리라이트에 걸지 않고도 시스템을 계속 진화시킬 수 있습니다.

그리고 무엇보다 중요한 한 가지: 많은 팀에 불안의 근원인 레거시 변경 작업을, 이해 가능하고 협력적이며, 심지어 약간은 재미있는 일로 바꿀 수 있습니다.