글이 너무 길어져서 일단 출간하고 수정해 나가겠습니다...
추후 글을 리팩토링 해서 여러 글로 남길 수도 있습니다...

오랜만에 쓰는 것 같은 글이다!
오늘은 정보 전달의 목적이라기보다는 나를 위한 정리에 가까워서 편하게 글을 써보려고 한다
정보 전달 목적의 글이었다면 좀 더 포괄적인 주제를 개념부터 써내려 갔겠지만
레벨 3 인터뷰를 준비하며 배운 것들을 정리하는 글이라서 다소 지엽적인 주제들을 써내려갈 예정이다

그래도 추후 볼, 나를 포함한 타인을 위해서 첨언을 붙이자면
레벨 2는 스프링과 기술적인 것에 대해 많이 알아가는 시간이었다
비유하자면 무에서 유를 만들어가는 과정이라고 크루들에게 말하고는 했다

반면에 레벨 3은 지난 레벨에서 알아간 것에 뼈를 붙이고 다듬어가는 과정이었다
따라서 새롭게 배운 것보다는 알아간 기술에 대한 나의 가치관을 정리한다든가,
빈틈을 채워가는 시간들이었다
팀 프로젝트를 진행하며 충돌하는 가치들 사이에서 무엇을 선택할까에 대한 고민을 하기도 하고
서로가 아는 것의 간극을 발견하고 좁혀가는 과정이기도 했다

오랜만에 글을 적는 거라 길어졌지만 정리하자면

이 글은 사막에서 바늘 찾는 것과 같은 글입니다

하지만! 누군가는 매우 공감할 수 있는 글 (이 되면 좋겠네요)

이제 서론을 끝내고 시작해야지
어쩌면 서론이 제일 길었을 수도 있겠다

레벨 3 인터뷰 준비

방끗에서 내가 했던 것들

방끗에서 지금껏 약 8주를 달려오면서 내가 한 것은 무엇이 있을까
기본적으로 기획과 ERD, API 문서에 관한 것은 다 함께 했기 때문에 열심히 참여하였다
기획적인 부분을 가장 많이 한 것 같지만 이 부분은 다음 단락에서 다루도록 하겠다

오로지 API 개발로만 보자면 나는 체크리스트 작성, 수정, 삭제 API를 전담하여 개발을 진행했다
해당 부분이 기획이 바뀌며 계속 수정되었고 논리적 삭제 등을 적용한다든가, 기능 추가로 변화되는 부분이 많아 같은 API지만 3번 이상의 이슈를 잡아 추가 구현을 거쳤다

사실 단순히 코드 작성의 시간은 그리 많지 않았다
그렇다면 난 무엇을 했을까?
주로 스프린트 업무를 진행하는 것에 집중했었다

• 개발(코드 컨벤션 등) 문서 만들기
  모두가 함께 진행하였다
  해당 부분은 WIKI에서 확인 가능하다

• 기술 스택 선택 및 이유 정리
  모두가 함께 진행하였다
  해당 부분은 WIKI에서 확인 가능하다

• 개발 서버에 서비스 띄우기
  해당 부분은 함께 진행하였다
  우리는 보안상의 이유로 8080 포트를 인바운드 규칙으로 막아 두어서 80을 8080으로 포트포워딩을 해 주어야 하는데 이 부분에서 꽤 많은 시간이 소요되었다
  NGINX를 통해 포트포워딩에 성공하였는데 살짝의 찜찜한 부분이 있었다
  관련 블로그 글을 작성하여 팀 블로그에 업로드 하기로 했는데 아직 정확한 파악을 못 하여서 방학 중 진행 예정이다

• CI와 쉘 스크립트 등을 활용한 배포 자동화
  해당 부분도 함께 진행하였다
  해당 부분은 WIKI에서 확인 가능하다

• 로깅 프레임워크 적용
  해당 부분은 페어로 진행하였다
  같은 레벨의 지식을 공유하기 위해 WIKI로 공유하고 팀원들과 나누었다

• API 문서 작성
  해당 부분은 모두가 함께 작성하였다
  사실 SWAGGER를 사용하기로 결정해 두었는데 해당 부분은 배포되어야만 확인할 수 있다는 단점이 존재했다
  우리의 브랜치 전략 특성상 한 스프린트가 끝나야 배포를 진행하기 때문에 사실상 작업 중에는 노션 API 문서에 의존하고 있다

