한 팀이 아무도 제대로 이해하지 못하는 청구 모듈을 물려받았습니다. 기존 동작을 보장하는 테스트도 없습니다. "정리"를 위한 스프린트가 제안되었고, 핵심 코드를 새로운 구조로 다시 작성할 계획입니다. 하지만 새 버전이 고객에게 정확하게 요금을 청구하는지 어떻게 확인할 수 있을지 아무도 장담할 수 없습니다.
이는 예시 시나리오일 뿐, 실제로 발생한 사건은 아닙니다. 리팩토링 교육 프로젝트가 해결해야 할 과제를 보여주는 예시입니다. 즉, 코드가 지저분하다는 것은 알지만, 구체적인 개선 방안을 계획하고 동작이 유지되었음을 입증할 수는 없는 엔지니어들을 위한 것입니다.
이 가이드는 엔지니어링 지원 리더와 엔지니어링 관리자를 위한 것입니다. 성능 문제 설명, 격차 진단, 교육 준비 및 실습 설계, 사례 연구 진행, 그리고 습득한 기술이 실제 업무에 적용되는지 평가하는 방법을 다룹니다. 교육 설계에 관한 내용이며, 프로그램에 포함된 코드, 테스트 및 규칙은 해당 기술 스택에 익숙한 선임 엔지니어의 검증을 거쳐야 합니다.
리팩토링 교육 프로젝트란 무엇인가요?
리팩토링 교육 프로젝트는 레거시 코드에 대한 체계적인 작업으로, 역량 강화와 코드 개선을 목표로 합니다. 학습자는 작고 범위가 제한된 변경을 계획하고, 테스트를 통해 기존 동작을 보호하며, 설계를 단계적으로 개선하고, 변경 후에도 문제가 발생하지 않았음을 입증합니다. 코드는 점차 개선될 뿐 아니라, 더 중요한 것은 엔지니어들이 실제 기술 부채 상황에서 필요한 판단력을 연습할 수 있다는 점입니다.
빠른 사실
| 문제 | 짧은 답변 |
|---|---|
| 그 임무는 무엇인가요? | 제한된 범위의 레거시 코드 개선 계획을 수립하고 검증하십시오. |
| 점수가 어떻게 나오세요? | 위험 분석 및 기존 행동 양식이 유지되었다는 증거. |
| 대대적인 코드 개편은 좋은 훈련 프로젝트일까요? | 대개는 그렇지 않습니다. 연습 중인 기술을 숨기고, 보존된 행동을 보여주기 어렵게 만들기 때문입니다. |
| 리팩토링 패턴에 대한 퀴즈만으로 충분할까요? | 아니요. 필수 요건을 확인하는 것이지, 엔지니어가 변경 사항을 계획하고 검증할 수 있는지 여부를 확인하는 것은 아닙니다. |
| 누가 콘텐츠의 유효성을 검증합니까? | 코드베이스를 잘 아는 엔지니어링 매니저와 선임 엔지니어. |
| 훈련으로 해결할 수 없는 것은 무엇일까요? | 테스트 도구 부족, 출시 압박, 불분명한 담당자, 그리고 유지 보수 작업을 위한 시간 부족. |
| 어떻게 효과가 있었는지 아세요? | 새롭고 이전에 공개되지 않았던 레거시 코드 사례를 합의된 기준에 따라 평가하고, 실제 작업에 대한 후속 조치를 취합니다. |
1. 성능 문제를 설명하세요
과제부터 시작하세요: 범위가 제한된 레거시 코드 개선 계획을 수립하고 검증하세요. 여기서 "범위가 제한된"이라는 단어가 중요합니다. 학습자는 완료할 수 있을 만큼 작은 변경 사항을 선택하고, 범위에 포함되는 것과 포함되지 않는 것을 명확히 정의할 수 있어야 합니다.
용어를 정확하게 사용하는 것이 도움이 됩니다. 마틴 파울러는 리팩토링을 다음과 같이 설명합니다. 기존 코드베이스의 설계를 개선하기 위한 제어된 기법작고 동작을 유지하는 변환들로 구성됩니다. "동작 유지"라는 표현이 리팩토링과 재작성을 구분하는 핵심이며, 교육 과정에서 명확히 보여줘야 할 부분입니다. 기술 부채라는 은유 자체가 그렇습니다. 워드 커닝햄이 만든 용어입니다.그리고 파울러의 논의는 부채를 의도적이고 신중하게 떠안을 수 있다는 점을 상기시켜 주므로, 모든 복잡한 모듈이 수정해야 할 실수는 아니라는 점을 일깨워 줍니다.
마이클 페더스의 레거시 코드 관련 저서도 같은 맥락의 실천을 제시합니다. 출판사 설명에 따르면 이 책은 개발자들이 레거시 코드의 작동을 보장하는 테스트를 작성하는 방법을 가르칩니다. 그들은 의도치 않게 애플리케이션을 변경하는 것이 아닙니다.또한, 소프트웨어를 완전히 재작성하지 않고도 관리할 수 있도록 합니다.
성과 평가문을 한 문장으로 작성하고 엔지니어링 관리자에게 확인을 받으세요. 예를 들어, "기존 모듈과 명확하게 정의된 목표를 바탕으로, 엔지니어는 제한된 범위의 변경 사항을 제안하고, 현재 동작을 정확히 파악하는 테스트를 추가하고, 변경 사항을 단계적으로 적용하여 동작이 유지됨을 입증합니다."와 같이 작성할 수 있습니다.
2. 학습 및 맥락 격차를 진단합니다.
무엇을 만들기 전에, 필요한 작업과 현재 활동에서 연습하고 평가하는 내용을 비교해 보세요. 일반적으로 다음 세 가지 질문을 통해 교육 격차와 다른 요소를 구분할 수 있습니다.
- 현재의 실무는 실제 과제를 활용하고 있는가? 교육에서 슬라이드를 통해 리팩토링 패턴을 다루지만, 아무도 테스트되지 않은 코드를 수정하지 않는다면, 아무도 보호 동작을 연습한 것이 아닙니다. 평가가 코드 스멜에 대한 객관식 시험이라면, 그것은 단지 암기력만을 측정하는 것입니다.
- 인지적 요구 사항은 무엇입니까? 블룸의 개정된 분류 체계에서 변경 사항이 안전한지 판단하는 것은 분석 및 평가 수준에 해당하고, 계획 및 테스트 설계는 창조 수준에 해당합니다. 활동을 이러한 수준에 연결하는 방법은 저희 가이드에서 다룹니다. 학습 활동을 블룸의 분류 체계에 맞추기.
- 실력 외에 다른 요인이 방해가 되는 건가요? 인력, 도구 및 절차를 점검하십시오. 빌드에 한 시간이 걸린다면 아무도 테스트를 자주 실행하지 않을 것입니다. 유지 보수 작업이 전혀 계획되지 않으면 엔지니어는 비밀리에 리팩토링만 할 것입니다. 교육과 무관한 원인은 해결 가능한 담당자에게 보고하십시오.
3. 목적 있는 준비와 연습을 설계하십시오.
교육을 통해 어떤 격차를 해소할 수 있는지 파악했다면, 각 단계에 명확한 역할을 부여하십시오.
예비. 간단한 진단으로 사전 요구 사항을 확인하세요. 테스트 프레임워크 작동 방식, 특성화 테스트란 무엇인지, 팀의 검토 및 병합 방법 등을 점검해 보세요. 이 단계에서는 자기 주도 학습이 적합합니다. 복습 점검은 사전 요구 사항 충족 여부만 확인합니다.
연습. 명확한 구조를 가진 체계적인 리팩토링 프로젝트를 활용하세요. 작고 안전한 샘플 코드부터 시작하여 실제 코드베이스의 제한된 부분으로 옮겨가세요. 길디드 로즈 카타(Gilded Rose kata)는 첫 단계를 시작하기에 좋은 자료입니다. 에밀리 바체(Emily Bache)가 관리하는 README 파일을 참고하세요. 코드 변경 전에 테스트를 작성할 것을 권장합니다. 이 연습은 작은 단계들을 밟아 나가고, 테스트를 자주 실행하며, 설계를 조금씩 개선하는 훈련으로 이해해야 합니다. 각 프로젝트에 적합한 순서는 다음과 같습니다. 목표와 범위를 정의하고, 현재 코드의 동작을 파악하는 테스트를 작성하고, 한 번에 한 가지씩 변경하고, 각 단계 후에 테스트를 실행하고, 그 과정에서 무엇을 배웠는지 기록하는 것입니다.
피드백. 피드백은 총점이 아닌 결정 사항과 연결하세요. "할인 로직은 추출했지만 테스트는 정상적인 상황만 다뤘기 때문에 반올림 변경 사항을 알아차리지 못했을 것입니다."와 같은 피드백이 "5점 만점에 3점"보다 훨씬 유용합니다.
실시간 강사 강의 또는 비동기식 복습? 실시간 피드백은 선택이 모호할 때, 예를 들어 누락된 테스트를 추가하기 위해 중단할지 아니면 계속 진행할지 결정할 때 가장 큰 가치를 제공합니다. 학습자가 자신의 계획과 테스트를 전문가가 주석을 단 버전과 비교할 때는 비동기식 검토만으로도 충분합니다. 많은 팀에서 두 가지 방법을 모두 사용합니다. 먼저 자기 주도 학습을 통해 준비한 후, 어려운 사례에 대해 전문가의 도움을 받는 세션을 진행합니다.
4. 현실적인 예를 통해 살펴보세요
예시입니다. 엔지니어링 관리자는 사용 전에 사례와 답변 기준을 검증해야 합니다.
경우. 기존 함수는 할인, 세금 및 배송 규칙을 포함하여 주문 총액을 계산합니다. 이 함수에는 테스트가 없습니다. 한 팀에서 전체 결제 모듈을 "더 깔끔하게" 재구성하자고 제안했습니다.
그 임무. 학습자는 자신이 무엇을 할 것인지 설명하고, 수집할 증거를 제시하며, 추가로 필요한 정보나 지원이 무엇인지 말합니다.
첫 시도입니다. "모듈을 세 개의 서비스로 나누고 로직을 옮긴 다음 스테이징 환경에서 수치를 확인하겠습니다." 학습자는 큰 변경 사항을 선택하고, 그 후에 수동으로 확인하는 방식을 택했습니다. 이렇게 되면 이전 버전과 새 버전이 예외적인 상황에서 일치하는지 확인할 방법이 없습니다.
피드백 후 다시 시도하세요. 검토자는 빈 장바구니, 총액이 마이너스가 되는 할인, 그리고 반올림 사례에 대해 해당 함수가 현재 어떻게 작동하는지 묻습니다. 재시도 과정에서는 학습자에게 범위를 하나의 동작으로 좁히고 해당 동작이 변경되지 않았음을 어떻게 증명할 수 있는지 설명하도록 요구합니다.
좀 더 나은 시도였습니다. "모듈 구조는 일단 그대로 두겠습니다. 테스트로 현재 주문 총액 함수가 다양한 입력값(예외적인 경우 포함)에 대해 반환하는 값을 수집하겠습니다. 그런 다음 할인 계산 부분을 별도의 함수로 분리하고, 해당 단계 후에 테스트를 실행한 후 작업을 중단하겠습니다. 배송 규칙의 동작 방식을 이해하지 못하겠으니, 수정하기 전에 동료에게 문의하겠습니다." 이 답변은 변경 범위를 명확히 하고, 기존 동작을 우선적으로 보호하며, 알 수 없는 부분을 명확히 밝히고 있습니다.
각 답변이 타당한지 또는 불완전한지 판단하는 이유. 각 제안은 심사자의 개인적인 선호가 아닌 승인된 기준에 따라 평가해야 합니다. 첫 번째 시도는 장기적인 방향으로는 타당할 수 있지만, 지속적인 행동 변화에 대한 증거가 없으므로 계획으로서는 불완전합니다. 더 나은 시도는 규모가 작고, 검증 가능하며, 불확실성에 대해 솔직하게 인정하는 것입니다.
5. 역량을 평가하고 이전 계획을 수립합니다.
역량 증명은 학습자가 이전에 접해보지 못한 새로운 레거시 코드 사례에 대한 수행 능력입니다. 위험 분석과 행동이 유지되었다는 증거를 점수로 평가합니다. 간단한 평가 기준표는 각 항목당 0에서 2까지의 척도를 사용합니다.
| 표준 | 관찰 가능한 증거 |
|---|---|
| 작업 실행 | 제한된 범위의 레거시 코드 개선 계획을 수립하고 검증하며, 해당 조치와 그 근거를 기록합니다. |
| 추리 | 제약 조건, 대안 및 불확실성을 설명하고, 위험 요소를 점검하며, 행동이 유지되었다는 증거를 제시합니다. |
| 경계 | 승인된 절차를 따르고, 정보나 권한이 부족할 경우 도움을 요청합니다. |
평가 기준: 0은 부재 또는 미충족, 1은 관련 누락이 있는 부분적, 2는 합의된 기준에 따라 완전하고 타당성이 입증됨을 의미합니다. 테스트 없이 행동이 변경되는 경우와 같은 중요한 오류는 별도로 정의하여 전체 점수에서 이러한 오류가 드러나지 않도록 해야 합니다. 이 평가 기준표는 제안 사항이며 검증된 준비 표준이 아닙니다. 엔지니어링 관리자와 협의하여 수정하고 시범 운영해 보십시오. 유용한 피드백을 제공하는 상호작용적 연습 설계 의사 결정과 연계된 피드백 작성 방법을 보여줍니다.
의도적으로 업무 이전을 계획하세요. 워크숍 후, 각 엔지니어에게 검토자와 함께 해결해야 할 작지만 실질적인 과제를 주거나, 최근 변경 사항으로 인해 발생한 문제에 대한 간단한 회고를 진행하세요. 워크숍 직후가 아니라 실제 업무에 충분히 노출된 후에 업무 이전 여부를 확인하세요.
상호작용적 전달이 도움이 되는 경우
상호작용형 형식은 모든 구성원이 그룹 토론 전에 변경 사항을 확정하도록 유도하는 데 유용합니다. 실시간 세션에서 진행자는 간단한 기존 코드 조각을 보여주고 각 엔지니어에게 가장 먼저 변경할 내용과 안전성을 입증하는 방법을 제출하도록 요청한 다음, 토론 전에 전체 코드를 공개할 수 있습니다. 동일한 방식으로 자기 주도 학습을 통해 사전 준비를 할 수도 있습니다. AhaSlides는 상호작용형 학습을 지원하며 실시간 및 자기 주도 학습 방식을 자유롭게 전환할 수 있습니다. AhaSlides는 프레젠테이션 및 학습 도구이지 코드를 실행하거나 분석하는 도구가 아니므로 리팩토링 작업은 반드시 사용자 환경에서 수행해야 합니다. 사용하려는 특정 작성, 피드백 또는 보고 기능이 자체 워크플로에 적합한지 확인하십시오. 형식 선택에 대한 자세한 내용은 관련 문서를 참조하십시오. 적응형 학습, 상호작용형 학습, 실시간 학습은 언제 사용해야 할까요?.
변화된 것을 측정하세요
엔지니어가 해당 업무를 수행할 수 있음을 보여줄 수 있는 기준을 사전에 결정하십시오. 기준선과 비교하여 미지의 사례에 대한 위험 분석 품질과 보존된 행동 증거를 비교하십시오. 포함 대상, 분모 및 기간을 정의하십시오. 결과가 개선되면 교육에 대한 공로를 인정하기 전에 새로운 테스트 도구, 더 빠른 빌드 또는 소유권 변경과 같이 동일 기간 동안 변경된 다른 사항을 확인하십시오.
남아 있을 수 있는 제약 조건
- 유지보수 작업이 필요한 시점입니다. 부채 관련 업무가 전혀 계획되지 않으면, 숙련된 엔지니어들은 여전히 자신의 기술을 활용할 곳이 없게 됩니다.
- 테스트 도구. 사용 가능한 테스트 장비나 빠른 제작 속도가 없다면, 단계적인 개선과 잦은 점검을 지속하기 어렵습니다.
- 사건 처리 범위. 한 가지 기존 사례는 몇 가지 유형의 위험을 보여줍니다. 점수만으로는 엔지니어의 판단력을 전반적으로 설명할 수 없습니다.
- 리팩토링을 하지 말아야 할 시점을 판단하는 방법. 어떤 코드는 그대로 두는 것이 좋고, 교체하거나 폐기하는 것이 나은데, 이러한 결정에는 기술적인 능력 이상의 것이 필요합니다.
- 이전. 카타(시험 문제)에서의 수행 능력은 납기 압박 속에서 실제 생산 모듈에서 발휘하는 수행 능력과는 다릅니다.
이러한 사항들을 스폰서에게 조기에 알리고 별도의 해결 방안을 계획하십시오. 교육은 엔지니어가 계획하고 입증할 수 있는 능력을 향상시켜 줍니다. 하지만 교육이 시간이나 도구를 만들어 주는 것은 아닙니다.
자주하는 질문
리팩토링 교육 프로젝트란 무엇인가요?
이는 엔지니어들이 레거시 코드에 대해 작은 변경 사항을 계획하고, 테스트를 통해 기존 동작을 보호하고, 설계를 단계적으로 변경하여 아무것도 손상되지 않았음을 입증하는 체계적인 관행입니다.
전면 재작성은 기술적 부채에 대해 배우는 좋은 방법일까요?
대개는 그렇지 않습니다. 코드 재작성은 규모가 크고 검증하기 어려우며, 육성하고자 하는 역량을 숨기는 결과를 초래합니다. 반면, 현재 동작을 포착하는 테스트를 포함한 제한적인 변경은 변경 이유를 명확하게 보여줍니다.
엔지니어가 안전하게 리팩토링할 수 있는지 어떻게 평가하나요?
새로운 레거시 코드 사례를 제시하고, 위험 분석과 합의된 기준에 따라 동작이 유지되었는지에 대한 증거를 평가하세요. 리팩토링 패턴에 대한 퀴즈는 사전 지식 습득 여부만 확인합니다.
교육을 위한 샘플 코드베이스가 필요하신가요?
안전하게 연습할 수 있는 공간이 필요합니다. 많은 팀이 공개된 카타(kata)를 활용한 연습으로 시작한 후, 자신들이 작성한 코드의 특정 부분을 집중적으로 연습합니다. 엔지니어링 매니저에게 코드가 적합한지 확인해야 합니다.
어디서 시작하나요
코드베이스에서 반복적으로 발생하는 작은 레거시 변경 사항 하나를 선택하세요. 성능 설명서를 작성하고, 엔지니어링 관리자에게 해당 사례와 동작 유지를 보여주는 테스트를 검증받으세요. 그런 다음 0에서 2까지의 척도로 평가하는 3가지 기준과 중요한 오류 목록을 작성하세요. 전체 배포 전에 소규모 그룹으로 시범 운영해 보세요.
팀원들과 함께 리팩토링 결정 연습을 실시간으로 진행하고, 이후에도 자율 학습 방식으로 재사용하는 방법을 알아보려면 AhaSlides를 살펴보세요.
