사내 표준 프레임워크 개발기

회사에서 가장 당황스러웠던 건, 경우의 수를 정리된 규칙 없이 단순히 if 문으로만 처리하는 코드 스타일이었어요.

대부분의 동료들이 요구사항이 들어오면 장기적인 유지보수는 고려하지 않고, 눈앞의 문제를 해결하는 데만 집중하다 보니 코드가 점점 복잡해지고 관리하기 어려운 상황이 되더라고요.

이런 문제를 조금이라도 해결해 보고 싶어서, 퇴근 후 시간을 내어 회사에서 활용할 수 있는 프레임워크를 직접 개발해봤습니다.

우리 회사 서비스의 일부로, 다양한 장비에서 데이터를 여러 형태(PDF, XLS, CSV 등)로 내보내고 있습니다. 이 데이터를 수집한 후, 필요한 부분을 파싱하여 DB에 저장하거나 다른 서비스로 내보내는 시스템을 운영하고 있습니다.

그런데 기존 사내 코드의 가장 큰 문제는, 장비 하나가 여러 형식으로 데이터를 내보낼 때마다 if (장비, 파일 형식) {} 형태로 코드를 덕지덕지 붙여서 처리한다는 점입니다. 예를 들어, A라는 장비가 원래 TXT 형식으로 데이터를 내보내다가, 새롭게 PDF 형식도 지원하게 되었다고 가정해보죠. 그러면 개발자는 매번 if (장비…, 파일 확장자…) 같은 코드를 추가하며 대응해야 합니다.

이런 비효율적인 방식에서 벗어나 유지보수성을 높이기 위해, 개발을 했으며 최종적인 형태는 아래와 같습니다.

이제 우리 개발자들은 단순히 클래스를 하나 만들고, 해당 장비와 처리할 파일 형식을 명시해주기만 하면 됩니다. 그러면 프레임워크의 핵심 구성 요소인 Extractor 를 통해 데이터를 쉽게 파싱할 수 있도록 문자열로 넘겨줍니다.

개발자는 여기서 정규식을 사용하든, 더 편한 방법을 선택하든 원하는 부분을 추출하기만 하면 되죠. 덕분에 불필요한 if 문 추가 없이 깔끔하고 확장성 있는 구조로 개발할 수 있게 되었습니다.

(위 코드는 HPLC21 이라는 장비에서 떨어진 TXT를 처리하겠다 라는 뜻)

프레임워크 자체도 유지보수성을 높이기 위해 신경을 썼습니다. 위 코드에서는 InterfaceType.TXT를 명시했는데 TXT말고 일반적으로 사용하는 CSV, PDF, XLS 등 등이 있어요 이것들을 가공하기 편한 형태로 변환하는건 Extractor에서 처리하는데요

이런식으로 Extractor도 @Parser 와 마찬가지로 처리할 확장자를 명시함으로써 Extractor를 확장하거나 정의할 수 있도록 설계하였어요.

EZ..

모든 개발은 끝났어요 남은 건 월간 회의에서 이 프레임워크를 발표하고 사내 표준으로 이끌도록 최선을 다해야겠습니다.

(더이상 if 지옥은 그만.)