2021 회고

2021년은 굉장히 빠르게 지나간거같고, 되돌아보면 또 긴 것 같다.
2021년을 지나면서 나의 개발경력은 2년차를 지나서 드디어 만 3년을 넘게 됐다.

많은 일이 있었던 2021년이었기에 귀찮지만 힘내서 돌아보며 기록해보려 한다.
2021년은 크게 세가지 키워드로 구분할 수 있을 것 같다.

[다시 홀로서기] - [팀 리딩] - [이직]

---

다시 홀로서기 (21.01 ~ 21.06)

2020년 말부터 2021년 초까지 애정했던 팀원들이 이직을 하면서
회사는 디자이너/기획자가 없는 상태가 됐고 개발자는 나홀로..
사운드짐에서 2021년의 절반동안은 혼자 일을 하게 됐다.

2020년에는 번아웃이 두번정도 있었는데, 오히려 2021년에는 번아웃이 없었다.
지금 생각해봤을때는 이유를 크게 두가지에서 찾을 수 있을 것 같다.

1. 사라진 보상심리
   • 출근시간과 무관하게 매일 야근하는데, 유연하지 못한 출근시간 > 유연근무제 도입
   • 투자 이후에 지급된 인센티브, 연봉 상승
2. 새로운 할 일
   • 협업사와 협업을 위한 API 인터페이스 구축
   • 팀 리딩 & 프로덕트 숙원사업 해결(환경 분리 및 배포 파이프라인 재구축)

회사에서는 직원이 발휘하는 퍼포먼스에 대해서, 적절하고 합리적인 보상을 설계해야 한다는것도 깊게 체감했다.
보상은 꼭 물질적인게 아니라 복지가 될 수도 있다.
구성원들과 자주 이야기를 나누자.
물론 둘 다 되면, 가장 베스트다.

--

쿵짝이 잘맞던 디자이너가 퇴사하기 전까지 작업한 내용들을 이 시기에 진행 했는데, 이때 혼자서 진행했던 기억나는 굵직한 피쳐들로는 컴포넌트 디자인 반영 / 홈 리뉴얼 / 개인화 및 기록차트 / 소셜 기능(프로필, 피드, 좋아요/댓글 추가,글쓰기 UI,UX 개선) 등이 있었고, 분리되어있던 오디오/비디오 콘텐츠 화면을 하나로 통합하고 뷰어만 컴포넌트로 분리하는 작업을 진행하면서 운동루틴(연속재생) 기능에 비디오도 추가 할 수 있게 되었다.

React-Query 도입

포스트와 피드 피쳐를 작업할때 스크린을 넘나들며 좋아요/댓글의 싱크를 맞추는 작업이 꽤나 골아펐는데
이 틈을 타서 유심히 보던 react-query 를 도입하면서 말끔하게 해결했다.

또 사운드짐에서는 컴포넌트 레이어를 아래와 같이 구성하고 있었는데
react-query 가 이런 구조에서 이점이 있을 것 같아서 적극적으로 도입했다.

function App() {
  return <FetcherComponent someId={'1234'} />
}
function RenderComponent({some}){
  return <View><Text>{some.id}</Text></View>
}
function FetcherComponent({someId}){
  const [loading, setLoading] = useState(false);
  const [some, setSome] = useState();
  
  useEffect(() => {
    api.get(`/some/{someId}`)
      .then(data => setSome(data))
      .finally(() => setLoading(false));
  }, [someId])
  
  if(loading) return <Loading />
  if(!some) return null;
  return <RenderComponent some={some} />
}

1. 상위 레이어에서 캐시 정책을 관리
   기존에는 Axios client에 LRU 캐시를 붙여서 fetcher 단에서 캐시 관리를 했었는데, Path 단위로 캐시가 돼서 사용이 좀 제한적이었다.
   캐시 정책을 react-query 로 넘기게 되면서, 캐시를 fetcher 로부터 분리시켜 유연하게 다룰 수 있다는 이점이 있다.

2. 한결 더 간결한 코드
   사실 fetcher 를 받아서 데이터와 로딩을 반환해주는 동일한 인터페이스의 훅을 만들어서 쓰고 있었다. 다만 캐시가 없었을뿐.

