[과제 프로젝트 회고] 눈물은 닦으면 에피소드, 프로젝트는 회고하면 추억

목차

1. 내가 한 것과 잘한 것

2. 배운 것과 성장 지점

3. 아쉬운 것과 다음에 다시 시도해 볼 수 있는 것

4. 미래의 나에게 

 

---

1. 내가 한 것과 잘한 것

 

1) 마감 기한 준수

WBS를 작성하여 일정관리 하였으며, 마감 기한 내에 마무리했다. 

개발 기간은 총 3주였지만, 실제로 개발할 수 있는 기간은 2주였다. (코로나 걸림..) 오디션 프로그램 보면 퀄리티가 좋으나 결국 마감기한 못 지킨 참가자들이 생각났다. 그래서 개발 오디션 프로그램 참가자가 된 상상을 하며, 비록 못생긴 포키일지라도 기한 내 제출하겠다는 마음가짐으로 작업했다.

 

내가 만든 포키... . . 너를 위해 구웠지....

 

 

 

 

2) 개발 항목 정리

기능 구현 전, 개발 항목에 대해 상세하게 정리했다.

고민을 많이한 흔적이 보인다고 말씀해 주셨는데 뿌듯했다. 진짜 고민을 많이 했거든요 ㅠ

개인정보보호 가이드 지침이나 네이버 비밀번호 작성 규칙등을 참고하여 설정했다.

물론 정의한 모든 기능을 구현할 수는 없었지만, 꿈은 야무졌다. 

 

 

1,2) 개발 전, 필요 기능에 대해 정리하였다. 3) 실제로 개발한 것

 

 

3) 에러 원인 분석 스터디

동작 원리를 이해하고 넘어갔다. 새로운 개념이나 모르는 개념이 나오면, 귀찮아도 꼭 정리하고 넘어갔다. 

그리고 추가로 더 업데이트 할 예정이다. 에러가 많으니까 포스팅할 내용도 많아서 좋다. 

 

눈물은 닦으면 에피소드고, 에러는 해결하면 글감이다 ~ 에러 이겨내야지 ~ 

 

https://seongeun-it.tistory.com/281

[SpringBoot + JPA] API 호출 시, 404 에러

 

 

4) 우선순위 정하기

우선순위를 정해 기간 내에 구현하지 못하는 기능은 보류하였다.

비밀번호 암호화를 위해 spring security 적용, 카카오 로그인 구현을 위해 api 연동까지 했는데, 문제는 기본적인 게시판 CRUD 조차 기능을 끝내지 못했다는 것이다. 그래서 중간 리뷰 때 피드백 주신 것처럼, 기본적인 기능 먼저 끝내고 추가 개발을 진행하는 방향으로 수정하였다. 마찬가지로 꿈은 야무졌으나, 실제 수행 가능한 범위를 객관화하는 것, 그리고 개발 가능한 기능의 우선순위를 정하는 것의 중요하다는 것을 깨달았다.

아픈 손가락들..

 

5) app 서버와 api 서버 분리

이번 프로젝트에서 처음으로 app 서버와 api 서버를 분리하여 개발하였다. 이렇게 개발하게 되면 app서버와  api 서버가 독립적인 운영이 가능하고, app서버는 화면단만을 담당하고, api 서버에서는 비즈니스 로직에 집중할 수 있다. 그리고 app 서버에서 직접 db에 접근하는 것이 아니기 때문에 보안성이 높아진다. 

 

 

2. 배운 것과 성장 지점

1) 새로운 기술 스택 학습

spring boot, jpa, vue, axios, webclient 등 새로운 기술 스택을 학습하였다.

spring boot로 프로젝트 해보고 싶었는데, 이번 기회에 써볼 수 있어서 좋았다.

jpa와 vue 모두 처음 사용해보는 api와 프레임워크였다.

초반에는 친해지면 편할 것 같은데 막상 나를 불편하게 하는 친구.. 같은 느낌이었는데, 2주 정도 지나니까 아주 조금 친해졌다..!

기본 개념이 정말 중요하다는 것을 다시 한번 배웠다..! 

 

퇴근하고 매일 인강 들었다..

 

 

2) study logs 작성

새롭게 배운 내용들을 노션에 데일리로 정리하였다. 나중에 동일한 에러가 발생하더라도 이전에 검토해 본 자료에서 찾으면 되니까 금방 해결할 수 있겠지 (제발..)

 

 

