개요
서비스
미리보기
소개
- 서비스 명: SPACE, 스페이스
- 서비스 주제: 프로젝트 관리 툴
- 서비스 플랫폼: DESKTOP WEB
핵심기능
- 프로젝트를 생성해 팀원을 추가할 수 있다.
- TDD 칸반보드 형태로 업무를 관리할 수 있다.
- 업무는 회의의 안건과 실행 계획으로 참조할 수 있다.
- 업무와 회의에서 참조된 항목을 조회할 수 있고 바로 이동이 가능하다.
(자연스러운 업무-회의 순환구조) - 프로젝트 팀원과 메시지를 주고 받을 수 있다.
FBS
ERD
프로젝트
규모
- 기간: 한달
21.05.20 ~ 21.06.21 - 인원: 3명
- ✋ PM
도메인 설계, API 서버 기능 구현(회원, 프로젝트, 팀원, 메세지) - 👨💻
API 서버 기능 구현(업무, 회의) - 👩💻
React 화면 개발, 프로젝트 리팩토링, 배포
- ✋ PM
기술스택
- 언어
- Java
- Mysql
- JavaScript
- 프레임워크
- Spring Boot
- 라이브러리
- JPA
- Lombok
- Jasypt
- React
필요하면 만들자
1. 사건의 발단
1-1. 프로젝트 관리(협업) 툴
최소 1년에 1개 이상 프로젝트를 진행하는 나에게 매번 프로젝트를 진행할 때 마다 Tool에 대한 아쉬움이 있었다. 그나마 Notion으로 거의 유사하게 사용을 했지만 일반 팀원에게 짜여진 구조에 대한 설명을 하고 있자니 여간 번거롭고 사용까지 잘 이어지기 어렵기 일쑤였다. 예컨데, 표가 아닌 데이터 베이스의 개념을 설명을 해야하고 컬럼들의 종류 등 더 나아가면 관계형까지 설명을 해야했다. 그래서 쉽게 접근이 가능하고 직관적인 서비스를 찾아보았다. 생각보다 퀄리티가 좋아보이는 서비스들이 많이 있었다. 기대에 차 열심히 알아보았지만 되려 "기능이 많다" == "할 수 있는게 많다" == "자유도가 높다" == "일반 팀원이 어렵게 느껴한다"로 이어지거나 소수 그룹에게 제공하는 무료 플랜이 존재하지 않았다. 그리고 매달 내야하는 인당 요금제는 상당히 부담스러운 상태였다.
1-2. 너무 비싸다
이 단점들을 보완하는 대책이 직접 만들면 다 해결된다. 인당 기준 매달 내야하는 구독료의 합보다 AWS의 서버 비용이 낮으며 원하는 기능을 원하는 만큼 만들 수 있으니 말이다. 하지만 개발하는데 소요되는 시간과 노동력이 관건이였다. 마침 JPA 스터디를 진행하고 있었고 스케일도 크지 않으니 훈련도 할 수 있고 적당한 먹잇감으로 보였다.
2. 타겟 분석
2-1. 쉬워야 한다
프로젝트에는 IT 전공자들 이외의 인원들도 많이 참여한다. 노션이 아직까지는 높은 자유도 때문인지 입문에 심리적 거부감(?)을 느끼는 인원들이 많았다. 이왕이면 쉽고 간단한 사용에 포커스를 맞춰야 했다. 그래서서비스를 설계할때 최대한 단순하고 필요한 것만 챙기려고 신경을 많이 썼다.
2-2. 업무와 회의의 순환
굳이 노션을 벗어나야했던 큰 이유가 일을 하는 흐름을 잘 반영할 수 없었다는 것인데, 우리 크루에서 일하는 스타일은 이렇다. 아이디어, 브리핑, 피드백, 컨펌, 투표, 의사결정 등 어떤 회의이던지와 상관없이 회의를 통해 새로운 업무들이 발생한다. 그 업무들은 다시 회의를 통해 기록되어 마무리 지어진다. 그러기 위해서는 회의와 업무간의 참조가 필요하고, 이렇게 하나의 업무 흐름이 완성된다. 업무 내용을 파악하는 것도 용이해진다. 이 과정이 어렵지 않아야하는데 노션은 아쉽게도 대체 수단이 되지 못 했다. 그래서 이번 서비스에서는 손쉽게 업무와 회의를 참조하는 기능이 추가되었다.
익숙하지만, 낯설다.
1. 기술적 변화
이전까지는 MVC 패턴을 준수하는 Spring Framework를 사용하며 Controller에서 Data를 Model에 담아 JSP로 전달했다. 하지만 JPA 스터디 직후였고 새로운 개발 환경에서 작업을 하게 되며 겪은 차이점들을 적어보려고 한다.
1-1. Servlet ➡ REST API
이전에는 서버에서 너무 많은 역할을 하고 있었다. DB와 연결을 통해 Data를 주고 받으며, 서버 자체에서 Data를 가공하는 로직의 연산도 하며, 화면의 흐름제어와 동적 페이지 렌더링까지 웹 전반의 거의 모든 일을 도맡아 해왔다. 그런데 JPA를 사용하며 HTTP 프로토콜을 이용한 REST API 서버는 화면과 관련된 영역을 프론트 서버로 완전히 논리적으로 분리시켜놓은 듯 했다. 데이터의 입력/출력, 필요한 형태로 데이터를 정제 및 가공하는 역할만 오롯이 맡게된 것이다. 명확하게 WAS 서버와 클라이언트를 분리한 덕분에 멀티 플랫폼에도 대응하기 유리해졌다. 하지만 프론트 작업은 WEB 서버를 통해 별개로 관리 해야해서 성능상으로 이점을 가져오지는 못 한다고 한다.
1-2. MyBatis ➡ JPA
Mybatis는 Mapper에 일일히 사용할 쿼리들을 직접 작성하고 객체와 매핑하여 SqlSession에서 호출해서 사용해야 했다. 웹 개발을 하며 제일 지긋지긋한 시간이였던 것 같다. 그리고 의미없이 반복적인 작업을 해야하는 부분이였다. Spring Data JPA를 사용하면 이 시간들이 말끔히 사라진다. 기본적인 CRUD는 이미 자동으로 설정되어있어 이 구간을 생략할 수 있다. 그리고 이외의 쿼리는 쿼리 메소드를 이용하여 아주 쉽게 네이밍룰만으로도 추가할 수 있다. 더 복잡한 쿼리라면 JPQL을 사용하면 된다. 그리고 다이나믹하게 쿼리를 구현해야한다면, QueryDSL을 사용할 수 도 있다. 이 부분에서도 프로젝션을 이용해 엔티티 자체를 조회하거나 객체를 접근하듯이 엔티티의 요소들을 접근할 수도 있다. 말도 안되는 혁신이다. 영속성 컨텍스트를 잘 이해하고 나면 말이다.
1-3. Spring ➡ Spring Boot
Spring Boot는 Spring의 상위 버전이라기 보다 REST API를 개발하는 프로젝트를 위한 전용 무기같은 느낌이였다. 그래서 REST API 개발에 최적화되어 생략된 기능들만큼 설정도 줄어들었고, 그마저도 중요도가 높지 않은 셋팅을 자동으로 구성해주었다. Dependency도 ' spring-boot-starter-* '를 제공하고 있어 추가하면 메이븐이나 그래들을 통해 필요한 라이브러리들을 자동으로 추가해준다. Spring 공식 사이트의 이니셜라이저를 하면 바로 실행이 가능한 코드를 제공해주기도 한다. 프로젝트를 셋팅하는 일이 엄청나게 간소화되어 시간 절약할 수 있어 좋았지만, 차이를 상세하게 알지 못하는 만큼 찜찜함도 가지고 있어서 나중에 더 공부 하는 시간을 가져야 겠다.
1-4. Maven ➡ Gradle
Maven은 외부 라이브러리를 손쉽게 네트워크를 이용해 받아줄 뿐만 아니라, 프로젝트의 Clean, Build, Site 등 전체적인 라이프 사이클을 관리하는 도구이다. 그리고 Gradle은 빌드 배포 도구로서 라이브러리 관리, 프로젝트 관리, 의존성 관리를 도와준다. 큰 차이점은 XML형태의 프로젝트 환경설정(POM, Project Object Model)로 Maven은 작성해야하고, Gradle은 Groovy라는 별도의 스크립트 언어를 사용해 동적인 환경설정이 가능하다고 한다. 가장 크게 느낀점은 속도가 메이븐에 비해 빠르며 스크립트가 매우 직관적이라는 것이 인상깊게 남았다.
2. 관점적 변화
2-1. 생산적 개발을 위한 위임
개발을 하다보면 마법같이 시간과 노력을 단축시키는 장치들이 있다. 반복문과 어노테이션같은 경우 그렇다. 그렇게 효율과 생산적인 것에 비중을 두는 직업군이고 그런 환경을 조성하게 위해서도 많은 개발자들이 일을 하는데 이상하리만큼 단순 노동이 잦을 때도 많았다. 그런데 점점 그런걸 보완하는 대안들이 생기고 있다. 예를 들어 이번 프로젝트에서는 MyBatis에서 쿼리를 작성하는 것을 JPA를 사용하면서 단순반복을 줄인게 가장 크고, Spring Framework의 Bean을 이용한 DI도 그렇다. 그리고 아직 공부를 해보지는 않았지만 DDD를 도입한 프로젝트를 본적이 있는데 중복 로직을 방지하는 등 유지보수의 이점도 있고 불필요한 작업들이 줄어들어 있었다.
다양한 방법으로 반복되는 일련의 작업들을 위임한다는 발상, 그것을 위해 한층 더 치밀하게 설계하며 핵심 로직에 더 집중한다. 백엔드의 묘미가 강화된 것 같다. 같은 결론을 두고도 더 나은 설계적, 운용적, 효율적인 방법을 채택하게 위해 항상 첨예하게 고민한다. 무너지지 않는 모래성을 보는 것 같다. 너무 멋진일이다.
2-2. 책임자의 역할
중요한 것, 필요한 것에 집중할 수 있게 된 대신 그에 따라오는 책임도 있다. 시스템을 운용하는 관리자적 설계가 필요해졌다. 로직을 고안할 때도 단순히 기능 범위를 넘어섰기 때문에 넓은 전문성을 요하게 됐고, 설계와 매핑의 중요도가 더 높아졌다. JPA를 예로 들면 엔티티와 테이블을 정확하게 매핑을 해야한다. 연관관계를 매핑할때도 미리 빈도를 잘 고려해 단방향과 양방향을 결정해야한다. 최적화를 위한 영속성 컨텍스트의 특징들을 모른다면 골치아픈 상황에 처할 수도 있다. 숲도, 나무도 모두 중요해졌다.
마무리
회고를 작성하다보니 그때는 잘 못느꼈지만 정말 도움이 많이 됐구나라는 생각이 다시금 든다. 아이디어가 목적이 아니라 JPA 스터디였다 보니 학습에 포커스를 맞추기 수월했다. 처음에는 직관적이지 않다고 생각했다. 명확하지 않다고 생각해서 찜찜했고 낯선데 어렵다고 느꼈다. 그런데 프로젝트 셋팅하고 엔티티 매핑이 끝나고 로직을 구현하고 완벽하게 API로 분리해서 Postman 으로 테스트하는 과정이 신기하고 즐거웠다. 아직 공부해야할 것들이 많지만 그래도 완전히 모르던 미지의 영역에서 탈출시켰다.
