[회고] 2023 당근(마켓) 썸머테크 인턴십 후기

2023.06.26 ~ 2023.08.26 두 달간 진행된 당근의 <2023 썸머테크 인턴십> 을 통해 당근알바팀에서 프론트엔드 개발 인턴으로 근무한 경험을 정리했습니다.

지원부터 합격까지

이전 회사에서 인턴이 끝나기 2주 쯤 전에 우연히 썸머테크 공고를 보게 되었다. 사실 학부를 한 학기 남겨놓고 있어서, 2023년의 남은 6개월은 대학생 생활을 조금 누리고(…) 잘 마무리하려 했지만 사람 마음이라는 게…! 딱 방학 기간 동안 하는 인턴십이라 부담이 적기도 하고, 당근이라는 회사를 경험해보고 싶은 욕심이 나서 후다닥 지원서를 작성했다.

선발 과정은 빠르게 지나갔다. 코딩테스트나 과제가 없었기 때문에, 내가 그동한 공부하고 고민한 것들을 간결하면서도 부족하지는 않게 정리하는 데 가장 노력을 들였다. 그래서 노션을 사용해 지난 인턴십 업무, 개인 공부, 동아리 프로젝트 등을 분류 별로 정리한 포트폴리오를 작성했다. 각 프로젝트의 내용을 채우면서 가장 고민한 것은 어떤 점을 어필해야 하는지였다. 신입으로서, 당근 인턴으로서 내가 어필할 수 있는 부분은 무엇일지 나름의 고민을 거쳤다.

포트폴리오와 이력서

단순히 프로젝트의 진행 과정과 기술 스택을 나열하기보다는 그 과정에서 내가 느꼈던 문제의식과 그에 따라 재정의한 문제들, 해결 과정을 전달하고 싶었다. 읽는 사람에게 이 내용들이 막힘없이 스토리텔링 될 수 있도록 계속 내용을 다듬었던 것 같다. 이렇게 포트폴리오에 심혈을 기울이고 나니 지원 페이지의 질문에 답변을 작성하는 건 어렵지 않았다. 포트폴리오의 내용을 이것저것 가져와서 조금 더 자세하게 살을 덧붙였다. 공부했던 내용들은 미리 블로그에 정리해두었던 것도 많은 도움이 되었다.

다만, 이력서는 노션으로 만들지 않았다. 처음에 포트폴리오와 같이 노션으로 만들었더니 내 솜씨가 부족한 탓인지 매우 아마추어같은 (아마추어가 맞지만) 인상을 주는 듯했다. 그동안 작성했던 포멀한 레쥬메와 너무 다른 형태가 되었는데, 포트폴리오의 내용을 충분히 작성했으므로 이력서에는 정말 텍스트로 핵심만 적혀 있는 게 좋겠다는 생각이 들어 그냥 원티드에서 작성했다.

면접

사실 면접을 보고 나서는 떨어졌을 것 같다는 생각이 들었는데, 포트폴리오에 적힌 내용에 대한 질문이 거의 없으셨기 때문이다. 면접 경험이 많이 없었던 나는 흔히들 말하는 면접 플로우 - 포트폴리오의 내용으로 시작해 점차 꼬리 질문이 엮이는 - 를 상상하고 ‘프론트엔드 면접 대비’ 등의 이름으로 돌아다니는 질문 모음집과 내 포트폴리오 및 이력서 내용만 냅다 공부했다. 그러나 내가 받은 질문들은

• 구두로 간단히 주어진 케이스에 대해 어떻게 해결(구현)할 것인지 대답하기
• 평소 개발 스타일, 삶의 방식(?)

같은 것들이었다. 기술 질문들을 공부하는 데 매몰되어서 가장 기본적인 ‘인턴십을 통해 무엇을 얻어가고 싶은지’ 같은 질문들에 대한 대답을 전혀 생각을 안 해두었는데, 아니나다를까 면접 때 여쭤보셨고 나는 당황해서 같은 말만 여러번 반복했었다. 너무 초보적인 실수였다고 생각해서, 끝나고 굉장히 우울했었다 (…)

하여튼 기타등등의 이유로 탈락을 예상하던 중 발표 예정일보다 이틀 빠르게 연락이 왔다. 아무 생각 없이 이메일 창을 켜놓고 있다가 갑자기 창이 갱신되며 당근에서 이메일이 왔길래, 휴면 계정 전환 같은 서비스 알림인 줄 알았다. 그러다 축하합니다! 로 시작되는 메일 내용을 읽고 정말 기뻤던 때가 생생하다. 여담으로, 입사 이후 면접에 대해 여쭤보았더니 이미 포트폴리오와 블로그에 내용이 다 적혀 있어서 면접 때 굳이 질문하지 않으셨다고 한다. (무서웠어요)

