👀 사건의 전말

지난 6월, 대구SW마이스터고의 교내 입학전형시스템 개발을 담당하게 된 나는 선배들로부터 인수인계를 받게 되었다. 이 서비스의 백엔드는 원티드랩에 합격한 선배, 그리고 무려 토스에 합격한 선배 등 우리 학교의 실력자들이 작성한 것이였기에 나는 유지보수/운영 업무를 통해서 많은 것을 배워갈 수 있을 거라 기대했다.

하지만.. 그것은 열어서는 안될 판도라의 코드였다.

뭐가 문제였는데?

일단 이 코드가 가진 문제점은 크게 2가지 분류로 나눌 수 있었다. 첫번째는 우리가 흔히 코드 스멜이라고 부를 만한 것들이였고, 두번째는 그것보다도 더더욱 심각한 보안 문제였다.

아래 나온 것들은 가장 대표적인 문제들을 정리해 본 것이다.

[코드 스멜] Controller에서 비즈니스 로직 수행

이 부분은 코드 스멜이라고 하기에는 좀 애매한 면이 존재하지만, 위에서 문제들을 2가지 분류로만 나누었기에 여기에서 서술한다.

제목 그대로, Controller에서 비즈니스 로직을 수행하는 문제가 존재했다. 그나마 파일과 관련된 컨트롤러에서만 이처럼 코드가 작성되어 있어서 다행이였지, 만약 모든 컨트롤러가 위 사진과 같이 구성되어 있었다면.. 아마 유지보수 과정에서 지금보다도 더 많은 자원(= 시간)을 낭비해야 했을 것이다.

[코드 스멜] 장황한 메서드

이 문제는 합격자 산출 로직이나 엑셀 자료 생성 로직(신입생 선발담당 선생님들의 편의를 위해 지원자들의 명부를 엑셀 파일로 생성해 주는 서비스)을 담당하는 메서드들에서 많이 발견할 수 있었다. 물론 구현을 위해 복잡한 계산식 또는 코드를 요구하다 보니 어느 정도는 메서드가 길 수 있다는 걸 짐작하고는 있었지만, 30줄에 달하는 난해한 코드에서 문제가 발생할 경우 버그를 수정하려면 엄청난 노력을 필요로 하게 될 것은 불 보듯 뻔한 상황이였다.

실제로 신입생 선발 기간(= 서비스 운영기간)이 되어서야 합격자 산출 결과에 심각한 문제가 존재한다는 것을 발견하게 되는 비상 상황이 발생하게 되었고.. 결국 나는 정규 수업시간을 빼 가면서까지 장황한 메서드를 디버깅해가는 뼈 아픈 일을 겪게 되었다.

[코드 스멜] 방대한 클래스

서비스 Interface 별 메서드 갯수를 확인해보니, 평균적으로 10~20개 사이의 메서드가 존재했다. 확실히 메서드 수가 많다는 것을 알 수 있다. 게다가 앞서 말한 장황한 메서드와 합쳐진 탓에, 심한 경우에는 서비스의 구현체 클래스가 900~1,000 라인에 달하는 경우도 발생하였다. IDE에서 제공하는 텍스트 찾기 기능이 없었다면, 아마 기능 하나 수정하는 데에 최소 하루는 잡아야 했을 것이다.

[보안] 비밀번호 평문 저장

이 서비스를 인수인계 받기 1년 전 쯤, 선배에게 Spring Boot를 배우다 비밀번호 해시랑 솔트값에 관한 개념을 여쭤본 적이 있었는데, 이 때 선배가 솔트는 소금이잖아 ㅋㅋㅋ라고 말한 적이 있었다. 나는 이 선배가 지금 장난으로 이러는거겠지?라고 생각했지만.. 그 선배가 그렇게 답한 이유를 드디어 알 수 있었다.

2022년 지원한 신입생들의 비밀번호는 평문으로 저장되었던 것이였다. 프로젝트의 어느 곳에서도 비밀번호를 해시하는 로직은 찾아볼 수 없었다. 결국 나는 이 문제를 해결하기 위해, Spring Security 라이브러리를 의존성에 추가한 뒤 인증 로직에 추가하는 조치를 취하게 되었다. (이 문장에서 알 수 있다시피, 사실 이 프로젝트의 인가 로직은 Spring Security가 아니라 Interceptor로 직접 구현되어 있었다)

[보안] 개인정보 평문 저장

그나마 이 문제의 경우, 다른 학교(대덕 등)의 입학전형시스템도 암호화를 진행하지는 않는 것 같다고 판단되었기에 우리만의 문제는 아니였다. 하지만 그렇다고 개인정보를 평문 저장해도 된다는 의미는 아니였기에 이 문제의 경우에는 앞선 비밀번호 평문 저장과 마찬가지로 내가 단방향 암호화 로직을 추가하여 문제를 해결하게 되었다.

새롭게 만드는 서비스

결국, 나는 위에서 언급한 것처럼 서비스를 힘들게 유지보수/운영하며 버텨 나갔고, 2023년도 신입생 선발을 끝마친 10월이 되어서야 자유의 몸이 될 수 있었다. 그리고 그 동안 받은 스트레스로 인해 동아리의 PM직을 내려놓게 되었다. (새 PM직은 나보다 더 실력 있는 친구에게 넘기게 되었다)

