[회고] 우아한테크코스 Level 2 1~4주차 회고

방학 일주일 동안 글을 두 편 썼다. 하나는 함수형에 관한 글이고, 다른 하나는 Claude에 관한 글이다. 그리고 쓰는 내내 내가 글쓰기에 재능이 없다는 걸 절실히 느꼈다. 아마 평소에 글을 자주 쓰지 않아서일 거다.

사실 나는 원래 이런 종류의 글쓰기를 좋아하지 않았다. 전문 지식을 단순히 나열하는 글이라면, 내가 쓴들 AI가 뱉어주거나 구글이 알려주는 것 이상으로 잘 전달될 수 있을까 싶었다. 내가 쓴 개념 글들이 누군가에게 유용할 수 있을까..? 나는 아니라고 생각했었다.

그런데 막상 써보니 생각이 조금 달라졌다. 독자의 입장에서 보면 문장 하나, 자료 하나하나에 정성을 들여야 했다. 어떻게 전개해야 내가 전달하려는 결론까지 논리적으로 이어질까? 지금 내가 펼치는 논리에 빈틈은 없을까? 이런 것들을 계속 고민하게 됐다. 그리고 그렇게 쓰다 보니 내가 어떤 개념을 어설프게 알고 있었는지도 드러났다.

그래서 태도를 바꾸기로 했다. 글을 자주 쓰자. 미뤄두기만 했던 블로그 리모델링도 빨리 해보고 앞으로는 많은 글을 써보고자 한다.

"송곳으로 판다"는 게 대체 무엇일까. 원정대를 시작하면서 이 말을 두고 정말 많은 생각을 했다.

원정대는 일단 스터디의 일종이라고 생각한다. 다만 보통의 스터디와 달리 뚜렷한 목표가 있고, 해야 할 일이 있다. 공부 방식은 함께, 그리고 전투적으로. 공부 범위는 좁고 깊게. 마무리는 공유와 전이로. 내가 그동안 해오던 스터디와는 확실히 다른 느낌이었다.

그래서 송곳으로 판다는 게 무엇을 의미하는지는 솔직히 아직도 답을 모르겠다. 일단은 좁은 범위에서 공부하고 싶은 것을 한없이 깊게 파보기로 했다. 우리가 고른 주제는 리액트 렌더링 파이프라인과 VDOM이었다. 리액트의 어떤 부분을 공부하더라도 렌더링은 그 근간이 되는 지식이라고 생각해서 이걸 골랐다.

진행은 매일 2시간씩 대면으로 만나서 했다. 방식은 이랬다.

• 매일 그날 공부할 내용에 대한 질문을 하나 정한다. 예를 들면 이런 것들이다.
  • "브라우저 렌더링 파이프라인에서 어떤 연산이 비쌀까?"
  • "리액트는 비싼 연산을 어떻게 해결할까?"
  • "렌더 단계와 커밋 단계는 왜 나뉘어 있을까?"
  • 등등..
• 그 답을 내리기 위해 수단과 방법을 가리지 않고 30분 동안 공부한다.
• 30분 뒤에는 발표자 한 명을 정해 자신이 공부한 내용과 함께 내린 답을 공유한다.
• 그 과정에서 다른 사람들이 설명을 덧붙이거나 질문을 던진다.
• 나온 질문들은 대부분 바로 답하기 어려운 것들이라, 이 부분을 10분 정도 다시 전투적으로 공부한 뒤 공유한다.
• 마지막은 꼭 회고로 마무리한다.

사실 어쩌면 이렇게 많은 시간과 열정을 투자해서 얻은 이 지식(리액트의 렌더링 과정을 파이버 레벨에서 이해하는 것)을 쌓았다고 해서 실제로 내가 개발함에 있어서 많은 도움을 얻을 수 있을까? 그 어느 프론트엔드 개발자에게 물어봐도 답은 "그렇지 않을 것"이라고 말할 것이다. 그럼에도 원정대 활동의 만족도는 무척 높았다. 얻어가는 것이 많았고, 함께한 2시간이 정말 효율적이고 알찼다고 생각하고 있다.