인턴십에서의 역할

팀이 계속 달려나갈 수 있도록, 떨어진 것들을 줍줍하기

내가 우리 팀에서 맡은 역할을 표현하자면 위와 같다.

개발에 드는 가장 큰 비용은 시간이다. 누군가는 빠른 개발과 퀄리티 높은 개발이 상충하지 않는다고 하지만, (장기적인 유지보수성 보다) 태스크 단위로 생각했을 때에는 오직 기능 개발에 집중했을 때보다 퀄리티를 고려할 때 더 많은 시간이 드는 것이 사실이라고 생각한다.

하지만 프로덕트가 중심이 되는 팀에서 최우선 순위는 프로덕트의 성장이기 때문에 개인 프로젝트처럼 기술적인 욕심을 모두 채워 가며 개발하기 어려운 상황이 생긴다. 그래서 우선순위에서 자주 밀리는 태스크들이 있다. 하지만 마치 잡초처럼, 이런 태스크들이 쌓일수록 이후의 개발 환경 자체를 지저분하게 만들기 때문에 (고구마줄기 탄생) 마냥 내버려두고 달리기만 할 수도 없다. 그래서 이걸 처리하는 게 나의 역할이 되었다.

‘당근에서 인턴은 인턴이 아니다’ 라는 말을 쉽게 찾아볼 수 있다. 인턴에게도 모든 정보 및 자유로운 발언권이 주어지고, 맡은 일에 오너십이 요구되기 때문이다. 자유가 주어지는 만큼, 느껴지는 책임감도 훨씬 크다. 이전까지 내게 개발이란 ‘요구되는 기능을 구현하는 것’ 에 지나지 않았다. 그래서 기능이 명세대로 작동하도록 빠르게 개발을 마치는 것이 개발을 잘 하는 것이라고 생각했다. 썸머테크는 이런 생각(착각!)을 완전히 뒤바꿔 놓는 시간이었다.

개발자로서의 성장

프로덕트 중심의 우리 팀에서 나는 기술적인 문제들을 빠르게 해결하는 역할을 맡았다. 마치 1인 기능조직인 셈이다. 물론 인턴이기 때문에 객관적으로 경험이 덜할 수는 있지만, ‘인턴이라서 실력이 부족할 것이다’ 라는 가정을 전제로 하지는 않는다. 다른 팀원들과 마찬가지로 나 역시 이슈의 시작부터 마무리까지 책임지고 끝내야 했다. 그렇다 보니, 내가 짠 코드가 프로덕트에 어떤 영향을 미칠지 훨씬 신중하게 생각하게 되었다.

손가락 멈춰!

먼저, 냅다 손가락부터 움직이는 습관을 고치고 데이터의 흐름과 구조를 먼저 들여다보게 되었다. 코드 파악이 덜 된 상태에서 빠르게 기능을 만들어내는 데 집중하다 보니 여기저기 side-effect를 유발했고, 불필요한 수정이 잦아지는 걸 느꼈다.

• 대체 컴포넌트 만들면서 인터페이스 바꿔버리기
• 상위 컴포넌트에서 하위 컴포넌트 스타일링 제어하기
• 버그 발생 지점(원인 지점 X)에서 바로 수정하기 등등

잠깐만 생각해 봐도 내 발목을 붙잡았던 여러 실수들이 스쳐지나간다. 구조를 조금 더 넓은 시야로 봤어야 했는데, 당장 문제가 보이는 그 지점에 꽂혀서 바로 구현에 들어간 것이 원인인 경우가 많았다. 더군다나 데이터 흐름이나 구조가 머릿속에서 충분히 정리되지 않은 상태로 구현을 시작하면, 처음에는 무언가 되는 것 같다가도 마무리 단계에서 깔끔하게 태스크를 끝내지 못하고 자잘한 수정들로 늘어지거나 코드 속에서 길을 잃는 것이 느껴졌다. 그래서 태스크를 시작하면 가장 먼저 관련 로직들과 데이터 흐름을 파악해서 정리해 놓고, 머릿속에서 어느정도 구조가 잡힐 때 구현에 들어가려 노력했다.

