당근에서의 6개월, 나는 얼마나 달라졌나

첫 직장이자, 정말 가고 싶었던 기업 중 하나였던 당근에서의 인턴 생활이 끝이났다.

프론트엔드 엔지니어로서 인턴 기간동안 다양한 것들을 경험했다. 단지 기억으로 휘발되기에는 아깝다고 생각하여 정말 오랜만에 글을 쓰게 되었다.

당근 입사

아직도 당근에 합격했던 순간은 잊혀지지 않는다.

최종 합격 메일을 받았을 때 본가에 가기 위해 기차를 기다리고 있었는데, 합격 메일을 받고 부모님, 친구들에게 전화하며 울먹이던 순간이 있었다.

사실 직무 면접과 라이브 코딩 테스트를 전혀 잘봤다고 생각하지 않았기에, 최종 합격 사실이 믿겨지지 않았다. 후에 내 면접에 들어오신 팀원 분이 말씀해주시길 "특정 기능을 구현하는 과정이 가장 현업자스러웠다" 라고 말씀해주셨던 것이 기억에 남는다. 그 말을 듣고 정말 뿌듯했던 기억이.. 있다.

입사날에는 눈이 펑펑 왔던 기억이 있는데, 벌써 여름이 끝나간다.

팀에 녹아들기

입사 한 이후로 약 2주간의 온보딩 기간이 주어졌다.

당근 내부에 존재하는 다양한 사내 툴을 설치하고, 우리 팀이 일하는 방식에 대해서 파악하고 체화해야 했다.

가장 어려웠던 것은 정말 큰 규모의 코드 베이스를 파악하는 것이였다. 팀 코드 베이스를 파악하는 데에만 3개월 걸린 것 같다. 그 후에야 대충 뭐가 어딨고, 뭐를 사용해야하고, 컨벤션은 이거고 .. 라는 인지가 제대로 섰던 것 같다.
내가 "아 요런 기능이 없네 ? 내가 만들어야겠다" 싶은 생각이 들면 무조건 이미 구현되어 있었다.

확실히 남의 코드를 읽는 것도 능력이고 실력이다. 나는 우리 팀의 코드를 모두 파악하는데 정말 많은 리소스가 들었다.

내가 퇴사하기 전 약 3주 전에, 프론트엔드 5년차 엔지니어 분이 새로 팀에 합류하였다.
그 팀원분은 거의 내 3배 정도로 코드 베이스를 파악하더라. 제 3자의 사고를 trace 하며 읽어나가는 과정도 실력이다라는 것을 느꼈다.

기술 역량은 당연하다. 기술이 뛰어날 수록 코드를 읽기 수월하지 않을까 ?

메이커로 일하기

나는 엔지니어보다는 메이커로서 6개월을 보냈다.

성능을 최적화하고, 더 나은 아키텍쳐를 고민하고, 자동화에 기여하는 등의 일보다는 어떻게 제품을 더 잘 만들 수 있는지에 참여하였다. 물론 엔지니어링을 하지 않았다는 것은 절대 아니다. 하지만 PM, 디자이너와 협업하며 제품 개선에 많이 힘썼던 것 같다.

달리는 자동차의 엔진을 교체하는 일을 하였다고 느낀다. 실시간으로 우리 제품을 사용하고 있는 유저들에게 더 나은 경험을 제공하고자 하루에 많게는 7번 정도도 프로덕션 배포가 이루어졌다.
프로덕션에서조차 이렇게 변경이 자주 일어나기에 내 Capacity는 얼마인지, 내가 지금 작업하고 있는 태스크는 무엇인지 등에 대한 상황 공유의 중요성은 더욱 올라갔다.

팀 개발자들이 신경썼던 부분 중 하나가 Atomic한 커밋인데, 이 또한 우리 팀이 일하는 방식에서 기인한다. 최대한 리뷰어들이 내 PR에 쏟는 리소스를 줄이고자 커밋 하나 하나에 독립적인 맥락을 담고자 하였다. 리뷰를 하는 것도 당연히 많은 리소스가 들기 마련이다. 이러한 작업 방식에 많이 익숙해졌을 때 쯤, 팀원분이 커밋 별 컨텍스트가 정말 잘 작성되어 있어 리뷰하기가 정말 많이 편했다는 피드백을 받았던 기억이 있다.

지금은 쓸데없는 커밋을 절대 하지 못하는 습관이 든 것 같다. 뭐 하나 커밋들 중 맥락이 겹치는 커밋이 보인다면 바로 인터랙티브 리베이스부터 때리고 있는 나다. 물론 히스토리, 팀 맥락을 어떻게 관리하냐에 따라 불필요하기도 하다.

