프로젝트 소개

※ 이 발표는 프로젝트 소개 그리고 회고와 고난을 다룹니다.

기술도 규칙도 내가 정하는 사이드 프로젝트를 했다. 왜냐하면 내가 PM이자 PL이었기 때문이다.

왜 했는가?

회사에 들어온 지 3년 차부터 나는 부서의 운영 업무를 관리하기 위한 프로젝트에 여러 번 참여했다. 우리 회사는 내부 사정으로 Github나 Jira 같은 시중에 나온 이슈 관리 시스템을 쓸 수가 없어서 직접 개발해야만 했다. 아쉽게도 길게 이어진 하나의 프로젝트가 아니라 단발성 프로젝트여서 주어진 하나의 논제만 해결할 뿐 전체적인 개선은 하지 못했다. 그리고 과거에는 사용자 경험을 전혀 고려하지 못해서 내가 사용하면서도 불편했고 그 감정은 곧 부채가 되었다.

일종의 기술 부채가 남아있던 나는 KPI를 정할 때 운영 업무 관리, 즉 Back Office 시스템을 만들고 싶다고 건의했다. 놀랍게도 나의 의견은 바로 받아들여졌고 부서의 사이드 프로젝트로 내가 PM이자 PL을 맡을 수 있었다.

같이할 사람

같이할 사람을 구하는 건 생각보다 쉬웠다. 사내 스터디를 운영하고 있기에 스터디 내에서 같이 사이드 프로젝트를 할 사람을 쉽게 구했다. 사이드 프로젝트이지만 아직 주니어인 내가 PM인데도 개의치 않고 지원해 준 후배들에게 감사를 표한다.

일단 옮겨보자

내가 제일 처음 내린 결론은 우선 운영 업무 관리 시스템을 별도의 시스템으로 분리하는 것이었다. 운영 업무 관리가 다른 시스템에 곁다리 식으로 하나씩 끼워져 있어서 상징성이나 유연성이 부족했다. 팀원들과 새로 만들 사이트 이름, 기술, UI, 인증 방식 등을 상의했다. 이렇게 상의하는 것만으로 그림이 완성되는 기분이었다.

처음 한 일

운영 업무 관리 시스템은 사용자가 우리 부서 사람이기 때문에 그만큼 피드백이 즉각적이었다. 여러 번 만족 혹은 불만의 소리를 들었던 나는 사이트를 기획하기 전에 먼저 시장조사와 민심 조사에 나섰다.

사용자 경험 개선하기

조사 결과 역시나 UI/UX의 불만이 많았다. 특히 긴 스크롤과 여러 가지 팝업에 대한 불만이 많아 먼저 레이아웃을 효과적으로 변경했다. 레이아웃을 변경하고 나서 세부적으로 단계를 기획할 때는 장정 3일간 10시간의 시간이 걸렸다.

해 사용자 경험을 개선하기 위해서 기능 목록을 사용자별로 분류해 보았다. 그러자 출구가 보이는 것 같았다. 기존 데모 버전은 모든 사용자가 동일한 페이지를 써서 개발이 복잡해지고 스크롤이 길어지며 느렸다. 한 페이지로 다 할 수 있다는 장점도 있지만 좀 더 사용자를 명확하게 나누기 위해 사용자별로 메뉴를 나누기로 했다.

사용자

• 이슈 등록 : 등록 – 사용자 테스트 – 최종 완료
• 승인 : 이슈 승인
• 개발 : 개발 – 테스트 요청 – PR 요청 – 최종 확인 요청
• 리뷰 : PR 승인
• QA : 내부 테스트

프로젝트 개발 및 회고

JWT

사이트를 독립한다고 했을 때 가장 중요한 문제는 인증 방식이었다. 다른 사내 시스템을 통해 들어왔을 때 바로 인증이 가능해야 하고 혹시나 나중에 프로젝트를 MSA로서 API 서버로 다루는 것도 고려해야 했다. 이때 여러 가지 대안 중에 가장 적합한 기술이 바로 JWT였다.

짧은 JWT 설명

• 서버와 클라이언트를 분리
• 인증 정보를 클라이언트에서 관리
• 페이지 요청에서는 사용자 정보를 가져올 수 없다.

회사에서 JWT를 써 본 경험도 없고 개인적으로 사용해 보는 것도 처음이라 애로가 많았다. 마침 인프런에 무료 강의가 있어 데모로 한 번 만들어 보고 이해는 했지만, 문제는 프로젝트 팀원과 부서 사람들에게 JWT를 이해시키는 거였다. 우선 데모로 만들어진 코드를 팀원들에게 1시간 동안 설명하고 직접 해보게 했다. JWT나 Security는 특히나 직접 하면서 깨닫는 점이 많았기 때문이다.

JWT는 인증 정보를 클라이언트에서 관리하다 보니 서버에서는 사용자 정보를 알 수 없다는 점이 생각보다 큰 변곡점이 되었다. 먼저 프론트도 SPA로 구성해야 했고 외부에서 인증 시 CORS 등 여러 가지 문제를 해결해 줘야 했다.

SPA

