어제는 실전 프로젝트의 중간 발표 날이였다. 아주 중요한 날이였음에도 불구하고 며칠 전부터 너무 지치고 힘들어서 발표 준비를 제대로 하지 못했다. 트러블슈팅도 그 날 그 날 다 정리해놔서 정말 이야기할 것도 많았지만 갑자기 현타가 와서 중요해 보이는 트러블슈팅도 아닌 것 같고 어디까지 정리해야 할지도 모르겠어서 조금 소홀하게 준비했던 것 같다. 지금껏 열심히 하다가 중요한 날 바보같은 행동을 하게 되어서 속상하지만 지나간 일은 지나간 일이고, 앞으로는 컨디션 조절을 잘해서 최종 발표 때엔 후회없도록 최선을 다해야겠다.
나뿐만 아니라 모든 팀원들이 지쳤기 때문에 월요일까지 재충전하는 시간을 갖고 화요일에 다시 모여 앞으로의 3주간의 방향을 잡아보기로 했다. 백엔드 팀들과는 월요일에 잠깐 만나서 중간 발표 피드백을 회고하는 시간을 갖기로 했다. 피드백 회고록 관련 포스팅은 내일 작성하도록 하고 앞으로 3주간 하고 싶은 것들을 리스트업하는 것으로 TIL을 마무리하려고 한다.
(1) 로깅
운영 중인 웹 어플리케이션이 문제가 발생했을 경우, 문제의 원인을 파악하려면 문제가 발생했을 때 당시의 정보가 필요하다. 이런 정보를 얻기 위해서 Exception이 발생했거나, 중요 기능이 실행되는 부분에서는 적절한 로그를 남겨야한다.
로깅에 대한 키워드에 대해서만 대강 아는 수준이고, @Slf4j
어노테이션에 대해서만 조금 아는 수준이다. 로깅을 할 줄 알게 되면 문제 원인을 파악하는데 도움이 된다고 하니 적용해 보면 좋을 것 같다.
(2) 스캐줄러
한정적인 메모리를 프로세스가 효율적으로 사용 할 수있도록 작업을 할당시켜주는 역할을 한다.
스케줄러는 심화주차 때 추가 학습 주제였는데 기본적으로 공부해야할 부분을 따라가기도 벅차서 쳐다보지도 못했던 주제이다. 프로젝트 내에서 갈수록 쌓여가는 데이터를 관리하기 위해 스케줄러를 사용해서 주기적으로 데이터를 삭제해주는 기능을 구현하면 좋을 것 같다.
예를 들어, 봉사 활동이 끝난 게시물의 경우, 봉사 활동에 참여한 멤버에게 이력 정도만 남긴 상태로 게시물은 삭제하는걸 고려해봐도 좋을 것 같다.
(3) CI / CD
CI
Continuous Integration의 약자로 지속적 통합이라는 뜻이다. 개발을 진행하면서도 품질을 관리할 수 있도록 하는 것으로 여러 명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있음을 의미한다.
CD
Continuous Deployment의 약자로 지속적 제공이라는 의미이다.
CI를 통해서 새로운 소스코드의 빌드와 테스트 병합까지 성공적으로 진행되었다면, 빌드와 테스트를 거쳐 github과 같은 저장소에 업로드하는 것을 의미한다.
(4) QueryDSL
for (Board myBoard : myBoards) {
List<Enrollment> enrollments = enrollRepository.findAllByBoard(myBoard);
List<Hashtag> hashtags = hashtagRepository.findAllByBoardId(myBoard.getId());
List<String> tags = new ArrayList<>();
for (Hashtag hashtag : hashtags) {
tags.add(hashtag.getTag().getMsg());
}로직을 구현하면서 이중 for문을 처음으로 써봤다. 처음엔 아무것도 모르고 복잡한 로직을 구현했다는 것 자체에 초점이 맞춰져서 기분이 좋았었는데 알고 보니 매우 비효율적인 코드라는걸 알게 되었고, 주변 동료들로부터 QueryDSL을 사용해보라는 이야기를 들었다.
QueryDSL은 가장 하고 싶은 주제 중 하나이다. 처음 배운게 JPA라 JPA가 뭐가 좋은지도 글로만 배웠다. 복잡한 쿼리를 날리거나 동적 쿼리를 사용할 때 QueryDSL이 더 유용하다고는 들었는데 듣는거 말고 직접 체감하고 싶다. 다만, SQL도 아직 모르는 상태에서 QueryDSL을 배울 수 있는지에 대해서는 조금 생각해봐야겠다.
(5) swagger
Swagger는 REST API를 설계, 빌드, 문서화 및 사용하는 데 도움이되는 OpenAPI 사양을 중심으로 구축 된 오픈 소스 도구 세트이다.
지금까지는 API 명세서를 노션에 작성하곤 했다. API 명세는 아무리 신중하게 짜더라도 수정 사항이 필수불가결로 생기곤 하는데 이럴 때마다 노션의 API 명세를 수정해 주는 것이 여간 귀찮은 일이 아니였을 뿐더러, 급하게 수정할 일이 생겼을 때 API 명세 수정하는 것을 깜빡하곤 해서 협업하는데 문제가 생긴 적도 있다.
스웨거 사용법을 좀 익숙하게 하고 싶은 생각이 있어서 스웨거도 적용해 보면 좋을 것 같다.
(6) Jmeter
서버에 부하를 걸어서 성능을 분석할 수 있게 도와주는 툴이다. 하지만 이 툴을 사용해 보려면 성능 개선이 전제가 되어야 하는데 그러려면 성능 개선할 수 있는 방법을 공부해야만 한다.
(7) 테스트 코드
테스트코드란 내가 작성한 메서드가 실제로 재대로 동작하는지 테스트 하는 코드이다. 테스트 코드를 작성하면
- 개발단계 초기에 문제를 발견하게 도와준다.
- 개발자가 나중에 코드를 리팩토링하거나 라이브러리 업그레이드 등에서 기존 기능이 올바르게 작동하는지를 확인 할 수 있다.
- 기능에 대한 불확실성을 감소시킬 수 있다.
- 시스템에 대한 실제 문서를 제공한다.
TDD다 뭐다 하면서 테스트 코드가 중요하다는 말은 얼핏 듣기는 했지만, CRUD 공부가 우선이였기 때문에 우선순위를 뒤로 미뤄두었지만 공부의 필요성을 점점 체감하고 있다. 지금까지는 내가 구현한 코드가 어떤 상황에서 문제가 생기는지 파악하려면 포스트맨으로 그런 상황을 재연해내야만 해서 여간 불편한게 아니였다.
(8) xss, csrf
이 이슈는 중간 발표 예상 질문으로 나왔던 키워드들이다. 아마 이런 질문을 주신데에는 프로젝트에 적용해 보라는 의미일 것이다. 아직도 여전히 Config 설정하는게 익숙치가 않지만 이번 기회에 조금 깊이 공부해서 xss와 csrf를 방어하는 방법에 대해서도 공부해 봐야 할 것 같다.
마치며..
하고 싶은건 8가지나 되는데 하나하나가 굵직한 주제들이 많기 때문에 3주라는 짧은 시간동안 어떤 공부를 하면 좋을지 신중하게 생각해서 선택해야겠다.