자신감 넘치는 디버깅을 위해

두 번째로, 문제를 진단하는 나름의 프로세스를 만들게 되었다. 사실 지난 인턴십도, 이번 썸머테크도 주된 업무는 버그를 고치는 것이었다. 글자가 잘린다거나, 툴팁이 다른 컴포넌트에 가린다거나, 렌더링 타이밍 이슈가 있다거나… 그런데 어떤 버그는 시작부터 끝까지 깔끔하게 고친 것 같다가도, 또 어떤 버그는 시작은 창대했으나 마무리는 불만족스럽게 고쳐지는 일들을 겪으면서 자연스럽게 내 작업 방식을 되돌아보게 되었다.

모든 디버깅은 소거법이다. 가능한 케이스들을 찾고, 빠르게 지워 나가야 한다. 이 관점에서 디버깅이 늘어지는(길어지는) 원인을 진단해 보았는데,

• 가설을 정확히 정의하지 못한 경우
• 가설을 정확히 정의했으나, 검증의 답을 명확히 얻지 못한 경우

이 두 가지 이유가 컸다. 그리고 둘 다 근본적인 문제는 ‘기반 지식의 부족’ 이다. 예를 들어 렌더링 이슈가 생겼다면, 리액트의 컴포넌트 생명 주기와 렌더링 순서, 이에 영향을 미치는 effect 등등에 대한 개념이 정확하게 들어 있어야 가설을 빠르게 세우고 검증할 수 있다. 반면 이러한 개념이 모호하다면 가설부터 정확하게 세울 수가 없고, 검증을 하더라도 결과를 스스로가 확신하지 못하게 된다. 그래서 계속 다른 방식의 검증을 덧붙이고, 서치하는 시간이 더해져 디버깅이 길어지는 것이라고 진단했다.

그래서 가설 검증에 들어가는 시간을 줄이는 데 많은 노력을 기울였다. 먼저, 개인적인 궁금증을 해소하지 않도록 주의했다. 문제를 서치하다 보면, 딥다이브를 넘어서 공부에 가깝게 서치에 몰두하는 때가 있었다. 이걸 의식적으로 줄이고, 문제 해결에 초점을 맞춰 불필요한 내용까지 과도하게 서치하지 않도록 노력했다. 그리고 가설을 최대한 작게, 구체적으로 세우기 시작했다. 하나의 가설에 여러 조건이 맞물려 있다면, 해당 가설이 맞다는 걸 알아내도 다시 그 중 정확히 어떤 조건이 원인인지 찾아내는 과정이 필요하다. 따라서 하나의 가설은 한 개의 조건만 나타내도록 신경썼다. 그러자 가설을 검증하는 과정도 훨씬 간단해졌고, 이 검증 결과에 스스로 확신을 가질 수 있게 되었다.

이유를 댈 수 있는 코드 작성하기

개발자로서 성장했다고 느끼는 또 다른 점은 “모든 코드는 결정사항이다” 라는 말을 어렴풋이 이해하게 됐다는 점이다. 사실 이 말은 티타임 때 토니가 해주셨던 말인데, 처음 들었을 때는 우와 멋진 개발자같은 말이다! 라고 생각하고 미처 깊이 곱씹지는 못했었다(ㅎㅎ). 반면 지금은 코드가 개발자 주관(opinion)의 표현이고, 결국 과정이 아닌 결정사항이라는 데 나름의 공감을 할 수 있게 된 것 같다.

인턴십이 진행되고 점점 더 복잡한 태스크를 맡을수록, 해결 방법이 여러 개인 문제들을 마주쳤다. 해소하는 문제는 같지만 훅으로 분리할 수도 있고 컴포넌트로 감쌀 수도 있다. 스타일을 입히는 데 CSS 선택자를 사용할 수도 있고 wrapper 컴포넌트를 사용할 수도 있다. 공통 컴포넌트를 만들면서 인터페이스를 최대한 많이 열어 둘 수도, 일부를 감추어버릴 수도 있다. 당장 기능에 영향을 주지는 않지만, 개발 관점에서 의사 결정이 필요해지는 것들이다.

앞서 말했듯 이전까지는 빠르게 기능을 개발하는 것이 개발을 잘 하는 것이라고 생각했다. 하지만 계속해서 피드백을 받으며, ‘이렇게 하는 데 이유가 있나요?’ 라는 질문에 말문이 막히는 순간들을 겪었다. 그래서 단순히 기능을 만들어내기 위해서가 아니라, 최선의 방식을 선택하기 위해 고민하기 시작했다. 그러자 고민의 관점이 달라져야 했다. 정확히는, 고민의 폭이 넓어져야 했다.