function FetcherComponentWithRQ({someId}){
  const { data, isLoading } = useQuery(['some', someId], () => api.get(`/some/{someId}`))
  if(loading) return <Loading />
  if(!data) return null;
  return <RenderComponent some={data} />
}

3. 캐시
   위와 같이 컴포넌트 레이어를 구성할 경우, 렌더링이 몰리는 시점에 너무 많은 네트워크 호출이 발생하는데 캐시를 통해서 좀 더 퍼포먼스나 비용적으로 이득을 볼 수 있을거라고 생각했다.

---

팀 리딩 (21.07 ~ 21.10)

연초부터 진행하던 투자가 슬슬 마무리 되면서 투자금이 들어왔다.
리드를 맡게 되면서 더 본격적으로 개발자 채용을 진행했다.(아마도)

인터뷰는 회사의 이미지 라고 생각하기 때문에 인터뷰 경험 개선을 위해서 나름의 절차도 만들고 지원자들에게 피드백도 열심히 보내고..
팀을 위해서는 지원자 리스트도 만들고..
절차가 종료된 지원자에 대해서는 개인정보 보호를 위한 프로세스도 만들고..
뭐 이런저런 일들을 많이 했는데, 혼자서 하다보니 내가 한 일들이 얼마나 퍼포먼스가 있었는지는 잘 모르겠다.

인터뷰 과정에서는 입사 이후에 기대했던 바와 다른 환경, 그리고 이어지는 퇴사를 막기 위해서
지원자들에게 회사의 현재 전체 조직의 상황, 개발팀의 상황, 채용 계획, 향후 사업방향 등을 투명하게 공유하려 노력했다. 그래서인지 채용하기가 힘들었지만, 그 속에서 소중한 개발자 두분을 채용하게 되면서, 3/6년차 개발자 두분을 리드하는 2.5년차 엔지니어가 되었다 😇

개인적으로는 역량이 있어야 직무를 수행할 자격도 있다고 생각한다.
사운드짐에 개발자가 나혼자였지만 CTO 가 아닌 개발자1 이었던 이유가 여기 있다.
그래서 리드 엔지니어라는 자리도 조금 고민이 됐지만, 저 시점에 내가 이 포지션을 할 수 있다고 판단한 이유는 네가지였다.

1. 사운드짐의 도메인을 내가 가장 잘 알고있다.
2. People management 역량은 모르겠으나, Tech lead management 역량은 충분히 된다.
3. 설계, 개발, 문제해결, 일정추정, 스케쥴링, 커뮤니케이션, 채용 등 이미 하고 있는일들에서 크게 바뀔게 없다.
4. 영원히 주니어일수는 없다.

새롭게 팀원들이 합류한 이후에는 메인 피쳐 작업에서는 조금 멀어져서 프로젝트 관리에 리소스의 30~40% 정도를 할애하고, 나머지 리소스는 퇴사까지 남은 세네달동안 메인 피쳐 이외의 나머지 작업들을 진행했는데, 적고보니까 뭐가 많았네(?)
프로젝트 관리 / 신규피쳐 프론트/백 인프라 및 CI/CD 세팅 / 마이그레이션 지원
웹,앱,백엔드 개발환경 분리 /배포 파이프라인 개선 / 이것저것 자동화 / 기타 잡무(타사 협업 지원, 짜잘한 피쳐, 버그 수정, 백오피스 지원)

--

리딩을 하면서 했던 가장 큰 고민을 꼽으라면, 에러 발생이 급 늘어난것과 그에 연관된것들이 가장 큰 고민이었다.
(앱의 경우 안정도는 99.n% 를 유지했고 에러 발생은 한손에 꼽아도 없었던거로 기억하는데, 짧은새에 95~7%까지 떨어졌던 것 같다.)

물론 도메인에 익숙하지 않은 개발자들이 합류하면서 새로운 코드를 작성하고 에러 발생률이 높아질 수 도 있다고 생각하나..
내가 봤을때 주요한 에러 발생의 원인은 퀄리티 부족 이였다.