왜 실용성도 없는 공부가 그렇게 값지게 느껴졌을까. 원정대 활동이 끝나갈 시점에 시지프와 크루들이 작은강의실에 모여 다같이 실용 vs 이론을 두고 이야기를 나눴다. 시지프는 당시 써먹을 수 있는 걸 배워야 한다고 말했다. VDOM이나 fiber, 렌더 단계는 솔직히 현업에서 그대로 꺼내 쓸 개념은 아니긴 하다. 그럼에도 그날 내가 내린 답은 좀 달랐다. 개념 자체야 어차피 인간이 망각하니 필요하면 AI한테 물어보면 된다. 정작 남는 건 그 개념이 나오기까지 누군가 문제를 정의하고 풀어낸 사고 과정이고, 그걸 좁게 함께 파면서 "왜"를 계속 던져본 게 이번 원정대에서 얻어가는 것이지 않았을까 싶다.

이번 활동을 하면서 몇 가지를 깨달았다. 함께 무언가를 진행할 때는 무조건 타임박싱이 필요하다는 것. 그리고 각 타임박스마다 정확한 목표점, 혹은 그 시간이 끝난 뒤에 기대하는 모습이 분명해야 한다는 것. 공부의 효율을 위해서는 어느 정도의 긴장감이 필요하다는 것이다.

타임박싱이 유독 나한테 잘 들었던 건, 결국 긴장감을 만들어주는 장치였기 때문인 것 같다. 끊어주니까 늘어지지 않았다. 힘들수록 작은 습관이나 구조를 더 악착같이 지켜야 한다고 평소에 생각해왔는데, 원정대가 힘들 때 나를 붙잡아준 게 바로 그 타임박싱이라는 구조였다.

초반 프론트 수업에서 대 AI 시대에 우리가 집중해야 하는 것이 무엇일지에 대한 많은 인사이트를 얻을 수 있었다. 현업의 일의 구성요소를 나누어 보면 사람도 있고, 여러 도구와 코드, 공식문서나 명세와 같이 믿을 수 있는 정보의 원천들, 그리고 그 사이에 AI가 있다. 앞으로 AI가 차지하는 비중은 점점 커질 것이다. 그렇다고 사람의 역할이 사라지는 건 아니고, 비중이 달라질 뿐이라는 이야기였다.

그래서 사람이 잘하는 게 뭔지를 다시 생각해보게 됐다. LLM과 달리 사람은 적은 데이터만 가지고도 거기서 의미를 찾아내고, 한 단계 더 나아간 추론을 한다. 이게 우리의 영역이고, 사람이 잘하는 부분이다. 그렇다면 사람만이 할 수 있는 걸 더 잘하는 쪽으로 가야 한다.

그 연습으로 가추법으로 읽는 훈련을 해보기로 했다. 적게 읽고 더 많이 생각해보는 것이다. 문장 하나하나를 그냥 받아들이지 않고 의심해보고, 왜 이렇게 했을까 하는 질문을 던지면서 읽는다. 이런 식으로 읽는 근육을 만들어보자는 거다.

마침 스토리북 공식문서로 연습해봤다. 랜딩 페이지 하나만 가추법으로 읽었는데도 머리가 뜨거워졌다. 그런데 의외로 나와 잘 맞았다. 생각해보면 나는 원래 공식문서를 이런 식으로 자주 읽어온 편이었다. (물론 늘 이렇게 읽는 건 아니고, 읽는 목적에 따라 방식을 달리하기도 한다.)

사실 이번 글에서 여러 번 언급하겠지만, 지식을 얻는 것은 너무나도 싼 활동이라고 생각한다. 인터넷이 발전하고 검색엔진이 나오고, 심지어는 이제 명확한 용어나 노하우를 통해 검색으로 정보를 얻던 시대에서 아무 말이나 해도 잘 알아듣고 내 맞춤으로 설명해주는 AI가 있기에 지식 자체의 가치는 많이 떨어진다고 생각한다. 우리가 집중해야 하는 것은 지식을 습득하는 것, 문제를 잘 정의하는 것, 그리고 이를 우리의 기술로 지혜롭게 해결하는 일일 것이다.