이처럼 6개월이 지나고 가장 많이 향상되었다고 느끼는 부분 중 하나가 Git을 다루는 능력이다.

---

서버 엔지니어보다는 확실히 타 직군 팀원들과 교류할 일이 많았다.
우리가 이 피쳐 기능을 개발하고 배포함으로써 얻는 기대효과가 이것이고, 성공 지표는 이런 것들인데 어떤 방향이 더 개발에 용이한지, 예상 소요 기간은 얼마인지 논의하였다.
UX를 챙기기에는 이렇게 구현하는 것이 더 좋을 것 같다고 하다면, 개발자로서 구현 가능 여부와 실제 구현 결과의 예상 동작을 말해주었다.

모두가 메이커로서 제품 개발에 힘쓰기에, 주기적으로 폴리싱 기간이 주어졌다. 빠르게 제품 개발을 하느라 신경쓰지 못했던 엔지니어링적인 개선 요소들에 투자하는 기간이다.

개인적으로 이 기간이 정말 재밌었다.
설계 측면에 잔존했던 안티 패턴들을 제거하고, 인터페이스를 재설계했었다.
또한 내가 입사했던 시기가 팀 단위로 LLM 고도화에 많은 투자를 하던 시기였는데, 폴리싱 기간에 AI를 통한 마크업 산출물의 완성도를 높히고자 노력했었다.
AI는 더 이상 도구가 아니라, 한 명의 파트너임을 절실하게 느꼈다. 위협(?)이 되었던 것은 사실이지만 굉장히 재밌었던 경험이었다.

버그 맞이하기

회사에 가니 정말 다양한 버그를 맞이할 수 있었다.

원래 있던 버그, 내가 만들어낸 버그, 누가 준 버그 .. 수많은 오류들을 해결하다 보니 디버깅 능력 또한 많이 향상된 것 같다.

많이 체감되었던 것은, 디버깅 능력은 실력은 당연하고 경험치에 꽤나 비례하다는 것이다. 내가 1시간 반 동안 머리를 싸매고 있던 것들이 누군가에게는 1분 컷일 수도 있다. (실화이다)

이는 어떻게 보면 당연하다.
사고의 흐름이 해당 오류를 해소하는 길을 경험해보지 못했다면, 이는 죽어도 해결하지 못할 수도 있다.

FE 팀원들과 다양한 대화를 했었는데, 한 팀원분이 자신은 이렇게 디버깅한다고 말씀해주셨다.

1. 발생한 문제에 대해 파악한다.
2. 원인가설을 다수로 추려낸다.
3. 가장 시간이 적게 드는 원인들부터 확인하면서 소거한다.
4. 가설들을 하나씩 검증하며 추론한다.

실제로 굉장히 워킹했던 방법이다.

2의 결과물이 "실력 + 경험치"에 따라 나뉜다. "A에 대한 원인이 B야!"를 말할 수 있으려면 B가 A를 초래할 수 있다는 경험 또는 기술 기반이 있어야한다.

복합적인 문제의 경우, 최소 재현 조건을 설정해두면 좋다. 최소 재현 조건을 제외하고 모두 지워놓은 상태에서 테스트하다보면 원인이 좀 더 명확해진다.

---

실제 예시로 스크롤 이벤트를 다루는 도중 컨테이너 ref에 대한 콜백이 실행되지 않아 디버깅했던 경험이 있다.
ref 값이 계속하여 null 로 초기화되었는데, 나는 도저히 ref.current가 올바르게 할당된 이후 해당 레퍼런스가 초기화될만한 원인을 찾아내지 못했다.

여기서 "하위 컴포넌트 트리에서 비동기 상태를 반환하였고, 이에 대한 서스펜스 경계의 부재 때문에 해당 컴포넌트가 리마운트되어 ref가 초기화될 수 있다" 라는 사실이 하나의 원인 가설이 될 수 있다.
내가 마주한 버그의 경우 해당 가설이 워킹하였다.

물어보기

당연하게도(?) 다양한 방면에서 팀원들에게 구두로, 슬랙으로 물어봤던 것 같다. 여기서 이야기 해보고 싶은 것은 두 가지이다.

1. 질문을 질문 자체로만 볼 것인가 ?
2. 어떻게 질문할 것인가 ?

1)은 작업의 효율성 측면에서 질문을 어떻게 바라볼 것인가이고, 2)는 질문을 어떻게 더 잘할 것이냐이다.

입사 후 초반에는 정말 혼자서 고민하는 시간이 많았다. 팀원들에게 물어보는 것 자체를 스스로 부정적으로 바라보았고, 흔히 말하는 핑프라고 생각했다.
그렇기에 혼자서 이것을 해결해보려고 고군분투하였다.

