서론

초기에 한국기술교육대학교에 KAP라는 동아리가 설립되었고, 이 때 node.js를 기반으로 KOIN 플랫폼이 만들어졌다.

하지만 유지보수가 안된다는 문제점에 봉착하면서 해당 프로젝트는 php, Laravel로 개편되었다. 이를 다른 인원이 이어받아 프로젝트가 진행되고 있었다.

2018년도에는 KAP 동아리가 BCSDLab 동아리로 개편되면서 Koin 프로젝트는 Spring3으로 변경되었다. 정확히 이 때 참여한 인원이 아니라 Spring을 사용하는 주된 이유 듣지 못했지만 예상컨데 국내에서 가장 많이 사용되는 프레임워크이기 때문이 아닐까 조심스래 생각해본다.

이 외에도 비용 문제로 인한 인프라 개편, 동아리 운영을 위한 다양한 행사, 꾸준한 교육과정 개편, 지식의 선순환을 위한 멘토제 도입 등 많은 노력이 있었기에 지금의 BCSDLab이 유지될 수 있었으며 한기대 커뮤니티 서비스인 Koin 또한 지속적으로 운영될 수 있었다.

이렇게 좋은 환경을 만들어주신 선배님들께 감사합니다 🙇‍♂️

KOIN

때는 2020년 코로나 및 동아리 부원의 입대 이슈가 겹치면서 KOIN 프로젝트는 간신히 유지보수만 수행되고 있었다.

나는 많은 기능이 구현되어있고 많은 기술이 적용되어있는 KOIN 프로젝트의 온보딩을 수행하면서 그 때 당시 기능 추가는 엄두에도 안났다.

이 때문이였을까 1년동안 프로젝트에 대한 문서화만 하다가 입대를 하기도 했었다.

입대하는 과정에서 일어나는 인원의 부재와 이로 인한 작업의 연기에 클라이언트, 서버 트랙원 간의 일정을 맞추기 어려운 상황도 종종 생겼다.

이 사이에 기능 축소도 일어나면서 API를 제거하는 상황도 있었다.
당시에는 API를 제거하는 과정에서 일어나는 사이드 이펙트를 고려할 수 없었기 때문에 일단 코드를 주석처리하고, Deprecated 어노테이션을 달아두는 등 임시 방편 정도의 조치를 하는것이 대부분이였다.

문제 인식

이러한 환경 속에서도 동아리에서는 학교 주변의 가게 사장님들을 위한 기능을 기획하고 개발하기 시작했다.
이 때 백엔드에는 사장님과 관련한 기능이 기존에 작성되어 있었고, 이 코드는 Deprecated 상태로 남아있었다.
백엔드는 이 코드를 다시 활성화하고 코드를 유지보수하는 것이 개발의 대부분이였다.

이런 경험은 새로운 기능을 개발하면서 학습을 진행하고자 하는 BackEnd 인원들의 성장욕을 만족시키지 못했다고 나는 생각한다.

앞으로 들어올 신규 부원들에게 어떤 작업을 할당해줘야할지도 많은 고민이 든다.

6개월간 비기너 과정에서 학습한 내용과는 다소 괴리감이 큰 레거시를 다루면서 과연 유의미한 동아리활동이라고 생각할 수 있을지 의문이 든다.

자연스래 프로젝트에 대한 애정도 떨어지고, 또 다시 유지보수해야하는 활성화된 레거시만 늘어난 셈이 되기 마련이라는 생각이 든다.

무엇을 할 수 있을까?

과거에 node를 Lalavel로, Lalavel을 Spring으로 바꿔오면서 주된 핵심은 유지보수가 핵심이였다.

이번에 봉착한 문제 또한 유사하게 유지보수와 관련된 문제라고 생각된다.

백엔드 트랙의 Spring 코드의 대부분은 과거에 짧은 시간 내에 구현된 코드들이다. 당시에 개발하는 기간만 해도 굉장히 촉박했을 것이라고 여겨지기 때문에 인수인계 및 교육에 대한 부분을 많이 신경쓰기 어려웠을 것이라고 생각된다.

현재 동아리 내 프로젝트 인수인계 환경에 대해서 현 레귤러 인원들에게 피드백도 구하기도 했다.
현재 온보딩 과정은 문서와 키워드만 던져주고 알아서 학습해오라는 방식으로 진행되고 있었고, 이 과정이 꽤나 불친절하게 다가왔었다는 피드백을 받았다.

2020년도 레귤러로 전환되었던 나도 인수인계를 위해 확인할 문서조차 없었을 때였던지라 인수인계를 위한 문서를 만드는게 온보딩의 대부분이였다.

가장 공수가 많이 들었던 부분은 아무래도 Spring3 프로젝트를 구동하는 환경을 구성하고 배포하는 흐름, 설정 및 동작방식 등을 이해하는 부분이였다고 생각한다.

하지만 공수를 들였음에도 내가 작성한 문서는 알아보기 쉽지 않았고, KOIN에 사용중인 모든 기술을 이해하기에도 한참 부족하기도 했다.

이러한 공수를 줄이고 온보딩을 보다 효율적으로 개선할 수 있는 방법으로 SpringBoot 마이그레이션을 고려해볼 수 있겠다고 생각한다.

SpringBoot 마이그레이션

현재 Spring 3로 구성되어있는 프로젝트는 많은 xml 파일과 부수적인 환경설정, 의존성 관리로 인해 관리 포인트가 많은 상황이다.

Spring 3라는 환경은 외부 라이브러리를 사용할 때 버전을 다운그레이드 해야하는 상황 또한 계속해서 고려하게 만들기도 한다.

레거시 살펴보기

KOIN 프로젝트를 직접 확인해보는 시간을 가져보자.

Spring 코드

