# 개발 용어 탐구 8편 - 개발 문화 용어: 리팩토링, 레거시, 기술 부채, 코드 리뷰, 애자일

About this offer

개발 용어 탐구 8편 - 개발 문화 용어: 리팩토링, 레거시, 기술 부채, 코드 리뷰, 애자일 들어가며 개발자는 단순히 코드를 작성하는 사람만을 의미하지 않는다. 실제 회사에서는: 기존 코드를 개선하고 팀원과 협업하고 프로젝트를 관리하고 지속적으로 서비스를 발전시키는 과정이 중요하다. 이 과정에서 자주 사용하는 용어들이 있다. 대표적으로: 리팩토링(Refactoring) 레거시(Legacy) 기술 부채(Technical Debt) 코드 리뷰(Code Review) 애자일(Agile) 스프린트(Sprint) 등이다. 이번 글에서는 개발 조직에서 실제로 사용하는 업무 용어를 알아본다. 1. 리팩토링(Refactoring) 리팩토링은: 프로그램의 동작은 유지하면서 코드 구조를 개선하는 작업 이다. 쉽게 말하면: "기능은 그대로 두고 코드를 더 좋게 만드는 것" 이다. 예: 처음 작성한 코드: 하나의 함수에 회원 조회 검증 DB 저장 메일 발송 모두 작성 문제: 코드가 길다 수정하기 어렵다 테스트하기 어렵다 리팩토링: 회원 조회 함수 검증 함수 메일 함수 분리 결과: 읽기 쉬움 유지보수 쉬움 오류 수정 쉬움 2. 리팩토링과 기능 개발의 차이 기능 개발: 새로운 기능 추가 예: 검색 기능 추가 리팩토링: 기존 기능 유지 코드 구조 개선 예: 검색 코드는 그대로 내부 구조 개선 중요한 점: 리팩토링은 사용자에게 보이는 기능 변화가 없다. 하지만 장기적으로 개발 속도를 높인다. 3. 레거시(Legacy) 레거시는: 오래된 시스템이나 코드를 의미하는 개발 용어 이다. 예: 10년 전 만든 서비스: 오래된 코드 낡은 기술 부족한 문서 이런 시스템을: 레거시 시스템 이라고 부른다. 4. 레거시는 무조건 나쁜 것인가? 아니다. 레거시는 상황에 따라 의미가 다르다. 좋은 의미: 오랫동안 운영된 안정적인 시스템 어려운 의미: 수정하기 어려운 오래된 코드 예: 은행 시스템: 20년 운영 검증 완료 중요 서비스 같은 경우도 있다. 5. 기술 부채(Technical Debt) 기술 부채는: 빠른 개발을 위해 나중에 해결해야 할 문제를 남겨두는 것 이다. 비유: 빚과 같다. 예: 빠르게 기능 출시: 일단 동작하게 개발 ↓ 출시 성공 하지만: 코드 중복 테스트 부족 복잡한 구조 가 남는다. 이것이 기술 부채이다. 6. 기술 부채가 발생하는 이유 1. 빠른 출시 시장 경쟁 때문에 빠르게 개발해야 하는 경우. 2. 요구사항 변경 처음 설계와 현재 요구가 달라지는 경우. 3. 유지보수 부족 시간이 지나면서 코드 품질이 떨어지는 경우. 7. 기술 부채 관리 좋은 개발팀은 기술 부채를 계속 관리한다. 방법: 리팩토링 테스트 추가 구조 개선 문서화 목표: 현재 개발 속도 + 미래 유지보수성 의 균형을 맞추는 것이다. 8. 코드 리뷰(Code Review) 코드 리뷰는: 다른 개발자가 작성한 코드를 검토하는 과정 이다. 흐름: 개발자 A 코드 작성 ↓ Pull Request 생성 ↓ 개발자 B 검토 ↓ 수정 ↓ 병합 검토 내용: 코드 오류 설계 문제 가독성 성능 보안 문제 9. 코드 리뷰의 목적 코드 리뷰는 단순히 잘못을 찾는 과정이 아니다. 목적: 코드 품질 향상 더 좋은 방법을 찾는다. 지식 공유 팀원들이 서로의 코드를 이해한다. 문제 예방 배포 전에 오류를 발견한다. 10. Pull Request(PR) PR은: 변경한 코드를 팀에 검토 요청하는 과정 이다. 예: 개발자가: 로그인 기능 개발 완료. ↓ GitHub에: Pull Request 생성 ↓ 팀원 리뷰. 현업에서: "PR 올렸습니다." "PR 리뷰 부탁드립니다." 같은 표현을 사용한다. 11. 애자일(Agile) 애자일은: 빠른 피드백과 반복적인 개선을 중요하게 생각하는 개발 방식 이다. 기존 방식: 폭포수(Waterfall): 기획 ↓ 설계 ↓ 개발 ↓ 테스트 ↓ 배포 애자일: 계획 ↓ 개발 ↓ 테스트 ↓ 피드백 ↓ 개선 (반복) 12. 스프린트(Sprint) 스프린트는: 애자일에서 일정 기간 동안 목표를 가지고 진행하는 개발 단위 이다. 예: 2주 스프린트: 목표: 로그인 기능 완성 기간: 2주 스프린트 동안: 개발 테스트 리뷰 를 진행한다. 13. 스크럼(Scrum) 스크럼은: 애자일을 실제 프로젝트 운영 방식으로 적용하는 방법 중 하나이다. 대표 활동: 데일리 스크럼(Daily Scrum) 매일 짧은 회의. 공유: 어제 한 일 오늘 할 일 문제점 스프린트 리뷰 완료한 기능 확인. 회고(Retrospective) 프로젝트 진행 방식을 개선. 14. 문서화(Documentation) 개발에서 문서화는 중요하다. 예: API 문서 설계 문서 장애 기록 개발 가이드 문서가 없으면: 작성자 퇴사 ↓ 새 개발자 이해 어려움 문제가 발생한다. 15. 개발팀에서 자주 사용하는 표현 현업에서는 이런 표현을 많이 사용한다. "리팩토링이 필요합니다." 의미: 현재 구조 개선 필요 "레거시 코드입니다." 의미: 오래되었거나 개선이 필요한 기존 코드 "기술 부채가 쌓였습니다." 의미: 빠른 개발 과정에서 해결하지 못한 문제가 증가 "PR 올렸습니다." 의미: 코드 검토 요청 마무리 개발자는 혼자 코드를 작성하는 직업이 아니다. 실제 개발 현장에서는: 기존 코드 개선 팀 협업 품질 관리 프로젝트 운영 이 중요하다. 정리하면: 리팩토링 = 코드 구조 개선 레거시 = 기존 오래된 시스템 기술 부채 = 나중에 해결해야 할 개발 비용 코드 리뷰 = 코드 검토 과정 PR = 변경 코드 검토 요청 애자일 = 반복 개선 방식 스프린트 = 짧은 개발 기간 단위 좋은 개발자는 단순히 코드를 작성하는 사람이 아니라, 팀과 함께 지속 가능한 소프트웨어를 만들어가는 사람 이다. 다음 글에서는 개발 성능과 확장성을 이해하기 위한 성능 관련 용어(병목, 캐시, 스케일 업, 스케일 아웃, 부하 테스트) 를 알아본다.