티스토리 뷰
최근 1년 6개월의 근무를 끝으로 퇴사하였다.
11월 27일, 28일 무섭게 눈이 내려 아침에 눈을 떠보니 하얀 세상이 되어 었었다.
작년의 하얀 세상보다 더 아름다운 풍경 같다 생각하였다.
이유는 나뭇잎들 위로 눈이 많이 쌓여 있었기 때문에 하얀색이 더 다채로워보였던 것 같다.
올해 무더운 더위는 10월 중순까지 계속 되어 나무들은 제대로된 가을을 맞이하지 못하였다.
그렇기에 단풍을 물들일 시기를 놓쳤으며, 아직 낙옆들을 떨어뜨리기 전에 눈이 먼저 와버렸기 때문이다.
퇴사도 이와 같았다.
사실 준비하고 있던 퇴사도 아니였고, 더 재직하고 싶던 마음이였다.
사실 가을이 아예 없진 않았었다.
충동적으로 내린 결정은 아니고, 3개월전부터 조금씩 고민하고 있었다.
하지만 그저 조금의 고민일 뿐이였다.
20명 남짓한 작은 규모의 스타트업 회사 라고 칭하는 중소기업이라 생각한다.
대표님은 스타트업이란 말을 엄청 좋아하신다.
아마 지금 생각해보면, 대표님의 인재상은 많은 열정을 갖고 주도적으로 창의적인 무언가를 먼저 제안하며 이를 업무 외적으로 개발하여 기여하는 개발자이지 않았을까? 싶다.
저러한 모습을 보여준 개발자들은 연봉협상시기가 아니더라도 약 30~40% 정도의 연봉인상을 해주시곤 하였다.
그럼에도 불구하고 재직 1년 3개월 시점부터 iOS파트내에서 가장 오래 근무한 개발자가 되었다.
재직중 좋았던 점.
1. SwiftUI와 TCA를 사용해보았다는 점.
여러번 포스트하였으니 지나가겠다.
2. iOS팀원들과 개발을 하였다는 점.
협업을 한다는 점이였다.
특히 TCA는 레퍼런스가 거의 없었다. - GPT도 초반부 TCA의 레퍼런스만 뱉어줄 뿐이였다.
그렇다고 이슈카드를 생상하고 PointFree에서 답변해주길 계속 기다릴 수 만은 없었다..
팀원들간에 서로 질문하고 트러블슈팅을 공유하며 이러한 문제들을 상당히 부드럽게 넘어갔던 것 같다.
기획회의에 같이 참여하여 일정산출에 대해 논의하고, 기술적 검토또한 빠르게 이뤄질 수 있었다.
형상관리
기존 merge를 많이 사용하였었는데, 브랜치의 흐름이 너무 복잡하게 엉켜 있어 rebase를 도입하였다.
보기에도 너무 깔끔하고 좋았던 것 같다.
브랜치 전략은,
1.0 버전의 브랜치에서 각자 feature에 맞는 명으로 브랜치를 생성하고, 작업이 끝나면 1.0브랜치를 pull, 작업브랜치에 rebase 후 PR을 보낸다.
PR에서 팀원들의 리뷰 및 리뷰반영이 끝난다면 이를 머지.
추후 QA 발생 시 QA번호를 이름으로 1.0에서 브랜치를 생성한 후 작업을 진행한다.
이후 피쳐와 같은 방식으로 머지한 후, 약속한 날짜에 Firebase AppDistribution을 활용하여 dev버전 앱을 한번 더 빌드한다.
문제가 없다면, TestFlight에 업로드 하여 최종QA를 마친 후 심사제출한다.
3. 시니어 개발자분들의 지혜
퇴사 당시 5명의 iOS개발자들 중 3명이 시니어 개발자셨다. 3분의 경력을 합치면 40년이 넘었다.
개발 외적으로도 일을 하다 생기는 상황에 대처하는 방법들을 제시하고 공유해주셨다.
괜히 시니어가 아니구나 하는 생각이 일을 하다 보면 몇번이고 들었다.
재직중 아쉬웠던 점.
1. 프로젝트 코드의 고질적인 문제들
어느회사를 가더라도 레거시코드는 피할 수 없을 거라 생각한다. 물론 정도의 차이는 있을 수 있다.
2. 0.1n% 크래시비율과 앱 리뷰에 일희일비하는 대표님
대표님이 CS와 크래시비율에 엄청 민감하셨다. 크래시 안정성은 항상 99.8%을 유지하였다.
유저들 중 0.1n%만 앱 사용 시 크래시를 경험한다는 뜻이였다.
모수가 1~2인 크래시들을 보느라 많은 시간을 쓴 적도 있었다.
+ 이전부터 내려오던 고질적인 이슈들의 해결을 원하셨다.
그러려면 해당 피쳐의 모델구조부터 개선해야 할 정도로 코드를 읽기 정말 힘든 부분들도 있었다.
해당 CS가 조금씩 들어올 때 마다 타운홀 때 전사원 앞에서 "iOS파트, 보고 느끼는거 없어요?" 라는 말씀을 하시곤 하였다.
주어진 일정안에서 책임감을 갖고 최선을 다하여 매주 스프린트 임무를 완수하고 있다고 느꼈었는데, 내가 해야 하는 일은 그거 뿐이 아닐 수 도 있겠구나 생각하였다.
3. 체계
올해 8월부터 팀 -> 스쿼드 체계로 변경되었다.
장점은, 정해진 기간 안에 무언가 결과물이 확실히 나왔다는 점이다.
단점은, 개발자가 개발하기 너무 힘든 환경이였다고 생각한다.
항상 QA기간에 엄청난 기능 + 디자인 QA 티켓들이 발행된다.
QA기간에 처리해야할 일이 많다는건 엄청난 부담과 압박이 동반된다.
당장 3일뒤 심사제출이니, 이전까지 QA들을 모두 끝내야 하기 때문이다. - (우선순위 낮은 QA는 생각보다 적음)
분명 스프린트 기간에 일정에 잡힌대로 열심히 개발하였는데 무엇이 문제였을까? 고민해보았다.
- 무엇을 하자! 정도의 윤곽만 잡힌 상태에서 개발이 시작됨.
요구사항 정책이 거의 없는 상황에서 일단 개발을 시작한다.
QA 티켓이 발행이유는 다음과 같다.
피그마를 보고 개발하였는데.. -> 알고보니 시안이였다.
요구사항에 맞춰 개발하였는데 -> 문서를 보니 요구사항이 아무도 모르게 변경되어 있다.
+ QA기간 중 미리보기 화면이 크게 보기로 보여지는건 어색하니 네비게이션 형태로 들어가면 좋겠다.
네비게이션형태로 바꾼다면 미리보기의 뷰를 따로 만들고, 이에 해당하는 로직을 모두 분리하여야 한다.
단순 화면이 보여지는 방식을 바꾸는 거라 하더라도 말이다.
왜 오래걸리고, 이 작업이 안전하지 않은지에 대해 기획쪽에 설명하였다.
하지만 "오늘 야근하고 일단 바꿔보는걸로 합시다. 제가 보기엔 어색한거 같아요." 로 결론이 내려졌다.
이런 문제들을 예방하기 위해서 2가지의 해결법이 떠올랐다.
1. 기획의 윤곽이라도 나온 이후 개발을 시작하기.
2. 업무체계를 잡아 QA기간에는 아무것도 넣지 않기. ( 중요도가 높은 작업이라면 당연히 수정 )
아무리 설득해보려 해도, "우리가 원하는걸 그때그때 넣어줄 수 있어야 한다."가 요점이였기에 체계는 잡지 않고 넘어가는걸로 결정되었다.
결과 일정산출 회의때도 엄청난 압박과 부담이 동반되었고, QA기간에 이런 환경은 계속 반복될 것이기에 퇴사를 결정하였다.
세상은 넓고 많은 회사들이 있을 것이다.
분명 이곳이 그 중에서 정말 좋은 회사에 속할 수 있다.
만약 다음 재직하는 회사에서 이와 같은 상황이 생긴다면 나는 또 퇴사할 것인가?
일단 1차적으로 내린 결론은 "마음가짐을 잘 가꿔나가야 한다." 이다.
일이 많다면 그냥 조금 더 하면 되고, 상황마다 느끼는 내용들을 잘 정리하여 회고할 뿐이다.
일단은 이런 방식으로 접근해봐야 할 것 같다.