2주차의 주말을 맞았다.
이번 주에는 바쁘게 지내느라 만나지 못했던 친구들을 오랜만에 만났다.
부스트캠프에 들어온 뒤로는 하루하루가 빠르게 지나가 개인적인 시간을 갖기 쉽지 않았지만,
잠시 숨을 고르고 사람들과 대화하는 시간이 필요하다는 것을 다시 느꼈다.
나는 2주차에 무엇을 배웠나!
미션
디버깅 툴
•
2주차 미션부터는 VS Code와 REST Client 같은 디버깅 툴을 어떻게 활용할지 고민하게 되었다.
•
기존에는 문제가 생기면 알고 싶은 변수만 console.log로 찍어보고, 문제가 없으면 다른 변수로 확인하는 식으로 문제를 해결했다.
•
하지만 이번에는 브레이크포인트와 REST Client를 활용해서 요청과 응답, 변수의 흐름을 단계적으로 분석해보려고 했다.
•
특히, REST Client를 잘 활용하려면 HTTP Request와 Response의 구조를 명확히 이해하고, 필요한 파라미터와 헤더를 정확히 설정하는 것이 중요했다.
◦
예를 들어, multipart/form-data 요청을 처리할 때는 boundary의 개념을 알고 있어야 한다.
•
3주차에는 브라우저 디버깅 툴을 공부해보고 적극적으로 활용하려고 한다.
API 설계의 중요성
•
이번 주에는 설계의 중요성을 다시 한 번 느꼈다.
•
1주차에 프로젝트 구조에만 집중하느라 API 명세서를 작성하지 않고 바로 개발을 진행했더니, 요청과 응답 형식이 혼란스러워 여러 번 수정을 반복하게 되는 비효율이 발생했다.
•
2주차 동료의 API 명세서를 참고하며 직접 API 명세서를 작성해보니, 내가 놓쳤던 부분과 잘못된 구현을 명확히 확인할 수 있었다.
◦
예를 들어, 409 Conflict가 적절한 상황에서 400 Bad Request를 사용하고 있다는 점을 발견했다.
◦
또한 API 설계 기준과 실제 구현이 일치하지 않은 부분도 확인할 수 있었다.
•
무엇보다, 설계 문서를 기준으로 구현하니 수정 횟수가 줄고 개발 속도가 빨라졌다.
•
3주차 부터는 설계 문서를 먼저 작성한 후 개발을 시작하는 방식을 습관화하려고 한다.
문서화
•
챌린지에서 멤버십으로 넘어오면서 가장 큰 고민이 늘어난 문서를 어떻게 관리할지였다.
•
챌린지에서는 문서화를 할 때 어느 정도 정해진 가이드라인이 있어서 크게 고민하지 않았지만, 멤버십에서는 문서 종류와 양이 훨씬 다양해지고 자유도가 높아졌다.
•
주간 계획, PR, 문제 해결 과정, 학습 기록, 설계 문서, 회고 등 여러 종류의 문서를 동시에 관리해야 하므로, 효율적인 정리 체계가 필요하다는 것을 느꼈다.
다른 동료로부터 배운 문서화 방법
피어 리뷰
팀 빌딩
•
이번 주에는 팀 빌딩에 들어가기 전에 1시간 정도 시간을 내서 새로 만날 동료들의 렛미인트로듀스 문서들을 읽고 갔다.
•
다른 동료분의 제안으로 첫 30분 정도는 서로를 알아가는데 집중하는 시간을 가졌다.
•
덕분에 첫 만남이 조금은 덜 어색했고, 대화할 때 상대방의 관심사나 경험을 미리 알고 있으니 자연스럽게 이어갈 수 있었다.
•
다음 주에도 같은 방식으로 준비해서, 대화할 때 상대방을 더 이해하고 빠르게 공감대를 형성할 수 있도록 해보고 싶다.
데일리 스크럼 & 코드 쉐어
•
1주차에는 동료들의 코드를 살펴본 시간이 너무 적었다고 스스로 생각했다.
•
이번 주에는 데일리 스크럼 시간에 들어가기 전에 1시간 정도 시간을 내서 코드들을 살펴보고 갔다.
•
1시간 안에 다른 동료들(3명)의 코드를 모두 다 읽기란 불가능하다고 생각해서 나는 다음을 중점적으로 봤다.
1.
어려웠던 부분 (내 것 + 동료가 언급한 부분)
2.
나와 다른 접근 방식
3.
코드를 읽으며 생긴 궁금증
•
다음은 내가 실제로 컴파일링을 하면서 작성했던 문서의 예시이다.
// 메모 예시
J999 (ooo님)
- 어려웠던 부분 (내 것 + 동료가 언급한 부분)
- 어려운점1
- 동료가 사용한 방법
- 어려운점2
- 동료가 사용한 방법
- 어려운점3
- 동료가 사용한 방법
- 배운점
- DTO를 활용하신 점이 인상 깊었다.
- 컨트롤러에서 try-catch 문으로 에러를 잡고 catch 블록에서 next(err)로 넘겨주신 점이 좋았다.
- 궁금한 점
- Service에서 try-catch문이 없는데 만약 repository 단에서 에러가 발생하면 controller로 에러가 전파되는지 궁금하다.
Plain Text
복사
•
이렇게 정리를 하고 들어가니 코드를 볼 때 훨씬 집중도가 높아졌다.
•
그리고 동료들에게 질문을 던질 때도 이미 정리한 내용을 바탕으로 하니 대화가 빠르게 이어졌고, 자연스럽게 토론 분위기가 만들어졌다.
•
3주차부터는 ‘코드 리뷰’ 과정이 추가되기 때문에 ‘메모’를 하는게 아니라 실제 코멘트로 남겨보면서 시행착오를 겪어볼 생각이다.
동료 피드백
•
1주차에 이어 2주차에도 SBI(Situation-Behavior-Impact) 방식을 활용해 동료에게 피드백을 남겼다.
•
2주차에는 동료 피드백을 잘 작성하기 위해 데일리 스크럼, 그룹 코드 쉐어 등 다양한 상황에서 동료들의 행동과 태도를 관찰했다.
•
피드백을 작성하면서 느꼈던 점은 다음과 같다.
1.
의견을 자주 개진하는 동료는 행동과 의도를 더 쉽게 관찰할 수 있어, 구체적이고 의미 있는 피드백을 제공하기가 수월했다.
2.
반대로 조용한 동료는 더 주의 깊게 관찰하고, 작은 행동이나 발언도 놓치지 않으려 노력해야 했다.
•
이 과정을 통해 좋은 피드백을 받기 위해서는 내 행동과 의견을 명확히 표현하는 것이 중요하다는 것을 깨달았다.
수료생과의 MeetUp
•
이번 주에는 네이버 부스트캠프 8기, 9기 수료생 분들의 이야기를 들을 수 있는 시간을 있었다.
•
특히 기억에 남는 조언은 세 가지였다.
1.
잘하는 사람을 따라하기보다, 내가 잘하는 걸 찾아라.
•
다른 사람을 모방하기보다 자신만의 강점을 발견하고 발전시키는 것이 중요하다.
2.
묻는 것을 두려워하지 마라.
•
질문을 통해 나 뿐만 아니라, 동료와 함께 성장할 수 있다.
3.
네부캠에서는 피드백을 받을 수 있는 최고의 환경이 마련되어 있다.
•
동료와 멘토에게서 즉각적으로 피드백을 받을 수 있는 환경을 최대한 활용하라는 조언이 인상적이었다.
•
나는 남 눈치를 많이 보는 성격이어서, 질문하거나 의견을 내는 것을 망설일 때가 많다.
•
하지만 수료생들의 이야기를 들으면서, 주저하지 않고 묻고 피드백을 받아들이는 태도가 성장에 큰 차이를 만든다는 것을 깨달았다.
•
앞으로는 작은 것이라도 궁금한 점이 생기면 적극적으로 질문하고, 동료와 피드백을 적극적으로 받아들이면서 나만의 강점을 개발하는 데 집중하고 싶다.
마치며
베이직 회고를 작성한게 7월 10일인데, 이제 벌써 두 달이 다 되어간다.
처음에는 단순히 ‘오늘 뭘 했는지’를 적는 정도였지만,
점점 무엇을 느끼고 배웠는지 다음에는 어떻게 개선할 수 있을지까지 생각하게 되었다.
짧게는 하루, 길게는 두 달 동안의 회고를 돌아보니
작은 습관과 꾸준함이 모여 큰 변화를 만든다는 것을 체감하고 있다.
앞으로도 이 기록들을 바탕으로 계속해서 배우고 성장하는 모습을 놓치지 않고 담아내고 싶다.