클라이언트에서 인증 정보를 꺼내어 서버에 확인받은 다음 API를 호출하고 컴포넌트를 그려야 했기 때문에 React.js나 Vue.js와 같은 프레임워크/라이브러리의 도움이 필요했다. 그나마 React가 익숙한 터라 React를 하고 싶지만, 아직 회사에서는 React를 도입하지 않았기 때문에 쓸 수 없었다. 그래서 간편히 CDN으로 Import할 수 있고 모던 자바스크립트로 구성할 수 있는 Alpine.js를 선택했다. React보다 코드가 다소 늘어나지만, 사용하는 경험은 나쁘지 않았다.

Data

회사에서는 Mybatis에 과거 MVC 모델을 사용하고 있었다. Model을 View에서도 사용하고 DB에서도 사용하다 보니 관리가 전혀되지 않고 클래스 변수가 무지막지하게 늘어나기 마련이었다. 그리고 여러 가지 RDBMS를 써야 하는 탓에 JPA를 쓰자는 고려는 있었지만, 아직 도입되지 않고 있었다. 그래서 신규 프로젝트는 Mybatis를 사용하되, JPA를 고려해서 디자인해야 했다. 그래서 아래와 같이 Mybatis ResultMap을 사용하여 JPA를 쓴다고 가정하고 도메인을 설계했다.

변경된 것

• Mybatis ResultMap 사용
• DB Layer / View Layer 분리
• Lombok, Enum 사용

개선된 것

• 데이터를 안전하게 사용
• Validation 용이

Mybatis의 ResultMap이 사용하기 까다로워서 관련 에러만 대처하면 오히려 깔끔해져서 개발이 더 편해졌다. 그러나 개발이 진행되다 보니 문제가 하나 생겼다. JPA에서는 Pageable이나 Sort를 제공하지만 Mybatis를 사용하면 Pagenation이나 Sort를 쿼리와 함께 직접 구현해야만 했다. 고민하다가 사용한 방법이 직접 Spring Data에 있는 Pageable과 Sort 인터페이스를 가져와서 구현체만 바꿔치기했다. 만약 나중에 JPA를 도입한다면 import만 바꾸면 작동할 것이다. 일종의 템플릿 메서드 패턴에서 착안했는데, 그때 한창 디자인 패턴을 공부하고 있었기에 떠올릴 수 있었다.

같이 하는 방법

사이드 프로젝트는 나를 포함해서 총 3명으로 구성되었다. 소수의 인원이다 보니 피드백이 빠르다는 장점이 있지만 각각 역량의 중요도가 높다 보니 기술적 부담감이 있었다. 그래서 우리는 소규모로 코드 리뷰를 도입했다. 3명이 서로의 강점과 격차를 해소하기 위해서는 코드 리뷰가 가장 효율적일 것 같았다.

먼저 내가 아래 규칙과 방법을 정리한 다음 팀원에게 공유했다.

• 정적 코드 검사 Sonarlint
• Commit 규칙
• Pull Request 양식
• Pull Request 방법

코드 리뷰를 도입했더니 업무가 배로 늘어났다. 양식을 지켜서 PR을 올리고 다른 사람이 올린 PR을 리뷰하다 보니 어떨 때는 코딩하는 시간보다 리뷰하는 시간이 더 길 때도 있었다. 그래도 서로 리뷰에 익숙해지고 문제점을 하나씩 깨닫다 보니 리뷰하는 시간은 줄고, 코딩하는 시간이 충분히 확보되었다.

구조에 대한 고민

정적 코드 검사인 Sonarlint를 적용하긴 했지만 사실 가장 어려운 부분은 도메인 설계와 같은 구조적 문제였다. 그런 부분은 PR을 올릴 때 자세히 확인하지 못하기 때문에 한 번씩 오프라인 코드 리뷰를 하기 전에 스스로 체크해 볼 수 있으면 했다.

마침 백기선 님의 더 자바, 애플리케이션을 테스트하는 다양한 방법 강의를 보고 있었기 때문에 강의에 나오는 ArchUnit을 적용해 보기로 했다. ArchUnit은 의존 관계나 상속 관계 등 구조를 확인할 수 있는 테스트 도구이다.

Archunit의 Usecase를 참고하여 팀원들과 협의하여 우리 프로젝트에서 지켜야 할 구조적인 규칙을 설정했다. 그래서 각자 PR을 Sonarlint와 Archunit 테스트를 미리 실행해 보고 올리게 되어 기본적이거나 반복적인 이슈는 PR전에 미리 해결할 수 있었다.

회고

이번 프로젝트는 처음 써보는 JWT와 JPA를 쓰지는 않지만 쓰는 것 처럼 개발해야 하는 점이 가장 어려웠다. 그래도 잘 따라와 준 팀원 덕분에 서로 배워가며 성장할 수 있는 계기가 됐다. JPA와 Refresh Token을 위한 Redis를 도입하고 싶었지만 올해 퇴사하면서 안타깝게 진행하지 못했다.

이번 프로젝트는 자의로 내가 PM이자 PL이 되긴 했지만 내가 모든 것을 알고 있고 결정할 수 있는 사람이라고는 생각하지 않았다. 내가 주도적으로 나서되 팀원들의 의견은 모두 들어보고 싶었다. 최대한 고민했는데 어땠을지 모르겠다. 부서 인원이 적기 때문에 나를 평가해 줄 수 있는 사람이 적은 게 아쉬웠다.

다음 프로젝트는 어떤 걸 할지 아직 모르지만, 이번만 같아라.