• (로그, 매트릭) 모니터링 대시보드 구성
  모두 CloudWatch로 진행하였다
  관련 부분도 페어로 진행하였고 WIKI로 정리하여 팀원들과 공유하였다

• 프로덕션 서버에 서비스 띄우기
  사실 이 부분은 현재 진행 중이며 페어로 하고 있다
  먼저 yml 파일을 local, dev, prod로 나누어 prod 서버 cd와 dev 서버 cd를 다르게 진행하고 있다
  local에서는 h2 database를 사용하고 dev에서는 서버 안에 mySql을 설치하여 내부 연동, prod에서는 rds로 database를 구축하여 외부 연동 방식을 택하여 각각의 설정 파일이 다르다

우리는 기획을 왜 열심히 해야 하는가

앞서 언급했듯 8주간 가장 열심히 한 것은 기획에 대한 부분이다
사실 8주 중 4주 이상은 기획만 했다고 생각한다
우리는 더 나은 서비스를 만들기 위해, 사용자가 진짜 사용할 수 있는 서비스를 만들기 위해
UI나 기획적인 부분을 수없이 고민해 왔다

그중 가장 우리만의 특색이 담긴 유저 친화적인 부분을 꼽자면 단언컨대 직접 부동산 가서 체크리스트 사용해 본 경험을 꼽을 수 있다

방끗의 특성상 방을 보고 최적의 방을 꼽는 데 질문과 기능이 적절한지, UI가 적절한지는 서비스의 경쟁력을 나타내는 부분이다
해당 부분을 우리의 가상 생각으로만 하는 것보다는 직접 체험해 보며 개선하고 싶다는 생각이 강해 팀원들과 부동산에 연락해 직접 우리 서비스를 사용해 보며 방 구하는 유저의 경험을 해 보았다
그리고 실제로 기획은 많이 갈아 엎어졌다

사실 이런 상황을 겪다 보니 종종 의문이 들 때도 있었다
우리는 개발자인데 왜 이렇게까지 기획을 열심히 해야 되는 것인가?
기술적인 것보다는 기획을 더 많이 하는 이 상황이 맞는 것인가?
실제 회사에 들어가면 기획은 기획자가 다 해 줄 것이고, 디자인은 디자이너가 다 해 줄 것이다
이것이 우리의 업무 영역도 아닌데 이렇게까지 할 필요가 있는가? 라는 고민이 스칠 때도 있었다
이러한 고민을 나누다가 사석에서 브리 (❤️)가 좋은 말을 해 주었고 나 또한 홀로 생각해 보다 내린 결론이 있다

생각해 보자면 개발자는 주어진 문제를 유저에게 가장 좋은 방향으로 해결하기 위해 서비스를 만들어가는 사람이다
따라서 모든 기술의 기준점은 유저여야 된다는 생각을 갖고 있다
비록 기획적인 부분이나 UI적인 부분이 BE 소관이 아닐지라도
이러한 배경 지식이 있으면 더 좋은 서비스를 만들어나갈 수 있다
나의 이런 유저 친화적인 서비스를 만들기 위한 경험은 추후에 회사에 입사해 서버를 만들어 나갈 때 여러 선택에 있어서 도움이 될 거라 생각한다
유저를 위한 서비스라는 본질을 잊지 말자!

주위 선배 개발자 분들이 해 주신 말을 조금 덧붙이자면,
신입 개발자들의 포트폴리오들을 보면 기술적으로는 훌륭한 성취를 거둔 서류가 많다
하지만 특색 있는 포트폴리오를 만들려면 얼마나 유저를 고려했는가도 중요한 요소이다
이러한 경험이 있으면 더욱 더 탄탄한 포트폴리오를 만들어갈 수 있다... 하는 말도 해 주셨다!

에러를 얼마나 상세하게 할 것인가

• 배경
  해당 문제를 고민하게 된 것은 한창 프론트와 서버를 연결하던 중이었다
  지난 레벨에서는 프론트의 영역, view 또한 서버와 합쳐져 있어서 에러 메시지가 화면에 바로 뜨는 구조였다
  따라서 최대한 정보를 숨기고 사용자 친화적으로 만들며 어휘 또한 다소 부정확하고 깔끔하게 만들었다
  예를 들어, "유효하지 않은 ㅇㅇ 정보입니다", "중복된 정보가 존재합니다" 정도의 메시지였다
  하지만 연결할 때에 이런 부정확한 메시지는 오히려 불편하게 느껴졌다