이전까지는 “리액트를 잘 알고, 이런 기능도 만들 줄 알아요. 이런 것도 해낼 줄 알아요” 라는 걸 보여주는 데 집중했다면, 이제는 어떤 구조로 만들어야 유지보수성이 지속될 수 있을지, 어떤 방식으로 구현해야 기존의 성능을 해치지 않을지, 관심사는 어떤 형태로 분리하는 게 좋을지 따위를 앞서 고민하게 되었다. 즉 그동안은 보여지는 기능들에서 고민이 그쳤다면, 이제는 그 뒤의 로직을 어떤 식으로 작성하고 관리해야 하는지도 포함해 고민하게 되었다고 느낀다.

---

사실 이 외에도 기술적으로 성장한 부분들은 훨씬 더 많다. GraphQL과 Relay를 처음 써 봤는데, 프론트엔드에서 매번 API 수정을 요청할 필요 없이 자유롭게 필요한 필드를 조합해서 쿼리할 수 있는 데다 fragment 개념을 통해 각 컴포넌트에서 필요한 데이터를 독립적으로 관리할 수 있다는 점 등등 장점이 정말 강력하다고 느낀 스택이었다. 아무래도 버그를 해결하다 보니 기본적인 개념들을 넘어 라이브러리 소스를 직접 보고 딥다이브 해야 하는 경우들도 있었는데, 이런 경험들이 쌓이면서 프론트엔드 전반에 대한 지식도 많이 늘고 다져진 듯하다.

팀원으로서의 성장

한 명의 팀원으로서의 역할이란 뭘까요?

첫 해피니스 체크 때 던졌던 질문이다. 썸머테크 기간 동안 열심히 고민했던 것 중 하나가 바로 이 팀원으로서의 역할이란 무엇인가였다. 앞서 말했듯, 당근에서는 인턴에게도 상당한 자율과 책임이 함께 주어진다. 출근과 퇴근도 자유롭고, 위에서 데드라인을 정해주거나 마이크로매니징을 하지도 않는다. 나 역시 해야 할 일들은 백로그에 쌓여 있었지만, 여기서 어떤 태스크를 먼저 시작하고 언제까지 끝낼지, 작업 범위는 어느 정도로 잡을지 등등 내 업무에 관련된 사항은 스스로 결정하고 공유해야 했다.

사실 위에서 적은 개발자로서의 성장들도, “어떻게 하면 팀원으로서 조금 더 팀에 기여할 수 있을까”(= 빠르고 정확하게 내 일들을 끝낼 수 있을까)를 고민하다 보니 자연스럽게 얻어진 것들이었다. 팀에서의 내 역할과 업무 범위를 스스로 정의하는 데 고민이 많았다. 팀마다 다르겠지만 나의 경우 이미 업무와 기대하는 바가 명확히 주어져 있다고 느꼈는데, 그럼에도 불구하고 더 적극적으로 무언가 찾아 나서야 하는 건지, 아니면 내가 느낀 대로 주어진 일에서 높은 퍼포먼스를 보이면 되는 건지 헷갈렸다.

내 진짜 역할이 뭘까

사실 우리 팀의 일하는 방식은 이전 인턴십 때 겪었던 업무 환경과 많이 달랐다. 우리 팀 자체로 작은 스타트업과 같다고 느껴졌다. 목적 조직이기 때문에 각기 다른 역할을 하는 모두가 하나의 목표를 향해 원 팀으로 일하고 있다. 의사결정 → 실험 → 피드백의 사이클이 매우 빠르다고 느꼈고, 그렇기 때문에 시간이라는 비용을 어디에 들여야 할지 줄타기가 필요하다. 앞선 고민을 해결하려면, 이러한 팀에서 내가 어떤 방식으로 기여할 수 있는지를 먼저 생각해야 했다.

나는 무언가 새로운 걸 계속 찾아나서기보다 주어진 업무 안에서 책임감을 갖고 퍼포먼스를 높이는 것이 팀원으로서의 내 역할이라는 생각이 들었다. 물론 계속 혼자 고민하면 답을 얻을 수 없으므로, 이런 생각을 조금 정리해서 티타임 때 버디에게 이런 부분들을 여쭤보았다. 사내 강연을 듣던 중 마이크로소프트에서 연차나 실력에 따른 개발자의 qualification 을 정량적으로 구분한 표를 보게 되었는데, 이 테이블을 가져다가 여쭤보았더니 깔끔하게 align할 수 있었다. 한마디로 level 1!

