[채팅 서비스 마이그레이션] 백엔드 직무 체험 1주차회고

📌 직무부트캠프 채팅 마이그레이션 백엔드 직무 체험 1주차 회고

채팅프로젝트 마이그레이션이라는 주제로 직무 체험에 참여했다. 주차별로 과제를 수행하고 제출 후 피드백을 받으며 진행된다.

과제를 수행하며 고민했던 내용들, 그리고 배웠던 점을 남겨놓으려고 한다.

 

피드백..감사합니다

 

 

 

 

 

📌 새로운 환경과 기술에 빠르게 적응하는 연습

# NestJs와 PostgreSQL 개발환경 세팅

프로젝트를 분석하고 앞으로의 마이그레이션 계획을 세우기 위해서는, 프로젝트를 내 로컬 환경에 세팅하고 프로젝트에 적응된 기술을 빠르게 습득해야 했다.

앞으로 개발자를 하면서 수많은 기술을 새로 접하게 될 것이고, 취업 후 직무에 투입된다면 빠르게 적응해 나가야 할 것이니, 이번 직무를 실전이라고 생각하고 수행하였다.

현재 나는 Java/Spring 환경에서 웹애플리케이션에 대한 경험이 있었고, 이러한 경험을 토대로 NestJS에 접근하기로 했다.

먼저 데이터베이스를 연결하이 위하여 PostgreSQL을 설치하는 과정이 필요했는데, PostgreSQL과 GUI환경에서 쉽게 관리하기 위한 PgAdmin을  빠르게 구축하게 위해서 Docker를 활용하였다. Dockefile 혹은 DockerCompose만 형식에 맞게 작성해주면 돼서 구축이 간단하고 빠르다. 또한 컨테이너환경의 데이터베이스 관리는 서로 다른 개발환경에서 관리해주기 쉽기 때문에 여러 이점도 존재했다.

데이터이스를 설치했으니 NestJS환경에서 데이터베이스 설정을 나의 데이터베이스로 변경해줘야 했다. 처음 접근하거나 환경을 세팅하는 과정은 공식문서가 정말 도움이 많이 된다고 느꼈다. NestJS문서같은 경우에는 전체적인 프레임워크 구조, 세팅법 등이 쉽게 나와있었고 무엇보다 Spring프레임워크와 비슷한 개념들을 많이 가지고 있어서 학습하는데 비교적 쉽게 접근할 수 있었다.

이렇게 NestJS의 TypeORM문서를 활용하여 데이터베이스를 연결하였고 애플리케이션이 구동됨을 확인하였다.

 

 

 

 

📌 문서도 소통이다

# 팀원들을 위한 가이드 문서 개발

"가이드 문서 개발" 이라는 개념이 나에게 조금 어렵게 다가왔던 것 같다. "어떻게하면 팀원들이 보기 좋게 문서를 읽을 수 있을까?"  "어떻게하면 내가 전달하고자 하는 내용이 잘 전달될 수 있을까?"를 계속해서 고민했었다.

이에 대한 대답은 "핵심적인 내용만 쉽게 설명하자" 였다. "쉽게" 설명하기 위해 내가 선택한 방법은 비교였다. 현재 팀원들이 Java/Spring을 사용할 줄 안다는 가정하에 기존에 알고있던 지식과 비교해서 새로운 지식을 설명하는 것이다.

NestJS의 경우 Controller, Service등 Spring의 레이어드 아키텍처와 비슷한 개념/구조를 가지고 있다. 그렇기 때문에 Spring을 통한 비교를 통해 핵심적인 개념을 쉽게 설명할 수 있었다.

 

# 테이블 구조, API명세

NestJS의 기본구조 만으로는 채팅프로젝트를 처음봤을 때 눈에 확 안들어올 수 있다. 그래서 추가적으로 테이블 구조와 API명세서를 만들어서 가이드문서에 함께 넣기로 결정하였다.(스스로 프로젝트 구조 공부도 하고, 공유도 하고 1석2조!)

개인 프로젝트 할 때에도 느꼈지만, 테이블, 도메인등을 도식화 하는것은 프로젝트는 바라보는데에 정말 많은 도움이 되는 것 같다. 테이블관계를 파악하니 TypeORM이라는 ORM기술을 사용함에 있어서 연관관계도 눈에 잘 들어오고, 서비스로직을 훨씬 수월하게 이해할 수 있게 되었다. 코드 하나하나가 눈에 잘 들어오지 않는다면 큰 맥락에서 전체 구조를 파악하고 코드를 보기 시작하면 훨씬 빠르게 파악하고 이해할 수 있다고 느꼈다.

 

 

 

 

📌 피드백

문서를 작성할 때 크게 2가지를 고려해야한다고 한다.

# 읽는 대상이 누구인가?

아주 기본적인 내용이지만 놓치기 쉬울 수 있다. 이번 과제에서 읽는 대상은 Java/Spring에 대한 기본개념이 있는분들이었고, 기존에 알고있던 지식(Java/Spring)과 비교해서 잘 설명했다고 생각한다.

 

# 짧게 작성하자

사실 처음에는 가이드 문서니까 꼼꼼하고 자세하게 작성 해야 하지 않을까? 라고 생각했었다. 그러나 이것은 큰 오산이었다. 가이드 문서도 결국 누군가 읽는 문서이기 때문에 길면 눈에 안들어올 수 있다.

내가 작성한 가이드 문서에는 예시를 들기위해서 코드예시를 많이 첨부하였는데, 너무 많은 코드 첨부는 오히려 가독성을 떨어뜨릴 위험이 있다. 적절하게 조절해서 꼭 필요한 경우만 사용하면 좋을 것 같다.

 

문서도 누군가에게 말을 하는 것과 같다. 소통의 한 방법으로써 신중히 작성하도록 노력해야겠다.