벌써 부스트캠프 멤버십에 입과한지 4주가 지났다.
이상하게 챌린지 과정보다 멤버십 과정이 시간이 더 빠르게 흐르는 것 같다.
챌린지 과정은 하루 단위로 시간이 가는 반면, 멤버십 과정은 주 단위로 시간이 흐르는 느낌..?
나는 4주차에 무엇을 배웠나!
미션
FE 디자인 패턴
•
이번 주에는 프론트엔드에서 사용하는 디자인 패턴과 상태 관리에 대해 깊이 학습해보자는 목표를 세웠다.
•
처음에는 controller, api, store, view 각각의 역할이 감이 잘 오지 않아 삽질을 많이 했다.
•
하지만 직접 기능들을 구현하면서 각 구성 요소가 어떻게 상호작용하는지 나름대로 해석할 수 있게 되었다.
•
예를 들어, controller가 중앙 관제 역할을 수행하도록 하고, store와 view의 강한 결합을 끊기 위해 옵저버 패턴을 도입했다.
•
이 경험을 통해 단순히 이론을 공부하는 것보다 직접 부딪히며 코드로 구현하며 깨달을 때 더 오래 기억에 남고, 스스로 이해했다고 확신할 수 있었다.
•
앞으로도 새로운 기술을 학습할 때 책이나 문서를 읽는 데 그치지 않고, 작은 기능이라도 직접 만들어봐야겠다.
FE/BE 역할과 책임
•
미션을 진행하면서 매번 책임을 프론트엔드에 둘지, 백엔드에 둘지 많이 고민했다.
•
예를 들어, API 응답을 서버에서 join 해서 내려주는 방식과 클라이언트에서 매핑하는 방식에서는 각각의 장단점이 있었다.
◦
서버에서 join → 클라이언트 구현은 단순하고 데이터 일관성도 보장되지만, 응답 크기가 커지고 재사용성이 떨어질 수 있다.
◦
클라이언트 매핑 → 재사용성은 높아지지만, 상태 관리와 동기화가 복잡해진다.
•
이번 미션에서는 학습의 목적에 맞춰 클라이언트 매핑을 선택했지만, 실제 서비스에서는 성능과 일관성을 위해 서버에서 join을 많이 사용한다는 점도 새롭게 알게 되었다.
•
이 과정을 통해 느낀 건, 프론트엔드와 백엔드 서로의 고충을 이해하는 가장 좋은 방법은 직접 풀스택을 경험해보는 것이라는 사실이었다.
문서화
•
지난 주까지는 PR 문서를 작성할 때 정해진 포맷 없이 프리스타일(?) 형태로 작성했다.
•
이렇게 작성하니 가끔은 글이 장황하게 길어져서 읽는 사람들이 불편해할 수도 있겠다는 생각이 들었다.
•
그래서 이번 주부터는 문제 접근 과정을 Problem - Approach - Result 순으로 핵심만 요약해서 작성해보았다.
Problem - Approach - Result 순으로 핵심만 요약해서 작성해보았다.•
덕분에 문서가 훨씬 명확하고 간결해졌고, 리뷰어도 빠르게 이해할 수 있었다.
•
또한, 스스로 글을 정리하면서 왜 이런 선택을 했는지, 어떤 과정을 거쳤는지 다시 점검할 수 있어 설계와 구현의 일관성을 확인하는 데 도움이 되었다.
•
앞으로도 이 구조를 유지하면서 중요한 의사결정과 학습 포인트를 문서에 담아 동료에게 공유하려고 한다.
피어 리뷰
코드 리뷰
•
이번 주는 피드백에 적극적인 동료들을 만나서 새로운 방식으로 코드 리뷰가 진행됐다.
•
리뷰 대상자는 꼬리잡기 방식으로 정해지는데, 덕분에 매일 다른 사람의 코드를 리뷰할 수 있었다.
•
내가 작성한 코드를 매일 누군가가 리뷰한다고 생각하니 조금 더 책임감 있게 코드와 PR 문서를 작성하게 됐다.
•
리뷰 과정에서는 단순히 잘한 점을 칭찬하는 데 그치지 않고, 구현 의도를 묻거나 더 나은 방법을 함께 고민하는 대화가 오갔다.
•
그 덕분에 나도 다른 사람의 시각으로 내 코드를 바라볼 수 있었고, 반대로 내가 가진 지식이나 팁을 공유하면서 동료들과 함께 성장할 수 있었다.
•
좋은 코드와 리뷰 방법이 무엇인지 깨닫게 해준 web12 팀 동료들(다미님, 혜정님, 서연님)에게 감사하다.
동료 피드백
•
3주차 동료들의 피드백을 보면서 감동을 많이 받았다.
•
팀에 조금이라도 도움이 되기 위해 했던 행동들을 다 기억해주시고, 좋은 점과 개선할 점까지 솔직하게 남겨주셔서 정말 감사했다.
•
나도 다른 동료에게 좋은 피드백을 주기 위해서 관찰을 더 꼼꼼히 하고, 메모를 조금씩 해놔야겠다고 생각했다.
마스터 클래스
기억에 남는 것
•
서비스의 장애 대부분(90%)는 DB에서 일어난다.
•
관계형 DB에서 제공하는 중요한 기능 중 하나는 트랜잭션이다.
•
내가 할 수 있는 것에만 AI를 써라.
•
풀스택의 장점은 최적의 상태 API를 고민해볼 수 있다는 것이다.
•
배포는 기능을 다 만들고 하는 게 아니라 시작하자마자 하는 것이다.
•
주니어들은 ERD를 그리면서 어떤 기능, 서비스를 만들지 명확히 정리할 수 있다.
☕️ ‘클린 코드와 코드 리뷰’ 특강
•
이번 주에는 SK플래닛과 우아한형제들을 거쳐 컬리의 CTO까지 역임하신 박성철 개발자님의 강의를 들을 기회가 있었다.
•
정말 많은 이야기가 강의에서 나왔던 것 같은데 그 중 가장 기억에 남는 것은 다음과 같다.
1.
클린 코드 != 예쁜 코드 (미학보다 오류를 줄이고 의미를 전달하는 것이 더 중요)
2.
[클린 코드] 창발적 설계로 깔끔한 코드 구현하기
a.
모든 테스트를 실행한다.
b.
중복을 없앤다.
c.
프로그래머 의도를 표현한다.
d.
클래스와 메서드 수를 최소로 줄인다. (실용적 관점에서 타협한다.)
3.
코드의 가치: 의도 드러내기 > 단순함 > 유연성
4.
코드 리뷰의 목적
a.
코드 품질 개선
b.
일관성 유지 (누가 짰는지 알 수 없을 정도로)
c.
지식 공유 (내 지식과 남 지식이 공유되는 좋은 기회)
d.
협력과 소통 (SW 개발 = 팀 스포츠)
5.
사람이 아닌 코드를 비판하고, 코드가 아닌 사람을 친절하게 대하라.
•
느낀 점: 의도가 잘 드러나는지, 단순한지 매번 생각하면서 코드를 작성해야겠다고 생각했다.
5주차에 보완할 점
FE
•
console.log를 쓰지 않고 개발자도구로 디버깅하기
•
비동기 코드 에러 핸들링 신경쓰기
•
FE/BE 개발과 학습의 균형 지키기
•
controller를 단순화 해볼 방법 고민해보기
BE
•
기본 틀만 잡고 바로 배포하기
•
비동기 코드 에러 핸들링 신경쓰기
•
성능 문제 항상 신경쓰기
•
repository 주석으로 반환 타입 명시
•
테스트 코드 신경쓰기
ETC
•
vscode path alias 설정
마치며
다음 주부터는 처음으로 캠퍼들을 오프라인 자리에서 만난다.
가서 잘 적응할 수 있을지 조금 걱정은 되지만,
그동안 온라인으로만 접했던 동료들을 직접 만나고 소통할 기회가 생긴다는 점이 기대된다.
5주차도 파이팅 해보자.