순공학,역공학,리팩터링,재엔지니어링,전면 재개발까지 한 번에 정리

반응형

 

순공학,역공학,리팩터링,재엔지니어링,전면 재개발까지 한 번에 정리

순공학 역공학 삽화 이미지

 

1. 순공학(Forward Engineering) vs 역공학(Reverse Engineering): “만드는 것”과 “거꾸로 이해하는 것”

소프트웨어를 만든다는 것은 크게 두 가지 관점에서 볼 수 있습니다.

하나는 “처음부터 새로 만드는 일(순공학)”이고, 다른 하나는 “이미 만들어진 것을 거꾸로 분석해서 이해하는 일(역공학)”입니다.

 

🔷 순공학(Forward Engineering)이란?

순공학(Forward Engineering)은 우리가 흔히 떠올리는 “정상적인 소프트웨어 개발 과정”을 말합니다.
즉, 요구사항 → 설계 → 구현 → 테스트로 이어지는 전통적인 흐름입니다.

1. 요구사항 분석

사용자가 무엇을 원하는지, 비즈니스가 어떤 기능을 필요로 하는지 정리합니다.

예: “사내 휴가 신청 시스템이 필요하다. 모바일에서도 승인할 수 있어야 한다.”

2. 설계(아키텍처/상세 설계)

요구사항을 만족하기 위해 시스템을 어떤 구조로 만들지 결정합니다.

예: “웹 프론트 + 백엔드 API + DB 3계층 구조로 하고, 인증은 OAuth2를 쓰자.”

3. 구현(코딩)

설계한 내용을 실제 코드로 옮기는 단계입니다.

예: Node.js로 REST API를 만들고, React/Vue로 화면을 구현합니다.

4. 테스트 및 배포

요구사항을 제대로 만족하는지 검증하고, 안정적인 상태에서 운영 환경에 배포합니다.

순공학의 핵심은 “아직 존재하지 않는 시스템을, 요구사항을 출발점으로 해서 새로 만들어 나간다”는 점입니다.

 

🔷 역공학(Reverse Engineering)이란? : 리버스 엔지니어링

반대로, 리버스 엔지니어링(Reverse Engineering, 역공학)은 이미 존재하는 시스템에서 설계·모델·요구사항을 거꾸로 추출해 내는 활동을 말합니다.

▸ 코드만 남아 있고, 설계 문서가 거의 없는 시스템에서 “이 시스템이 도대체 어떻게 돌아가는지”를 분석하는 작업

▸ API 명세서가 없어 실제 호출을 찍어 보면서 파라미터·응답 구조를 정리하는 작업
▸ DB에 쌓인 데이터와 스키마만 보고 도메인 모델과 비즈니스 규칙을 유추하는 작업
등이 모두 역공학의 한 예입니다.

 

역공학의 목적은 단순히 “코드를 읽는다”가 아니라,
사람이 이해할 수 있는 수준의 모델과 문서를 다시 세우는 것입니다.
예를 들면 다음과 같은 결과물이 나옵니다.
▸ 현재 구조를 나타내는 아키텍처 다이어그램
▸ 주요 도메인과 관계를 정리한 도메인 모델
▸ 핵심 기능의 플로우를 보여주는 시퀀스 다이어그램 또는 플로우 차트
▸ REST/GraphQL API 스펙, DB 스키마 정리 문서
이렇게 한 번 “머릿속에 들어오는 수준으로” 정리가 되어야, 이후에 재구조화, 리팩터링, 재엔지니어링 같은 다음 단계 작업을 계획할 수 있습니다.

 

2. 구조를 손보는 기술: 재구조화(Restructuring)와 리팩터링(Refactoring)

이제 시스템의 구조를 “더 낫게” 만드는 이야기로 넘어가 보겠습니다.

여기서 중요한 개념이 재구조화(Restructuring)와 리팩터링(Refactoring)입니다.

 

🔷 재구조화(Restructuring): 구조를 더 합리적으로 바꾸는 활동

