Experience on Automatically Converting a C++ Monolith to Java EE

이 논문은 80 만 줄의 C++ 모놀리식 코드를 Java EE 와 WildFly 환경으로 전환하는 과정에서 다중 상속, 열거형 처리, 스코프 객체 등 주요 기술적 난제를 해결하고, C++ 개발이 병행되는 상황에서 Clang 기반 도구를 활용해 Java 코드를 지속적으로 재생성하여 성공적으로 운영한 경험을 요약합니다.

핵심

1. 프로젝트의 배경: "자동 번역기"를 만든 이유

이 회사는 물류 소프트웨어를 만들었습니다. 기존 프로그램은 **C++**로 되어 있었는데, 이를 Java로 바꾸고자 했습니다.

• 왜? Java 개발자를 구하기가 더 쉽고, 서버 환경 (WildFly) 에 맞춰 구조를 바꾸고 싶었기 때문입니다.
• 어려움: 코드가 80 만 줄이나 되는 거대한 '단일 덩어리 (Monolith)'였습니다. 사람이 하나하나 손으로 고치면 몇 년이 걸리고 실수도 많을 테니, **자동으로 코드를 변환해주는 '로봇 (변환 도구)'**을 만들기로 했습니다.
• 특이점: 변환하는 동안에도 원래 C++ 프로그램은 계속 발전하고 있었습니다. 마치 운전하면서 차를 개조하는 것과 같았습니다.

2. 주요 난관과 해결책 (비유로 풀어보기)

이 변환 과정에서 만난 4 가지 큰 장애물과 이를 어떻게 해결했는지 보겠습니다.

① "한 번에 여러 엄마를 둔 아이" (다중 상속 문제)

• 문제: C++ 은 한 클래스가 여러 부모 클래스를 가질 수 있지만, Java 는 오직 한 명의 부모만 가질 수 있습니다. (마치 아이가 부모를 두 명만 가질 수 있는 법이 있는 셈입니다.)
• 해결:
  • 데이터베이스 연결 클래스 (DAO) 인 경우: "내가 너의 아들이야 (상속)"라는 관계를 **"내가 너의 도구를 가지고 있어 (소유)"**라는 관계로 바꿨습니다. (예: "아들"이었던 클래스가 "도구함"을 품에 안게 한 것.)
  • 명령 체인 (Chain of Command) 인 경우: C++ 의 긴 연결고리를 Java 의 **관리자 (Chain Manager)**가 하나씩 불러서 실행하게 만들었습니다.

② "숫자 옷을 입은 열쇠" (Enum 과 정수 변환)

• 문제: C++ 에서는 '빨강, 파랑, 초록' 같은 열거형 (Enum) 을 그냥 숫자처럼 취급할 수 있습니다. 하지만 Java 에서는 엄격해서, 숫자를 열거형으로 강제로 바꾸면 에러가 납니다.
• 해결: 변환 도구가 **가상의 '열거형 클래스'**를 만들어냈습니다.
  • C++ 의 RED (숫자 0) 를 Java 에서는 Color.RED라는 객체로 만들었습니다.
  • 숫자로 바꿔야 할 때는 asNum()이라는 버튼을 누르게 하고, 숫자를 열거형으로 바꿀 때는 forNum()이라는 문이 있는 문을 통과하게 했습니다. (문 밖으로 나가는 숫자는 감시당합니다.)

③ "자동 청소부" (생성자와 소멸자)

• 문제: C++ 에는 객체가 사라질 때 자동으로 자원을 정리해주는 '소멸자'가 있습니다. 하지만 Java 에는 그런 기능이 없습니다. (쓰레기 수거차가 오기 전까지 쓰레기가 쌓여있는 셈입니다.)
• 해결: Java 7 에 도입된 **'Try-with-resources'**라는 기능을 사용했습니다.
  • 마치 자동으로 문이 잠기는 방처럼, 코드를 실행하는 블록을 만들었습니다.
  • 블록을 빠져나가는 순간 (정상 종료든, 에러 발생이든), Java 가 자동으로 자원을 정리해주는 문을 닫아줍니다.

④ "글쓰기 도구" (스트림 입출력)

• 문제: C++ 의 cout 같은 글쓰기 방식은 Java 에는 없습니다.
• 해결: C++ 의 글쓰기 명령을 Java 의 **StringBuilder(글자 쌓는 도구)**로 변환했습니다.
  • 여러 글자를 이어 붙일 때는 효율적인 도구를 쓰고, 그냥 한 줄만 쓸 때는 바로 출력하게 했습니다.

3. 도구 (Transpiler) 의 작동 원리

이 변환을 한 것은 사람이 아니라 **clang-tool(코드 분석기)**을 기반으로 만든 전용 변환 도구입니다.