나는 개발자라면 개발할때 두가지를 항상 염두에 둬야한다고 생각한다.
첫번째는 요구사항을 정확하게 이해하려는 노력
두번째는 요구사항에 맞는 동작인지 여러 방면으로 예외처리를 하며 검증 이다.

주니어라면 애매한게 있으면 바로바로 커뮤니케이션하고, 예외처리에 대한 케이스는 모두 생각해보면서 손으로 테스트 진행을 하는 습관을 기르는게 좋지 않나 생각을 해본다. (이걸 코드로 짜면 테스트 코드잖아 🧐)

이 부분에서 스트레스를 좀 받았었는데, 개인적으로는 해결책은 없고 인내하면서 지속적인 피드백과 방향성을 주는것만이 할 수 있는 일이라고 생각했다.
리소스가 좀 더 여유로웠다면, 코드 리뷰를 통해서 모든 사람의 quality bar 를 점진적으로 높이는걸 해결책으로 제시할수도 있지 않았을까? 하는 생각을 지금이나마 해본다.

--

Jira

개발자분들 외에 P.O. 분이 합류를 하면서 이슈 보드를 노션에서 지라로 옮겼다.
기존에 이슈를 관리하면서 필요에 의해서 노션에서 만들어 사용하던 기능이나 구조/필드들이 Jira 와 같거나 모두 있어서, 기존 구성원들의 학습비용은 거의 없이 넘어갔다. (몇 명 안되지만)
여기에다 추가적으로 Automation 을 설정해서 GitHub 와 연동하여 PR이 생성되거나 머지되면, 태스크 Status 를 넘기거나 슬랙으로 알람이 오게되는 등의 설정을 해줬다.

백엔드 마이그레이션, class-validation / class-transformer

커뮤니티쪽 기능들을 강화하면서 복잡한 쿼리 지원과 읽기 속도를 높이기 위해서, firebase database 를 마이그레이션 하기로 결정했고
같은 NoSQL 로 마이그레이션이 그나마 용이함 + 새로 합류한 개발자분이 몽고디비를 잘 다루는 이유로 DB는 몽고디비를 선택했다.

몽고디비를 붙이면서 ASG 에 붙어있는 인스턴스들의 유동적인 out-bound IP 가, 아틀라스의 allowed list 에 들어가야 하는 상황이 생겼었는데
VPC 에 Private Subnet/NAT 를 붙여 해결하면서, VPC 에 대한 이해도를 조금 더 높일 수 있었다.

클라우드 만드는 개발자분들은 대체 뭐하시는 분들일까..? 그 지식을 어떻게 쌓는걸까, 리스펙..

마이그레이션과 함께 백엔드 개발자분이 작업해온 경험을 토대로, 기존에 사용하던 서비스 서버의 환경도 점진적으로 개선해나갔다.
테스트, class-validation, class-transformer 등을 도입했는데
transformer > validation > DTO 순으로 태우니까 굉장히 지저분했던 많은 작업들이 쉽게쉽게 처리가 됐다. 역시 아는게 힘이다.

중간중간에는 팀원들이 작성한 테스트 코드를 보면서, 테스트 작성의 이유에 대해서 한번 더 고민해보기도 했다.
비동기처리가 잘 안된 테스트 케이스들로 인해서 Unhandled Rejection 경고 메세지 혹은 간간히 테스트 실패가 뜨는 경우가 있어서..
최종 결과가 성공으로 나와도 내부적으로 문제가 있거나, 환경에 영향을 받아 항상 동일한 결과를 보장해주지 않는 테스트는 허울만 있는 테스트라고 생각이 들어, 팀원들과 함께 테스트의 목적에 대해서 리마인드 하는 시간도 가졌다.

신규 B2B 서비스

프론트는 amplify 만 빠르게 붙여서 배포쪽만 설정을 해뒀다. 신규 프로젝트고 백오피스에 가까워서 팀원분이 스택을 결정하고 개발을 자유롭게 하도록 장려했고, react-admin 을 사용하자고 해서 제한적인 프레임워크 선택을 할 때 고려해야 될 사항등을 알려드리기도 하면서...(요구사항에 맞는 적절한 UI 를 모두 지원하는지, 지원이 안되는게 있다면 커스터마이징은 어디까지 가능한지, 아키텍쳐는 어떻게 구성돼있고 개발하는데 제약사항이 없을지 등...) 어찌저찌 개발이 끝나긴 했으나, 결과물이 만족스럽진 않았다.