이와 관련해서 앞으로 남은 우아한테크코스 기간을 잘 보내려면 어떻게 해야 할지, 현업 시니어 개발자이자 교육자인 준의 인사이트를 얻고자 원온원을 신청했다.

준과의 첫 원온원이었다. 원래는 레벨 1 때 일정을 잡으려 했는데 서로 일정이 안 맞아 자꾸 미뤄졌고, 결국 레벨 2 첫 주가 되어서야 마주 앉을 수 있었다.

가져간 고민은 "좋은 개발자가 되려면 어떻게 해야 할까."였다. 나는 개발자를 문제를 올바르게 정의하고 그걸 지혜롭게 풀어내는 사람이라고 본다. 그러니 좋은 개발자란 이 두 가지를 잘하는 사람일 거다. 그렇다면 그걸 어떻게 잘하지? 남은 우아한테크코스 기간을 나는 어떻게 살아야 하지? 에 대한 답을 얻고자 준을 찾아가게 됐다.

하지만 준은 답을 주지 않았다. 대신 내가 스스로 길을 찾을 수 있도록 질문을 던졌다. 문제의 밑바닥을 짚어주면서 옆에서 길만 터주는 식이었다. 지금 와서 정리해보면 이런 단계였다.

• 되고 싶은 모습이 뭔지 먼저 그려본다.
• 그 모습을 위해 지금까지 해본 것들을 떠올린다. 별로였다면, 왜 별로였는지까지.
• 욕심내지 말고 딱 한 단계만 더 나아간다.
• 지금 이 모습을 그대로 유지하면 되고 싶은 모습에 닿을 수 있나? 닿는다면 그 확률은 얼마쯤일까?
• 그 확률을 단 1%라도 올리려면 뭘 해야 할까?
• 그래서 이번 주말에 당장 할 수 있는, 아주 작은 액션 아이템 하나를 정한다.

나는 액션 아이템으로 "내가 생각하는 멋진 개발자들의 컨퍼런스 발표를 두루 모아 AI를 활용해 좋은 개발자들이 문제를 어떻게 정의하고 어떻게 풀어내는지, 그 패턴을 뽑아내보고 정리해서 좋은 개발자 핸드북 같은 가이드를 만든다"를 정했다. 그리고 원온원을 하고 있는 그 자리에서 이렇게 정한 액션 아이템을 무조건 주말 내로 지킬 수 있도록 슬랙 예약 메시지로 걸어버렸다.

그렇게 예약 메시지를 걸어둔 덕에 도망갈 수 없었고, 주말 동안 컨퍼런스 발표 몇 개를 골라 AI에게 패턴을 분석시키고 정리해서 레포지토리 하나를 만들었다.

결과물은 여기에 있다. good-developer-handbook

이번 원온원을 하면서 문제를 잘 푸는 것 이전에, 페인 포인트를 먼저 관찰하는 게 먼저라는 것을 배웠다. 어디가 아픈지부터 봐야 한다는 것. 준이 원온원 내내 말하던 것도 결국 이거였고, 컨퍼런스 발표자들이 문제를 다루는 패턴을 모아놓고 봐도 출발점은 늘 관찰이었다. 관찰을 잘하는 개발자가 결국에는 문제 정의를 잘하고, 또 문제를 잘 해결할 수 있다. 앞으로 이 관찰하는 힘을 길러보아야 할 것 같다.

이번 미션은 Level 1과는 다르게 총 3단계까지 이어졌다. 단계가 올라갈수록 요구사항도 무거워졌고, 특히나 이번 미션은 프론트엔드 개발자로서 너무나도 악마 같은 요구사항이었다고 생각한다. 🥲

관련 PR : react-payments #517

리액트 난이도 자체는 어렵지 않았다. 간단한 폼을 구현하는 정도였으니까.

다만 페어가 리액트 경험이 없었다. 경험 차가 있는 만큼 우리 둘 사이 어디쯤에서 결과물이 나올지가 궁금하기도 했지만, 한편으로는 최대한 페어가 부담을 느끼지 않기를 바랐다. 이번 페어 프로그래밍을 하면서 가장 신경 쓴 부분이기도 했다.