내가 특정 무언가에 매몰되어 끊임없이 고민하는 동안, 내 팀원은 내가 무엇을 하고 있는지 파악하기도 힘들었고, 고군분투하는 시간동안 작업은 지연되었다.

실제로 엔지니어링 측면이든, 도메인 레벨이든 거의 뭐든지 혼자서 해결해보려고 많이 노력했던 것 같은데, 옆자리 팀원이 내가 지금 무엇을 하고 있길래 이렇게 모니터만 주구장창 보고있는지 여쭤보기도 하였다.

팀에 존재하는 유능한 팀원들도 자산이다. 혼자 해결해보려 하지도 않고 무엇이든지 물어본다면 당연히 잘못된 것이겠지만, 팀원들에게 이를 공유하고 질문하여 빠르게 해결할 수 있다면 제품 개발 측면에서는 이보다 좋을 것이 없는 것이다.

효율이 중요하다고 생각한다. 나는 이걸 혼자 해결해보라는 숙제를 맡은 것이 아니다.
빨리 해당 작업을 마치고 다음 태스크에 뛰어들어야 한다. 블로커가 생겼다면 이를 공유해보자

---

어떻게 질문할 것인가? 의 해답은 보다 명료하다.

내가 질문하려는 사람에게 내가 가지고 있는 맥락을 내포하여 말하면 안된다. 내가 무엇때매 질문을 하는지, 질문으로 해결하려는 것이 무엇인지 팀원은 충분히 모를 가능성이 있다.

또한 핵심을 잘 전달해야 한다. 결과적으로 이 질문을 "왜" 했는지 팀원이 인지할 수 있어야 한다.
장황하게 A - Z 모든 것을 전달하는 것보다, 내가 그 팀원으로부터 얻고자 했던 것이 무엇인지를 질문에 담자.

내 인턴 생활을 전반적으로 케어해주셨던 FE 팀원이 1 on 1 당시 해줬던 말이 있다.

"맥락을 모르는 것은 당연하다. 내가 고민했던 지점들을 많~이 물어봐라. 모두가 반겨줄거다"

꼼꼼함이란 무기

앞서 인턴 기간동안 가장 많이 향상되었던 부분 중 하나가 Git이라고 했다.
또 다른 하나는 꼼꼼함, 스스로하는 세니티(Sanity) 테스트이다.

나는 꼼꼼함이 부족했었다.

처음부터 100% 완성도로 개발하는 사람은 드물다. 100%를 채울 수 있는 능력이 꼼꼼함이다.
내가 개발한 기능의 독립적인 동작 여부를 테스트해보는 것에서 멈추면 안된다. 내가 만들어낸 산출물로부터 다른 코드들이 받을 사이드 이펙트까지 스스로 핸즈온해보는 것이 중요하다.

아무리 단순한 코드라고 한들, 내가 짠 코드가 당연하게 잘 동작하리라 예상해서는 안된다.
실제로 나는 단지 Enum 값을 변경하고 싶었는데, 임포트한 Enum 값이 실제로는 타입 시스템의 Type이여서 문제가 발생했던 경험이 있다. 호출문만 바꾸면 되기에 당연히 잘 동작할 줄 알았다.
말로 설명해서는 이 문제의 심각도가 안느껴질 수 있는데, 실제 제품 UI 상에 ...Type 이라고 찍혔던 것이다..

다시는 이러한 실수를 범하지 않겠다고 그때서야 다짐했다.
해당 일이 있고나서부터는 개발을 완료하고 PR을 올리기 전에, 영향 범위의 end to end로 20번까지 다시 반복해서 테스트해보았다.

좀 더 기존 스펙을 꼼꼼하게 점검할 필요가 있다. 내가 사용한 컴포넌트든, 함수든 이 구현체를 타고 타고 들어가서 정말 발생할 수 있는 문제가 없는지 코드 레벨에서 그리고 런타임에서 테스트해봐야 한다.

팀 리드이자 시니어 개발자 팀원분이 "주니어 레벨에서의 꼼꼼함은 정말 강력한 무기"다 라고 말씀해주셨던 기억이 있다.

나는 프론트엔드 개발자로서 스스로 꼼꼼함을 갖추기 위해 인턴 기간 동안 정말 많이 노력하였다. 생각해보면 이는 비단 개발자로서의 나뿐 만 아니라, 인생을 살아가는 한 명의 성인으로서의 나에게도 도움이 될지도 모른다.

인턴 최종 평가