개발환경 분리 & 배포 파이프라인 개선

신규 B2B 서비스를 추가하면서, 새롭게 서버와 프론트 환경 구성을 하게 됐는데
이때를 틈타서 개발환경 분리와 배포 파이프라인 개선 작업을 시작했다.

서버

기존에는 EC2+ASG+ELB를 사용했었는데, 기존/신규 서버들은 모두 빈스톡으로 옮겼다.

서버는 1년차때 고정 인스턴스 1대 + ASG 로 구성해놓고 아래처럼 얼기설기 해놨었는데...

• 고정 인스턴스 - github actions > pm2 deploy(ec2 로그인 > git pull > build > pm2 update)
• ASG - github actions 에서 ASG 새로고침 > 인스턴스 실행 시 스크립트 실행

하필 여기에다가 인스턴스에 github account+password 기반으로 sub module 싱크를 맞추게 해놨었는데
또 하필 새벽에 마이그레이션을 했고...
또 하필 다음 날 github password authentication brownout 진행됐고...
또 하필 그 때 서버 배포를 했고...

이 모든게 맞물리며 빚어낸 비극으로 인해, 다음날 새벽에 같은 마이그레이션을 한번 더 하게되는 상황이 생겼다.

그래서 다음날 바로 서버를 빈스톡으로 옮기는 작업을 시작했고
처음 1년차때 EC2 구성으로 인스턴스를 띄울 당시에는 ASG/ELB 설정을 하는데도 엄청 헤맸는데
빈스톡으로 옮기니 ASG/ELB/빌드&배포 설정같은게 한번에 다 해결돼서 좀 허무했다.
github-actions 에서는 CD 를 떼내고, CI 용으로 테스트와 린트체크만 하게 수정하고 배포는 코드 파이프라인쪽으로 옮겼다.
DNS 캐시를 고려해서 기존 인스턴스는 며칠간 띄워두고 트래픽이 줄어드는것 등등을 체크하다가, 주니어때 띄운 인스턴스와는 작별을 고했다.

웹

기존 firebase-hosting 에 수동 배포하던 웹 클라이언트들도 모두 aws-amplify 로 옮겼다.

React Native

개발환경 분리는 예전부터 계속 하고싶어서 정보만 모으고 있었는데, 컨셉 자체는 쉬웠으나 실제로 나누는 작업에 들어가니 이것저것 헤맸다.
Android 는 쉬웠는데, iOS 에서는 프로젝트 설정 이외에도 cocoapods 쪽도 커버를 해줘야해서 뭔가 좀 어려웠고, 나중에 글로 다시 정리할 생각이다.
중요한건 모든 Debug/Release를 카피해서 환경별로 잘 나눠야 DEBUG flag(Preprocessor Macro) 등이 안깨진다는것 (stag-Debug/stag-Release & prod-Debug/prod-Release)

늘어난 환경만큼 fastlane 에도 추가해줘야 할 게 많이 생겨났고, 특히나 iOS 의 경우 app/watch/notification-extension 이 있어서 identifier 랑 프로비저닝 프로파일만 10개 넘게 추가한거같다..

물론 circleci 에도 환경별로 스크립트를 추가해줘야 했다. 스테이징의 경우, fastlane-badge 로 앱 아이콘에 뱃지를 추가해주려고 했는데, circleci 이미지에서 imagemagick 설치가 안돼서, 그냥 소스코드 참고해서 sharp 로 스크립트를 따로 만들어서 넣었다.
안드로이드 스테이징은 firebase-deploy / iOS 는 ad-hoc 구성이 귀찮아서 테스트 플라이트로 배포했다.

기존에는 release 브랜치에 커밋이 들어오면 테스트 배포가 나갔었는데, 스테이징이 추가된 이후부터는 플랫폼별 두벌씩 총 4개의 앱이 나가게 됐다.
프로덕션의 경우 릴리즈 될때만 나가면 되는거라서 circleci 파이프라인을 스테이징 2벌만 기존 방식을 유지했고, 프로덕션은 approve 를 받도록 구성했다.
approve 를 슬랙을 통해서 받게끔 구성하는것도 나름 재미있었다.

