[게시판 어드민 서비스] 프로젝트 회고

황인권·2024년 8월 22일

Java Spring Spring boot

Spring 게시판 서비스

목록 보기

9/9

1인 개발로 진행해온 게시판 어드민 서비스 프로젝트가 마무리가 되어 프로젝트 동안 겪었던 내용을 정리해놓고자 합니다.

프로젝트에 대한 세부 내용은 깃허브 README로 대체합니다.

https://github.com/dlsrnjs125/project_board_admin

1. 프로젝트 시작 이유 및 선택

이전 게시판 서비스 프로젝트를 만들게 되면서 이를 관리하기 위한 어드민 서비스 프로젝트를 만들어봤다.
게시판 어디민 서비스 문제 정의는 게사판 관리자로서, 내부에서 접근하는 서비스 운영자 관점에서 만들었다.

가장 중요한 부분이 이전에 만들었던 프로젝트의 데이터를 받아와 사용해야 한다는 점을 중요하게 생각했고 그 점을 위주로 공부했다.

2. 기술 스택 선택 이유

Java 17

Java는 플랫폼 독립성을 제공하여 다양한 운영체제에서 실행될 수 있으며, 모듈화를 통해 재사용성을 높일 수 있음
Java 17 버전은 장기적인 지원을 제공하여 호환성과 안전성을 보장하며, 최신 기술과 트렌드에 대한 지원을 통해 다음 세대 프레임워크로의 마이그레이션이 용이함.
Spring Boot 3.0부터는 Java 17이상을 지원한다는 점도 고려

Spring Boot

Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 된다.
의존성 관리를 위한 스타터(starter) 패키지를 제공하여 필요한 라이브러리들을 쉽게 추가 가능
간단한 설정을 통해 스프링을 편리하게 사용할 수 있도록 지원

Spring JPA

Java 객체과 관계형 데이터베이스 테이블 사이의 매핑을 자동으로 처리해준다.
데이터베에스 관련 작업을 단순화하고 추상화하여 SQL 쿼리를 직접 작성하지 않아도 된다.
CRUD 작업을 위한 간단한 메서드를 제공하여 반복적인 작업을 간소화 시켜준다.

PostgreSQL

복잡한 쿼리, 대규모 데이터 처리, 고도의 병행성이 요구되는 환경에서 뛰어난 성능을 발휘한다.
널리 사용되는 오픈소스 관계형 데이터베이스이다.

Thymeleaf

Java 기반의 서버 사이드 템플릿 엔진으로, 웹 애플리케이션의 뷰를 생성하는 데 사용된다.
Spring Framework와의 통합이 원할하여 Spring의 컨트롤러와 모델 데이터를 템플릿에 쉽게 전달이 가능하다.
HTML을 직접 작성할 수 있어서, 템플릿을 서버 없이도 테스트할 수 있는 기능을 제공한다.

Oauth2

웹, 앱, 모바일 앱, 서버간 통신 등 다양한 클라리언트 유형 및 상황에 맞게 설계된 여러 인증 흐름을 제공한다.
토큰 기반의 인증 방식으로 제한된 기간동안에만 유효하며, 보안 위협을 최소화한다.
애플리케이션의 사용자 암호를 직접 다루지 않고 사용자의 데이터에 접근하도록 한다.

Lombok

Java 언어의 반복적인 코드를 줄이고, 코드의 가독성과 유지보수성을 향상시켜준다.
유용한 애노테이션을 제공하여 특정 설게 패턴을 쉽게 구현할 수 있게 해준다.

GitKraken

Git 클라이언트로 다양한 기능을 통해 Git workflow를 더욱 효율적이고 직관적으로 관리할 수 있게 도와준다.
시각적이고 직관적인 인터페이스를 제공하여 복잡한 히스토리와 브랜치를 쉽게 이해하고 관리할 수 있게 해주며, 명령어를 별도로 입력하지 않아도 된다.
Undo, Redo 기능이 존재하여 로컬에서의 작업을 되돌리고 싶으면 언제든지 되돌릴 수 있다.

Spring WebSocket

실시간 양방향 통신을 실시간으로 수행할 수 있다.
Spring Framework와 완벽하게 통합되어 있어 보안, 메시징등을 쉽게 사용할 수 있고 Spring Security와 잘 어울려 사용된다.

AdminLTE 3.2

