어제 스타트업 인턴즈 교육에 참석해 개발 일지의 중요성을 깨닫게 되었다.
그래서 당장 오늘부터라도, 개발 일지를 작성하고자 한다.
개발 일지 작성 이전에, 기존의 작업을 정리하는 차원에서 글을 작성한다.
프로젝트를 시작하게 된 계기
프로젝트를 시작하게 된 계기는 기존 졸업 프로젝트로 개발한 SIMS를 개선하기 위함이다. 학기 중 수업을 들으며 FE와 BE를 동시에 개발하는 것은 생각보다 힘든 일이었다. 그래도 기한 내에 '돌아가는' 프로그램을 만들기는 했지만.. 너무 많은 기술적 부채를 남겨두었다. 특히 BE는 졸업 프로젝트라고 내놓기 민망할 정도였다. 따라서 본 프로젝트를 통해 BE 개발에만 집중하여 보다 수준 높은 서버 코드를 작성하고자 한다.
프로젝트 목표
1. RESTful API 개념 적용
기존 SIMS server는 전혀 RESTful 하지 않았다. 본 프로젝트를 진행하면서 RESTful API를 학습하며 실제로 프로젝트에 적용하고자 한다.
2. DB 구조 개선
SIMS는 위성 데이터의 스키마 변경에 유연히 대응할 필요가 있다. 이 부분은 메타데이터 엔티티에 데이터 테이블 이름을 저장하고, 엔티티에 저장된 테이블명을 통해 실제 데이터 테이블을 조회하는 방식으로 구현했다. 구현 방식 자체는 기업체에서도 괜찮은 해결책이라 여겨 문제가 없었지만, '과연 RDB를 이런 식으로 사용해도 되는가' 라는 의구심이 남아있었다.
따라서 본 프로젝트에서는 메타데이터는 RDB에 저장하고, 실제 원격 계측 및 제어 데이터는 NoSQL에 저장하기로 했다. 메타 정보에 조회할 컬렉션명을 저장해두고, 해당 컬렉션을 조회하는 방식이다. 작동 방식 자체는 크게 다르지 않으나 다음과 같은 차이가 있다.
- RDB에 관계 규약이 없는 테이블을 만드는 상황이 없어진다.
- 기존 SIMS는 사실상 스키마가 변하면 변경된 스키마에 따라 테이블을 하나 더 생성해야 했다. 실제로 테이블의 스키마를 변경할 수는 없기 때문이다. 기존 SIMS는 삭제된 속성은 조회할 때 제외해 버리는 꼼수(?)를 써서 정상적으로 작동되는 것 처럼 보였을 뿐, 사실 실무에 사용되지 않는 데이터를 남기는 나쁜 프로그램이었다. NoSQL은 컬렉션에 스키마가 정의되지 않기 때문에 이러한 문제에서 자유롭다.
- 개념적으로 생각했을 때 더 자연스럽다고 생각한다. 읽을 문서 집합 이름을 속성값으로 저장해 두고, 그 문서 집합을 가져온다는 개념이다. 여전히 속성값으로 컬렉션을 가리키고 있다는게 불안정하고 더 생각해서 해결해야 할 문제지만, 적어도 RDB에서 테이블명을 속성값에 저장해놓고 조회하는 것 보다는 좋은 해결책인 것 같다.
3. Spring boot 적용
기존에 Node.js를 선택한 이유는 생산성 때문이었다. 한정된 기간 안에 BE와 FE를 모두 구현하기 위해 프레임워크 선정 단계에서 생산성에 가장 큰 초점을 두었다. 그런데 Spring boot도 Node.js 못지 않게 생산성이 높다는 생각이 들었다. 특히 Spring boot가 프레임워크에서 제공하는 기능도 더 많고, 참조할 수 있는 레퍼런스가 많아 Spring boot로 개발을 결정했다.
4. CI/CD 환경 구축
기존 프로젝트 진행시 CI/CD를 구축하는 것이 필요하다고 생각했다. 프로젝트 자체가 자주 변동되는 위성 데이터 스키마에 대응하는 모니터링 서비스를 개발하는 것이기 때문이다. 따라서 본 프로젝트에서 CI/CD 환경을 구축하고자 한다.
현재까지 진행한 작업 내역
- 프로젝트 생성 및 DB 연동
- Satellite, Orbit, User API 구현(컨트롤러, 서비스, 리포지토리)