재구조화는 말 그대로 기존 시스템의 구조를 더 합리적인 형태로 바꾸는 활동 전체를 뜻합니다.
핵심 포인트는 다음과 같습니다.
▸ 가능한 한 동작(기능)은 유지하면서,
▸ 구조, 구성, 설계 방식을 더 이해하기 쉽고 유지보수하기 좋게 손보는 것

 

재구조화는 여러 수준에서 일어납니다.

1. 설계/아키텍처 레벨 재구조화

▸ 모놀리식 서비스를 도메인별로 쪼개서 계층 구조를 명확히 하는 것
▸ 의존 관계를 정리해 “모든 것이 모든 것에 의존하는” 스파게티 구조를 줄이는 것
▸ 계층(Layer), 도메인(Bounded Context), 모듈 경계를 다시 나누는 작업

 

2. 코드 레벨 재구조화

▸ 중복된 로직을 공통 함수/모듈로 모으는 것

▸ 한 파일에 몰려 있는 기능을 역할에 따라 여러 파일로 분리하는 것

▸ 복잡한 메서드를 작은 메서드들로 나누는 것 등

 

🔷 리팩터링(Refactoring): 코드 레벨 재구조화의 대표 기술

리팩터링(Refactoring)은 특히 코드 레벨에서 이루어지는 재구조화를 가리키는 용어입니다.

"기능(외부 동작)은 그대로 유지하면서, 코드의 구조·가독성·유지보수성을 개선하는 체계적인 변경"

 

리팩터링의 중요한 특징은

▸ 동작을 바꾸지 않는다는 점입니다.
즉, 리팩터링 전과 후에 테스트 결과와 시스템 기능이 동일해야 합니다.

▸ 코드가 더 읽기 쉬워지고, 중복이 줄어들고, 변경에 강한 구조가 됩니다.

 

예를 들어

▸ 300줄짜리 거대한 함수에서 일부 로직을 잘 이름 붙인 작은 함수로 뽑아내는 것 (Extract Method)

▸ 같은 로직이 여러 곳에 흩어져 있다면 공통 모듈로 분리하는 것

▸ 이해하기 어려운 변수/함수 이름을 더 의미 있는 이름으로 바꾸는 것 (Rename)
등이 모두 리팩터링입니다.

반응형

 

3. 기존 자산을 살리는 방법: 재사용(Reuse)과 구조 개선의 연결

🔷 재사용(Reuse): 이미 있는 것을 잘 써먹는 전략

재사용(Reuse)은 말 그대로 이미 만들어진 자산을 다시 활용하는 것입니다.

여기서 자산이란 다음과 같은 것들을 포함합니다.

▸ 코드: 라이브러리, 유틸 함수, 공통 모듈

▸ 컴포넌트: UI 컴포넌트, 인증 모듈, 결제 모듈 등

▸ 서비스: 공통 인증 서비스, 로깅/모니터링 서비스 등

▸ 설계/모델: 도메인 모델, 아키텍처 패턴, 설계 템플릿

 

재사용의 목적은 단순히 “복사해서 붙여넣기”가 아니라,
중복된 노력을 줄이고, 품질이 검증된 것을 여러 곳에서 안정적으로 활용하는 것입니다.

 

🔷 재구조화·리팩터링과 재사용의 연결

재사용과 재구조화/리팩터링은 서로 강하게 연결되어 있습니다.
처음부터 재사용을 염두에 두지 않고 작성된 코드는 대개 다음과 같은 특징을 갖습니다.

▸ 특정 화면/특정 기능에 강하게 결합되어 있다.
▸ 전역 상태나 외부 의존성이 많아서 다른 곳에서 가져다 쓰기 어렵다.
▸ 네이밍과 구조가 재사용 관점에서 잘게 나누어져 있지 않다.

이런 코드를 바로 다른 프로젝트나 모듈에서 재사용하기는 쉽지 않습니다.

그래서 “재사용하기 좋은 형태”로 만들기 위해 재구조화와 리팩터링이 필요합니다.

 