미리 만들어진 UI 컴포넌트로서 반응형 디자인을 기본으로 하며, 다양한 환경에서 구현이 쉽게 가능하다.
다양한 스킨과 테마를 기본 제공하며, 개발자가 필요에 따라 쉽게 커스터마이즈를 할 수 있도록 설계되어 있다.
차트, 달력, 데이터 테이블 등 다양한 플러그인을 기본으로 제공해주며 관리 패널에서 자주 사용되는 기능들을 쉽게 추가할 수 있다.

3. 배우거나 얻은 점

전체적인 개발흐름을 이해할 수 있었던 것

이번 프로젝트는 아무것도 없이 시작한것이 아닌 전체적인 아키텍쳐와 ERD등을 먼저 구상하고 그에 따라서 옆길로 새지 않고 해당 내용만 탑다운 방식으로 진행했다.

개발을 함에 있어서 구현도 중요하지만 다른 여러가지 작업들이 중요하다는 것을 느끼게 되었다.

요구사항 분석
설계
구현
테스트
배포
유지보수
문서화
프로젝트 관리

이러한 각 단계를 통해 소프트웨어 개발이 체계적으로 진행될 수 있으며, 효과적인 결과를 도출할 수 있게 된다. 각 단계는 서로 연계되어 있고 각 단계에서의 결정과 작업은 다음 단계에 영향을 미치기 때문에 전체적인 흐름을 이해하는 것이 중요하다.

특히 프로젝트에서 요구사항 분석이 중요하다고 느꼈다. 요구사항 분석이 제대로 되어야 어떤 기능을 도출해야할지 정해지고 구현 방안의 기획이 잡히고 개발을 시작할 수 있기 때문이다.

Git 관리

이전에는 프로젝트를 구현할 때 모든 작업을 마치고 Github에 한번에 올리는 등의 방식을 사용했는데, GitKraken을 이용하여 Github에 각 개발과정을 세세하게 분리해서 관리할 수 있었다.
특히 개인 프로젝트이지만 브랜치를 나누어 진행하고 Github의 issue와 pull request등을 활용함으로써 작업을 분리하고 효율적으로 관리하며 협업에 대한 연습을 할 수 있었다.

테스트 코드, 문서화의 중요성

테스트 코드 작성 과정에서도 어려움을 겪었지만, 처음으로 테스트용 데이터베이스를 연결하여 통합 테스트도 작성해보고, 외부 영향을 받지 않고 내가 작성한 코드만 테스트하는 단위 테스트도 작성해보면서 테스트에 대한 이해도를 높일 수 있었다.
이전에 했던 프로젝트에서는 테스트코드를 작성하지 않은채 기능 구현 위주로 프로젝트를 진행했다.

그러던 중 기능이 점점 복잡해지고 코드의 양이 쌓여가면서 왜 그렇게 사람들이 테스트, 주석, 문서화와 같은 기본기의 중요성에 대해 말하는지 알 수 있었다.

내가 무엇을 만들고 있는지 정확히 인지

개발자는 주로 요구사항을 분석하여 설계 후 구현하는 일을 하는데 가장 중요한 것이 요구사항을 제대로 분석하는 일이다. 그리고 반드시 요구한 항목을 최대한 구현해야 한다.

테스트 코드를 작성하면서 요구사항의 기능적인 항목들을 차분히 정리하는 과정을 경험할 수 있고, 이때 발생할 수 있는 예상외의 코너 케이스를 찾을 수도 있다.

테스트 코드가 없다면 프로젝트 진행 속도가 현저히 느려진다.

테스트 코드를 작성하지 않을 때는 기능 하나를 작성하고 UI를 직접 보면서 기능이 원하는대로 잘 구현되어있는지, 문제는 없는지 확인을 했다.
서버를 재시작해가면서 기능의 동작여부를 확인하다가 기능들이 많아지고 점점 진행속도가 현저히 느려지게 될 것이다.
테스트 코드가 없는 프로젝트에서는 새로운 기능을 추가하는 것도 힘들겠지만, 기존 기능을 수정하는 것은 더욱 어려운 일이될 것이다.
하지만 테스트 코드가 있다면 수정이나 구조 변경 후에도 기능이 요구사항에 맞게 정상적으로 작동하는지 검증할 수 있게 된다.

주석과 문서화가 없다면 어떻게 동작하는지 알기 힘들다.

