2025년 half time 회고
(업무 관련한것만 있음)
1월
- 당근 입사 2개월도 안되었던 때.
- 당시에 이전 팀(농수산물 커머스)의 방향성 얼라인먼트 등으로 거의 한달을 다 쓴듯하다.
- 리팩터링, 개선 작업들을 하긴했지만..크게 임팩트가 있는 작업은 없어서 조금 늘어지기도 했다.
2월
- 당근 수습통과. 2월부터 3월은 커머스 운영성 과제들을 했고, 팀에서 작은 단위의 제품 테스트를 할 때 필요한 FE 작업들을 함.
3월
- 조직개편과 맞물려서 팀 이동. User Generated Contents 라고 해서, 로컬비즈니스 내에서 사장님의 맥락이 없는, '유저가 생산하는 컨텐츠'를 다루는 팀에 오게되었다.
- UGC의 퀄리티를 어떻게 높이고, 어떻게 잘 늘릴지를 고민한다.
- 이전 팀보다 지도 기반 플레이를 많이 하게 되었다.
- 기술적으로도 다루는 스택이 많이 달라졌다. 이전에는 당근 FE의 정석인 ㅎㅎ.. GraphQL , Relay 를 사용했는데 이 팀에 와서는 REST API 를 사용하고 Tanstack Query, Vanilla Extract 를 사용한다.
4월
- 팀이 처음 빌딩되고, 본격적으로 업무 시작함.
- 우리팀은 속도가 가장 중요했기 때문에, 정말 빠르게 개발하기 위해서 많이 노력했다.
- 기술 부채를 열심히 쌓아가며..죄책감을 느끼는 와중에 나의 직속 매니저님이 '집살 때 자기 돈 100%로 사는 사람 없지 않느냐'라는 말씀을 해주셔서, 기술 부채에 대한 편협했던 시각이 바뀌었다 ㅎㅎ..아무튼 열심히 새로운 코드베이스 내에서 온보딩했다.
5월
- 4월에서 크게 달라진 점은 없었다.
- 주도적으로 일하려고 많이 노력했다. 예를 들면 아래와 같은 식.
as-is
주신 문서에서 A페이지 로깅이 빠졌는데 어떻게 넣으면 될까요?to-be
주신 문서에서 A페이지 로깅이 없더라고요. 제가 생각하기에 a,b,c 로깅을 넣으면 될것같아서 넣어뒀는데 혹시 추가로 필요한거 있으면 말씀주세요.
- ^간단하지만 꽤나 효과적이고 협업 할 때 서로를 편하게 만드는 방법이라고 생각한다. 이전 회사에서는
as-is
의 방법대로 많이 일해왔었다. 다른 직군의 일에 크게 개입하지 않았고...직군별로 할 일들이 무자르듯 나뉘어져있는 분위기였기 때무네... - 그런데 지금 회사 다니다보니, 걍 다같은 메이커다. 그래서 누가 해주길 기다리는게 아니라 내가 먼저한다. 공유만 잘하면 문제없다.
- 아직 부족하지만 이런 커뮤니케이션 방법부터 좀 조정해나가려고 많이 노력했었드ㅏ..
6월
- 내가 여태껏 (..이라고해봤자 2년이지만) 만들어봤던 프로덕트중에 하드스킬 & 소프트스킬 적으로 많은 역량을 필요로하는 제품의 프론트 엔지니어링을 했다. 심지어 due date 도 촉박하게 정해져있어서, 챌린징했다.
- 다양한 팀들이 엮여있었고, 개발사이드에서는 네이티브 개발자들과의 소통이 필수적이었다.
- 이전에 한번도 안해봤던 웹뷰와 네이티브를 연동하는 엔지니어링 작업을 했고.. (원래 이런건 플랫폼 개발자들이 해줘서 딱히 제품팀 개발자들이 할 일이 없었다.) 이를 통해서 웹뷰가 어떻게 돌아가고있는지, 그리고 네이티브 (플랫폼)과 웹뷰가 새로운 피쳐를 추가한다고 했을때, 어떤식으로 접근하고 소통해야하는지 많이 배웠다. 또한, 소프트웨어 개발의 꽃이라고도 불리는 하위호환을 어떻게 지켜야할지도 많이 고민했다.
- 특히나 네이티브(플랫폼)사이드에서 해주어야할 것과, 웹뷰에서 해야할 것들을 어떤식으로 나눠야할지, 어디까지 요구해도 되는지, 어디까지는 웹뷰에서 책임져야하는지, 그리고 네이티브의 제약을 UX적으로 어떻게 풀어야하는지... 많이 배웠던..정말정말 값졌던 시간이었다.
- 아무래도 네이티브에 대한 지식이 없었다보니까, OS 정책이 무엇이고, 어떤게 구현인지 잘 구분이 안갔던게 가장 허들이 아니었나 싶다. 그래서 네이티브 개발자분들과 소통할때 어려운점도 있었지만, 그만큼 많이 배운것같다.
- 또한, 스콥이 작지 않은 프로젝트에 혼자 프론트엔드 개발을 하다보니, 내가 혼자 의사결정을 해야하는것들이 정말 많았다.
- 이 과정에서 내가 의사결정을 잘한건지?에 대한 걱정들이 많긴했는데, 최근에 1on1하면서 이런 불안감을 좀 해소했다.
- (최선의 의사결정이 아니었어도 괜찮다. 지금까지 모든 개발자들이 기깔나는 최고의 의사결정만 해왔으면 소프트웨어 생태계가 이모냥(?)이 되진 않았을테니ㅎㅎ..)
- 더불어 이번 달에는 처음으로 면접관으로도 들어가게 되었는데..좋은 질문하는게 정말 어려운듯 하다.
KPT 회고
keep
- 주도적으로 일에 접근하기.
- 의사결정 주도적으로하기
problem
- 제품에 대한 고민을 더 많이 하기. 지금은 나의 역량 부족 이슈(?)로 엔지니어링에만 힘을 쏟기에도 바쁘나, 지금 팀에서 정말 필요한건 제품에 대한 고민이다.
- 문제정의를 잘못하나?
- 최근에 든 생각인데, 나는 '문제가 문제라고 아는 것'을 잘못하는 것 같다. 그만큼 흐린눈을 잘하고, 불편한 상황에도 적응을 잘한다는 장점이 있겠지만... 엔지니어로서 가장 중요한건 '문제를 정의'하는거라고 생각한다. (문제를 해결하는건 쉽다.) 같이 일하는 FE 엔지니어들이 이걸 정말 잘해주고 있어서 도움을 많이 받고, 많이 배우고있지만..이제는 프로불편러가 될 때라고 생각한다.
Try
- 많은 제품 써보자. 그리고 관련된 글,영상 많이 읽고 보고 내 생각 정리하기.
- 사소한 의견/개선점/인사이트들도 팀원들과 스크럼시간에 짧게 나누기.
- 생산적인 1on1 시간을 만들기위해서, 1on1 prep 하기.
- 프로불편러 엔지니어 되기