매주 회고를 쓸 수 있을 지 모르겠지만... 이번주는 인사이트를 가볍게나마 나누고 싶어서 구구절절 적어보았습니다.
이번주에 한 것
What is New?!
- 피그마 처음 써봤는데, 이걸 왜 지금 썼지 싶을 정도이더라고요. 공부하는 방식에도 적용하고 블로깅할때도 가볍게 그림 컨텐츠를 제작할 때도 쓰면 좋겠어요 👍
- 이력서 갱신 ✨ 이제 블로그 쓰면서 링킹하면 됩니다.
- Spring 의 특징인 PSA에 대해서 공부했습니다.
👩🏻💻 What I leared
일은 작게 하자, 커밋은 한 단위를 다 포함시키게 하자.
이미 작업기간이 모두 끝나고 문서만 정비하고 있는 프로젝트가 있는데 정말 오랜만에 팀원과 만나서 문서화 겸 코드를 수정하여 브랜치를 합칠 일이 생겼습니다. 그런데 그 중간중간 저는 한 브랜치에다 주마다 1개씩 코드 수정사항을 쌓고 있었거든요. 함께 하는 백엔드 팀원은 프로젝트를 진행하지 않아서 피드백이 없었고, 합치기 뭐해서 그냥 옆에다가 쌓아둔 것이죠. 그렇게 커진 브랜치는 본 브랜치와 합치기 매우 힘들었습니다. 엄청난 충돌이 났거든요. 그래서 그냥 hard push로 origin을 모두 덮어 써 버렸어요.
이 경험으로 가장 강렬한 배움을 얻었습니다.
- 한 커밋에는 작업 단위에 대한 모든 변경사항을 다 넣어야 한다.
예를 들어 내가 파일의 이름을 바꾸었다면, 바꾸기 전과 후를 한 커밋에 넣습니다. pull을 받는 입장에서는 커밋 단위로 작업을 비교하기 때문에 이름변경에 대해 1회 처리할 것을 2번 거쳐서 충돌 처리를 하게 되더라고요. 이 작업은 한 트랜잭션에 이루어져야 하는 것입니다 (...)
- 커밋과 PR은 작은 단위로 해보자.
협업하는 동료나 미래의 내가 작업의 흐름을 따라올 수 있을 정도로 커밋을 작성합니다. 그리고 프로젝트에는 약 400줄 내외의 PR을 올립니다. 근데 다른 현업 팀의 예시를 들어보니 200줄 내외의 PR단위를 쓰기도 하시더라고요. 코드 리뷰 받기도 쉽고, 변화를 빠르게 적용하여 내 코드에서 사용하기 편해집니다.
이 주제와 비슷하게 취업 준비 스터디에서 추천받은 글 있습니다. Working in small batches (그리고 이 아티클을 바로 번역해준 동료의 블로그 글도 링크합니다 (번역 및 정리) Working In Small Batches)
간단히 내용을 요약해보자면 아티클은 다음과 같습니다.
작은 단위로 일할 때는 가벼운 접근 방식을 통해 소프트웨어 개발단계에서 테스트-운영-프로덕션의 과정을 축소할 수 있습니다.
소규모 단위 작업했을 때의 장점
1. 변경 사항에 대한 피드백을 받는 데 걸리는 시간이 줄어듭니다. 문제를 더 쉽게 분류하고 해결할 수 있습니다.
2. 효율성과 동기부여가 향상됩니다.
3. 소속한 팀이 매몰 비용 오류*에 빠지는 것을 방지합니다.
* 매몰비용 오류란, 지금 여기까지 했으니 이대로 하자! 라는 태도이겠죠? 그 길이 정답이 아닐지라도 종종 그렇게 의사결정을 하기도합니다.
소규모 단위 작업하는 방법
INVEST 원칙의 Agile 개념을 따릅니다.
- Independent 작업 배치를 최대한 독립적으로 만들어 구현/배포 순서에 독립적으로 배포하고 검증할 수 있도록 합니다.
- Negotiable 각 작업 배치는 반복 가능하고, 피드백을 받으며 재협상(수정)할 수 있습니다.
- Valuable 개별 작업 배치는 유의미하며, 이해 관계자들에게 가치를 제공합니다. (무의미한 작업을 나누지 않습니다.)
- Estimable 쉽게 추정할 수 있는 작업 배치에 대한 충분한 정보가 있습니다.
- Small 작은 시간 단위로 일괄 작업을 완료할 수 있어야 합니다.
- Testable 사용자가 기대하는 방식으로 작동하는지 자동화된 테스트로 테스트, 모니터링, 검증할 수 있어야 합니다.
핵심은 UI레이어가 아닌 서비스나 API레이어에서 개발을 시작하는 것입니다. UI 레이어는 작업 단위를 나누기에 너무 크기 때문입니다.
대신 주의할 점이 있습니다. 작업을 충분히 작은 조각으로 나누는 것과 이 작은 단위를 모아서 릴리즈 단위로 테스트를 실행하기 위해 그룹화 하는 것입니다.
일의 방식을 바꾸는 것은 물론 비용이 많이 듭니다. 구성원들의 공감대도 필요하고요. 특히나 저처럼 지금 리더가 따로 없는 프로젝트를 할 때는 그 공감대가 굉장히 중요합니다. 다음 프로젝트를 진행할 때 미리 공유해보고 소규모로 문제를 쪼개고 해결해보는 경험을 해보는 것도 좋을 것 같다는 생각을 했습니다.
문제의 엣지 케이스를 찾아내자
최근 쏘카 코딩테스트에 참여하였고 탈락했습니다 🥲
문제에 주어진 테스트 케이스는 모두 통과하였고, 제가 임의로 넣은 테스트들도 통과해서 문제가 없는 줄알았는데요. 제가 찾지 못한 엣지 케이스가 있었던 모양입니다.
돌이켜보면 알고리즘 문제를 풀면서 늘 주어진 테스트 케이스와 제출시 제공되는 테스트 결과에만 의존하고 있었던 것 같습니다. 엣지 케이스를 고민하고 찾아내는 연습을 해야겠다는 생각을 했어요. 실제로 개발할 때도 내가 개발하는 소프트웨어에 대한 상상력이 중요하니까요.
재능 있는 척 하지 않기
그리고 대충 아는 척 하지 않기 BUT 아는 것은 나누기
최근 인상깊게 읽은 블로그 글이 있습니다. 재능 있는 척 하지 않기
글의 요지는 '노력하지 않아도 잘 하는 척'을 했을 때의 단점에 대해서 였습니다.
과거 부끄러웠던 나의 과거를 돌아보며 현재의 마음가짐을 다잡을 수 있는 내용이었는데요.
과거에는 열심히 노력했는데 결과가 없는 사람이 되는 것이 매우 무서웠습니다. 무능한 사람이 되는 것 같아서요. 지금은 최대한 열심히 하는 나를 부끄러워하지 않으려 합니다.
예전 동료 중에 약 20년간 검도를 꾸준히 해온 사람이 있었는데, 그를 보고 꾸준함이 가장 큰 재능이라는 생각이 들었거든요. 제가 성실하지 않다고 생각했기 때문에 늘 그런 사람들을 존경하고 부러워하기 시작했던 것 같아요.
전혀 모르는 세계로 딥다이브하기 위해서는 내가 열심히 노력하고 있다는 사실을 크게크게 알리려 해야겠어요. 다른 기회도 제안받을 수 있을 뿐더러 '함께 하고 싶은' 사람이 될 수 있는 것 같아요.
여기에 더해서 생각한 것은 "대충 아는 척 덜하기"입니다.
최근들어 기술적 겸손함이 중요하다는 생각이 들었어요. 조금씩 아는게 생기니까 "오! 나 이것도 알아"하는 무의식이 있었나봐요. 하지만 이런 태도가 상대방에게 들을 수 있는 말들을 가로막는 것 같아요.
부트캠프를 다닐 때는 제 말버릇이 "저 잘 모르는 거에요. 어떤거에요? 알려주세요." 였는데요. 물론 진짜 모르는 개념을 만났을 때 이런 이야기를 하기도 했지만, 어설프게 알고 있을 때도 "~까지만 아는데 잘은 몰라요" 하고 얘기했었어요. 그 사람이 이해하고 해석한 개념을 듣는 것이 재미있었기 때문이었어요.
요즘들어 혼자 공부하는 시간이 많아지니까 자연스럽게 이런 기술적인 이야기를 주고받을 기회가 매우 적어지더라고요. 그러다보니 그 감각을 잊게 되어버린 것 같아요. 동료에게 배우고 내가 알고있는 것을 최대한 공유하려고 하는 그런 자세요. 다시 한번 러너로서의 자세를 다잡으며 연말을 맞이해야겠습니다.
신입 개발자 취준 모임
감사하게도 좋은 기회가 생겨서 매주 토요일 아침마다 신입 개발자 취준 모임을 시작하게 되었습니다.
매일 SoD와 EoD를 하고 매주 블로그 글을 작성하고 공유하고 매주 토요일 아침에 만나 한주간의 회고를 하곤 합니다.
특별히 기술적인 배움을 위해 모이는 것은 아닙니다만. 이 짧은 시간으로 마인드셋을 다시금 단단하게 잡게 되더라고요. 함께하시는 분들의 적극적인 태도가 얼마나 자극적이던지 🔥 (이 글도 자극받아서 쓰게 된 회고...)
앞으로도 기대가 되는 모임입니다. 열심히해서 내년 봄 전에는 방탈출이 목표에요 🔥
다음 주에 할 것
