[2023.10.27] Bi

✏️ WIL

1. 프로젝트

- 이메일 인증 API Feat (완료), Refactor (예정)

- 댓글 가져오기 API Feat (시작)

- 게시물 가져오기 API Feat (시작)

2. 코딩 테스트

- Solved.ac CLASS 3 3문제 풀이 (완료 예정)

- 알고리즘 스터디 결성

3. 면접 스터디

- Java, DB, OS, Network 관련 정리

 

💌  멘토링

우선 이번 주를 마지막으로 6개월 간의 2:1 멘토링은 종료되었다.

하지만, 나는 CRUD 기능 구현에서 생각보다 시간을 많이 쏟은 관계로 한 달 더 진행하기로 결정을 내렸다.

 

이번 주 세션에서 멘토님께서는 이번 한 달 동안은 체계적인 플랜 하에서 진행하는 걸 제안주셨고, 항상 채찍질이 고팠던 나는 제안을 수락하였으며 다음과 같은 프로세스로 진행이 되었다.

 

1. 현재 내가 구현해야할 기능(= 남은 기능), 구현 진행 중인 기능, 구현 완료 한 기능으로 나눠서 현재 상황을 보고했다.

2. 그러자 멘토님께서는 남은 기능들 중 "내가 아직 경험해보지 못한 개념이 있는 기능"들을 위주로 먼저 다음 주까지 하도록 안내해주셨다.

3. 따라서 페이징 개념(단, 인스타그램에서 쓰이는 무한 스크롤링 방식의 페이징)이 포함된 댓글 및 게시물 가져오기 기능을 구현하기로 결정내렸다.

 

사실 기본적인 페이징 기능에 대해서도 구현을 해본 적이 없기에 막막함이 약간 앞섰지만, 멘토님께서는 무한 스크롤링 방식에 쓰이는 페이징과 일반적인 페이징 기능의 주된 차이점에 대해 설명을 해주시면서 키워드를 알려주셨다.

또한, 구현 중 질문이 있다면 언제든지 call을 요청달라고 하셨기에 별다른 잡생각 없이 일단 구현을 해볼 예정이다.

 

사람은 아직 알지 못하는 미지에 대한 두려움이 가장 크다던데, 특정 개념을 처음 배우는 입장에서 든든한 길잡이가 있다는 건 인생에서 얻기 힘든 귀한 기회인 것 같다.

따라서 지난 날의 아쉬움을 바탕으로 이 기회를 더 효율적으로 누려볼 예정이다.

 

📑  레퍼런스가 많은 기능

우리가 기능 구현을 진행할 때, 나는 크게 구현 스타일이 2가지로 나뉜다고 생각한다.

하나는 레퍼런스가 많은 기능이고 다른 하나는 창작이 필요한 기능이다.

즉, 참고할 자료가 많은 노멀한 기능과 참고할 자료 없이 개발자가 스스로 구현을 진행해야 하는 기능으로 나뉜다고 볼 수 있다.

 

지금까지 구현했던 기능들을 포함하여 이번에 구현한 이메일 인증 API 또한 레퍼런스가 많은 기능이다.

일단 이전까지는 팀원 분의 코드를 기반으로 차용할 부분이 많았기 때문에, 팀원 분의 코드가 레퍼런스였다고 생각한다.

하지만, 이메일 인증 API의 경우 팀원 분 코드에서 참고하기에는 알맞지 않았기 때문에 검색을 통해 정말 많은 레퍼런스들을 참고했다.

 

이 과정을 거치면서 나는 "구현이란 무엇일까?"라는 생각을 하게 되었다.

에프랩에 들어온 후, 가장 많이 들은 이야기는 "구현보다 유지 보수성이 중요하다."라는 이야기였다. 그리고 이 이야기는 프로젝트를 하는 내내 조금씩 체감하고 있었기 때문에 동의한다.

하지만, 코드를 개선시키기 위해서는 선행 단계인 구현이 필요하다.

즉, 일단 구현을 완료해야만 개선이라는 단계로 넘어갈 수 있는 것이다.

 

하지만, 그동안의 나는 비교적 단순한 기능을 구현했기 때문에, 개선에만 몰두하고 구현에는 그닥 집중을 하지 않았다.

눈을 돌리면 당장 팀원 분의 코드에서 참고할 수 있는 부분이 많았고, 무엇보다 팀원 분과 멘토님이라는 든든한 멤버들과 함께 진행했기 때문에 모르는 것이 생기면 바로 질문을 통해 해결할 수 있었다.

따라서 예전처럼 모르는 것이 생겼을 때, 간절함을 가지고 검색을 통해 많은 해결 방법들을 시도하던 시기는 잘 겪지 않았다. 그리고 그에 따라 "사람들은 대체 기능을 구현할 때, 어떤 레퍼런스를 참고하는 거지? 블로그 코드는 퀄리티가 별로 좋지 않다던데.."라는 궁금증이 자연스럽게 생겼던 것 같다.

 

그리고 이번 이메일 인증 API를 통해 위의 궁금증을 극복하고자 했다.

"나보다 이 길을 먼저 걸어간 사람들이 대체 어떤 경험을 했기 때문에, 모두가 입을 모아 저런 말을 하는걸까?"가 궁금했다.

 

우선, 검색을 통해 수많은 블로그들과 약간의 공식 문서를 통해 기능을 구현했다.

그리고 발생하는 오류들은 GPT나 멘토님 및 팀원 분 등의 도움을 받지 않고 스스로 해결하고자 했다.

(예전의 나는 어떻게 했었지? 가 궁금하기도 했고, 멘토링이 끝났을 때의 나를 위해서 미리 경험했다.)

블로그의 많은 포스팅들을 통해 매직 넘버부터 시작해서 Controller와 Service의 역할과 책임에 맞지 않는 로직을 보고 코드를 읽는 입장인 나로서는 "정말 구현에만 집중했구나."라는 것을 금방 느낄 수 있었다.

하지만, 동시에 "블로그글의 코드가 아쉬운 건 사실이지만 이 코드를 기반으로 내가 개선을 시키면 되지 않을까?"란 생각이 들었다. 막연하게 Ctrl + C, Ctrl + V가 아니라 적당히 참고하면서 개선을 시킬 수 있다면 나쁘지 않는 방향이라고 생각했다.

 

결국, 나는 현재 나의 상태와 수준을 고려하여 사람들의 조언을 유연하게 적용시키면 된다는 결론을 내렸다.

- 구현보다 개선이 중요하다. -> 맞는 말이지만, 경험이 많이 없는 나에게는 구현도 중요하다.

- 블로그 글들은 퀄리티가 좋지 않다. -> 이것도 사실이지만, 참고할 부분은 참고하고 스스로 개선을 시키면 된다.

 

개발을 하는 사람은 나이기 때문에, 주체적으로 내가 사고하에 판단을 하면 된다.