예를 들면

▸ 화면 A와 화면 B에서 거의 같은 검증 로직을 사용한다면

→ 검증 로직을 별도 유틸 함수/서비스로 추출하는 리팩터링을 한다.
▸ 여러 서비스가 같은 방식으로 파일 업로드를 처리한다면

→ 업로드 로직을 공통 모듈 또는 공통 API 서비스로 재구조화한다.
▸ 도메인별 경계가 애매하면

→ 도메인 모델을 재설계하고, 모듈 구조를 그에 맞게 재구조화한다.

이 과정을 통해 “지금은 여기서만 쓰이는 코드”가 “여러 곳에서 재사용 가능한 자산”으로 바뀌게 됩니다.

재구조화/리팩터링은 재사용이 가능하도록 길을 닦는 작업이고,
재사용은 그렇게 다듬어진 자산을 여러 곳에서 활용하는 전략입니다.

 

4. 재엔지니어링(Re-engineering) vs 전면 재개발(Rewrite)

이제 마지막으로, 레거시 시스템을 개선할 때 자주 등장하는 두 가지 큰 선택지인
재엔지니어링(Re-engineering)과 전면 재개발(Rewrite)을 비교해 보겠습니다.

 

🔷 재엔지니어링(Re-engineering)의 정의와 위치

재엔지니어링(Re-engineering)은

역공학 + 재구조화/리팩터링 + 필요한 재개발을 포괄하는, 기존 시스템을 버리지 않고 근본적으로 개선·현대화하는 프로젝트

 

조금 더 풀어서 설명하면 다음과 같은 단계들을 포함합니다.

1. 역공학(Reverse Engineering)

▸ 현재 시스템의 구조, 도메인, 요구사항을 거꾸로 분석해 문서와 모델을 다시 세웁니다.

 

2. 재구조화/리팩터링(Restructuring/Refactoring)

▸ 기존 코드와 아키텍처를 이해 가능한 구조로 다듬습니다.
▸ 모듈 경계를 정리하고, 스파게티 의존성을 줄입니다.

 

3. 필요한 재개발

▸ 기존 코드로는 도저히 유지보수가 어렵거나, 새로운 기술 스택으로 옮겨야 할 부분은 부분적으로 새로 만듭니다.
▸ 예: UI는 완전히 새로 만들되, 핵심 도메인 로직은 리팩터링 후 재사용

 

재엔지니어링은 “기존 시스템의 자산(코드, 데이터, 도메인 지식)을 가능한 한 살리면서” 현대적인 구조와 기술로 재정비하는 접근입니다

완전히 새로 만드는 것보다 리스크를 줄일 수 있고, 과거에 축적된 도메인 지식을 최대한 활용할 수 있다는 장점이 있습니다.

 

🔷 전면 재개발(Rewrite)의 의미

전면 재개발(Rewrite)은 말 그대로 기존 시스템을 버리고 처음부터 새로 만드는 선택입니다.

▸ 기존 코드 기반을 유지·개선하려고 시도하기보다,
▸ “아예 새 시스템을 설계해서 만들자”라고 결정하는 것입니다.

 

이 선택은 다음과 같은 상황에서 자주 논의됩니다.

▸ 기술 부채가 너무 심각해서, 기존 코드를 고치는 것보다 새로 만드는 게 더 싸 보일 때
▸ 아키텍처가 근본적으로 문제라, 부분적인 리팩터링으로는 해결이 안 된다고 느낄 때

▸ 조직이 기술 스택을 크게 바꾸려 할 때 (예: 오래된 온프레미스 시스템 → 클라우드 네이티브로 전환)

전면 재개발은 순공학의 자유와 현대 기술의 이점을 누릴 수 있지만, 그만큼 큰 책임과 리스크도 따라옵니다.

 

---

 

※ 게시된 글 및 이미지 중 일부는 AI 도구의 도움을 받아 생성되거나 다듬어졌습니다.

반응형