진행은 계속 질문을 던지는 식으로 했다. "지금 문제 상황은 이렇고, 우리 목표는 이거다. 이를 해결하기 위해서는 두 가지 방안이 있다. 그중 A안은 이런 장단점이 있고, B안은 이렇다. 이때 우리는 어디로 가는 게 좋을까?"와 같은 형식으로, 내가 알고 있는 지식을 최대한 꺼내고 공유해서 서로의 지식의 위치를 맞춘 후, 하나의 문제를 바라보고 함께 고민해보는 형식으로 진행했다.

생각보다 이 방식이 지식의 간극이 있는 팀원과 논의를 해야 할 때 정말 좋은 방안이라는 생각이 들었다. 아마 앞으로도 팀원들과 함께 어떤 결정을 내려야 하는 상황 속에서 내가 말을 이끌어야 할 때 이 방식을 잘 활용할 것 같다.

추가적으로 오버엔지니어링도 경계하려고 정말 많은 노력을 했다. 혼자였으면 더 욕심냈을 거지만, 페어가 얻어갈 수 있을 정도만 가져가는 것이 당시 상황에서는 좋아 보였다. 이때 오버엔지니어링의 기준을 잡는 것 또한 어려웠다. 처음으로 가져간 기준은 "우리가 이것을 엔지니어링했을 때 시간 내에 개발이 가능할까?"로 정했다. 초반에는 프론트 수업 때 항상 강조하시던 도메인과 UI의 분리를 하나의 기준으로 컴포넌트를 나누자 정도로만 추상화의 기준을 가져갔고, 미션을 전부 다 마칠 정도가 됐을 때 조금씩 내 욕심을 드러내면서 이런 것도 만들어보는 건 어떤지 이야기를 했다.

그렇게 만들어진 게 <SwitchCase/>였다.

interface CaseBy<T> {
  case: T;
  component: React.ReactNode;
}
 
interface SwitchCaseProps<T> {
  value: T;
  caseBy: CaseBy<T>[];
  defaultCase?: React.ReactNode;
}
 
const SwitchCase = <T,>({ value, caseBy, defaultCase }: SwitchCaseProps<T>) => {
  // value와 일치하는 case를 찾아 해당 컴포넌트를 렌더링한다.
  const caseComponent = caseBy.find(
    ({ case: caseValue }) => caseValue === value,
  )?.component;
 
  // 일치하는 case가 없으면 defaultCase, 그것도 없으면 아무것도 렌더링하지 않는다.
  return <div>{caseComponent || defaultCase || null}</div>;
};
 
export default SwitchCase;

해당 컴포넌트를 만들기로 주장했던 이유는 아래와 같다.

• 리액트는 JSX 문법을 통해서 UI 자체를 선언적으로 작성할 수 있게 도와준다. 하지만 해당 흐름에 삼항 연산자가 들어가게 되면 "언제 어떻게 보이지?"라는 흐름이 들어가게 된다. *"컴포넌트의 return문 부분은 선언적일 거야"*라고 믿고 넘기는 일반적인 리액트 개발자의 의식의 흐름을 중단하고, 코드의 흐름을 하나씩 따라가며 이해해야만 하는 문제가 발생한다.
• JSX 문법에 JS 문법이 그대로 노출돼 있으면 일관된 추상화의 레벨이 지켜지지 않아, 코드를 읽어 내려감에 아주 약간이라도 JS의 동작 흐름으로 생각을 전환하는 비용이 발생하게 된다. 모든 것이 JSX였다면 이 조금의 비용도 줄일 수 있다.
• 조건부 렌더링 또한 하나의 책임이다. 하나의 컴포넌트에 해당 흐름이 있다면 그것만으로 책임이 두 개 이상이 되며, 해당 컴포넌트를 수정해야 할 이유가 많아지고, 변경/재사용/확장에 유연하지 못하게 된다.

사실 이에 대해서는 현업 개발자들도 많은 긍정/부정 의견이 대립하고 있다.

관련 논의 : Toss frontend-fundamentals discussions #4