프로젝트를 시작하고 며칠, 몇주까지는 모든 기능들이 어떻게 동작하는지 기억에 남아있고 이땐 이걸 이렇게 사용해야지 했지만 테스트 코드의 경우처럼 기능들이 많아져 복잡해지고 시간이 지나면서 문제가 발생했다.
작성할 당시에는 어떻게 동작하는지 알고 있었지만 시간이 지난 뒤는 기능이 어떻게 동작하는지 알지 못하는 상황이 온것이다.
본인이 작성한 코드를 한참 들여다보고 내부 코드를 이해하면서 시간을 쓰는 동안 남을 위해서가 아니더라도 나를 위해서 상세한 주석과 문서화가 필요함을 느꼈다.
이를 프로젝트상에도 문서화 했지만 각 기능별로 브랜치를 나누어 진행하여 Git에 Issue정리와 pull request를 함으로써 문서화를 하여 각 기능들에 대한 문서화를 진행했다.

API Mocking 테스트

이번 프로젝트의 단위 테스트를 진행하면서 API Mocking테스트를 진행했다.
지금까지는 DB에서 데이터를 가져와서 테스트를 진행해서 아무런 문제가 없었지만 API를 사용해서 데이터를 받아오는 프로젝트이기 때문에 생각해야할 부분이 Mocking 작업이다.

Rest방식의 API를 호출할 수 있는 Spring의 내장 클래스인 RestTemplate을 사용했다.
Json, xml등의 응답을 모두 받을 수 있으며 프로젝트에서 사용된 데이터 형태는 json이기 때문에 사용

실제 API 모듈을 사용해서 데이터를 가져오게 되면 여러 문제점들이 있을 수 있다.

아직 개발되지 않은 모듈에 의존한다면 테스팅 / 개발이 어려움
다른 모듈에 의해 테스트 결과가 바뀔 수 있어, 독립적인 테스트를 진행할 수 없음
원하는 형태의 데이터로 테스트를 하고 싶을 때 하지 못한다.

그래서 API를 진짜로 테스트 할것인가 가짜로 테스트할 것인가에대해서도 고민해봐야 한다.
그럴 때 사용할 수 있는 방식이 Mocking 방식인데 이러한 방식을 사용하게 될 경우
데이터의 소스가 외부의 것이고 외부 서비스의 변경에 흔들리지 않는 서비스를 만들 수 있게된다.
또한 지속적인 빌드와 배포에 큰 장점이 될 수 있다.

API 호출은 네트워크나 서버 등 외부요인에 의존적이므로 테스트의 신뢰성이 떨어진다. 하지만 Mocking 방식은 다양한 케이스를 재현하고 대응할 수 있다.

하지만 Mocking 만을 사용해서는 진짜 API가 서비스 상태인가 확인이 불가능 하므로 Nested 어노테이션을 활용해서 두가지 모두를 테스트 진행했다.

UI Framework (AdminLTE)

보통 개발자는 CSS 또는 Image를 만들거나, 수정할 일이 거의 없고, 특히 디자이너가 없을 경우 Web 개발 시 디자인을 수정하거나 추가할 경우 난감한 경우들이 있다.

그래서 이번에 사용하게 된 것이 UI Framework인 AdminLTE이다.
가장 큰 장점은 전체적인 UI의 대부분을 제공한다고 보면 된다.
특히 AdminLTE는 Bootstrap을 기반으로 만든 UI Framework이므로 Bootstrap + DataTable + DataPicker 등등 여러가지 플로그인을 조합해서 하나의 커다란 툴로 만들어져 있어서 관리자(어드민) 페이지를 만드는데 백엔드 쪽의 개발에 더욱 신경을 써볼 수 있었다.

4. 시도해보고 싶은 점(아쉬운 점)

다른 사람과 협업을 해볼 기회가 없었던 점

다른 사람과 함께 깃플로우를 이용하여 깃관리도 해보고 컨플릭션도 겪어보고 슬랙, 지라같은 협업툴도 써보고 싶었으나, 해당 프로젝트를 진행하며 그럴 기회가 없었던 점이 아쉽게 남았다.
혼자서 상황을 가정해보고 시뮬레이션을 진행해보는 것은 아무래도 한계점이 크고 문제를 해결한다는 느낌이 들지 않았고 서로의 코드를 리뷰하고 서로간의 더 좋은 코드를 위해 아이디어를 개선해보지 못한 것등도 아쉽게 남았다.

배포

프로젝트 완성 후 배포를 해보는 것이다. 개발하는 과정도 중요하지만 실제 사용자가 이용할 수 있도록 배포하는 것도 중요하고 그 과정에서 많은 문제들도 발견할 수 있다.
그렇기 때문에 AWS와 같은 개발 환경을 공부하여 배포를 해보도록 하겠다.

황인권

inkwon Hwang

이전 포스트