2주간의 Stack Overflow 클론코딩을 주제로 한 Pre Project 을 진행한 기록들을 블로그에 옮겨둔다.
Daily 회고
8/24
완성된 요구사항 정의서를 기반으로 테이블 명세서와 ER다이어그램을 작성해보았다. 요구사항의 각 기능에 대해 필요할 것으로 예상되는 데이터들을 컬럼으로 지정하였다. 사실 프론트엔드 측과 협의하에 어떤 데이터를 주고받을 지 결정된 후 테이블을 설계하는 것이 맞는 것으로 보인다. 하지만 요구사항 정의서 작성 시에 기능의 동작에 대한 전반적인 논의가 된 터라, 임의로 작성한 것을 프론트엔드측에서 확인했을 때 큰 문제는 없었다.
필요한 테이블들을 완성하고 테이블 간의 연간관계를 설정해주었다. 여기서 질문글의 ‘조회수'를 관리하기 위해 ‘질문'테이블에 컬럼으로 둬야할 지, 따로 조회수 테이블을 두고 1:1 연관관계를 만들지 고민이 컸다. 현재까지는 기존에 학습했던 내용에서 따로 테이블을 두고 1:1 연관관계를 두는 방식을 취했는데, 이를 따르기로 하였다. 정확한 이유는 찾고 있다. 해당 학습내용에 대한 이해가 부족해서 복습 중에 있다.
API 문서를 작성하는 것에 있어서 전체 기능들 모두에 대해 API 문서를 제공할 지, 일부 기능 먼저 API 문서를 제공할 지에 대해 논의하였고 제한된 시간관계상 ‘전체 질문 목록 조회'에 대해 먼저 제공하고 추후 기능들도 작성하기로 하였다. API 문서 작성 툴은 Swagger, Spring Rest Docs 를 고려하였고 학습했던 기술인 Spring Rest Docs를 선정하였다. 이 내용 또한 복습 중이다.
요구사항 정의서의 제출 기한이 오늘이어서 제출을 완료하였다.
8/25
어제 새벽 2시쯤 자서 아침 6시 50분에 기상했다.
바로 학습을 시작했다.
조금 남은 JPA를 빨리 끝내고 Spring Rest Docs 를 볼 예정이다.
하지만 JPA가 완벽히 이해되지 않아 걱정이다.
JPA 1회 복습을 끝내고 Transactional과 Testing은 건너뛰고 API 문서화를 학습하기 시작했다. API 문서화는 이전과 독립되어 학습이 가능하다고 들었었던 것 같기 때문이다.
- 오늘 프로젝트 진행 결과
- 질문 번호를 통한 질문 조회, 전체 질문 목록 조회 두 가지 기능에 대한 Spring Rest Docs API 문서를 완성했다.
- Stub Data를 이용했고 테이블 설계가 최종 완료되지 않았으므로 추후 많은 부분이 수정될 예정이다.
- 테스트 API 통해 프론트엔드 어플리케이션과의 최초 통신에 이용될 예정이다.
8/29
어제의 회고를 오늘 올린다.
심리적으로 매우 힘들었고 지금도 힘이 든다.
이 길이 내 길이 맞는 지에 대한 고민이다.
프로젝트는 Users 단일 엔티티에 대한 기본 CRUD 구현을 완료했다.
8/30
- 현재 시각 오전 3시 25분,, 밤샘 작업 중이다..
- 3가지 도메인 (회원, 질문, 답변) 의 엔티티를 작성하고 연관관계 매핑을 완료
- ‘답변'도메인의 비즈니스 로직을 구현
- ‘답변'도메인 코드의 리팩토링 완료
9/2
다행히도 오늘까지 스택오버플로우 클론코딩 프로젝트에서 우리팀이 1차 목표로 했던 기본 CRUD 는 구현이 완료되었다. 기본적인 회원, 질문, 답변 외에 태그 도메인도 추가하였다. REST API 의 설계부터 구현까지 전체적인 흐름을 알게 되었고, 필요한 기능의 비즈니스 로직도 전체적인 단계를 고려하며 알맞은 계층에서 구현해보았다. 또한 DB에서 JPA 를 이용해 무결성을 지키도록 엔티티들을 연관짓고, 연관관계를 통해 필요한 데이터를 비즈니스 로직에서 가져오고 저장해보는 기능도 구현하였다.
마지막으로 AWS에서 ec2에 배포를 하고 실행을 함으로써 실제 프론트엔드 쪽에서 사용할 수 있었다. API 문서는 Swagger를 통해 제공할 수 있었다.(API 문서 쪽은 백엔드 유일한 팀원인 주현님이 맡아서 해주셨다.)
현재로썬 서버 내부적으로 리소스를 많이 잡아먹는다던가 하는 이유로 ec2의 성능이 모자란 것이 아니면 잘 운영될 것으로 보인다. 서버 내부 성능 최적화에 대해서는 크게 고려하지 못했으니…(거기까지는 시간이 없었다.)
일단은 마음이 놓인다. 하지만 개선해야할 사항이 너무나 많고 추가 구현 목표도 있으니 남은 기간동안 다시 열심히 코딩해봐야겠다. 지금 바로 코딩하러 가야지.!
9/6
⏰ 06:32
- Pre Project
- JWT 이용한 로그인, 회원가입, 접근권한 구현
- 요청 경로 별 시나리오와 이에 따른 권한 설정 작업 → 구글 스프레드 시트로 정리
- AWS EC2 인스턴스에 Https 적용 시도
- JWT 이용한 로그인, 회원가입, 접근권한 구현
최종 회고
1. 기술 회고
📌 좋았던 점
- Spring Boot 이용한 Restful API 서버 구현의 전체적인 흐름을 알 수 있었던 것.
- API 계층/Service 계층/Data Access 계층으로 나뉘어, 단계별로 기능의 구분을 두며 구현한 점.
- DB 테이블을 설계하고 Spring Data JPA 를 이용해 연관관계를 매핑하였다. 설계한 바와 같이 DB의 무결성이 지켜지는 것을 확인할 수 있었다.
- 프론트와의 협의에 따라 비즈니스 로직을 수정하며 요구사항을 만족하도록 구현할 수 있었다.
- Spring Framework의 MVC 구조, 스프링 시큐리티의 체인, ApplicationContext(스프링 컨테이너)의 bean 관리 등 프레임워크 동작 Structure를 어렴풋이 알 수 있었다.
📌 아쉬웠던 점 & 개선할 점
- 설계 단계에서 기능 요구사항, 화면 정의서, 동작에 따른 요청과 응답 API 문서, DB 테이블 설계서 등 구체적으로 문서화되어 있지 않아 프론트와 백엔드 간 협업에 어려움이 있었다.
- 메인 프로젝트에서 팀원들과 설계 단계에 시간을 들여 구체화하기로 하였고 멘토님께 현업에서는 어떻게 설계하는지 여쭤보고 방향성을 조언받기로 하였다.
- Git Flow를 적용하여 Github 을 관리하려 했으나 Git 사용에 대해 모르는 것이 많았고 PR과 merge가 잘 되지 않았다. 그리고 각자의 개발브랜치에서 commit 과 push 를 자주 하지 않았는데 개선해야할 것 같다.
- 최초에 브랜치 생성에 문제가 있었던 것으로 보이므로 Git Flow를 적용하기 위해 어떻게 브랜치를 생성해야할 지 잘 이해하고 시작해야겠다. 그리고 협업하는 사람과 PR , Merge 한 결과가 다를 때 충돌이 발생하는데 이 때 어떻게 처리해야 하는 지 이해해야 한다. 현재 깃헙의 최신내용을 로컬 개인 브랜치로 pull 하고, 로컬에서 충돌을 해결한 뒤 push 후 PR 을 날리면 된다.
- 기능 구현을 위해 코드를 작성할 때, 학습기간동안 배운 내용이 많이 휘발되었음을 느꼈다.
- 다시 배운 내용을 보며 구현할 수 있었지만, 더 많은 복습이 필요할 것 같다.
- 스프링 시큐리티와 JWT 를 이용하여 회원가입, 로그인 기능을 구현하지 못한 점. 스프링 시큐리티에 대한 유어클래스 컨텐츠가 불친절했고 스스로도 이해도가 낮다고 생각하여 공식문서를 보고 구글링을 하는 등 시도했지만 구현하지 못했다.
- 시간이 부족한 이유도 있었지만, 필수적인 기능을 구현하지 못한 점이 아쉬웠다. 메인 프로젝트에서는 반드시 구현할 수 있도록 준비해야겠다.
- AWS EC2 인스턴스에 HTTPS 적용 실패
- 이점 역시도 마지막날 시도해본 것으로 시간이 부족한 점은 있었다. 하지만 구글링을 통해 찾은 가이드를 따라 HTTPS 를 잘 적용한 것으로 판단했으나 테스트 결과가 부정확하였다. 그리고 테스트 자체가 적절한 지에 대한 판단도 어려웠다. Https 와 Http버전(1.0, 2.0), 외부 접속 포트, 내부에서 실행되는 WAS의 localhost 포트, 도메인 사용 의미 등 개념을 모르는 점이 많았다.
- JUnit 이용한 테스트 미구현
- 앱의 기능 구현에 급급하여 테스트 구현에 시간을 투자하지 못해 구현하지 않았다. 다행히 슬라이스 테스트 및 통합테스트에서 에러가 발견되지 않아 동작했지만, 메인 프로젝트에서 단위테스트를 진행하지 않다가 상위단계 테스트에서 에러가 발견되면 해결이 어려울 수 있겠다는 생각이 들었다.
2. 느낀 점 회고
힘들었지만 열심히 했더니 결과가 나왔다. 다른팀보다 잘하지는 않은 것 같다. 하지만 어느정도 결과가 나와서 다행으로 생각한다. 팀장을 맡고 협업을 하고, 개발 과정을 어느정도 겪어보니 조금은 개발이 어떤 것인지 알 수 있었다. 같은 백엔드끼리의 협업도 쉽지 않았고 프론트와의 협업은 더욱 쉽지 않았다. 특히 백엔드간의 소통에서 서로가 사용하는 단어의 개념이 일치하지 않아 이해가 어려웠다는 점을 많이 느꼈다. 앞으로는 상대방이 사용하는 단어나 용어가 내가 이해하는 바와 맞는 지 물어보고 소통을 진행해야겠다. 그리고 개발은 학습에 끝이 없고 계속 시간을 투자하여 찾고 또 찾고 시도해보고 또 시도해보는 것이라고 느꼈다. 예를 들어 코드스테이츠에서 배우지 못한 내용 혹은 제대로 이해하지 못한 내용을 이용해서 구현을 하고 싶은데, 이를 위해서는 구글링을 통해 또다른 자료를 찾고 학습하고 적용해보고 등의 계속되는 try가 핵심이었던 것 같다. 물론 나의 학습능력이 부족해서 더 어려웠을 수 있으나 이 일을 해내기 위해서는 유일한 방법인 것 같다.
분명히 힘들었지만 나름대로 재미를 느끼는 순간도 있었다. 물론 앞으로도 걱정이지만 지금으로썬 더 나아가볼 생각이다.
트러블 슈팅 리포트
그림과 같이 노션에 기록해두었고 노션 페이지 링크로 확인할 수 있다.
https://www.notion.so/my-little-seollem/52755473415041c184bcbdacc4c9f8a9?pvs=4
트러블 슈팅 리포트
A new tool for teams & individuals that blends everyday work apps into one.
www.notion.so