목적 조직에서 기여하기

그렇다. 당근 인턴이라고 해서 무언가 대단한 걸 이뤄낼 생각을 하기 전에 주어진 일을 열심히 하는게 나 답다는 생각이 들었다. 우리 팀은 의사결정의 중심에 OKR과 데이터가 있다. 우선순위와 태스크 범위를 결정하는 데 있어 명확한 근거가 되고 모호함을 제거하는 효율적인 업무 방식이라고 느꼈다. 나에게도 쌓여있는 백로그 리스트와 컨텍스트만 주어졌을 뿐, 얼마만큼의 리소스를 들여 어느 정도로 문제를 해결할 지 스스로 정해야 했기 때문에 나름의 기준이 필요했다.

• 어떤 문제를 해결하려 하는지
• 해결하고 난 상태는 어떻게 되어 있어야 하는지
• 어떤 과정을 거쳐야 이 문제가 해결되는지

그래서 각 태스크에 적용할 미니 OKR을 만들고, 최대한 따라 보려고 노력했다. 시간을 조금 더 들여서 퀄리티를 챙길지, 빠른 개발에 집중할지 고민이 된다고 여쭤보면 “그 사이에서 줄타기를 잘 해내는 것이 이번 인턴십을 통해 얻어 가면 좋을 부분 중 하나” 라는 답을 주로 해주셨기 때문에(ㅎㅎ), 나만의 기준을 계속 만들어가는 기회로 삼았다.

목적 조직에서 각자 역할은 다르지만, 결국 모두가 추구하는 것은 ‘문제 해결’ 이다. 내게는 문제를 해결하는 수단이 프로그래밍인 것뿐이다. 이번 인턴십을 통해 생긴 큰 변화 중 하나는 내가 앞으로 어떻게 성장하고 싶은지 더 명확하게 그릴 수 있게 된 것인데, 그건 ‘문제를 푸는 사람’ 이다. 예전에 “기술이 혁신이 되려면 해결하려는 문제가 있어야 한다” 라는 말을 인상깊게 들은 적이 있다. 그러니까 개발자가 되고 싶다는 것은 결국 프로그래밍을 통해 문제를 해결하겠다는 선언이다.

문제를 더 잘 해결하는 사람이 되자

좋은 팀 안에서 문제를 해결하는 데 몰입하는 경험은, 짧은 시간에도 시야를 훌쩍 트이게 한다. ‘팀’ 의 일원이기 때문에, 단순히 코딩만 잘할 것이 아니라 먼저 문제를 정확하게 정의할 수 있어야 하고, 어떻게 해결하는 것이 최선의 방법인지 찾아낼 수 있어야 한다. 두 달 동안 나는 서버를 공부하는 데 새롭게 관심이 생겼고, 프로덕트 성장의 관점에서 구조와 확장성을 고민하게 되었고, 기술을 공부하는 이유를 ‘코딩을 더 잘하는 것’ 이 아닌 ‘문제를 더 잘 해결하는 것’에서 찾게 되었다.

처음 지원할 때 기대했던 것 이상으로 많은 경험을 하고, 개인적으로도 크게 성장한 두 달이었다. 이것은 그저 내가 고민에 많은 시간을 쏟아서가 아니라, 그만큼 좋은 환경을 갖춘 팀에서 업무를 경험해볼 수 있었기 때문이고, 주변의 좋은 동료들을 계속해서 보고 배울 수 있었기 때문이다. 그래서 썸머테크가 끝난 지금은, 근무를 연장하게 되어 올해까지 당근알바팀에서 경험을 쌓기로 했다. 올해가 지나면 또 어떤 사람이 되어 있을지 기대가 된다!

---

만약 이 글을 읽고 계신 당신이 다음 시즌테크 지원을 고민 중인 분이시라면, 지금 떠오르는 것보다 더 멋진 경험을 쌓을 수 있을 것이라고 진심으로 말씀드리고 싶습니다. 당근 개발자 또는 알바팀 팀원이시라면! 두 달 동안 많은 고민을 거치고 배울 수 있어 정말 감사했다는 말씀을 드리고 싶어요 😁😁

알: 알바는
바: 미쳤다~!