그리고 얼마 안 있어, 수학여행과 기말고사 등 굵직한 일정들로 인해 입학전형시스템은 내 기억속에서 잊혀진 흑역사가 되었다. 12월 말이 되기 전까지는..

기말고사가 끝나고 할 일이 없어지자, 나는 할 일을 찾다가 다시 입학전형시스템을 떠올리게 되었다. 입학전형시스템 운영은 매년 2학년들이 운영하기에, 내년 신입생 모집때에는 1학년 친구들이 이 코드를 또 힘들게 유지보수하고 운영해야 한다는 것을 깨닫고 나서, 후배들이나마 입학전형시스템을 운영하면서 받을 스트레스를 줄일 수 있게 서비스를 처음부터 다시 만들기로 결정했다.

👷 설계

그렇게, 새로운 PM 친구와 함께 새 입학전형시스템(앞으로는 IDA라고 부르겠다)을 개발하는 먼 여정을 떠나게 되었다.

스택

문제의 IDA 백엔드는 사실 Kotlin으로 작성되어, Java를 중심으로 하던 나와 새 PM 친구에게는 너무나도 유지보수하기 어려운 코드였다. 따라서 IDA 백엔드의 새 버전은 Java로 작성하기로 결정하였다.

데이터베이스의 경우, 진입장벽이 낮은 MySQL을 그대로 사용하기로 하였다. 다만 DB 스키마의 경우 정규화가 되어 있지 않은 기존 스키마를 사용할 수 없었기에 새로 작성하게 되었다. 또한 기존 서비스에서 동일한 연산을 여러번 반복하여 성능이 저하된 사례를 목격하였기에, 캐시 목적으로 Redis도 추가하기로 결정했다.

ORM의 경우 Spring Boot JPA를 기반으로 하고, 복잡한 쿼리를 사용하기 위해 QueryDSL을 추가로 붙여 사용하기로 결정했다.

최종적으로 다음과 같은 스택으로 구성되었다:

• 언어: Java
• DB: Mysql(MariaDB), Redis(캐싱 목적)
• Library: Spring Boot JPA, QueryDSL

아키텍처

본래 새 버전의 IDA는 MSA 기반으로 제작될 예정이였다. 하지만 시간이 촉박하다는 점, 그리고 MSA를 구성할 만큼의 트래픽이 발생하지도 않는데다 예산도 넉넉하지 않다는 점을 고려해 추후 MSA로의 전환이 수월한 헥사고날 아키텍처(Hexagonal Architecture)를 사용하기로 하였다.

예전에 대덕소프트웨어마이스터고 친구들과 함께 프로젝트를 진행할 때 헥사고날 아키텍처를 사용해 본 적이 있었는데, 당시 프로젝트 구성은 gradle 기반의 멀티모듈로서 아래와 같이 이루어져 있었다:

• Root Project
  • Domain 모듈 - 도메인 비즈니스 로직
  • Infrastructure 모듈 - API(Application Programming Interface) 및 SPI(Service Provider Interface)

이렇게 모듈이 Domain과 API/SPI로만 구분이 되어있었기에, 개발할 때 파일/디렉터리들이 워낙 많아서 IDE가 난잡해지는 문제가 발생한 적이 있었다.

그래서 이번 개발에는 모듈을 Domain과 API/SPI로 구분함은 물론, 거기 내에서도 도메인 별로 모듈을 나누어 개발 시 생산성을 높이고자 하였다. 아직 개발에 들어가지 않아서 추측일 뿐이지만, 나중에 MSA로 전환할 때에도 이렇게 구성하는 편이 훨씬 편리할 것이라 생각이 된다. (도메인 별로 모듈들이 나눠지기 때문에 MSA 프로젝트를 생성할 때에도 기존 코드를 옮기기에 더 편리하기 때문에..? 이런 추측을 해 보았다 물론 추측이 잘못되었을 가능성도 높다..)

최종적으로 IDA의 멀티모듈은 다음과 같이 구성될 것이다:

Root Module
├── Domain-Layer
│   ├── User domain
│   ├── Score domain
│   ├── Admin domain
│   └── ...
└── Application-Layer
    ├── Http API (for all domains)
    ├── User SPI (for User domain)
    ├── Score SPI (for Score domain)
    ├── Admin SPI (for Admin domain)
    └── ...

Http API(Spring Boot 기반)마저 도메인별로 분리해버릴 경우 Spring Boot에 의존하는 프로젝트가 너무 과하게 많아진다는 문제점이 있기에, HTTP API의 경우 하나의 모듈로 통합하기로 했다.

코드 작성 규칙

코드를 작성할 때에는, 앞서 언급된 문제점들이 발생하지 않도록 하기 위해 여러가지 조치를 취하고, 규칙도 정하기로 했다.

먼저 기본적인 코드 스멜을 잡기 위해, Sonarcloud를 이용한 CI를 설정하기로 하였다. 특히 장황한 메서드를 막기 위해서 메서드별 라인 제한 규칙도 적용 가능한지 찾아볼 예정이다.

👋 마무리하며

이렇게 입학전형시스템을 개발하는 새로운 여정이 시작되었다. 앞으로 2월 초까지 IDA의 개발 현황, 그리고 개발하면서 겪은 문제점과 해결책들을 Velog에서 공유하고자 한다.

프로젝트가 잘 완성되어 올해 신입생 선발 업무는 수월하게 진행될 수 있기를.