[2023.11.03] Bi

✏️ WIL

1. 프로젝트

- 이메일 인증 API Refactor (진행 중)

- 댓글 가져오기 API Feat (완료), Refactor (진행 중)

- 프로필 피드 가져오기 API Feat (진행 중)

- 게시물 생성 API Code review (진행 중)

2. 코딩 테스트

- 1주차 Code review 및 PR Merge

- 2주차 Feat (예정 - 현재 1/5 진행 중)

3. 면접 스터디

- Java/Spring 관련 정리

- 혼공컴운 Section 5, 6 수강

 

💌  멘토링

이번 주부터 1:1 멘토링이 시작되었다.

그리고 저번 주 세션 때, 과제로 내주셨던 댓글 가져오기 API 및 프로필 피드 가져오기 API 구현에 대해서 대략 75%정도 완료해갔다.

 

25%가 빠진 이유는 다음과 같다.

- Controller의 validation이 몇 개가 누락된 점

- SQL문의 조건문에 몇 개가 누락된 점(ex. lastCommentId가 없을 경우)

- resultMap을 작성하지 않아 response body에 null 값이 매핑된 점 (이 사항은 무한 스크롤링이라는 동일한 기능을 제공하는 프로필 피드 가져오기 API에서도 동일하게 발생했다.)

- 테스트 코드는 아직 작성하지 못 한 점

 

따라서 기존의 내 페이스보다는 더 나아가 계획했던 진도까지는 맞췄다는 점이 약간 놀랐지만, 그럼에도 불구하고 위와 같은 아쉬운 점이 존재했기에 세션 때 바로 주간 피드백을 요청드렸다.

 

그러자 멘토님께서는

- "왜 프로필 피드 가져오기 API는 구현하지 못하셨나요?(= PR을 올리지 않은 점)"

- "댓글 가져오기 API를 구현하는데, 실제로 어느정도 걸리셨나요?"

- "왜 생각보다 시간이 걸리셨다고 생각하셨나요?"

- "서칭을 오랫동안 하신 것 같은데, 이유는 무엇인가요?"

- "해당 행위가 도움이 되었나요?"

와 같은 객관적인 질문을 많이 하셨다.

 

이에 대답을 하면서 어느 질문은 확신에 찬 대답을 할 수 있었지만, 어떤 질문은 '그러게, 지금 생각보니 너무 지나쳤다.' 또는 '생각 외로 시간을 잘 활용하지 못 했구나.'와 같은 자아 성찰을 할 수 있었다.

 

전에 2:1로 진행을 할 때에는 아무래도 멘토님이 팀원 분과 나를 동시에 코칭해야했기 때문에 + flexible한 멘토님 성향에 따라 유야무야 시간이 흘러갔던 때가 많았다.

하지만, 1:1로 전환되고 나니 서로 직접적으로 피드백을 요구하기가 수월해졌기에 밀착 마크를 받는 지금은 "내 수준에 맞게 계획을 설계"하는 것이 수월하게 진행되었다.

아무래도 스스로 계획을 세울 때는 조급함을 느끼기 때문에 과도하게 계획을 설계하거나 보수적으로 계획을 설계했던 때가 많았기 때문이다.

 

그리고 이번 주 세션에서 멘토님과 나눴던 수많은 토픽 중 2개의 토픽이 인상깊었다.

 

먼저, 나는 무한 스크롤링 기능을 구현하기 위해 수많은 레퍼런스를 찾아 헤맸다.

하지만, JPA + Querydsl과 같은 조합은 많이 보였지만 Mybatis로 구현한 레퍼런스(SQL은 있었지만, Application layer에 관한 코드)는 찾을 수 없었다.

따라서 나는 정말로 "내가 온전히 스스로 구현해야 하는 기능"을 구현해야 하는 상황을 마주했다.

 

그래서 나는 찾았던 SQL문을 바탕으로 필요한 필드들을 뽑아냈고, 해당 필드들이 Mapper까지 잘 전달될 수 있도록 Application layer 코드까지는 설계했다.