모듈

위에서 나왔던 brownout 을 겪고 난 후, submodule 관리의 번거로움이나 npm module 이 다른 팀원들이 더 이해하기 쉽고 익숙한 방법이라고 생각이 들어서, git submodule 로 제공하던 모듈을 github packages 에 내부 배포하는 방식으로 전환했다.
github packages 에서 단순한 방법 + 프라이빗 레지스트리까지 무료로 제공을 해줘서 손쉽게 설정할 수 있었다.
모노 레포로 팀의 prettier/eslint 설정을 내부 모듈로 배포하는 경험도 재미있었다.

자동화

그렇게 환경분리와 함께, 전 프로덕트에 CI/CD 를 붙여버렸고...두둥...
남는 시간동안에는, 사업쪽으로부터 요청받아서 수동으로 처리하던것들을 스크립트로 작성하고
Github actions 를 통해서 버튼을 누르거나, 스케쥴러 등으로 실행이 가능한 환경을 만들었다. (ex: 데이터 추출/인증서 갱신/쿠폰 관련작업 등)

---

이직 (21.08 ~ 21.10)

사운드짐에 다니면서 매일같이 최소 10시간 최대 18시간은 일을 해왔다. 2년 조금 넘게 다니면서 아래 일들을 혼자 다했다.
웹/앱/애플워치/백엔드/인프라/컨벤션정립/프로젝트설계/사내모듈/배포자동화/슬랙봇(앱리뷰,KPI,인증서 갱신알림,배포인터렉션)/오픈소스/사내모듈관리

이외에도 매일 아침 에러 모니터링 하고, cloud-front/ondemand-resize 도입해서 트래픽 비용 절감을 한다거나, 불필요한 비용이 나가는 레거시 데이터는 찾아서 삭제하고, 비용 절감이 가능한 부분들이 있으면 떼내고 (e.g. 앱 안정도가 99.n% 이상을 유지하면서부터 에러가 거의 들어오지 않아서 Sentry 는 유료 구독을 중지했다.)

서비스와 회사를 유지하기 위해서 개발쪽에서 당연히 해야된다고 생각하는것과, 역량이 딸리는것 & 아직 내가 모르는 수준에 있는것 빼고는 개발을 하면서 하고싶다고 생각한건 거의 다 해본 것 같다.

내가 갑자기 MSA 를 도입해서 서버를 다 갈아치운다던가 서비스가 급격하게 성장해서 새로운 규모의 어플리케이션을 구축해야 하는게 아닌 이상에야
뭔가 새로운 성장 가능성이나 재밌는걸 찾기가 어렵다고 생각했고, 그래봐야 앞으로 남은건 서비스의 새로운 피쳐 개발인데...
회사에서는 쇼핑몰을 한다고 해서, 조직의 방향성과 내 방향성이 맞지 않다고 생각했고 이직을 결심했다.
사실 결심만 하고 해야지 해야지 하다가, 토스 NEXT 지원하고 코테랑 과제 합격하고 경력기술서를 내야해서, 이때부터 제대로 준비를 시작했다.

--

서류를 작성할때는 특히나, 내 경험들을 잘 녹여내면서 한눈에 들어오게 하기 위해서 굉장히 굉장히 굉장히 힘들었다.
덜어내는것도 기술이다 정말... 서류 작성은 굉장히 공을 들였고, 덕분에 서류로 인해 탈락한적은 한번도 없었다.

코테는 따로 준비를 안했다. 대학교 3학년때 N-Queens 같은 문제를 내주던 수업때
알고리즘 문제들을 처음접한 이후로는 한번도 공부를 한 적이 없고, 앞으로도 할 생각은 크게 없다.
사실 알고리즘을 조금 풀어봤고, 서비스를 구현하면서 요구사항을 기반으로 비즈니스 로직을 작성하는 사고 방식을 잘 길러온 1~2년차 개발자라면 웬만한 기업의 기본 알고리즘 테스트는 준비 없이도 어지간하면 풀 수 있다고 생각한다. (카카오같은데 말고...) 물론 DP 같은 최적화 문제에서는 조금 난항을 겪겠지만.

