시작하며
담당업무
- 서비스 기획, 업무 분담 및 일정 조율 100%
- 기능 정의, ERD 등 개발 문서 작성 70%
- 도메인 설계, API 서버 기능 구현(회원, 프로젝트, 팀원, 메시지) 100%
기술스택
| 언어 |
|
| 서버 |
|
| 프레임워크 |
|
| API, Library |
|
| 데이터베이스 |
|
| IDE |
|
어려움과 극복
첫 API 서버 구축하기
프로젝트를 준비하며 JPA와 HTTP에 대한 이해를 쌓기 위해 공부했다. 낯설고 복잡했던 개념들이었지만, HTTP의 기본 지식과 자바 ORM 표준 JPA 프로그래밍 - 기본편을 교재를 통해 스터디를 진행했다. 하지만 당연하게도 이론 공부와 실제 적용 사이에는 괴리가 있었다. 특히, 연관관계의 주인을 혼동해 ‘mappedBy’ 설정 실수와 ‘@Transactional’ 어노테이션을 적용하지 않아 데이터가 제대로 업데이트되지 않는 문제는 꽤나 고민을 안겨주었다. 엔티티 매핑 문제는 해결한 후에도 한참을 더 고민해보아야했다. 다행스럽게도 JPA를 경험이 풍부한 동료 개발자의 피드백을 받아 신속하게 해결하고 넘어갈 수 있었다.
API 테스트
서비스의 중요한 부분인 API가 프론트엔드에서 호출되지 않는 문제에 직면했다. 코드를 뜯어보아도 원인을 찾기 어려웠는데, 이는 나와 프론트 담당 (백엔드)개발자 모두 해당 기술이 처음이었기 때문이었다. 고심 끝에, POSTMAN을 이용해 API를 직접 테스트하기로 결정했고, 그 결과 서로의 실수를 발견하고 수정할 수 있었다.
업무와 회의가 참조되는 아이디어
이번 기획의 핵심은 프로젝트 관리 서비스이지만 ‘기존 업무가 안건이 되어 회의를 진행한 뒤 결정된 사항은 새로운 업무로 추가한다.’라는 흐름이었다. 우리 크루는 노션에서 이와 같은 방식으로 진행중이었는데 이 과정이 복잡하고 수기로 작성하는게 너무 불편했었다. 제대로 된 서비스로 기획화하는 과정에서 어느 단계에서 어떤 방식으로 참조하고 확인하게 할지 정하는 것이 참 어려웠다. 번호로 업무와 회의를 연결하는 초기 아이디어도 있었지만, 불편함에서부터 서비스 기획이 기인된 만큼 회의를 중심으로 업무 검색을 따로 구현해 안건과 결정 사항을 추가하는 형태로 마무리됐다. 업무의 상세정보에 참조된 회의를, 회의의 상세정보에 참조된 업무를 확인할 수 있다.
배운 점
항상 새로운 기술과 환경에 적응하는 과정은 흥미롭다. 이번 프로젝트를 통한 경험은 나의 기술적 관점을 확장시켜준 것 같다. 이전의 Spring Framework와 MVC 패턴을 사용하여 Controller를 통해 Model 데이터를 JSP에 전달하는 방식에서 벗어나, 새로운 개발 환경에서 작업을 하게 되며 겪은 차이점 위주로 적어보려고 한다.
Servlet ➡ REST API
이전에는 서버에서 너무 많은 역할을 하고 있었다. DB와 연결을 통해 Data를 주고 받으며, 서버 자체에서 Data를 가공하는 로직의 연산도 하며, 화면의 흐름제어와 동적 페이지 렌더링까지 웹 전반의 거의 모든 일을 도맡아 해왔다. 그런데 JPA를 사용하며 HTTP 프로토콜을 이용한 REST API 서버는 화면과 관련된 영역을 프론트 서버로 완전히 논리적으로 분리시켜놓은 듯 했다. 데이터의 입력/출력, 필요한 형태로 데이터를 정제 및 가공하는 역할만 오롯이 맡게된 것이다. 명확하게 WAS 서버와 클라이언트를 분리한 덕분에 멀티 플랫폼에도 대응하기 유리해졌다. 하지만 프론트 작업은 WEB 서버를 통해 별개로 관리 해야해서 성능상으로 이점을 가져오지는 못 한다고 한다.
MyBatis ➡ JPA
Mybatis는 Mapper에 일일히 사용할 쿼리들을 직접 작성하고 객체와 매핑하여 SqlSession에서 호출해서 사용해야 했다. 웹 개발을 하며 제일 지긋지긋한 시간이였던 것 같다. 그리고 의미없이 반복적인 작업을 해야하는 부분이였다. Spring Data JPA를 사용하면 이 시간들이 말끔히 사라진다. 기본적인 CRUD는 이미 자동으로 설정되어있어 이 구간을 생략할 수 있다. 그리고 이외의 쿼리는 쿼리 메소드를 이용하여 아주 쉽게 네이밍룰만으로도 추가할 수 있다. 더 복잡한 쿼리라면 JPQL을 사용하면 된다. 그리고 다이나믹하게 쿼리를 구현해야한다면, QueryDSL을 사용할 수 도 있다. 이 부분에서도 프로젝션을 이용해 엔티티 자체를 조회하거나 객체를 접근하듯이 엔티티의 요소들을 접근할 수도 있다. 말도 안되는 혁신이다. 영속성 컨텍스트를 잘 이해하고 나면 말이다.
Spring ➡ Spring Boot
Spring Boot는 Spring의 상위 버전이라기 보다 REST API를 개발하는 프로젝트를 위한 전용 무기같은 느낌이였다. 그래서 REST API 개발에 최적화되어 생략된 기능들만큼 설정도 줄어들었고, 그마저도 중요도가 높지 않은 셋팅을 자동으로 구성해주었다. Dependency도 ‘ spring-boot-starter-* ‘를 제공하고 있어 추가하면 메이븐이나 그래들을 통해 필요한 라이브러리들을 자동으로 추가해준다. Spring 공식 사이트의 이니셜라이저를 하면 바로 실행이 가능한 코드를 제공해주기도 한다. 프로젝트를 셋팅하는 일이 엄청나게 간소화되어 시간 절약할 수 있어 좋았지만, 차이를 상세하게 알지 못하는 만큼 찜찜함도 가지고 있어서 나중에 더 공부 하는 시간을 가져야 겠다.
Maven ➡ Gradle
Maven은 외부 라이브러리를 손쉽게 네트워크를 이용해 받아줄 뿐만 아니라, 프로젝트의 Clean, Build, Site 등 전체적인 라이프 사이클을 관리하는 도구이다. 그리고 Gradle은 빌드 배포 도구로서 라이브러리 관리, 프로젝트 관리, 의존성 관리를 도와준다. 큰 차이점은 XML형태의 프로젝트 환경설정(POM, Project Object Model)로 Maven은 작성해야하고, Gradle은 Groovy라는 별도의 스크립트 언어를 사용해 동적인 환경설정이 가능하다고 한다. 가장 크게 느낀점은 속도가 메이븐에 비해 빠르며 스크립트가 매우 직관적이라는 것이 인상깊게 남았다.
결과 및 성과
매년 최소 한 번은 프로젝트를 진행하면서 기존의 관리 툴들이 늘 아쉬웠다. Notion은 그나마 나은 대안이었지만, 팀원들에게 복잡한 구조를 설명하는 일이 번거로웠다. 데이터베이스의 개념부터 시작해 관계형 구조까지, 팀원들에게는 높은 진입 장벽으로 작용했다. 저는 누구나 쉽게 사용할 수 있는 직관적인 서비스를 찾아보았지만, 아래의 문제가 있었다.
- 기능이 많고 자유도가 높을수록 팀원들이 사용하기 어려워한다.
- 소수 그룹에게 제공되는 무료 플랜이 없다.
- 인당 부과되는 구독료는 상당히 부담스러운 상태였다.
비싸지 않다
직접 서비스를 개발하면 비용에 대한 문제가 해결된다. AWS 서버 비용이 서비스 구독료를 훨씬 경제적이긴 하다. 원하는 기능을 맞춤형으로 구현할 수 있는 장점도 있었다. 그러나 개발에 필요한 시간과 노력은 만만치 않아 보류 중이었다. 다행히 JPA 스터디를 진행 중이었고, 프로젝트의 규모도 크지 않아 학습과 실습을 겸할 수 있었다.
쉬워야한다
프로젝트에는 IT 전공자 이외의 인원들도 많이 참여한다. 노션의 높은 자유도가 오히려 사용에 부담을 주었기에, 이왕이면 간단하고 쉬운 사용자 경험에 중점을 두었다. 서비스를 설계할때 최대한 단순하고 필요한 것만 챙기려고 신경을 많이 썼다.
마무리
회고를 작성하다보니 그때는 잘 못느꼈지만 정말 도움이 많이 됐구나라는 생각이 다시금 든다. 처음에는 직관적이지 않다고 생각했는데 오히려 더 직관적이라고 생각된다. 명확하지 않다고 생각해서 찜찜했고 낯선데 어렵다고 느꼈다. 그런데 프로젝트 셋팅하고 엔티티 매핑이 끝나고 로직을 구현하고 완벽하게 API로 분리해서 Postman 으로 테스트하는 과정이 전부 신기하고 즐거웠다. 반복되는 일련의 작업들을 위임한다는 것. 한층 더 치밀하게 설계하여 핵심 로직에 더 집중할 수 있다. 백엔드의 묘미가 강화된 것 같다.