1. 레거시 코드와 첫 만남: 레거시 코드에서 느낀 한계
개발자라면 누구나 한 번쯤 레거시 코드라는 지옥을 경험해본 적이 있을 것이다. 회사에서 TF 프로젝트를 진행하며 나 역시 레거시 코드의 한계를 체감했다. 프로젝트 속도를 높이기 위해 기존의 C 기반 코드와 GCC 컴파일러로 작업을 시작했는데, 처음부터 메모리 누수 문제가 상당했다. Valgrind로 누수를 추적하고, 수많은 테스트 코드 작성 끝에 간신히 해결할 수 있었다. 처음에는 이 프로젝트를 JNI 인터페이스로 Java 라이브러리와 회사의 기반 라이브러리를 연결하는 모듈로 개발해 JAR 파일을 배포하는 방식으로 진행했다. 이후 리눅스 기반에서 개발한 코드를 윈도우 환경으로 포팅하여 엔지니어들이 쉽게 테스트할 수 있도록 하면서 프로젝트는 성공적으로 마무리되었다.
그러나 프로젝트가 끝난 후에도 C 파일과 GCC 컴파일러를 사용하는 것이 마음에 걸렸다. C/C++ 개발자라면 마땅히 Cpp 파일과 G++ 컴파일러를 사용해야 한다는 생각이 강했다. 그래서 이번 기회에 프로젝트를 C++로 마이그레이션하기로 결심했다. CentOS 6에서 CentOS 7로 마이그레이션하고 G++ 컴파일러로 변경하면서, 코드 구조를 보다 정돈할 수 있을 것이라 기대했다.
2. C to C++ 마이그레이션: 필요한 과정과 어려움
기대감 속에 본격적으로 C 코드를 C++로 마이그레이션하는 작업을 시작했다. 우선 C 파일의 확장자를 cpp로 바꾸고, GCC에서 G++로 컴파일러를 변경했다. 그다음으로는 각 cpp 파일마다 헤더 파일을 새로 작성하고, 필요한 클래스 구조를 만들며 public과 private를 구분하기 시작했다. 변수 사용이 유연해졌고, OOP 개념을 도입할 수 있었기 때문에 구조적으로 나아질 거라 확신했다.
하지만 작업이 진행될수록 예상치 못한 에러와 경고가 쏟아졌다. 빌드는 처음보다 더 복잡해졌고, 하나씩 문제를 해결해가며 warning과 error를 수정해야 했다. Google C++ Style Guide를 참고하며 클래스를 정의하고 함수와 변수의 접근 제어를 명확히 하려 했지만, 작업을 진행할수록 이 마이그레이션 작업에 대한 회의감이 들기 시작했다. 이렇게 많은 노력을 들여 코드를 C++로 변경하는 것이 과연 필요한가라는 의문이 떠오른 것이다.
3. 마이그레이션 과정에서의 혼란과 재고
C++로의 변환이 프로젝트에 필수적인 것이라 생각했지만, 점점 혼란에 빠지게 되었다. 기존 C 코드에서 잘 돌아가던 프로젝트를 굳이 갈아엎어야 하는 이유를 스스로도 명확히 설명할 수 없었다. 당장 새로운 코드 스타일과 클래스, std::string 같은 강력한 도구가 제공된다는 점에서 장점이 있지만, 애초에 코드가 잘 작동하고 있는데도 왜 이러한 변경을 시도하는지 의문이 들었다.
지금까지 나는 VSCode와 cpplint Extension을 사용하여 코드 규칙을 준수해왔고, 경고가 뜨면 고치고 규약에 맞추어 수정을 해왔다. 그러나 단순히 규약에 맞추는 것 이상의 이유가 필요했다. 이런 작업을 하는 근본적인 이유를 찾기 위해 다시 Google C++ Style Guide를 펼쳐 보고 진지하게 공부해볼 필요성을 느꼈다.
4. 마무리: 코드 스타일과 규약의 중요성
그동안의 작업은 툴이 지시하는 대로 따라가는 것이었다. 규칙에 맞추어 경고가 뜨면 수정하고, 규약을 준수하기 위해 코드를 바꿔왔다. 하지만 이러한 규약을 왜 준수해야 하는지, 왜 중요한지에 대한 확신이 부족했던 것은 부정할 수 없다. 최근 면접에서 스타일 가이드의 의미를 물었을 때, 고작 기억나는 규약 몇 가지와 헤더 가드에 대해 말하면서도 왜 이런 규칙을 따라야 하는지 명확히 설명하지 못했던 경험이 있다. 규약을 지킨다는 것의 진정한 의미를 이해하지 못했던 것이다.
그래서 이번에는 구글 코딩 스타일 규약을 단순히 따라하는 것이 아니라, 그 이유와 중요성을 제대로 파악하고 실무에 반영해보려 한다. 규칙은 단순한 틀을 넘어서 코드의 품질과 유지보수를 위해 존재한다. 이번 마이그레이션 경험을 통해 코드 스타일과 규칙의 진정한 의미를 이해하고 나아가려 한다.
'기술 노트' 카테고리의 다른 글
애자일 선언과 소프트웨어 장인 정신: 더 나은 개발을 위한 나의 다짐 (0) | 2022.02.10 |
---|---|
형상 관리 도구의 선택: Git, SVN, 그리고 DevOps 환경에서의 최적화 (3) | 2022.02.09 |
개발과 운영의 경계를 허물다: 데브옵스와 실무 경험기 (1) | 2022.02.08 |
CMake 입문: 빌드 자동화 기초와 실전 예제 (0) | 2022.01.29 |
GitLab Runner 설치 및 설정 가이드 (0) | 2022.01.21 |