과제는 본인이 해온 도메인이 아니라면 코드야 짤 수 있겠지만, 합격해도 과제 기반의 인터뷰에서 굉장히 굉장히 난항을 겪을 확률이 높다.
과제 리뷰는 코드를 비롯한 커뮤니케이션이나 문제 해결방식 등도 함께 보기때문에
자신감이 있음에도 불구하고 코드에 대한 아이디어가 잘 안떠오른다면, 그냥 방향성이나 힌트를 요구하자.

인터뷰는 그냥 여러번 해보는게 답이다. 몇번하든 긴장이 되는건 마찬가지지만 인터뷰를 진행할수록 입이 풀리고, 대답을 할 때 어떤 스탠스를 취해야 할 지 방향성을 좀 잡을 수 있었다.
내 경우는 질문에 대해서 생각나는 모든 답변을 굳이 다 하지 않고 넘어갔었는데, 예를들면 개발/컨벤션 관련 질문은 딱 정답이 정해져있는 경우보다는 팀원들하고 커뮤니케이션하고 결정된 방향으로 따라갈때가 많으니 유동적으로 가야된다는 생각이 떠오른다거나.. 추상/개념적인 질문들에서는 복잡하기보단 단순한 답변들만 떠올라서 대답을 머뭇거렸는데, 그냥 생각한것들을 정제해서라도 천천히 풀어내면서 대화를 핑퐁하는게 오히려 더 나았다.

--

토스/마리트/숨고/클원/리디/센드버드 에 지원했고, 이직하고 싶은 회사의 기준은 아래와 같았다.
내 기준에 두가지가 정확히 부합하여 가고싶었던 곳은 토스/리디/센드버드 세개 회사였다.

회사

1. 내가 성장을 할 수 있는 회사 (분야에 구애받지 않고)
2. 미친듯이 일을 하면서, 가시적인 성과를 낼 수 있는 회사 (워커홀릭)

포지션

1. 내가 가진 기술을 확실하게 활용할 수 있는 포지션 (typescript / react-native)
2. 내가 가진 경험을 잘 녹여낼 수 있는 포지션 (전 분야에 걸친 발담구기...)

toss

• 회사 - 팀원들의 개발 실력과 학습 방법 / 조직이 유기적으로 일하는 방식 / 재미있게 일을 하는것(오늘 출근해서 내일까지)
• 포지션 - typescript

ridi

• 회사 - 찐 react-native hard work / 다양한 미디어 기반 작업경험(웹툰/애니메이션)
• 포지션 - react-native / typescript

sendbird

• 회사 - 조직 문화를 유지하는 C레벨의 스탠스 / 영어 / 퀄리티 높은 오픈소스를 만들어 볼 경험 / 문서화 경험
• 포지션 - react-native / typescript / rtc, 모듈 배포 경험

--

면접 절차, 면접 경험, 결과는 아래와 같다.

toss (Web Automation)

• 코테 > 과제 > 과제기반 라이브코딩
• 커리어를 시작하고 처음으로 지원자 입장에서 인터뷰를 해보는거라서 긴장을 굉장히 많이 했었다..
  거기에다 도메인이 다르다보니, 원하는 질문에 대한 코드를 작성해본적이 거의 없어서 적절한 대답을 잘 내놓지 못했다.
  챕터 리드분이 질문을 하나 던지시고, 생각하거나 코드에 손을 대는 와중에 또 다른 질문을 던지고.. 하는식으로 인터뷰가 진행돼서 정신이 없었다.
  사람이 아닌, 말 그대로 코드를 굉장히 구조적으로 잘 짜는 개발자를 뽑는 느낌이었다.
  뭔가 나에대해서 물어보지도 않고 탈락시켜서 섭섭하면서도, 들어가면 얼마나 잘하는 높은 수준의 동료들이 있을까 더 기대가 되는 느낌.. 토스 RN 포지션이 늦게 열려서 너무 아쉽다.