3) 서버에 개발 환경 구성 및 배포

ubuntu에 자바 설치 및 jar 배포하였다. spring boot은 내장 톰캣이 있어 별도의 tomcat config 세팅을 하지 않아도 된다.

tomcat config 설정하는 거 까다로웠는데 프레임워크가 해주니 너무 편했다. 사실 개발 환경 구성하고 jar파일 배포하는 건 금방 했는데,  maven build 하는 방법을 헤매서 여기서 시간이 오래 걸렸다. 적당히 하다가 모르면 동료에게 물어보자.. 집단지성 최고(ㅠ) 

 

 

4) 모르는 게 나와도 끝까지 물고 늘어졌다.

2주 풀야근하고 안 되는 거 있으면 집에서도 붙잡았다. 예를 들면 app <-> api 서버 간 통신ㅇ이라던가... . . (따로 포스팅할 예정이다.)

거의 4시까지 했는데도 안되던 게, 다음날 1시간 만에 해결되었다.. 너무 안 풀리는 문제는 잠깐 쉬어가자.

 

5) 화면단 레이아웃 디자인을 신경 썼다.

프론트단에서 시간을  꽤 잡아먹었지만, '작은 프로젝트이지만 기본적인 화면 레이아웃등 디자인을 맞추려는 노력이 보인다'는 평가를 들어서 뿌듯했다. 화면 디자인은 멋진 디자이너인 막냇동생이 해줬는데, 처음으로 디자이너와 협업(?)을 하여서 재미있었다. 역시 약은 약사에게, 디자인은 디자이너에게...

 

 

 

 

 

3. 아쉬운 것과 다음에 다시 시도해 볼 수 있는 것

3-1. 아쉬운 것

 

- 질문하기 전에 충분히 생각하고, 정리해서 질문하자

마음이 급하다 보니 '질문하기 전에 생각했나요? 정리했나요?'라는 원칙을 잘 지키지 못했다. 말하면서 생각하는 게 내가 제일 싫어하는 내 모습인데, 그러는 내 모습을 보니 질문하면서도 너무 부끄러웠음.. ^.^.. 미안하고 고마워요 동료분들.. 이 은혜 꼭 갚으리..

했던 질문 중에 그나마 제일 괜찮다고 생각했던 질문은 dto, vo 차이점에 대한 질문인데, 이 개념을 이해하려고 1시간 동안 공부해서 질문했다. 질문은 답변자의 시간을 빌리는 거니까 질문할 때는 충분히 생각하고,.. 꼭 정리해서 질문하자! (내가 궁금한 것, 시도해 봤던 것, 내가 생가하는 에러 원인 등) 명심 또 명심! 

 

 

- 백 단 먼저 개발하고, 프런트단 개발하자.

프론트단은 하다보면 정말 욕심이 나서, 적당히 넘어가야 되는 부분도 집착(?)하게 된다. 그래서 초반에 여기에 시간을 많이 썼다.

이후 개발할 때는 프론트 비율과 백단 비율을 좀 조절할 필요가 있을 거 같다. 그래서 페이징 버튼까지 만들어 놓고, 정작 페이징 기능은 구현하지 못하는 이런 불상사가 일어나지 않으니 말이다.. 

 

 

- 간단하게라도 프로토 타입을 먼저 만들고, 추가로 세부 기능을 개발하자

일단 간단하지만 촘촘하게 만들어서 테스트해 보자. 그리고 이후에 추가 기능을 개발하자!

게시판 crud도 구현 안 하고, 비밀번호 암호화 하지 말고! 

(결국 비밀번호 암호화까지는 되었으나 로그인하는 부분 때문에 원복 하였다. 물론, 비밀번호 암호화도 중요하지만 추가 기능은 기본적인 기능을 먼저 끝낸 후에 개발하자) 

 

 

- 형상관리 툴은 한 개만 사용하자

하나의 프로젝트를 관리하는데 인텔리제이, vscode, 터미널, git desktop을 사용했다. 그러다 보니 commit과 push 해야 하는 디렉터리를 못 찾아서, 이것 저것 해보다가 잘 있던 프로젝트 날렸다.. 정말 다행히 백업 파일이 있었지만, 만약 없었다면 정말 아찔한 상황

zip 파일로도 백업 파일은 꼭 가지고 있자. 그리고 형상관리는 툴 하나로 하자. 나는 git desktop으로 정했다. 

 

 

