테스트
[테스트 케이스를 공유한 이유]
테스트 케이스를 작성하고 PR 본문에 공유했다. 해당 PR에서 무엇을 했는지 테스트 케이스로 공유할 수 있어 좋았다. 테스트 케이스만 봐도 어느 영역까지 커버했는지 알려줄 수 있었다.
[스토리북에 디자인 토큰이 꼭 필요한가?]
팀원은 피그마에 있는 디자인 토큰을 스토리북에 넣고 싶어 했다. 하지만 나는 반문했다.
"그게 정말 스토리북에 필요한가요?"
장점도 있었다. 피그마를 열지 않고도 디자인 토큰을 확인할 수 있다는 점이다. 하지만 나는 유지보수 관점에서 반대했다.
- 피그마와 스토리북 간 싱크가 깨져 SSOT가 무너질 수 있다.
- 싱크를 맞출 때마다 불필요한 커밋과 PR이 발생한다.
- 결국 스토리북이 유지보수 부담이 되는 도구로 전락할 수 있다.
그래서 피그마를 직접 열어 확인하는 편이 더 낫다고 생각했다.
Cherry-pick / Merge into Branch
[Cherry-pick]
A 브렌치에서 개발한 기능 중 3개의 커밋을 B 브랜치로 가져올 때 사용했다.
[Merge into Branch]
Dev로 머지해야 하는 상황에서, 먼저 Dev를 최신 상태로 업데이트한 뒤 한 번 병합하고 Dev로 보낼 때 사용했다.
계속해서 잡아주는 것
팀 프로젝트가 완전히 끝난 뒤에 주는 피드백은 서로 성장에 도움이 되지 않는다고 생각한다. 오히려 다 끝나고 나서 받으면 '왜 미리 말 안했어?'라는 생각이 들며 기분이 상할 수도 있다.
그래서 프로젝트를 진행 하면서 지속적으로 피드백을 주는 것이 중요하다고 본다. 또, 서로를 존중하고 신뢰하기 때문에 그 피드백을 공격으로 듣지 않는 것도 중요하다.
레벨 3 팀 프로젝트 동안 나는 팀원들에게 꾸준히 피드백을 했다. 여러 가지를 한꺼번에 지적하기보다, 가장 개선되었으면 하는 한 가지에 집중해 전달했다. 팀원이 그 피드백을 받아들이고 개선하려는 모습을 보이면, 나는 그것이 잘 자리 잡을 수 있도록 계속해서 반복해 강조했다.
피드백을 줄 때 처음에는 많이 망설였다. 말이 칼날이라도 되는 듯, 혹여 상대를 베는 건 아닐가 조심스러웠다. 하지만 의외로 여러 번 해보니, 가볍게 말하는 것이 가장 자연스럽고 효과적이었다. 상대는 내가 이런 피드백을 줄 거라고 전혀 예상하지 못했다고 했다. 결국 나만 고민하고 있던 부분이었던 것이다. 이런 피드백일수록 빨리 공유하고, 함께 생각을 맞추는 게 낫다고 느꼈다.
피드백 예시)
리뷰에서 바로 구체적인 구현 예시를 제시하기보다는, 먼저 방향성을 함께 논의한 후 필요한 경우 예시를 공유하는 방식이 서로의 성장에 더 도움이 될 것 같다는 생각이 듭니다. 이유는 ~ 중략
마무리
앞으로는 글을 좀 더 가볍게 써보려 한다. 완성도를 높이려고 하다보니 포스팅이 밀리게 됐다. 완성도보다 더 자주 쓰는 것에 신경쓰려 한다. (회고하는 형식 자체를 바꿀 수도 있다)
마무리는 트위터에서 발견한, 내가 좋아하는 사람의 글을 대신한다.
사람과 사람 사이에 관계는 원래 폐를 끼치는 거라 생각해요. 물론 그러지 않으려 노력하고 걱정하고 배려하는 태도는 멋지고, 그런 따뜻한 사람들을 좋아하지요. 하지만 선생이던 친구던 사랑하는 사람이던 자식이던 동료 시민이던. 서로 "피해를 주지 않을 것"을 요구하기 시작하면 황폐해져요.
- 탐정 토끼 -
