🐤 25년 8월 회고

오픈 닥터 제품팀에 7월에 입사해서 온보딩을 지나 8월부터 본격적으로 내부에서 사용하는 솔루션 마이그레이션 기능을 담당하고 있다.

DB와 백엔드 코드도 틈틈히 살펴보면서 비즈니스 로직을 찾아가며 이해하려고 하고 있지만 로직들이 복잡해서 해맬 때가 부지기수이다. 동료들과 사수분의 도움으로 빠르게 적응해가고 있다. 🙏🏼🙏🏼

우선 8월 한 달간 일하면서 하루하루 배워나가는 게 많았다. 가장 크게 든 생각은 필요한 기능을 빠르고 잘 만드는 역량을 키워야겠다는 것을 느꼈다. 또한 일정을 맞춰 개발하는 훈련이 필요하다는 것을 느꼈다.

우리는 스프린트 플래닝 미팅을 2주 간격으로 진행하고 있다. 2주간의 스프린트에 내가 할 일들을 제품팀 안에서 공유하는데 8월에는 평균적으로 내가 공유한 일정보다 최소 1.5배에서 최대 2배까지 걸리는 것을 보면서 수습 기간에 이 갭을 줄이는데 집중해야겠다고 느꼈다. PO님이 그 갭을 줄이기 위해 나아가야 할 방향을 제시해주셔서 진심으로 감사했다. 수습 기간에 철저히 연습해보려고 한다.

일정이 밀리는 원인은 복합적이다. 이를 본 포스트에서 이슈 트리를 활용하여 문제를 정의해보았고 이를 기반으로 9월에는 솔루션 피처를 일정에 맞춰서 개발하는 연습 및 팀에 더 녹아들 수 있도록 힘 써볼 예정이다.

들어가며

다시 한번 점검하고 가는 Git!

• 참고 : 깃 공식 문서 이미지

Git은 버전 관리 시스템이다. 즉 파일의 변화를 시간에 따라 기록했다가 특정 시점의 버전으로 돌아갈 수 있게 해주는 시스템이다. 이게 왜 필요한가? 생각해보면, 만약 어제 수정한 파일에서는 문제를 발생시키지 않았는데 오늘 수정한 파일에서 문제가 발생될 경우가 있다. 이럴 때 유용하다. 만약 버전 관리 시스템을 사용하지 않고 일반적인 GUI인 폴더 안에서 파일 형태로만 관리하고 있을 경우라면, 직접 오늘 수정하기 전 상태를 기억하고 오늘 수정한 부분을 어제 상태로 직접 되돌려야 하는데 이는 휴먼 에러를 발생시킬 수밖에 없다. 그래서 Git이 필요하다.

Git은 여러 명의 작업자가 하나의 폴더를 수정하는 것을 원활하게 해준다.

Git에 대해 이전 회사에서도 온보딩 문서를 만들기도 하고 특정 시나리오를 가정하고 상황극을 통해 동료에게 설명하기도 했지만, 실제 깊이 써볼 기회는 적었던 것 같다. 이론적으로 알고 있던 부분들을 오픈닥터에서 깨달아가고 있고 더 제대로 알아야겠다는 생각을 했던 한 달이었다.

1. 오픈 닥터의 브랜치 전략 및 병합 방식

우리가 사용하는 방식이 정답은 아닐 것이다. 이렇게도 사용할 수 있구나 참고하면 해주시면 감사하겠습니다. 우리는 git flow 전략을 간소화하여 활용하고 있다.

우선 크게 main, develop 그리고 feature 브랜치가 존재한다. main 브랜치는 실제 운영 중인 프로그램의 소스 코드를 관리하고 있고 develop에서는 실제 운영 서버에 즉시 배포되어도 문제없는 시점의 기능들이 쌓여있는 브랜치이다.

그리고 한 가지 feature 브랜치가 있는데 feature 브랜치는 하나의 기능이 큰 기능일 경우, 따로 feature 브랜치를 만들고 이 안에서 feat/fix/refactor 브랜치를 만들어 작업을 진행한다. 큰 기능을 더 정확히 정의해보면 여러 기능들이 조합된 하나의 기능을 말한다. 예를 들어 특정 페이지 디자인 반영이라고 했는데, 해당 디자인을 반영하기 위해서는 컴포넌트도 구현해야 하고 레이아웃도 반영해야 하고 기능도 반영해야 할 경우가 있는데 이를 큰 기능이라고 말할 수 있다.

그리고 동료들과 코드 리뷰를 통해 feat/fix/refactor의 브랜치의 HEAD가 feature면 feature 브랜치로 병합하고 develop이면 develop 브랜치로 병합하는 과정을 거친다. 그 이후 정해진 시간에 main 브랜치로 병합 후 배포를 완료하는 방식으로 진행된다.