퇴사하기 전 약 2주 전에 최종 인턴 평가를 받았다. 동료 엔지니어들이 나를 한 명의 동료 개발자로서 어떻게 평가했을지 많이 궁금하기도 하면서 걱정되기도 하였다.

당연하게도 긍정적인 피드백과, 부정적인 피드백(보완해야할 점)을 받았다.
내가 받았던 보완해야할 점 중 대표적인 것들이, 앞서 언급했던 블로커에 대한 공유, 꼼꼼함 이었다.

생각해보면 첫 직장으로 당근을 다니기 전, 다양한 IT 동아리와 사이드 프로젝트를 진행하며 엔지니어로서 건설적인 피드백을 받은 적이 거의 없었던 것 같다.

그렇기에 더 많이 나에게 와닿았다. 긍정적인 피드백들은 내 강점들을 확인시켜주며 동기 부여를 주었고, 한 층 성장하였음을 인지시켜 주었던 반면, 부정적인 피드백은 여전히 엔지니어로서 부족한 부분들이 많다라는 것을 뼈저리게 느끼게 해주었다. 그것이 기술 역량이든 소프트 스킬이든 말이다.

---

또한 피드백 수용성에 대해 다시 생각해보는 계기가 되었다.

특정 피드백을 받았다라는 사실은 중요하지 않다. 이 피드백을 장기적으로 끌고가 내 것으로 체화하는 것이 중요하다. 끊임없이 내 안의 구멍들이 존재함을 리마인드해야한다. 상기하지 않는다면 잊기 마련이라고 생각한다.

최근에는 내 안에 새로운 것을 더하는 것에 집중하였다. "피드백을 장기적으로 리마인드하여 체화한다" 라는 것은 더하는 것보다는, 기존 룸의 빈 공간을 채우는 것에 비유하면 맞는 것 같다.

내 부족한 점을 인지하고, 이를 메꾸기 위해 끊임없이 리마인드한다면 내 성장 곡선에서도 탄력을 받지 않을까 생각한다.

다시 돌아간다면

지금 막 백수 5일차를 맞이하였다.

누군가 나에게 "인턴 기간이 끝나면 시원섭섭한 감정은 없고 해방감만 들 것이다."라고 말해주었는데, 나에게는 그렇지 못하나 보다.

인생에서 가장 빨리 지나갔던 6개월이였다. 회사에 다닐 때는 당연히 힘들 때가 더 많았지만, 퇴사하니 그 치열했던 때로 돌아가고 싶은 생각도 든다. 당근 사내에서도 최고라고 생각이 들었던 유능한 팀원들이였다.

다시 돌아간다면 내 초반 2 ~ 3개월을 더 주도적으로, 능동적으로 보내고 싶다.
인턴 초반에는 실제로 "난 인턴인데" 라는 걱정이 나를 많이 억제했다. 동료들이 나를 평가하는데 있어 인턴이라는 위치는 아무 짝에도 영향을 미치지 않는다는 것을 3개월이 지나가면서 알았다. 내가 뱉는 말, 내 역량, 내가 보여주는 성과들이 내 위치를 만든다.
오히려 내가 나를 더 인턴으로 평가했다.

다시 돌아가도 동일한 회사의 동일한 팀 인턴을 하고 싶다. 팀원들과 후에도 연락을 하고 싶어 안하던 링크드인을 시작했다.

미래에 좋은 기회로 꼭 다시 뵙고 싶다는 인사를 마지막으로, 팀원들이 준 케이크를 들고 교보문고를 나왔다.

마무리하며

25년 3월과 비교하면 9월의 나는 정말 많이 성장했다. 기술적으로도, 소프트 스킬적으로도 내 역량이 한 층 성장했다라는 것을 느낀다.

당근에서의 경험은 앞으로의 회사에 가서도 끊임없이 동기 부여가 될 것 같다.

단순히 개발자로서 역량보다, 회사와 팀 내 구성원으로서 신뢰와 확신을 주는 엔지니어로 자리잡고 싶은 욕심이 있다. 그것이 제품 사이드든 기술이든, 명확한 솔루션이나 의견을 줄 수 있는 그런 팀원이 되고 싶다.

9월 한 달은 조금 쉬면서 재충전을 해야할 것 같다. 다시 취업 시장에 뛰어들 준비를 해야하기 때문이다.

개인적으로 작년 겨울의 취준 때와는 많이 상황이 다른 것 같다. (많이 힘들었던 겨울이였다)
당근에서의 6개월은 앞으로 무엇이든지 해낼 수 있다는 자신감을 주었다. 어떻게 해야 좋은 엔지니어가 될 수 있는지에 대한 감을 찾은 것만 같다.