H-UP은 문서 기반의 프로젝트 관리 플랫폼입니다.
Notion의 문서 작성 기능과 Jira의 일정 관리 기능을 결합하여, 프로젝트를 보다 효율적으로 관리하고 팀원들과의 협업을 간편하게 할 수 있는 서비스를 제공합니다.
현재 많은 기업들이 프로젝트 관리 및 협업을 위해 여러 도구를 사용하고 있습니다.하지만 각각의 협업 도구들을의 다음과 같은 불편한 점들이 있습니다.
- Notion : 노트, 업무, 할 일 관리, 데이터베이스 등의 기능을 지원하는 온라인 올인원 협업 도구
- 장점
- 실시간 문서 동시 편집
- 단점
- 분산된 자료들을 찾는 어려움.
- 장점
- Jira : 프로젝트 내 이슈 추적, 관리 툴
- 장점
- 구조화된 일정 상태 관리로 협업을 도움
- Kanban, Scrum 등 프로젝트 일정, 현황 파악
- 단점
- 한 눈에 파악하기 힘든 프로젝트, 업무 내용
- 장점
- 다양한 협업툴 : 각 도구마다 다른 인터페이스와 기능을 가지고 있어 사용자들이 학습 및 적응하는 데 어려움을 겪을 수 있음.
- 팀 관리
- 팀 생성과 초대 기능으로 멤버 간 프로젝트 관리 및 협업
- 문서 기반 이슈 관리
- 이슈를 실시간 동시 편집이 가능한 문서로 관리
- MD 기반으로 간편하게 작성
- 프로젝트와 업무 내용을 한눈에 파악 가능
- 일정 관리
- 칸반보드를 이용하여 이슈 상태를 간편하게 관리
- Drag & Drop 으로 상태 변경 가능
- 할 일과 의사결정 현황을 한눈에 파악
- 캘린더 기능으로 일정을 간단하게 조정
- Drag & Drop 으로 일정 변경 가능
- 칸반보드를 이용하여 이슈 상태를 간편하게 관리
- 로그인화면
- 회원가입
-
사이드바
-
-
이슈 탭
-
칸반 탭
-
-
할일 탭
- 의사결정 탭
-
캘린더
-
� -
이슈
-
- IntelliJ UE 2023.3.5
- Visual Studio Code
- AWS EC2 lightsail
- Ubuntu 20.04
- Docker 25.0.4
- AWS S3
- React 18.2.0
- vite 5.2.0
- Java OpenJDK 17
- SpringBoot Gradle 3.2.5
- websocket 2.3.3
- Spring Data JPA
- Spring Data Redis
- Spring Data mongodb
- Spring Security
- Lombok
- MySQL 8.3.0
- Redis 7.2.4
- MongoDB 7.0.8
- Jenkins 2.440.3
- docker-compose 1.29.2
- nginx 1.18.0
- JIRA
- Git
- Notion
| 이름 | 역할 | 맡은 기능 |
|---|---|---|
| 이경태(PM) | BE | |
| 손현조 | BE | |
| 강용민 | BE | |
| 김은비 | INFRA | |
| 김성욱 | FE | |
| 김한중 | FE |
- 김성욱
- SockJS와 Stomp를 이용해 프론트엔드에서 실시간 통신을 구현하는 과정
- Stomp와 SockJS를 다루는 것은 처음이었기 때문에 구독과 발행이라는 개념을 이해하는데 오래 걸렸음. 공부한 결과, 구독이라는 과정 자체가 데이터를 받아오는 것을 뜻하고, 발행이라는 과정이 데이터 변화가 생길 때 데이터를 구독자에게 전달하는 과정을 뜻하는 것이었음. 또한, connect와 disconnect를 다루는데 주의할 필요가 있었고, 그 함수들이 언제 작동하는지 이해할 필요가 있었음. disconnect를 하고 난 뒤에 connection이 필요한 함수가 작동되지 않도록 주의할 필요가 있었음.
- Yjs를 이용한 동시편집 기능 적용 과정
- CRDT 알고리즘이 내장되어있는 Yjs 라이브러리를 통해서 문서의 업데이트 사항을 전달하는 과정이 필요했음. 다행히 BlockNote는 Yjs와 호환이 되었고, WebSocket을 통해서 전달받은 데이터를 ydoc에다가 저장하는 과정이 필요했음. 이때, Uint8Array로 전달받은 데이터를 ydoc에다가 지정하는 함수를 찾는 과정이 힘들었음. 공식문서를 찾고 GPT를 활용한 결과 Y.applyUpdate함수를 통해서 변경사항을 저장할 수 있었음.
- BlockNote의 블록 커스터마이징
- 블록노트에서 한 줄에 여러 개의 요소를 표시하고 싶었으나, 한 줄에는 하나의 요소만 표시할 수 있다는 문제가 있었음. 이를 해결하기 위해서 propSchema를 사용해서 한 줄에 여러 개의 문서를 표기할 수 있었고, 커스터마이징을 잘 하기 위해서는 안내되어있는 공식문서를 꼼꼼히 읽고, 이것 저것 기능을 만져봐야 한다고 느꼈음.
- 주저하지 말고 요청할 것은 백엔드에게 요청할 것
- 의사결정 ItemContainer 안에 있는 사진의 데이터가 null로 전달되어 이미지가 저장된 이미지가 아닌 기본 이미지로 표기되는 문제가 있었음. 알고보니 백엔드 쪽에서 의사결정 조회 결과로 반환하는 데이터 중에서 img 데이터를 반환하지 않는 문제가 있었음. 요청하면 바로 해결되는 문제였는데 초반부에 백엔드에게 요청하지 않고 다른 데이터를 통해서 구현할 수 있는지 연구를 했었는데, 이렇게 하면 시간이 더 소요되고 코드도 복잡해지는 문제가 있으니 주저하거나 미안해하지 말고 백엔드에게 요청해야 하는 것은 바로 요청하고, 백엔드 측에서도 비슷한 내용의 피드백을 받았음. 실무에서는 요청할 것은 바로 요청해야 한다고 느꼈음.
- SockJS와 Stomp를 이용해 프론트엔드에서 실시간 통신을 구현하는 과정
- 김한중
- 칸반 보드는 Recoil로 전역상태관리를 통하여 형제 컴포넌트 간 상태 공유가 가능하도록 하였습니다. 이전에 React를 거의 다뤄보지 못했으나 인터넷 검색 등으로 얻은 참고 자료들을 통하여 경험적으로 학습하면서 Drag & Drop 같은 기능들을 구현할 수 있었습니다.
- 캘린더의 경우는 React-Big-Calendar 라이브러리를 이용하였으나, 공식 문서의 설명이 완전하지 못한 부분과 관련된 기능들은 제대로 구현할 수 없었습니다. 저희가 개발한 소프트웨어를 다른 사람들이 사용하는 경우, 구현한 기능에 대한 문서화를 제대로 해야 할 필요성을 알 수 있었습니다.
- 손현조
- 웹소켓 끊김 문제
- WebSocket 메시지 Content Length 16500byte 초과 시 WebSocket 연결 끊김 발생
- 메시지를 10000byte의 Chunk로 나누어 전송
- 메시지와 Chunk에 번호를 부여하여, 수신 측에서 모든 번호의 Chunk 수신 시 문서 내용을 업데이트하도록 적용
- 느낀점
- 테스트 중요성 : 테스트를 통해 WebSocket 연결이 끊기는 점을 찾음
- CS 중요성 : Packect을 Chunk로 나누는 개념에서 착안하여 적용함
- 강용민
- 가장 어려웠던 점 : 설계의 미흡. 전체적인 요구사항에 대한 설계가 미흡해 후에 개발할때 예상치 못한 기능 추가나 수정들이 자주 발생했음. 또한 일정에 대해 제대로 확인할 수가 없어 서로 이해하는 부분이 상이했던 경험이 있었음.
- 극복해낸 점 : 설계 하나하나 다시함. 최대한 생각해낼 수 있는 자잘한거 까지 컴포넌트 하나하나 까지. 담당자도 지정했음. 그랬더니 일정이 파악되고 소통에도 한층더 수월해졌음.
- 프로젝트를 하면서 느낀 부분 : 설계는 개발만큼 중요하다
- 이경태
- JWT 토큰의 유효성 검증 문제
- 원인 : Access-Token의 만료 시간 때문에 서비스 이용 중 “만료된 토큰” 이라는 에러가 출력됨.
- 해결 : 토큰 자동 갱신 로직 구현
- axios interceptor를 이용하여 만료된 토큰으로 API 호출 시 갱신 요청 후 재발급된 토큰으로 원래의 API를 다시 호출하는 방식으로 해결함
- JWT 특성 상 상태가 없기 때문에 서버에서 관리가 힘듦. Redis로 유효 토큰 목록을 관리하고 TTL을 활용해 자동 만료를 관리함.
- 데이터 동기화 문제
- 원인 : 서버의 데이터 변경이 클라이언트에 실시간으로 반영되지 않아 데이터 불일치 발생
- 해결 : Tanstack query 사용한 Custom hook, Recoil을 활용한 클라이언트 측 업데이트 여부 관리
- refetchInterval을 이용한 주기적인 데이터 갱신. onWindowFocus를 활용해 창 포커스 시 갱신.
- 클라이언트 측에서 데이터 변동 시 Recoil을 통해 업데이트 여부를 알림. useEffect로 이 값이 변동 시 API 호출하여 서버 측에 반영.
- 설계 시 패키지 구조 관련 갈등
- 원인 : 팀원들 간 패키지 구조 설정 시 도메인 형과 계층형의 장단점이 혼재되어 의견이 갈림.
- 해결
- 혼합형 구조 채택 : 계층형을 기반으로 하되 서비스 레이어를 도메인 별로 분리. 로직 수정 시 해당 도메인의 패키지만 보면 되기에 편의성 향상.
- Repository default 화 : Repository의 접근 수준을 default로 변경. 해당 도메인의 서비스에서만 접근할 수 있도록 하여 보안성을 높힘.
- Facade 패턴 도입 : 해당 서비스로만 도메인에 접근 가능. 여러 도메인을 참조하는 기능의 경우 Facade 패턴을 도입하여 도메인간 의존성 관리와 코드 가독성을 높힘.
- 느낀 점
- 설계의 중요성 : 개발 진행 중 추가되거나 변경되는 API가 많아 진행속도에 영향이 있어 철저한 설계의 중요성을 배울 수 있었습니다.
- 업무 분담 및 진행현황 관리 : 진행도를 정확히 파악할 수 없어 앞으로 남은 업무가 무엇인지 알기 힘들었습니다. 이를 통해 일정 관리 및 업무 분담이 중요함을 알 수 있었습니다.
- JWT 토큰의 유효성 검증 문제
- 김은비
- Docker 사용
- docker를 사용하는 이유와 docker의 장점을 이해하며 사용함으로써 기존 방식에서 오는 불편함을 깊이 있게 이해할 수 있었고 docker 사용 의의를 느낄 수 있었습니다.
- Jenkins 사용
- 코드를 자동을 배포해주는 로직을 이해할 수 있었습니다.
- 느낀점
- 다양한 툴들이 서로 상호작용하며 간편한 배포를 구현해주는 로직을 이해할 수 있었습니다.
- Docker 사용