안녕하세요, 2023 신입 개발자 블라인드 채용을 통해 카카오에 합류한 신입 FE 개발자 gray입니다.
제가 블라인드 채용에 합격했다는 소식을 듣고 방방 뛰었던 게 엊그제 같은데, 어느새 카카오에서 신입 FE 개발자로서 일련의 ‘온보딩’을 경험하고 마무리하는 시간을 맞았습니다.
온보딩은 신규 입사자가 조직에 잘 적응할 수 있도록 지원하는 교육 과정을 말하는데요, 카카오에선 다양한 형태의 온보딩이 신규 입사자의 역할에 따라 구성되고 제공됐습니다.
신입 FE 개발자의 역할로 입사한 저는 아래와 같은 구성의 온보딩을 경험할 수 있었습니다.
제가 경험한 일련의 온보딩을 주욱 되돌아봤을 때, FE 기술 온보딩이 유달리 특별하게 느껴졌습니다. 주어진 긴 시간 동안, 좋은 환경에서 멋진 동료들과 함께 제가 좋아하는 FE 기술 학습에 온전히 몰입할 수 있었기 때문이 아닐까 생각합니다.
저는 이 글을 통해 제가 경험한 FE 기술 온보딩을 소개하고자 합니다.
FE 기술 온보딩의 특징
제가 경험한 FE 기술 온보딩은 아래의 4가지 특징을 가지고 있었습니다.
단계적 학습
FE 기술 온보딩은 기초 HTML, CSS, 자바스크립트(JavaScript)와 같은 기본적인 기술 주제부터 시작해서 FE 빌드, 비동기 제어, 리액트 및 테스트 코드와 같은 기술 주제들을 학습할 수 있도록 단계적으로 구성됐습니다.
미션 중심
미션은 주어진 기술 주제를 중점적으로 다룰 수 있도록 설계된 프로젝트 요구사항을 의미합니다. 백견불여일타라는 말을 들어보셨나요? 저희 신입 FE 개발자들은 여러 활동을 통해 학습한 기술 지식을 개인 미션 구현에 적용하는 식으로 효과적인 학습을 수행할 수 있었습니다.
소통 지향
FE 기술 온보딩은 기술 지식을 학습하는 것뿐만 아니라 동료들과 함께 소통하고 성장할 수 있도록 하는 페어 세션, 그룹 피어 세션, 코드 리뷰, 미니 세미나 등의 다양한 활동들로 이루어졌습니다.
현업 연계
각 신입 FE 개발자들이 추후 일하게 될 부서의 현업자 분들께서 코드 리뷰어의 역할을 맡아주셨는데요, 덕분에 부서의 코드 스타일이나 리뷰 문화를 FE 기술 온보딩 중에 미리 접할 수 있었습니다.
주어진 기술 주제와 미션들
FE 기술 온보딩은 단계적 학습과 미션 중심의 특징이 있다고 앞서 언급했습니다.
저희 신입 FE 개발자들은 구체적으로 어떤 단계를 밟았을까요? 저희에게 주어졌던 기술 주제들을 한 번 열거 해봤습니다:
HTML, CSS, 자바스크립트와 같은 기본적인 기술 주제부터 시작해서 FE 빌드, 비동기 제어, 리액트 및 테스트 코드와 같은 기술 주제들이 차례대로 주어졌다는 것을 확인할 수 있습니다.
FE 기술 온보딩에선 이와 같은 기술 주제를 다루는 실시간 강의가 매일 오전 시간에 제공됐고, 주도적으로 행해지는 개인 학습과 동료들과 함께하는 다양한 활동들로 기술 주제에 대한 지식을 습득할 수 있었습니다.
주어진 실시간 강의, 주도적인 개인 학습, 동료들과 함께한 활동들… 저희는 이렇게 다양한 경로에서 습득한 지식을 개인 미션 구현에 적용하며 더욱 효과적으로 학습할 수 있었습니다.
미션은 주어진 기술 주제를 중점적으로 다룰 수 있도록 설계된 프로젝트 요구사항이라고 앞서 간단히 설명해드렸는데요, 이번엔 FE 기술 온보딩에서 주어진 미션들을 하나씩 소개하겠습니다.
인스타그램
첫 번째로 주어진 미션은 인스타그램의 일부를 클로닝하는 것이었습니다.
디스플레이 다크 모드에 대한 토글, 스토리 리스트에 대한 스크롤, 포스트 이미지 리스트에 대한 슬라이드, 스크린 너비에 대한 레이아웃 반응 등 다양한 기능을 구현하면서 FE 개발의 기초가 되는 HTML, CSS, 자바스크립트의 기본 개념들을 익힐 수 있었습니다.
요구사항엔 코드의 들여쓰기 깊이와 전역 변수의 사용을 최소화하라는 내용이 포함됐는데요, 이 덕분에 기능 구현을 넘어서 코드 품질에 대한 고민까지 함께 할 수 있었다고 생각합니다.
노트 앱
두 번째로 주어진 미션은 노트 앱을 구현하는 것이었습니다.
미션에서는 ES modules를 이용한 모듈 단위 프로그래밍과 Webpack의 적용이 포함되어 있었습니다. 이를 위해 신입 FE 개발자들은 Webpack을 이용해 모듈 단위로 나누어진 코드를 효율적으로 묶을 수 있는 방법을 학습했습니다. 또한, Babel과 Sass 등의 유용한 도구들을 이해하고 통합하면서 FE 빌드에 한 발 가까워졌습니다.
이때 Webpack을 이용하면서 UX 저하 이슈를 겪었습니다. sass-loader, css-loader, style-loader를 적용해서 분리된 SCSS 모듈들을 번들링했을 때, 최초 진입 시 스타일 규칙이 적용되지 않은 상태로 페이지가 렌더링 되고, 그 이후에 스타일 규칙이 적용된 상태로 다시 페이지가 다시 렌더링되면서 화면이 깜빡이는 현상이 발생했습니다.
이 문제를 해결하기 위해 조사한 결과, 이러한 깜빡임은 style-loader와 브라우저의 동작 방식에 기인한 자연스러운 현상이란 것을 알게 됐습니다. style-loader는 스타일 규칙을 자바스크립트 런타임에 주입하는 방식으로 동작하는데, 이 때문에 브라우저에서 관련된 자바스크립트 파일이 로드되고 실행되기 전까진 스타일 규칙이 적용되지 않았던 것입니다.
해당 자바스크립트 파일은 스타일 규칙뿐만 아니라 스타일 규칙을 주입하는 로직이 포함됐기 때문에 같은 내용의 스타일 규칙을 담은 CSS 파일보다 로드하는 데에 시간이 많이 소요될 수 있었습니다. 적절한 코드 분리 처리가 없으면 다른 로직을 담은 모듈들과 함께 번들링되고 이로 인해 파일 크기는 더욱 커질 수 있었고요.
결국 빌드 시점에 하나의 CSS 파일에 분리된 스타일 규칙들을 모으고 이를 HTML 파일에 링크하는 도구를 찾아 적용하는 것으로 해당 이슈를 해소할 수 있었는데요, 이러한 Webpack과 관련된 이슈들을 경험하며 FE 빌드 과정과 브라우저 동작을 더 잘 이해할 수 있게 됐다고 생각합니다.
미션을 진행하는 동안 노트 앱의 여러 기능들(노트 리스트 보기 방식 토글, 스낵바 제어 등)을 구현하면서 자바스크립트와 DOM API의 많은 부분을 학습할 수 있었던 것도 의미가 있었다고 회고합니다.
깃허브 파인더
세 번째로 주어진 미션은 Github API를 연동한 애플리케이션을 구현하는 것이었습니다.
미션에서는 OOJS(Object-oriented JavaScript)와 관련된 기술인 Prototypes와 Classes를 응용하라는 내용이 포함되어 있습니다. 이를 응용하면 객체를 적절한 역할 단위로 세분화할 수 있습니다. 신입 FE 개발자들은 이러한 기술들을 응용하면서 컴포넌트 단위 개발을 시도하였습니다. 이를 위해 MVVM 패턴을 적용하는 동료도 있었고, 개발 대상 UI를 ‘컴포넌트’라는 부류의 객체들로 나눈 동료도 있었습니다.
컴포넌트 단위 개발을 진행하면서 경험한 props drilling 이슈를 해결하기 위해 상태를 관리하고 변화를 관찰할 수 있도록 하는 객체를 추가로 정의하였고, 애플리케이션 상에 여러 개의 객체가 존재할 수 있기 때문에 이러한 객체에 대한 개별적인 바운더리를 지정하기 위해 MutationObserver와 CustomEvent 같은 DOM API를 학습하고 적용하는 등 다양한 시도를 하였습니다. 이렇게 다양한 시도를 통해 FE 개발 역량을 향상할 수 있었습니다.
또한, Github API를 연동하는 부분에서는 자바스크립트의 프로미스(Promise)와 async function을 학습하였습니다. 이를 통해 이벤트 루프의 동작 방식을 충분히 이해하고 비동기 제어에 익숙해질 수 있었습니다.
넷플릭스
네 번째로 주어진 미션은 넷플릭스의 일부를 클로닝하는 것이었습니다.
이번 미션에서는 리액트를 사용해야 했습니다. 슬라이딩이 가능한 무비 리스트, 스크롤링이 가능한 모달, 검색바에 적용된 디바운싱과 네비게이팅 등 다양한 리액트 컴포넌트를 개발하면서 리액트의 동작 방식을 이해할 수 있었습니다. 이러한 이해를 바탕으로 고차 컴포넌트(HOC, Higher Order Component)나 사용자 정의 훅(Custom Hook)을 만들고, 개발에 도움을 주는 라이브러리들을 학습하며, 재사용이 용이한 컴포넌트에 대해 고민하는 등 다양한 경험을 가질 수 있었습니다.
무비 컴포넌트를 렌더링하기 위해 The Movie Database API를 이용하는 과정에서 HTTP 트랜잭션을 다룰 필요가 있었습니다. 사용자가 검색 바에 쿼리를 입력하면 HTTP 요청을 수행하고 이에 대한 응답을 적절히 렌더링해야 했습니다.
그러나 연이어 HTTP 요청이 수행되는 경우, 드물게 발생할 수 있는 문제가 있었습니다. 프로토콜의 버전에 따라 다르겠지만, HTTP/2에서는 하나의 TCP 커넥션 상에서 HTTP 트랜잭션이 다중화될 수 있습니다. 사용자의 입력에 따라 연이어 발생한 HTTP/2 요청 A, B가 있다면, A에 대한 응답이 B에 대한 응답보다 늦게 도착하는 경우 문제가 발생합니다.
이 문제를 단순하게 표현한 그림은 아래와 같습니다.
사용자가 요청한 B에 대한 렌더링 결과가 보여지길 기대하는 동안, A에 대한 렌더링 결과가 이를 덮어쓸 가능성이 있습니다. 이러한 잠재적인 문제를 방지하기 위해 리액트에서 제공하는 훅을 활용하여 해결했습니다. 마지막 HTTP 요청에 대한 프로미스 객체를 useRef 훅을 사용하여 따로 관리하였고, 이 프로미스 객체와 현재 처리 중인 HTTP 응답에 대한 프로미스 객체가 서로 다른 경우에만 렌더링 처리를 하도록 구현했습니다.
아래는 작성한 코드입니다.
function SearchPage() {
…
const lastPromiseRef = useRef(null);
useEffect(() => {
const promise = axios.get(buildUrl(debouncedQuery));
lastPromiseRef.current = promise;
promise.then(
(res) => {
if (promise !== lastPromiseRef.current) return;
setMovies(res.data.results);
},
(err) => {
setError(err);
}
);
}, [debouncedQuery]);
…
}
위 코드는 잠재적인 문제를 효과적으로 방지합니다. 다만 작성된 코드가 동료들로 하여금 그 의도를 파악하기 힘들다는 아쉬움이 있습니다.
주석을 사용해서 의도를 명시하는 방법으로 아쉬움을 해소해도 되겠지만, 더 나은 방법이 존재했습니다.
코드 리뷰어 jake의 제안에 따라 AbortController를 사용하는 것이었는데요. (참고로 jake는 일전에 AbortController와 관련된 흥미로운 글을 투고하셨습니다.)
해당 API를 사용해 아래와 같이 코드를 변경했습니다.
function SearchPage() {
…
useEffect(() => {
const abortController = new AbortController();
axios
.get(buildUrl(debouncedQuery), { signal: abortController.signal })
.then(
(res) => {
setMovies(res.data.results);
},
(err) => {
if (err instanceof CanceledError) return;
setError(err);
}
);
return () => {
abortController.abort();
};
}, [debouncedQuery]);
…
}
이전의 코드보다 훨씬 더 명시적인 코드가 만들어졌습니다. AbortController라는 API가 자체적으로 의도를 명확히 보여주기 때문에 별도의 주석이 필요 없는 코드입니다.
미션을 진행하는 동안 이러한 시행착오를 많이 겪을 수 있었는데요. 리액트를 학습하는 것은 물론이고, 좋은 코드에 대한 생각을 많이 확장할 수 있었다고 봅니다.
미션 구현 막바지엔 개발한 애플리케이션에 대한 프로파일링과 렌더링 최적화를 시도했습니다. 이 경험 덕분에 리액트의 동작 방식을 더욱 깊게 이해할 수 있었습니다.
쇼핑몰
마지막으로 주어진 미션은 간단한 쇼핑몰을 구현하는 것이었습니다.
이번 미션은 구현 기간이 짧았지만 리액트와 관련된 여러 기술들을 학습하고 적용하며, 테스트 주도 개발을 진행하는 동안 많은 경험을 쌓을 수 있었습니다. 구현해야 할 기능들은 단순하지만, 테스트를 작성하는 과정에서 어려움이 있었습니다. 하지만 이러한 과정을 통해 외부 환경과 격리된 테스트를 달성할 수 있는 MSW(Mock Service Worker)를 학습하고 적용하는 방법을 배울 수 있었습니다.
또한, 새로운 리액트 기술들인 Context와 Suspense, Error Boundaries에 대한 학습과 적용도 진행하며 기존 코드를 더욱 개선하는 경험을 할 수 있었습니다.
동료들과 함께한 다양한 활동들
기술 온보딩의 소통 지향, 현업 연계라는 특징이 있습니다. 이와 관련해 FE 개발자들은 페어 세션, 그룹 피어 세션, 코드 리뷰, 미니 세미나, 스터디 세미나와 같이 다양한 활동을 진행했습니다. 이러한 활동을 하면서 소통 능력을 향상시킬 수 있었고 좀 더 현업과 가까운 코드를 작성할 수 있었습니다.
페어 세션
페어 세션은 다른 동료 한 명과 함께 페어 프로그래밍을 진행하거나 기술 내용을 공유할 수 있는 활동이었습니다.
페어 세션을 통해 코드 작성에 대한 기술적인 측면 뿐만 아니라, 커뮤니케이션과 협력에 대한 측면에서도 많은 것을 얻을 수 있었습니다. 코드 작성을 지시하거나 지시대로 코드를 작성하는 역할을 번갈아 가며 수행했습니다. 그 과정을 통해 자신의 의도를 명확하게 표현하거나, 상대방의 의도를 파악하는 경험을 할 수 있었습니다. 코드 작성에 유용한 단축키를 공유하고, 좋은 코드에 대한 의견을 교환하면서 동료와의 신뢰도와 협업력이 향상될 수 있었습니다. 페어 세션의 경험들은 좋은 FE 개발자로 성장하는 데 유익한 시간이었다고 생각합니다.
그룹 피어 세션
그룹 피어 세션은 네 명의 동료가 한자리에 모여 기술 내용을 공유할 수 있는 활동이었습니다.
주로 미션을 진행하면서 겪은 시행착오를 말하거나 새롭게 학습한 내용 중 유용하다고 생각되는 것을 공유하는 시간을 가질 수 있었습니다.
같은 목표가 있어도 개발자마다 목표를 달성하기 위한 구현 방식은 달라집니다. 다른 동료가 겪은 시행착오를 공유받으며 생각을 많이 확장할 수 있었다고 회고합니다. 뿐만 아니라, 다수의 인원이 대화에 참여하는 상황에서 참여자 모두를 고려해 기술적 관심사를 모으고 대화를 이어 나가는 연습도 할 수 있었다는 점에서 또 다른 의미를 가지는 값진 활동이었습니다.
코드 리뷰
코드 리뷰는 미션을 구현하면서 작성한 코드에 대한 피드백을 받을 수 있는 활동이었습니다.
위에서 잠깐 언급했듯이 각 신입 FE 개발자들이 추후 일하게 될 부서의 현업자 분들께서 코드 리뷰어의 역할을 맡아주셨습니다.
코드 리뷰는 들여쓰기 사이즈부터 시작해서 변수 네이밍, 모듈 구성, 클래스 설계, 심화 기술 적용 등등 다양한 측면에 대해 양질의 피드백을 받을 수 있을 뿐만 아니라 궁금한 내용을 질문하고 명쾌하게 해소할 수 있었던 시간으로 회고합니다.
가끔씩 작성된 코드에 대한 질문을 역으로 받기도 했는데요, 이에 대해 명확하게 답변하려고 노력하면서 소통하는 능력 또한 많이 향상할 수 있었다고 생각합니다. 코드 리뷰는 앞서 설명드린 다른 활동들과 달리 텍스트로, 더군다나 비동기적으로 소통이 이뤄진다는 특징을 가집니다. 그래서 그런지 상대방의 입장을 더 많이 고민하며 조심스럽게 텍스트를 작성했던 기억이 있습니다.
제 코드 리뷰어께서 종종 내주신 기술적 수수께끼들도 소개하고 싶은데요. No newline at end of file, 모듈 간 의존성 줄이기 등등 작성한 코드와 관련해서 한 번쯤 고민해보면 좋을 내용에 대해 흥미롭게 언급해주셨습니다. 덕분에 저는 FE 기술 온보딩 동안 정말 즐겁게 고민하며 코드 리뷰 활동을 진행할 수 있었다고 생각합니다.
미니 세미나
매주 마지막 날에 진행한 미니 세미나는 모든 동료들이 번갈아 가며 한 주 동안의 주된 경험을 말하는 활동입니다. 지난 시간을 회고할 수 있는 기회를 만들어주기도 했고, 값진 내용을 추출하고 정리해서 공유할 수 있는 기회를 만들어주기도 했던 뜻깊은 활동으로 회고합니다.
스터디 세미나
저희 신입 FE 개발자들은 주어진 활동들에 만족하지 않고 별도의 활동을 만들어 진행하기도 했는데요, 자유로운 기술 주제로 30분씩 발표를 진행하고 함께 토론하는 활동인 스터디 세미나를 소개하고 싶습니다.
스터디 세미나는 수 차례 진행됐고 그 동안 Django, 크롬 개발자 도구 분석, TypeScript, React Error Boundaries 적용 사례, Github Actions, React useReducer 분석 등 정말 다양한 기술 주제가 나왔습니다. 학습과 공유에 진심인 동료들과 함께라서 정말 많은 것을 배우고 느낄 수 있었다고 회고합니다.
신입 FE 개발자들의 말말말
지금까지 제가 경험한 FE 기술 온보딩에 대해 소개해드렸는데요.
6주 동안 함께한 다른 동료들은 FE 기술 온보딩을 어떻게 느꼈는지, 그 소감을 들어보지 않을 수가 없겠죠! KPT 회고 방식과 유사하게 ‘좋았던 점, 아쉬웠던 점, FE 기술 온보딩을 다시 한다면?’ 순으로 동료들에게 한 번 물어봤습니다.
좋았던 점
아쉬웠던 점
FE 기술 온보딩을 다시 한다면?
마지막 한마디
마치며
못다 한 이야기가 많아 아쉽지만 이만 글을 마치려고 합니다.
이 글을 작성하면서 6주 동안의 소중한 시간을 되돌아보고 정리할 수 있었네요.
곱씹으면 곱씹을수록 성장하기 너무나 좋았던 시간으로 여겨집니다.
멋진 동료들이 함께 했고, 카카오 내부 감수자 및 코드 리뷰어 분들 그리고 코드스테이츠 교수자 및 운영자 분들의 많은 지원이 있었기 때문이겠죠!
FE 기술 온보딩 내내 곁에서 많은 지원을 해주신 김진웅 님, 강은정 님, 안재원 님, jake, elphie 정말 수고 많으셨습니다.
함께한 모든 동료들 hash, tori, kuma, hape, holly, joy, musc의 무궁한 발전을 기원하며 글을 마치겠습니다.
읽어주셔서 감사합니다!