2. git reflog 고마워...

실례로 하나의 에피소드가 있었다. 실수로 3일간 작업한 달력 컴포넌트와 해당 기능을 아예 삭제해버렸다. 의도해서 삭제한 것은 아니고 꼬인 develop 브랜치를 해결하는 과정에서 브랜치를 잘못 삭제했었다. feat/지라티켓명 방식으로 브랜치를 만드는데 잘못 보고 아예 삭제해버린 것이다.

반전) 덕분에 git reflog 명령어에 대해 이번에 알게 됐다.

만약 내가 힘들게 작업한 커밋이 날아간다면??? 어떻게 할 수 있을까?

이럴 때 git reflog를 사용할 수 있다. 작업한 커밋이 날아가는 건 여러 상황에 발생할 수 있다. reset hard를 했다거나 특정 시점으로 이동하면서 누락된 커밋이 있거나, 동료의 작업 커밋을 의도하지 않고 삭제해버렸다거나... 등등 있을 수 있다. 찾아보니 reflog는 HEAD가 가리키는 커밋이 바뀔 때마다 사용하는 개발자 몰래 자동으로 그 커밋을 특정 공간에 기록한다고 공식문서에서 정의한다. 이를 정확히 이해해보자.

우선 HEAD가 가리키는 커밋이 바뀔 때마다는 언제인가?

HEAD는 브랜치의 최신 커밋을 가리키는 포인터이다. 만약 develop 브랜치에서 feat/Undo 라는 브랜치를 만들었다고 가정해보자. 여기서 작업 단위로 커밋을 작성해서 10개의 커밋이 쌓여있다고 생각해보면 10개 중 마지막 커밋이 해당 브랜치의 HEAD인 것이다.

그래서 HEAD가 가리키는 커밋은 마지막 커밋을 말하고 마지막 커밋이 바뀔 때마다로 이해할 수 있다. 즉 커밋을 생성하거나 되돌릴 때 reflog가 자동으로 실행된다는 의미이다. 그래서 다시 돌아오면 reflog는 커밋의 발자취를 돌아볼 수 있게 해주는 명령어다. 심지어 실수로 삭제한 커밋도 확인할 수 있을 뿐만 아니라 다시 살릴 수 있다. 이제 더 이상 두려워할 필요가 없다.

예제를 활용해서 확인해보자

$ git log --pretty=oneline
fdf4fc3344e67ab068f836878b6c4951e3b15f3d 동료의 커밋
cac0cab538b970a37ea1e769cbbde608743bc96d 내 커밋

동료의 커밋을 실수로 삭제해버렸다고 가정해보자.

$ git log --pretty=oneline
cac0cab538b970a37ea1e769cbbde608743bc96d 내 커밋

reflog를 활용해서 삭제 혹은 누락된 커밋을 확인할 수 있다.

$ git reflog
1a410ef HEAD@{0}: reset: moving to cac0cab
fdf4fc3 HEAD@{1}: commit: 동료의 커밋

그리고 git switch -c fdf4fc3를 하면 해당 브랜치를 살릴 수 있다. 이런 방식으로 3일에 걸쳐 구현한 컴포넌트와 기능을 살려낼 수 있었다... 작지만 놀랐던 일이어서 공유해본다.

2. git merge와 Rebase 동작 원리

TODO : 이 부분은 따로 지식 학습에서 다뤄보려고 한다.

3. 내 실수를 돌아보자

TODO : 이 부분은 따로 지식 학습 > 트러블 슈팅에서 다뤄보려고 한다.

일정 예측을 보다 잘할 수 있길 바라며

왜 일정을 지켜 개발하는 게 어려울까?

여러 이유가 존재할 것 같다. 이를 조금 더 MECE하게 쪼개보려고 한다.

오픈 닥터 온보딩 교육을 통해 MECE적으로 이슈 트리를 알게 됐고 이를 개인적으로 연습해보았다. MECE는 겹치지 않고(Mutually Exclusive) 빠짐없이(Collectively Exhaustive)의 약자이고 정보를 나누는 원칙이다.

