F-Lab

1. 시작하며 21년 11월부터 22년 4월까지 6개월 간 F-Lab의 멘토링을 수료했다. 그동안 여러 궁금증도 해소하고, 내 문제점들도 파악하고, 많은 개발자 분들과 교류도 하고, 크고 작은 서비스 회사에 면접을 보는 기회도 얻고, 운이 좋게도 그 중 몇몇에는 합격하기도 햇다. 정말로 치열한 백엔드 개발자 시장에서 합격한 대로 입사하는 마냥 쫓아가기만 하는 상황에서 선택이라는 사치를 아주 조금이나마 부릴 수 있는 정도는 된거 같고 어떻게 하면 경쟁력을 유지할 수 있는지도 (hopefully) 익힌 것 같다. 약 반년 전 까지만해도 방황하던 나를 더 나은 상황에 있게 만들어준 F-Lab의 백엔드 개발자 멘토링에서 경험한 것들을 공유해본다. F-Lab의 멘토링을 고민하고 있을 또 다른 개발자분들께 조금이나..

이번 포스팅은 혹시나 다른 방법을 찾으신 분은 댓글로 공유 부탁드립니다! Contents 0. "중계 서비스" 관점에서 API 문서화가 필요한 이유 1. Swagger 채택 이유 1-a. 적용을 위한 비용이 상대적으로 낮습니다. 1-b. Swagger에서 Spring Rest docs로 전환하는 케이스가 많습니다. 1-c. 저렴한 전환 비용 2. Swagger : 단점과 보완 전략 2-a. 검증이 되지 않은API의 노출 2-b. 서비스를 위한 코드와 문서화 코드의 결합 3. 서비스 코드와 문서화 코드의 분리 방법 3-a. Swagger의 동작 원리 3-b. 적용 순서 3. 마치며... 0. "중계 서비스" 관점에서 API 문서화가 필요한 이유 최근 프로젝트에 문서화 툴을 적용하자는 제안을 받았습니다. 물..

Contents 시작하며 Level 1. 이벤트 순서대로 나열하기 갑자기 Bonus? 중개와 중계 차이점 Level 2. 역할 관점으로 분리하기 Level 3. 결과 반환시점을 기준으로 기준으로 분리 Level 4. 커뮤니케이션 역할에 따른 서비스 분리 Level 5. 동기-비동기로 분리 Level 6. 초기세부구현 : 시작점 Level 7. 추후 고민이 필요한 부분들 1. 주문상태확인 기능 2. 중개 기능 (요청 전달) 3. 라이더의 위치정보 오늘은 여기까지 시작하며 지난번 블로그에서 프로젝트 주제선정 과정과 기초 유저 플로우(위 사진)를 소개해드렸습니다. 이후 저는 상세 구현 목록과 서비스 아키텍처를 도출하기 위해 로버트 마틴 "클린 아키텍처"를 옆에 펼쳐놓고 서비스를 디테일하게 분석하기 시작했습니다..

Contents 0. 시작하기 앞서 1. 주제 범위 좁히기 2. 주제는 "배달의민족 중계 서비스"로 정했습니다. 3. 유저 플로우를 정의했습니다. 4. 마치며.... 5. 참고 자료들 0. 시작하기 앞서 팀프로젝트 주제 선정은 왜 중요하고, 왜 어려울까요? 우선 주제는 명확할수록 개발 과정에서 협의가 순조롭게 진행될 수 있기 때문입니다. 또한 주제는 프로젝트 이름에 반영되고 프로젝트 이름은 git repo와 소스 코드에 조금이라도 반영되기 때문입니다. 저는 과거 여러 프로젝트들을 거치면서 나름의 주제 선정 전략을 다듬어왔고 이번 프로젝트 주제를 기대 이상으로 순조롭게 정할 수 있었습니다. 주제도 팀 전체가 만족하는 것으로 보입니다. (please!) 그래서 오늘은 이번에 적용해본 주제 선정 과정을 여러 ..

Contents 프로젝트를 시작합니다 프로젝트를 통해 목표하는 우리의 경험 마치며 프로젝트를 시작합니다 프로젝트를 싫어하는 사람이 있을까요? 드디어, 제가 참여하고 있는 F-Lab 멘토링에서 팀 프로젝트를 시작하게 되었습니다! (참고로 이론 공부도 재밌습니다) 저는 프로젝트라면 다 좋은데요 그중 팀 프로젝트에서 재밌는 부분은 커뮤니케이션 때문인 것 같습니다. 정말 열심히 연구해서 공유한 솔루션이 반영돼도 좋고, 그 내용보다 더 효과적인 솔루션을 찾으면 하나 배우게 돼서 좋고, 그렇습니다. 이번 프로젝트는 전반적인 프로젝트 진행 과정을 저와 멘티님 한분이 주도하게 되서 더 의미 있을 것 같네요. 오늘은 F-Lab 에서 제안하고, 멘토님도 제안하시고 제가 배우는 입장에서 생각해보는! 프로젝트를 통해 목표하는..

나의 첫 회고록 나의 첫 회고록이다. 어제의 자신보다 나은 내가 되는 것을 중요시 여겼는데. 한달전, 1년전의 나보다 발전했는지를 체크하지 않은 것 같다. 지금 생각해보면 회고를 하지않고 회고록을 작성하지 않음으로 목표를 향해 우회할 가능성이 더 높아보인다. 앞으로 주기적인 회고를 통해 발전할 수 있기를! A. 퇴사와 멘토링 시작 "나의 학습 방법이 맞는 걸까?" "나의 커리어를 내가 주도적으로 이끌어가고 있나?" "나는 성장하고 있을까?" 최근 정말 많이 던졌던 질문들이다. 프로그래밍을 시작한 이후 항상 어제보다 더 나은 전문가가 되기위해 노력했다. 하지만 누군가 "노력 대비 최선의 결과를 만들어냈는지"를 묻는다면 그렇다고 대답할 자신이 없는게 문제... 여기서 내린 현실적인 결론은 이렇다. "나의 방..