• 고민 방향
  서버에서는 최대한 정확한 메시지를 던지고
  이것을 숨기는 역할은 프론트에서 하는 게 맞는 게 아닐까? 라는 생각이 들었다
  그래서 "친절함"도 중요하지만 해결 "단서"를 제공하는 것이 중요하다 생각했다
  기존에는 HttpStatus, ErrorMessage만 주었지만
  가장 이상적인 영역은 HttpStatus와 내부적으로 사용하는 ErrorCode, 문제가 발생한 지점을 알려 주는 ErrorMessage까지 주면 좋다는 생각의 결론이 내려졌다
  Error 코드를 기존에는 사용하지 않고 httpStatus와 Message의 영역에서만 처리를 해 주었는데 정보를 주고 프론트에서 가공해야 하는 나의 설계에서는,
  프론트가 어느 에러를 어디에 맵핑할지 한 단계 나아가야 하기 때문에 ErrorCode 또한 필요하다는 생각이 들었다
  에러의 경우이지만 사용자에게 꼭 에러를 보여 주지 않고 그냥 묵인 후 넘어가야 할 에러 또한 존재하기 때문이다
  예를 들어, 삭제 요청을 보냈는데 이미 삭제된 항목이라면 중요하지 않을 경우 read만 다시 한 후 넘어가는 방안도 있을 것이다
  이는 서버에서는 남아야 하지만 사용자의 입장에서는 필요 없는 정보이기 때문에!

로그를 어떻게 남길 것인가

기본적인 로깅 전략 및 기술은 기술 문서를 따로 정리해 놓았으니 여기를 참고할 수 있다

• LOGBACK을 선택한 이유
  로그를 남기는 로깅 라이브러리의 종류는 매우 많다
  우리는 그중 logback을 선택하여 관리하기로 했다
  Log4j, Logback, Log4j2 등이 있는데 logback이 따로 의존성을 추가할 필요가 없고 현재 개발 진행이 꾸준히 되고 있는 라이브러리라 선택하였다

• INFO 로그는 왜 필요한 것인가?
  모니터링 대시보드를 구축할 때에 로그 남기는 것 또한 중요했다
  현재 서버에 문제가 발생할 경우 로그를 확인하려면 ssh에 접속해야 하는데,
  해당 접속이 인바운드 보안 규칙으로 캠퍼스에서만 가능하여
  로그를 따로 보는 것에 대한 필요성을 느꼈다
  따라서 ERROR의 경우 서버 오류를 바로 확인하기 위해 필요했으며
  WARN의 경우 프론트 연결에서 어느 문제인지 바로 체크하기 위해 필요했다
  하지만 INFO의 경우 도대체 왜 남겨야 하는가? 에 대한 의문이 있었다
  정리하자면 ERROR 혹은 WARN이 발생한 위치와 메시지만으로는 어느 단계에서, 어떤 문제가 발생했는지 부족하기 때문이다
  주요 로직 중 어디까지 도달한 후 해당 문제가 발생했는지,
  무슨 로직에서 문제가 있는지 파악을 하기 위해서는 INFO 로그가 중요하다
  따라서 시스템을 파악하는 데 중요한 정보만을 남겨야 한다

• AOP와 ControllerAdvice
  우리는 로그를 남길 때 Spring AOP를 사용하여 관심사 분리를 하였다
  비지니스 로직과 로그 로직이 혼재되어 있는 것을 방지하기 위해

논리적 삭제 후 테이블 관리

테이블 설계와 연관 관계

CI/CD 과정

리팩토링 논의 과정

문서화에 대한 고민

브랜치 전략

글을 마무리하며

아니 한 페이지 분량으로 간단하게 정리만 하려고 했는데 왜 이렇게 길어졌지?

오랜만에 블로그 글을 남기니까 너무 재미있다
평소에 워낙 기록을 좋아하여 몇몇 크루들은 알겠지만 하루도 빠짐없이 일기를 쓰고는 한다
내가 하루하루를 어떻게 보냈냐를 볼 수 있고 스스로 회고하며 발전하는 시간이 마음에 들어서 글, 영상, 사진을 모조리 활용하는 기록광인데
딱히 공유는 하지 않고 있다

블로그는 기술적인 내용을 담아야 할 것 같아 사설을 최대한 줄이고는 하는데
기술적인 내용에 슬쩍 사설을 담으니까 꽤 재미있고 마음에 든다
앞으로 잘 활용해 봐야지
이렇게 이 글이 마지막이 될 수도

떨리는 레벨 인터뷰 파이팅!