• 작동 방식: C++ 코드를 하나씩 읽어가면서, **템플릿 (양식)**에 맞춰 Java 코드로 다시 씁니다.
• 지능: 단순히 글자만 바꾸는 게 아니라, "이건 C++ 의 A 타입인데 Java 에서는 B 타입으로 바꿔야 해"라고 타입을 추론하는 능력도 있습니다.
• 결과: 처음에는 에러가 많았지만, 도구를 계속 개선하고 Java 의 타입 시스템을 도입하면서 에러 수가 급격히 줄었습니다.

4. 결론: 성공적인 이주

• 결과: 80 만 줄의 코드 중 약 99% 이상이 자동으로 변환되었습니다.
• 나머지 1%: 약 10 개의 클래스만 사람이 손으로 다듬었습니다. (완벽한 자동화는 불가능하지만, 사람이 할 일을 극도로 줄였습니다.)
• 의의: 이 프로젝트는 거대한 레거시 시스템을 현대화하면서도, 개발을 멈추지 않고 진행할 수 있음을 증명했습니다.

---

한 줄 요약:

"거대한 C++ 성을 해체하지 않고, 그 안에서 모든 벽돌을 Java 벽돌로 바꾸는 자동화 공사를 성공적으로 마쳤습니다. 다만, 몇몇 특수한 구조는 사람이 손으로 다듬어주어야만 완성되었습니다."

기술 요약

논문 요약: C++ 모놀리식 아키텍처를 Java EE 로 자동 변환하는 경험

1. 문제 정의 (Problem)

이 연구는 물류 및 관련 소프트웨어를 제공하는 한 기업이 기존에 사용하던 80 만 줄 (800k LOC) 의 C++ 코드베이스를 Java 8로 전환하고, 아키텍처를 단일 실행 파일 (Monolith) 에서 WildFly 애플리케이션 서버를 기반으로 하는 Java EE 환경으로 변경해야 하는 과제를 다룹니다.

주요 도전 과제는 다음과 같습니다:

• 규모와 지속성: 대규모 코드베이스를 수동으로 변환하는 것은 비효율적이며, C++ 코드베이스의 지속적인 개발 (기능 추가, 버그 수정) 이 병행되고 있어 일관성을 유지하기 어렵습니다.
• 언어 및 아키텍처의 차이: C++ 의 다중 상속 (Multiple Inheritance), 스코프 기반 객체 관리 (RAII), 열거형 (enum) 과 정수 간의 암시적 변환, 스트림 I/O 등 Java 가 지원하지 않거나 다르게 구현된 개념들을 처리해야 합니다.
• 아키텍처 변경: 단순히 언어만 바꾸는 것이 아니라, 멀티스레딩 환경에서의 동시성 제어, 예외 처리, 그리고 애플리케이션 서버 표준에 맞는 구조로 재설계해야 합니다.

2. 방법론 (Methodology)

저자들은 LLVM/Clang-tool을 기반으로 한 자동 변환 도구 (Transpiler) 를 개발하여 문제를 해결했습니다.

• 도구 아키텍처:

  • Clang AST 기반: C++ 소스 코드를 Clang 파서가 구문 분석 트리 (AST) 로 변환하면, 이를 방문자 (Visitor) 패턴을 통해 분석합니다.
  • Transpile Visitor: 클래스 선언, 멤버 함수, 문장 등을 순회하며 Java 코드 생성을 위한 데이터를 추출합니다.
  • Rewrite/Template Engine: 추출된 C++ 구조를 Java 템플릿에 매핑하여 코드를 생성합니다.
    • Cast Template: 타입 변환 규칙을 정의합니다.
    • Free Function Mapper: C 스타일 함수 (예: atoi) 를 Java 정적 메서드로 매핑합니다.
    • Member Expression Rewriter: std::string 등의 표준 라이브러리 함수를 Java 에 해당하는 메서드 (예: charAt, indexOf) 로 변환하는 규칙을 테이블 형태로 정의합니다.
  • 패키지 관리: C++ 의 #include 를 Java 의 import 로 자동 변환하고, 필요한 패키지를 중앙 레지스트리에 등록하여 누락을 방지합니다.
  • 타입 시스템: C++ 의 타입 정보를 Java 타입 시스템과 연결하여 불필요한 캐스팅을 방지하고, Enum-Int 변환 오류를 감지합니다.

• 반복적 개선 프로세스:

  • C++ 개발이 중단되지 않았으므로, 변환 도구는 체크인 (Check-in) 시마다 실행됩니다.
  • 변환된 Java 코드가 템플릿과 일치하지 않거나 오류가 발생하면, 수동으로 수정된 파일을 '체크 (Checked)'하여 빌드 시스템에 통합하고, 이후 변경 사항이 발생하면 알림을 받도록 설계되었습니다.

3. 주요 기여 및 기술적 해결책 (Key Contributions & Solutions)

논문은 C++ 에서 Java 로 변환 시 발생하는 구체적인 문제들에 대한 실용적인 해결책을 제시합니다.