- 에러가 나면 쪼개서 테스트해보고, 정상적으로 실행되는 경우와 그렇지 않은 경우를 파악하자

개발 환경에서는 정상적으로 실행이 되는데 서버에서는 axios 404 에러가 발생했다. 해당 문제의 원인을 config에서 설정한 proxy 경로 문제라고 생각했는데, 그게 아니었다. 이것저것 바꾸면서 테스트하다 보니 더 꼬이는 것 같아서, 테스트 환경을 하나로 정하고 정상적으로 실행되는 경우와 그렇지 않은 경우를 파악해서 원인을 분석했다. 확인해 보니까 npm run serve 후 webpack 테스트 서버에서는 api 서버를 호출하지만 build 후 app 서버에서는 404 에러가 나는 것이다. 이 부분을 확인하니 app서버에서는 api 서버의 controller 아닌 app 서버의 controller를 호출하고 있다는 것을 확인할 수 있었다. (그래서 webclient를 사용하여 app <-> api 서버 간 통신이 되도록 설정하여 해결하였다.) 

 

- response는 어떤 에러든 200으로 주는 게 좋다. 왜냐면 구체적인 에러 코드가 외부에 노출되면, 보안에 취약하기 때문이다.

클라이언트가 구체적으로 에러 메시지를 확인할수록 보안에 취약하다. 

 

- vue에서 watch 대신 Validation Provider 사용하자. validation check를 위해 watch를 사용하였는데, 간헐적으로 입력이 느려지는 현상이 있었다. 입력값이 많은 화면이라면 더 느려질 것이다. 다음엔 Validation Provider로 입력값 체크해 봐야겠다.

 

 

3-2. 다음에 시도해 볼 것

• 회원가입
  • space 공백 처리
  • 카카오 로그인 연동
    • 카카오계정으로 로그인하기 (카카오톡 로그인 API 사용하기)
  • 비밀번호 칼럼은 암호화 처리한다. (spring security로 구현 필요)
  • (옵션) 아이디, 이메일일등 개인정보로만 이루어진 경우
  • (옵션) 비밀번호 변경 시 현재 사용 중인 비밀번호와 체크하여 다른 경우에만 비밀번호 변경을 처리한다.
  • (옵션) 비밀번호 갱신일 후 6개월마다 비밀번호 변경창이 뜬다.
  • (옵션) 동일 비밀번호 사용 제한한다. (oldpasswd1,2,3)
  •  
• 게시판
  • 게시글이 0일 경우 Default 메시지 출력하기
  • 페이징 처리
• 로그인
  • 비밀번호 5회 이상 입력 실패 시 입력 횟수를 제한하기 위해 계정이 잠긴다
  • 잠긴 계정은 관리자가 비밀번호 초기화할 수 있다.
    • 초기화 비밀번호는 최소 6자 이상이어야 하며, 안전하게 생성된 난수여야 함
  • 초기화된 비밀번호로 로그인할 경우 비밀번호 변경 페이지로 이동하여 사용자에게 비밀번호 변경을 유도한다.

 

4. 미래의 나에게 

새로운 기술스택이 익숙하지 않았고, app 서버며 api 서버며 일련의 모든 과정이 쉽지 않았다.

그래도, 이왕 하는 거 좋은 결과를 내고 싶은 마음과 새로운 기술 스택을 배우고 싶다는 욕심이 생겼다.

이런 욕구가 채워져서인지 지난 2주 동안 매일같이 야근했지만, 고통스럽지 않았고 오히려 재미있었다. 

어제 내가 몰랐던 걸, 오늘의 나는 조금 더 잘할 수 있으니, 내일의 나는 오늘보다 더 잘할 것이다. 

그런 순간들이 모여서 버틸 수 있게 하는 것 같다. 내일은 지금 이 그지 같은 코드보다 조금 더 나은 코드가 될 것이라는 흐 ㅣ 망.. ?

 

친절한 동료들 덕분에 여기까지 올 수 있었으니, 나도 쑥쑥 커서 받은 만큼 도움을 주고 싶은 마음뿐이다.

열심히 배워서 아는 만큼 나누고, 성공하는 기쁨을 함께 누리는 짱발자가 되자 ^-^ ! 

 

 

얼레벌레 돌아가기는 하는 저의 코드가 궁금하다면..?

 

GitHub - seongit/Uri-Seoro-APP

 

GitHub - seongit/Uri-Seoro-API