물론 이 과정 중에서 정말 gpt의 도움은 받고 싶지 않았는데, "도통 잘 맞게 진행하고 있는건가?" 또는 "내가 빼먹은게 있나?"라는 생각으로 머릿속이 가득차서 도움을 좀 받았다. 그리고, 든 생각은 "정말 이게 끝이라고?"라는 생각이었다.

 

내가 찾아봤던 JPA + querydsl 조합의 코드들은 정~말 코드가 길었고, 다양한 기능을 제공하고 있었다.

하지만, 내가 구현한 코드는 무한 스크롤링, 즉 no-offset의 정의만 그대로 나타내고 있었다.

따라서 "진짜 잘 구현한게 맞나? 분명 조건을 더 추가해야할 것 같은데? gpt의 설명이 잘못된 것 아닐까?.." 등등의 생각으로 머릿 속이 복잡해졌었다.

 

이를 멘토님께 말씀드리니, 멘토님께서는 다음과 같은 말씀을 해주셨다.

"우선, 구현은 요구사항에 맞춰 동작하기만 한다면 잘 구현한거에요. 은비님께서 구현하신 코드도 no offset의 기능을 잘 나타내셨잖아요? 그리고 실제 request에 따라 response에 값이 잘 담겼다면, 거기서 끝이에요.

물론 몇몇 SQL에 몇몇 조건이 누락된 건, 사실 잘 구현했다고 볼 수는 없죠. 하지만 이런 부분은 코드 리뷰를 통해 개선을 받을 수 있는 부분이에요.

 

그리고 gpt의 도움을 받으신 건 사실 저는 그렇게 나쁘게 보진 않아요.

사실 지금은 간단한 기능을 구현하는 과정 중에 gpt를 참고하신 거잖아요?

하지만, 우려해야 하는 부분은 나중에 보다 복잡한 기능을 구현할 때 - 그러니까 gpt도 이해하기가 힘든 기능을 구현할 때에는 어떻게 구현해야 할까?라는 부분이죠.

개발은 확실히 경험치가 필요한 순간이 많고, 위와 같은 순간이 그런 순간이죠.

그래서 당장 gpt를 참고한 사실보다 나중에 경험치를 요구하는 순간을 맞닥뜨렸을 때, 어떻게 대처할 것인지에 대해서 생각을 하면 될 것 같아요."

 

멘토님의 말씀을 듣고 나니 "평소에 내가 gpt를 참고하는 것을 우려했던 본질적인 이유가 이거였구나."라는 생각이 들었다.

 

나는 불과 얼마 전까지 구현보다 개선이 중요하다고 생각하고 있었다.

따라서 현재 내 수준에 맞는 학습 방향성을 잡지 못했었고, 구현도 중요하다는 생각을 느낀지도 얼마 안 되었다.

그렇기에 구현을 할 때에도 레퍼런스가 있는 기능만 구현했지, 정말로 레퍼런스가 없는 기능을 구현을 해본 적도 / 이렇게 빨리 하게 될 줄도 몰랐다.

 

그래서 처음으로 혼자 구현해보는 이 상황이 너무나 어색해서 타자 하나하나가 "이게 맞나?"라는 생각으로 가득찼었다.

그리고 레퍼런스를 정도껏 참고하는 것처럼 gpt를 정도껏 참고하는 것도 그 순간에 처음 학습했었다.

 

결과적으로 처음 마주하는 상황에서 하는 행동 하나에 의구심을 갖고 진행했던 것 같다.

사실 이 글을 쓰는 지금도 이 상황을 다시 마주하면 어떻게 진행해야 할지 잘 모르겠지만, 의구심은 줄이고 나를 좀 더 믿고 발을 떼볼 수는 있을 것 같다는 생각이 든다.

 

이제는 다시 부딪히면서 해결책을 강구하고 싶기 때문에, 오히려 빨리 다시 이 막막함을 느끼고 싶다.