리뷰어도 <SwitchCase/> 코드를 보고 내 추상화 기준에 대해서 물어보기도 했다.

돌이켜보면, 오버엔지니어링에 대한 기준이 조금 더 정량적인 방향이었으면 좋았겠다는 생각이 들었다. 다음에 일정이 정해진 개발을 진행해야 할 때에는 재사용 횟수와 같은 명확한 기준을 잡고 가야 할 것 같다.

관련 PR : react-payments #548

2단계.. 요구사항이 정말 많았고, 어려웠다.

먼저 컴포넌트 분리부터 손을 댔다. 도메인 로직과 UI 로직을 분리하면 변경에 용이하다는 말을 듣고, 그 영향을 받아 컴포넌트를 나눌 때 최대한 도메인을 덜어내려고 했다. 도메인을 덜어낸 컴포넌트가 어디 갖다 써도 무리가 없다고 봤다. 그래서 components/common에는 도메인 없는 컴포넌트를, components/feature에는 도메인 있는 컴포넌트를 두는 식으로 폴더를 나눴다. 도메인이 있는 쪽은 공통 컴포넌트를 가져와 거기에 도메인을 붙여서 썼다. 이렇게 컴포넌트를 분리해두고 보니 생각보다 수정사항을 반영하기가 쉬웠던 것 같다(아마도..?). UI만, 혹은 비즈니스 로직만 따로 떼어내 손볼 수 있었던 것 같다.

그다음은 커스텀 훅이었다. "반복되는 로직을 custom hook으로 분리했는가?"라는 요구사항을 만족시키려다 보니, 무엇이 반복되는지, 무엇이 반복될 수 있는지를 깊이 들여다보게 됐다. 그러다 리액트에서 가장 많이 쓰는 훅인 useState가 어떻게 프로그램 전역에서 재사용되는지를 생각해봤다. useState는 도메인을 넣어주거나 로직 등을 넣어서 사용하는 곳에 맞추어서 사용이 가능하다는 특징이 있다. 확실히 각 컴포넌트의 필요에 맞게 도메인과 규칙을 덧붙일 수 있도록 만드는 편이 여기저기 가져다 쓰기 좋다는 결론을 내리게 됐다. 도메인을 제거한 훅을 만들자라는 기준을 가지고 커스텀 훅을 만들어 봤다. 그렇게 만든 게 useFocus와 useFormWrapper다. useFocus는 input의 형태나 개수, 도메인에 상관없이 포커스를 옮겨주고, useFormWrapper는 어떤 폼이든 상태만 받아서 관리한다.

결론적으로 step 2 미션을 하면서 컴포넌트든 훅이든 도메인을 잘 분리하는 방식이 정말 중요하구나를 깨달았던 것 같다. 도메인이 격리되어야 재사용성적인 측면에서도, 변경/확장에도 유연한 코드가 될 수 있다는 것을 느낄 수 있었다.

사실 이 미션을 진행하기 이전에 이러한 방식으로 리액트를 사용해오고 있긴 했었다. 예전에 EEOS 프로젝트를 진행하고 있을 때 운이 좋게도 사용자를 유치할 수 있었고, 그만큼 정말 빠르고 예측 불가능하게 요구사항이 추가/변경되는 경험을 했었다. 이때 개발자의 입장에서 코드 변경의 비용을 줄이기 위해서 Toss Slash 영상을 보고 한번 적용을 해보고자 했었다.

지속 가능한 성장과 컴포넌트 컴포넌트를 바라보는 다양한 관점이 존재하겠지만, Headless 관점으로 바라보고 도메인을 격리시킬 수 있다면 훨씬 유연한 코드가 될 수 있다는 내용이었다.

물론 당시에도 정말 미숙한 실력이었지만, 이렇게 얻은 통찰을 바탕으로 발표도 진행했었다.

발표 링크 당시 음향 이슈가 있어서 스크립트 위주로 봐주세요!

뭔가 이번 step 2는 내가 컴포넌트를 바라보고 추상화 레벨을 가져가는 방식이 그래도 어느 정도 괜찮은 방법이구나를 느낄 수 있는 시간이었던 것 같다.