• 라이브 코딩 탈락

ridi (RN)

• 서류 > 개발 인터뷰 > CTO 인터뷰 > C레벨 인터뷰
• 인터뷰들이 모두 편안한 분위기에서 진행돼서, 긴장이나 실수가 덜 나온 느낌이 있었다.
  전체적으로 어떤 경험을 하면서 성장해왔는지를 주로 보는 분위기였고
  내 얘기를 많이해서 그런가, 면접은 전체적으로 재미있었다.
  지원자에게 관심과 집중을 굉장히 많이 준다는 느낌을 받아서 좋았다.
• 최종 합격

sendbird (RN)

• 서류 > 과제 > 과제 기반 라이브코딩 > 엔지니어링 매니저 인터뷰 > 알고리즘 기반 라이브코딩 > 7core values 인터뷰
• 모든 절차는 화상으로 진행됐는데, 모든분들이 시간을 딱 칼같이 지키신다. 이 부분이 굉장히 인상깊었다.
  질문에 둥그스름하게 대답하면 그냥 지나칠수가 있는데도 정확하게 어떤 부분에서 경험을 더 디테일하게 듣고싶은건지
  재차 질문을 하셨었는데, 이런 부분들이 지원자에게 집중하고 있다는 느낌을 받을 수 있었고 좋았다.
  라이브 코딩들도 무조건적으로 결과에 집중하는건 아니고, 전체적으로 과정을 찾아나가는 방향에 집중을 하는 느낌이었다.
• 최종 합격

myrealtrip (Web Frontend)

• 서류 > 개발 인터뷰1 > 개발 인터뷰2
• 면접은 소프트하게 진행됐지만, 내가 여러측면에서 준비가 안된상태에서 인터뷰를 진행했다.
  그저 죄송..
• 인터뷰 탈락

class101 (Web Frontend)

• 코테
• 코딜리티 플랫폼에서 코테를 진행하는데 온통 영어다. 재제출도 안돼서 빠르게 풀고 껐다.
  문제 난이도는 그냥 일반적인 코테 수준이었는데, 생각보다 컷이 높았다.
• 코테 탈락

soomgo (RN)

• 서류 > 과제 > 과제 리뷰 & 개발자 인터뷰 > CTO 인터뷰
• 과제는 쉬운난이도.
  CTO 인터뷰는 좋았으나, 실무자 인터뷰는 지원자에 관심이 있다는 느낌은 크게 못받았다.
  전체적인 질문도 아는지 모르는지를 체크하기 위한 느낌의 질문들이었다.
• 최종 탈락, 연락이 안왔다. 전체적인 채용과정의 톤앤매너는 좋았는데
  과제 내줄때도 메일이 안온적이 있어서 메일 발송이 안된건지.. 결과를 보내준다고 했는데 안와서 의아했다.

--

리디와 센드버드 사이에서 고민을 굉장히 많이했는데, 시기가 둘 다 너무 적절했다.
한곳에서는 마침 새로운 프로덕트를 만들 계획이고, 한곳에서는 한창 프로덕트의 코어한 부분들을 전환하고 있어서..
어느곳에 합류를 하던 프로덕트 코어에 대해서 일을 하면서 알아가기에 적절한 시점이고, 장기적으로는 기여에 따른 보상도 충분히 가져갈 수 있겠다고 판단이 들었다.

정말 한참 고민했고 최종적으로는 센드버드라는 네임밸류 25%, 단 한명만 뽑았던 포지션이라는 자부심 15%, B2B라는 새로운 경험을 하고싶은 마음 60% 로 두곳 중 센드버드에 합류하기로 결정했다.

---

2년동안 일하면서 성장했던 사운드짐을 떠날때는 굉장히 기분이 싱숭생숭 했다.
자식을 두고 떠나는 기분이랄까..

센드버드에는 합류한지 이제 한달이 조금 넘었는데, 팀 분위기나 회사의 분위기도 만족스럽다.
이제 프로젝트를 킥오프 했는데 좋은 제품으로 만들어내고 싶어서, 설계 단계에서부터 굉장히 힘을 쏟고있다.

올해도 열심히 살자 🙌