코드가 어떤 방식으로 구현되어있는지 확인해보자.

의존성

Maven으로 의존성을 관리하고있다.

SpringBoot가 아니기 때문에 라이브러리 버전을 일일히 Spring 버전과 호환되는지 확인하고 관리하고 있는 모습을 확인할 수 있다.

설정

servlet-context.xml, web.xml, root-context.xml 등 spring과 관련된 다양한 설정들이 xml로 수동 관리되고있다.

이러한 설정을 어떻게 인수인계해야할지.. 구성원들이 어떻게 받아들일지 고민이 된다. 위에서 이야기했다시피 Spring을 1달만에 배우고 이 모든 설정을 이해할 것을 기대하기는 결코 쉽지 않다고 생각한다.

Bean 관리

몇몇 Bean은 xml로 관리되는 모습도 종종 확인할 수도 있다.

필드주입도 자주 발견할 수 있었다.
이는 런타임 시점까지 순환참조를 발견하기 어려운 위험성을 내포하고 있기도 하다.

인프라

인프라와 관련된 부분도 살펴보자

Ubuntu

배포 환경은 AWS EC2를 사용중이다.
현재 Production을 운영중인 Ubuntu 버전이 16.04.6 버전인 부분이 눈에 들어온다.

우분투 릴리즈 노트를 확인하면 16.04 LTS 버전에 대한 보안적인 업데이트 지원이 2021년 즈음 종료되었음을 확인할 수 있다.

(보라색으로 표기된 부분은 Ubuntu Pro에 대한 추가적인 지원사항이다.)
급하진 않지만 안정적인 릴리즈를 제공하고 있는 버전으로 업데이트가 필요해보이긴 한다.

DB

MySQL 버전은 5.7.33 버전을 사용중이다.
마이SQL 5.7 지원 종료 대비하기라는 기사를 보고 DB 버전 업그레이드의 필요성을 생각해보긴 했지만 아직 버전 업그레이드 과정에서 발생할 수 있는 사이드이펙트를 충분히 고려하지 못했기 때문에 해당 부분은 섣불리 판단하기 어렵다고 생각했다.

아직 관련한 지식이 부족한 부분도 있기 때문에 계속해서 공부해보고 보다 명확한 이유를 찾아봐야겠다고 생각한다.

마이그레이션

Regular 인원들이 보다 생산성있고 높은 참여도를 보여줄 수 있는 환경을 만들어보자는 취지로 Spring을 SpringBoot로 마이그레이션 하는 과정을 기획해보려고 한다.

배포

현재 사용자가 존재하는 서비스이기 때문에 기존 서비스를 유지하면서 새로운 프로젝트를 함께 사용할 수 있도록 구성해야한다.

지금은 2개의 WAS를 구성하고 새로 구성한 API 엔드포인트에 대해서 신규 WAS로 포트포워딩을 해주는 방식을 고려하고있다.

대략적으로 다음과 같이 생각중이긴 하다.

2개의 EC2로 띄우고 ELB를 사용해도되겠지만 동아리 서버비를 절약하기 위해 하나의 EC2에서 WAS를 2개를 띄우는 방향으로 생각해봤다.

DB

신규 WAS도 기존의 DB를 바라보게 구성한다. 필요한 값에 대해서는 쿼리로 조회하여 작업을 수행한다.

기존 KOIN의 DB 테이블 개수는 66개이고 연관관계가 여기저기 얽혀있다.
어느정도 영향이 있는지 기능 범위 파악을 거친 뒤 결정해봐야 할 것 같다.

추가적으로 생각해볼만한 부분으로는 DB서버의 분리가 있을 것 같다.
DB 서버와 Tomcat이 같이 존재하는 환경이기 때문에 DB서버 분리가 필요하다. WAS 2개와 DB를 띄울만큼 메모리가 충분한지는 의문이다.

만약 여차저차 해서 DB서버를 분리한다 해도 동아리 서버비는 여전히 고려해야할 문제이기도 하다.

코드

점진적으로 마이그레이션을 진행해 나갈 예정이다.

이미 기존 API를 사용중인 클라이언트들이 있기 때문에 API 엔드포인트에 대한 부분은 유지를 하면서 마이그레이션을 진행해야한다.
때문에 Controller 및 DTO의 형태는 정해져있다.

다만 새로운 프로젝트의 기술스택 및 개발환경, 팀 컨벤션 등 협업을 위한 다양한 사안들을 정해야한다는 부분을 조금 더 체계화 해야 할 것이다.

정리

BCSDLab의 KOIN 프로젝트가 지금까지 어떤 과정을 거쳐 개발되고, 유지되고있는지 그 과거를 알아보는 시간을 가졌다.

추가로 레거시를 살펴보고 마이그레이션 계획도 아주 간단하게 정리해봤다.

SpringBoot로 마이그레이션을 진행하면서 어떤 과정을 겪게 될지는 아직 미지수다. 물론 혼자서 총대메고 SpringBoot로 전환할 수도 있겠지만 나는 지속 가능한 프로젝트를 만들고 싶은 목적으로 이 작업을 기획하고 실행하려고 한다.

기존의 온보딩 방식(키워드 및 문서 위주의 방식)이 구성원들의 자발적인 학습을 유도하는 것은 이해하나 적어도 어떤 환경에서 서비스가 운영되고 있고, 지금 프로젝트가 어떠한 방향성을 가지고 있는지, 팀이 일하는 방식과 문화 등 함께 일하기 위한 최소한의 친절함이라도 묻어있는 그런 온보딩이 구성되었으면 하는 바램이다.

이러한 바램을 현실로 만들기 위해, BCSDLab이라는 조직을 함께 일하고싶은 조직으로 만들기 위해 점진적으로 개선해나가보려고 한다.