다만 아직까지 풀리지 않는 부분으로는, 어디까지가 도메인인지는 아직까지 잘 와닿지 않는 것 같다. 예를 들어 <Card/> UI 컴포넌트는 카드라는 도메인을 가지고 있는 것이 아닐까? 도메인 규칙과 비즈니스의 차이는 무엇일까? 이 규칙들 속에서도 다시 도메인이 아닌 규칙 함수로 나눌 수 있을까? 그렇다면 각각의 함수들은 어느 레벨의 컴포넌트에서 가져와 사용해야 할까? 이러한 질문들은 아마 차차 타 크루들과 이야기해보면서, 그리고 미션을 진행하면서 나만의 답을 내려갈 생각이다.

폴더 구조도 한 번 더 고민했다. 특정 컴포넌트에서만 쓰이는 util이나 type, hook, 작은 컴포넌트들이 일반 폴더에 흩어져 있으면 마음이 불편했다. 다른 컴포넌트가 그걸 잘못 가져다 쓸 수도 있는데, 해당 코드를 고치고 나서 어디까지 영향이 갔는지 가늠하기도 어려울 것이라 생각했다. 그래서 특정 컴포넌트 전용 코드는 그 컴포넌트와 같은 레벨, 혹은 더 깊은 레벨에 함께 두는 colocation 패턴으로 구조를 잡았다. 예를 들면 CardInfoFormSection/components/CardNumberInputField/ 아래에 utils.ts, types.ts, errorMessage.ts를 같이 두는 식이다. 리뷰어가 colocation 원칙에 잘 맞는 구조이고, 어느 정도 장단이 있는 방식이라고 말씀해주셨다. 폴더 구조를 가져가는 것에 대해서는 조금 더 많은 경험을 통해서 이 또한 나만의 방법을 정해야 할 것 같다.

부가적으로 step 1과 조금 다르게 추상화를 대하는 태도를 다르게 가져갔다. 이전 step 1에서는 "절대로 오버엔지니어링을 하지 말자"로 갔지만, 이번에는 "최대한 오버엔지니어링 해보자"로 방향성을 잡고 진행했다. 결국에는 내가 시도한 만큼 미션에서 얻어갈 수 있을 것이라 생각했다. 그렇기에 "이 정도면 괜찮다"의 태도를 최대한 경계하고, 최대한 내가 할 수 있는 만큼 노력해서 해보자라는 생각으로 진행해보았다.

그렇게 탄생한 게 StepFunnel이다. 퍼널 형태이지만, step을 지정할 때 순서만 존재하는 형식으로 구현을 해봤다.

관련 변경 : StepFunnel diff

이 구조를 두고 다른 크루가 PR 코멘트에서 멋지다고 해줬는데, 솔직히 꽤 기분 좋았다.

평화롭게 밥 먹고, 커피 한 잔 들고 캠퍼스 주변을 크루들과 산책하던 중에 리액트 미션 이야기가 나왔다. 다들 리액트가 처음이거나 경험이 많지 않다 보니 컴포넌트를 어떻게 나눌지를 두고 생각이 많았다.

그런데 이러한 이야기가 도무지 끝날 기미가 안 보였다. 아무래도 코드를 말로만 설명하다 보니 서로의 생각이 잘 전달되지 않는 것도 있고, 머릿속에 잘 안 잡히는 것도 있었던 것 같다. 그래서 내가 "각자 라이브 코딩하면서 그 기준을 설명해보는 거 어떠신가요?" 하고 던졌다. 그 자리에서 노트북을 열고 회의실을 잡았다.

질문은 두 개로 모였다. 컴포넌트의 추상화 레벨은 어디까지 가져가야 하나. 그리고 그 추상화의 기준은 뭔가. 일단 각자 30분 동안 설명할 수 있을 정도로 코딩을 진행한 이후 한 명씩 설명하는 시간을 가졌다.