• A. 다중 상속 (Multiple Inheritance) 처리:

  • DAO(데이터 접근 객체) 상속: "Is-a" 관계를 "Has-a" 관계로 변환합니다. DAO 클래스를 상속받는 대신, 해당 클래스의 멤버 변수로 포함시키고 접근 방식을 수정합니다.
  • Chain of Command 패턴: 명령어 체인 클래스를 상속받는 경우, Java 인터페이스 (Link) 를 구현하도록 변환하고, 제어 흐름을 '체인 매니저'가 관리하도록 재설계합니다.
  • 기타 다중 상속: 인터페이스로 변환 가능한 경우 implements 로 변경하고, 변환이 불가능한 소수 (5 개 미만) 의 클래스는 수동으로 처리하여 빌드 시 경고가 발생하도록 guard 를 추가했습니다.

• B. 스트림 I/O 변환:

  • C++ 의 std::cout 및 << 연산자를 Java 의 StringBuilder 와 System.out.println/print 로 변환합니다.
  • std::endl 유무에 따라 줄바꿈 처리를 자동화하여 가독성을 유지합니다.

• C. Enum 과 정수 변환 (Enum vs Int):

  • C++ 의 Enum 은 정수 값과 자유롭게 변환 가능하지만, Java 의 Enum 은 타입 안전성이 강합니다.
  • 해결책: C++ Enum 을 Java 의 enum 클래스로 변환하되, 내부에 int 값을 저장하는 필드와 asNum(), forNum() 메서드를 추가하여 C++ 의 동작 방식을 시뮬레이션합니다. 이는 데이터베이스 인터페이스에서의 잘못된 정수 전달을 방지하고 타입 안전성을 확보합니다.

• D. 생성자 및 소멸자 (Constructors & Destructors):

  • C++ 의 RAII 패턴 (소멸자에서 리소스 해제) 은 Java 에 존재하지 않습니다.
  • 해결책: Java 7 의 Try-with-resources 패턴을 적용합니다. 리소스를 사용하는 클래스는 Closeable 인터페이스를 구현하도록 하고, 소멸자 로직이 포함된 경우 주석으로 표시하여 try 블록 내에서 자동 해제되도록 변환합니다.

• E. 예외 처리 (Exceptions):

  • 기존 C++ 코드는 예외를 던지지 않고 에러 코드를 반환하는 방식을 사용했습니다.
  • Java 로 전환 시 예외 처리 전략 (전체 체인 수준 또는 각 링크 단위) 에 대한 논의가 진행 중이었으며, 각 링크 호출 주위에 try-catch 를 추가하는 방식이 유력한 대안으로 검토되었습니다.

4. 결과 (Results)

• 성공적인 변환: 80 만 줄의 C++ 코드를 Java 로 변환하여 WildFly 서버에서 실행 가능한 상태로 만들었습니다.
• 오류 감소: 개발 기간 동안 Java 컴파일 오류 수가 급격히 감소했습니다. 특히 Java 타입 시스템 도입 (10 월 15 일 ~ 11 월 15 일) 이후 타입 캐스팅 및 Enum 변환 오류가 대폭 줄어들었습니다.
• 최종 상태: 프로젝트 종료 시 약 60 개의 오류가 남아 수동으로 수정되었으며, 수정된 코드는 정상적으로 실행되어 기본 기능을 수행했습니다.
• 유지보수성: 변환된 코드는 가독성이 유지되었으며, C++ 코드 변경 시 자동 변환 도구를 통해 Java 코드를 지속적으로 동기화할 수 있는 프로세스가 확립되었습니다.

5. 의의 (Significance)

• 실무적 검증: 대규모 레거시 C++ 시스템을 Java EE 로 전환하는 것은 이론적으로만 논의되던 주제였으나, 실제 80 만 줄 규모의 프로젝트에서 자동화 도구의 성공적인 적용 사례를 제시했습니다.
• 자동화 도구 개발: Clang-tool 을 활용한 유연한 변환 도구 아키텍처와 템플릿 기반의 매핑 전략은 다른 언어 간 변환 프로젝트에 귀중한 참고 자료가 됩니다.
• 아키텍처 현대화: 단순한 언어 변환을 넘어, 애플리케이션 서버 표준에 맞는 아키텍처 (DAO, Chain of Command 패턴 재설계 등) 로의 전환을 동시에 수행한 점에서의 의의가 큽니다.
• 현실적인 접근: 완벽한 자동화가 불가능한 부분 (소수의 복잡한 다중 상속 등) 에 대해서는 수동 개입과 자동화된 감시 시스템을 결합한 현실적인 해결책을 제시했습니다.

이 논문은 대규모 시스템의 언어 전환이 단순히 번역기를 돌리는 것이 아니라, 언어의 철학적 차이 (메모리 관리, 타입 시스템, 아키텍처 패턴) 를 이해하고 이를 자동화 도구와 수동 전략의 조화로 해결해야 함을 보여줍니다.