나는 `일정을 지키겨 개발하기가 쉽지 않다...'를 문제로 보았다. 먼저는 일정 계획 자체가 문제 원인인지 실행단이 문제 원인인지 나누어 생각해보았다.

최상위 구분 : 계획 vs 실행

그로 인해 계획 단계에서 내가 놓쳤던 부분들을 알게 됐다.

1. 일정 산정하는 스프린트 미팅 때 다가올 2주간 예정된 미팅 혹은 일정을 포함하지 않고 순수 개발에 소요될 코딩 시간만 생각하고 공유했다.
2. 수정 및 개선해야 하는 기능의 현재 코드 파악을 하지 않고 일정을 산정했다.

그리고 실행 단계에서 내가 놓쳤던 부분 또한 알게 됐다.

1. 기존 구현 방식을 이해하고 더욱 적극적으로 질문해야 일정을 맞출 수 있다는 것을 알게 됐다.
2. 하나의 기능을 구현하더라도 단위 테스트도 좋고 수동 테스트도 좋고 꼼꼼하게 파악하고 넘어가는 습관을 들여야 한다.

우선 이렇게 4개 포인트를 얻게 됐고 다음 스프린트에는 보다 일정을 잘 산정해보고 실행을 보다 정확하게 해보려고 한다.

팀 내 스프린트 회고에서는 우선 일정을 개발자가 생각하는 것보다 2배 그리고 일정 산정이 어려울 때는 최대 3배까지 일정을 산정해보라고 팁을 주셨고 그 갭을 줄여가면 좋다고 PO님께서 말씀해주셨다. 한번 잘 줄여보자.

수습 중간 피드백

오픈 닥터에 온 지 한 달이 조금 넘은 시간에서 수습 중간 피드백을 받을 수 있는 시간이 있었다. 개인적으로 피드백을 받는것에 대해 두려움이 없는 게 나의 큰 장점이다. 실은 감사로 받는다. 어릴 적부터 공동체에서 왜 그렇게 피드백을 많이 주던지... (ㅎㅎ 문제가 많았나보다...) 드럼이라는 악기를 오래 치면서 다른 악기들과 합을 맞추는 과정에서 아픈 피드백부터 건설적인 피드백까지 여러 피드백을 받아왔다. 그래서 그런지 굳은 살이 박혀있는 것 같다.

이런 나는 피드백을 받을 수 있다는 게 감사했다. 우선 회의를 잡고 다 같이 회의실에 모였다. 부드러운 분위기를 PO님께서 만들어주셨는데 이게 정말 도움이 됐다. 그리고 개발팀 동료분들이 한 명씩 돌아가며 CSS(Continue / Stop / Start) 기반으로 피드백을 주셨는데 결론부터 공유해보면 정말 좋았다. 피드백의 내용은 노션에 존재하지만 따로 정리해보았다.

이런 귀한 피드백을 받을 수 있었다. 혼자 일하면서 간절했던 피드백을 이렇게 받을 수 있다니 진심으로 감사했다. 위의 피드백을 기반으로 업무 체크리스트를 만들면 되겠다는 인사이트가 있었고 그래서 만들어봤다. 앞으로 더 많은 피드백이 있겠지만 업무 체크리스트만 잘 관리하면 해결할 수 있지 않을까 싶어 공유해본다.

다들 나를 파워 J라고 하는데, 이렇게 안 하면 내 기존 습관들을 고치는데 어렵다고 느꼈다...

하반기에 체크리스트를 다듬어보면서 불필요한 것들은 제거하고 필요한 것들은 추가하는 방식으로 더욱 일하기 편한 동료가 되어보기로 다짐해본다.

---

마치며

8월은 수많은 시행착오로 팀 안에서 함께 일하는 방식을 배우고 익히는 과정이었다. 다시 한번 동료들에게 감사하고 다가오는 9월에는 보다 함께 일하기 좋은 동료가 되어보길 기대해본다.

8월을 돌아보고 9월 Action Point를 작성해보자

• 내부 CRM 개선 작업 본격 진행
  • Undo 기능 구현 (대략 한 페이지에 50개의 인풋이 존재하는데 N 페이지가 존재하고 값은 입력하면 서버로 저장이 된다.)
  • PDF 내보내기 기능 (DOM을 완벽하게 출력하는 게 어려웠고 디자인대로 구현하는 게 어려웠던 것 같다.)
• 온보딩 중 받은 도서 완독
• 기능 구현 전 PRD 정독 및 개발 조건 정리
• 에러 바운더리 및 슬랙 연동 도입 (개발 외 영역까지 기여)
• 메디컬 부동산 도메인 관련 서적 읽고 정리
• 기술 서적 기반 AS-IS / TO-BE 비교 실습

8월을 돌아보며 전반적으로 회사에 적응하는데 시간을 많이 할애했다. 동료분들의 도움으로 빠르게 적응할 수 있었다.

9월 액션 포인트

개발 관련

• 사내 신 솔루션으로 마이그레이션 기능 빠르게 쳐내기 (10월 구솔루션 사용하지 않기 위해 달리자)
• 토스 클린 코드 공식문서 1회독 (9월)
• CLAUDE.MD나 .cursorrule 같은 설정 관심가지고 사용해보기

그외 (커뮤니케이션)

• 스프린트 시작 미팅 전에 명확한 일정 공유를 위해 업무 쪼개는 과정이 실행 시도
• 바바라 민토 논리의 기술 읽고 9월에 느낀점 정리