내 관점은 비교적 확고한 편이었다. 위에서 작성했듯 나는 무조건 도메인부터 나눈다. 도메인 단위로 먼저 가르고, 그 안에 도메인이 없는 내부 로직과 UI가 따로 존재한다. 그리고 모든 컴포넌트는 자기보다 한 단계 아래 레벨에만 의존하게 둔다. UI는 다시 레이아웃과 UI 둘로 쪼갠다. 단, UI 컴포넌트끼리는 서로 호출할 수 있게 열어둔다. 위에서 아래로 흐르는 의존성은 지키되, 같은 층 안에서는 좀 풀어주는 셈이다.

들어보니 다들 기준이 정말 달랐다. 같은 미션인데 이렇게까지 다양한 방식이 나올수고 있구나 싶기도 했다. 그중 인상 깊었던 건 공통 컴포넌트로 둘지 말지 애매한 요소를 다루는 방식이었다. 가령 이게 헤딩이어야 하나 그냥 span이어야 하나 싶을 때, .태그 형식으로 호출해서 쓰던 방식. 그 작은 처리 하나가 오래 남았다.

워킹그룹을 돌아보면 라이브 코딩 자체는 좋았다. 다만 시간이 빠듯해서 설명이 조금 두루뭉술해진 부분이 아쉽기도 했다. 기준 코드를 잡은 점은 좋았다. 덕분에 서로가 이야기하는 코드가 비슷했고, 이해하는 비용을 줄일 수 있었다. 다음에 워킹그룹을 열게 된다면 차라리 라이브 코딩보다는 코드를 미리 가져와서, 페어 프로그래밍 방식으로 구성해서 열어볼 생각이다.

이번 Level 2 기간 동안 리액트를 조금 깊이감 있게 동작 원리까지 공부하고자 했고, 스터디를 만들어보았다. 책은 모던 리액트 Deep Dive로 잡았다. 스터디 진행은 책을 한 주 동안 읽어오고, 돌아가면서 릴레이로 설명하는 방식이었다.

그런데 생각보다 스터디 초반에는 이 릴레이가 잘 안 지켜졌다. 다들 공부하는 관점이 다르고 방식도 다르니까, 발표도 제각각으로 흘렀다.

사실 이렇게 스터디를 진행하는 방식은 내가 우아한테크코스에 오기 이전 시절, 동아리 내에서 내가 운영하던 스터디에서 여러 차례 수정해서 정착된 방식이다. 당시에는 너무나도 이 릴레이가 잘 이뤄졌는데, 정말 똑똑하고 공부 열심히 하는 우아한테크코스 크루들에게 오히려 전혀 맞지 않는 방식이었다.

처음에는 왜 이렇게 된 거지? 하며 혼자서 고민했었는데, 이게 꼭 단점만은 아닌 것 같기도 하다. 우아한테크코스 사람들은 본인만의 정답을 찾아 헤매는 데 익숙하다. 누가 떠먹여주길 기다리지 않고 스스로 들이받으며 배우는, 말하자면 야생학습에 길들여진 사람들이다. 그러니 발표가 정돈되지 않는 게 어쩌면 당연했다.

또한 어쩌면 그동안 나는 전투적이지 않은 학습을 해왔던 것 같다. 누가 깔아준 길을 따라 얌전히 걸었지, 스스로 부딪혀 길을 내본 적은 없었다. 앞으로 회고하면서 그 방향성을 조금씩 잡아가보려 한다.

사실 이 글을 쓰고 있는 시점은 우아한테크코스 Level 2 4주가 지난 지 3주가 된 시점이다. 그동안 너무나도 바쁘게 살아가는 것 같기도 하다. 미션도 그렇고 원정대와 스터디 2개, 우아한테크코스 이외에도 나는 사이드 프로젝트도 2개를 병렬로 돌리고 있으니까(물론 이때는 개발자가 크게 바쁘지 않은 시점이었다)..

너무 정신없고 할 일 처내기 바쁜 삶을 살아가다 보니, 언젠가는 길을 잃고 방황하며 기대하는 바를 얻지 못한 경우에는 지쳐 열정이 식을 수도 있을 것 같은 두려움도 없지 않아 있기도 하다.

그래도 이 열정 잃지 않고, 남은 Level 2 일정을 잘 마무리하고 엄청나게 성장한 내 모습을 기대하면서 남은 기간도 잘 달려가보려고 한다!