[회고] 우아한테크코스 7, 8주차 회고

역시나 열심히 달려왔던 2주였다. 특히나 이번 7, 8주차의 수업이 정말 인상이 깊었다.

내가 모르던 하드 스킬적인 부분뿐만 아니라 앞으로의 성장 방향성, 공부 방식과 가치관, 소프트 스킬 등에 대한 인사이트를 정말 많이 얻을 수 있었다. 그래서 이번 회고는 미션 그 자체보다는, 수업과 대화 속에서 내가 흔들리고 다시 세워졌던 생각들을 위주로 정리해보려고 한다.

7주차에는 비동기와 이벤트 루프에 대한 수업을 받았다.

나는 js를 처음 쓰기 시작한 지 햇수로만 보면 4년 가까이 되는 사람으로서, 얼추 이벤트 루프의 동작 방식이나 callback, Promise, async/await 코드를 사용하는 방법을 이미 알고 있다고 생각하고 있었다. 하지만 이번 수업을 들으면서 정말 내가 부족하다는 것을 뼈저리게 느끼게 되었다.

수업에서는 예시 코드가 어떤 절차로 콜 스택, Web APIs, 매크로/마이크로 태스크 큐에 들어가는지 그 절차를 먼저 직접 작성해보고, 페어와 이야기를 나눠보는 시간이 있었다. 나는 너무 쉽다는 생각으로 답안을 거침없이 작성해갔다. 그런데 페어와 이야기를 해보니, 생각보다 내가 잘못 알고 있던 부분, 그리고 아예 알지 못하는 부분이 많다는 것을 알게 되었다.

우선 나는 어떤 API들이 Web APIs로 이동하여 다른 곳에서 처리되는지를 제대로 구분하지 못하고 있었다. Web API를 호출한 경우, 그 동작과 콜백을 호스트로 전달하게 되고, 이를 브라우저(혹은 노드 런타임)에서 따로 처리하게 된다. 그런데 나는 여기서 무엇이 Web API인지를 구분하지 못했던 것 같다. Promise와 같은 비동기 내장 객체를 호출하는 경우에도 Web API로 이동하는 것으로 잘못 알고 있었다. (Promise는 Web API를 거치지 않고 바로 마이크로 태스크 큐로 향한다.)

그뿐만이 아니었다. 큐에는 콜백 자체가 쌓이는 것인지 혹은 콜백 내부의 코드들이 쌓이는 것인지, Promise.resolve를 하는 경우 힙 메모리에 객체가 만들어지는 과정은 어떻게 되는지, async/await의 경우에는 어떤 코드가 큐에 들어가는지 등등. 평소라면 그냥 넘어갔을 질문들을 페어와 정말 많이 주고받았다.

수업 시간에 이 궁금증을 전부 해결하지 못해서, 몇몇 크루들과 함께 회의실을 잡아 직접 그림을 그리고 예시 코드를 만들어 디버깅 도구를 돌려보면서 하나하나 확인해보기도 했다.

이 과정에서 개념을 얻는 것을 넘어, 함께 공부하는 방식에 대해서도 많은 생각을 할 수 있었다.

• 내가 무엇을 모르는지를 알 수 있었다.
• 내가 잘못 알고 있던 것이 무엇인지 알 수 있었다.
• 내 지식을 직접 말로, 그림으로 꺼내보면서 온전히 내 것으로 만들어볼 수 있었다.

js에서는 비동기를 처리하는 방식으로 크게 callback, Promise, async/await 이 세 가지가 있다.

물론 js의 비동기 처리 방식은 시간이 지남에 따라 이전의 불편함을 해결하기 위해 새로운 방식이 만들어지는 방향으로 발전해왔다. 그럼에도 이전 방식이 여전히 살아남아 있다는 것은, 각각의 특성과 장단점이 있기 때문일 것이다.

이번 영화 리뷰 미션을 진행하면서 나는 fetcher라는 헬퍼를 두었다. 이는 fetch 비동기 함수를 처리할 때 success/loading/error 세 가지 상태에 따라 실행할 코드를 콜백으로 받아 실행해주는 헬퍼 함수였다. 나는 이를 비동기 함수의 상태 관리적인 부분만 깔끔하게 떼어낸, 꽤나 잘 추상화한 코드라고 생각했다. 가독성적으로도, 유지보수적으로도 이점이 있다면서 페어를 열심히 설득했었다. (지난 회고에서 페어와 한바탕했던 그 fetcher다..!)

하지만 이번에 시지프가 선언적인 코드와 async/await에 대해 진행한 라이브 코딩 수업을 보면서 많은 충격을 받게 되었다. 물론 상황마다 다르겠지만, 콜백을 사용했을 때의 문제점, 그러니까 콜백이 또 다른 콜백을 부르며 지옥에 빠질 수 있다는 점, 가독성이 떨어진다는 점, 코드 분리가 어렵다는 점을 설명하시면서, 고수의 코드를 async/await로 선언적으로 개선해나가는 모습을 보여주셨다.

이 설명을 듣고, 내가 그렇게 좋다고 주장했던 콜백 방식의 fetcher가 꼭 좋은 코드는 아닐 수 있겠구나를 느끼게 되었다.

엄청 충격을 받았다. 어떻게 보면 내 코딩 실력이 이 정도밖에 안 되는구나를 알게 된 시점이었던 것 같다. 그래도 덕분에, 내가 잘 알고 또 잘 사용하고 있다고 믿어왔던 비동기 방식에 대해 많이 부족함을 알게 되었고, 앞으로 어떤 공부를 어떻게 해나가야 할지를 알게 된 것 같다.

그리고.. 정말 겸손해져야겠다는 것을 깨달았다.

레벨 1 동안 총 3번의 페어 프로그래밍을 해보았다. 사실 우아한테크코스에 오기 이전에 여러 프로젝트를 해봤지만, 두 명이서 하나의 코드를 작성한 경험은 멘토링을 제외하고는 없었다.

다르게 말하면, 페어로 프로그래밍을 하는 행위 자체는 프로덕트를 만드는 개발자의 입장에서 어쩌면 크게 필요 없는 것일 수도 있다. 그럼에도 우아한테크코스에서 모든 미션을 페어로 진행하도록 하는 이유가 뭘까에 대해, 처음에는 많은 의문을 가졌었다. 하지만 레벨 1이 끝나가는 지금 시점에서 돌이켜보면, 그 안에서 느낀 많은 장점들이 존재했다.

우선 페어 프로그래밍으로 하드 스킬적인 큰 성장을 기대하기는 어렵다. 빨리 가려면 혼자, 멀리 가려면 함께라는 말처럼, 제한된 시간 내에 돌아가는 결과물을 내야 하는 상황에서 함께 하라는 것은 기술적으로 새로운 것을 배우거나 적용하는 데에 많은 제약이 따른다. 무엇인가를 시도하려면 내가 그것에 대한 근거를 먼저 빠르게 정리하고, 이를 바탕으로 페어를 설득해야 하는 정말 큰 비용이 발생한다.

반면 이런 불편함에 자주 노출되다 보니, 어떻게 해야 내 의견을 잘 정리할지, 그리고 그것을 어떻게 페어에게 전달해서 설득시킬지에 대해 고민하고 연습할 수 있었던 것 같다. 두 달 동안 같이 지낸 크루들 사이에서도 소프트 스킬적으로 뛰어나다고 이야기 나오는 크루들이 있는데, 나 또한 그 크루들의 모습을 최대한 흡수해서 멋진 개발자가 되려고 노력했다.

수업 시간에는 페어 프로그래밍과 관련한 내용도 있었다. 페어 프로그래밍은 하나의 작은 회의 상황과 같다. 그러므로 페어 프로그래밍을 잘한다는 것은, 어쩌면 회의를 잘 이끄는 사람이 되는 것과 같다.

회의를 잘 이끄는 사람의 특징이 있다면 절차적 회의 행동을 한다는 것이다. 예를 들면 아래와 같은 것들이다.

• 목표 지향(Goal orientation) : "좋아요, 그럼 주제로 돌아가서요."
• 분명히 하기(Clarifying) : "그 말씀은 본질적으로 OO이라는 거군요."
• 절차 제안(Procedural suggestion) : "우선 OO에 대해 이야기해볼까요?"
• 절차에 대한 질문(Procedural question) : "다음은 무엇을 해볼까요? 말씀하신 걸 한번 적어볼까요?"
• 우선순위(Prioritizing) : "지금 우리에게 OO가 가장 중요한 이슈 같네요."
• 시간 관리(Time management) : "이제 회의 시간이 5분 남아서 결정을 해야겠네요."
• 업무 배분(Task distribution) : "OO님이 이걸 화면에 띄워주시면 어떨까요?"
• 시각화(Visualizing) : (회의 아젠다를 화이트보드에 적는다.)
• 요약하기(Summary) : "그럼 지금까지 우리가 이야기한 건 OO이었네요."

이렇게 회의나 워크숍을 이끄는 사람을 퍼실리테이터라고 한다고 한다.

이러한 절차적 회의 행동들은 회의를 이끌어가는 포지션의 사람들이 할 수 있는 것들이라는 생각이 든다. 하지만 나를 되돌아보았을 때, 나는 아직 누군가를 이끄는 사람이라기보다는 팔로워십이 더 익숙한 사람인 것 같다. 그래서 앞으로는 페어 프로그래밍이라는 비교적 작은 단위뿐만 아니라, 더 넓은 범위의 협업까지 이끌어가보는 경험을 쌓아보려고 한다.

단순히 코드를 잘 작성하는 개발자가 아니라, 팀의 방향을 만들고 함께 문제를 풀어갈 수 있는 사람으로 성장할 수 있기를 바란다!

AI가 발전하고, 앞으로도 우리의 삶 전반에 큰 변화를 가져올 것이라는 점은 이제 너무나도 자명하다. 기술은 이미 빠른 속도로 우리의 일상과 학습, 그리고 일하는 방식에까지 깊숙이 스며들고 있고, 앞으로는 그 변화가 더욱 자연스러워질 것이다.

이런 흐름 속에서 AI라는 개념과 함께 IA라는 개념도 함께 떠올랐다. IA는 지식 증강이라는 의미를 가지며, 기술이 인간의 의사 결정이나 능력을 향상시키기 위한 도구로 사용되는 개념이라고 한다. 즉, 기술이 인간을 대체하는 방향만을 바라보는 것이 아니라, 인간이 더 잘 생각하고 더 잘 배우고 더 나은 판단을 할 수 있도록 돕는 방향으로도 충분히 이해할 수 있다는 것이다.

그래서 더 중요하게 느껴졌던 것은, AI가 우리 삶에 점점 더 자연스럽게 녹아드는 흐름 속에서 이를 피하거나 멀리 두기보다는, 오히려 나의 지식을 증강시키는 하나의 도구로 받아들이는 태도였다. 단순히 편리함을 누리는 수준을 넘어서, AI를 통해 더 많이 배우고 더 빠르게 이해하며 더 나은 방향으로 성장할 수 있어야 한다는 생각이 들었다.

결국 AI를 잘 활용해 내 지식을 증강시키는 능력 또한, 이 시대에서 뒤처지지 않고 빠르게 발전할 수 있는 사람이 되기 위한 중요한 조건이지 않을까 싶다.

우아한테크코스에서는 매 수업이 끝날 때마다 Q&A 질문을 익명으로 받는다. 이때 나에게 정말 인상이 깊었던 질문이 있었다.

"AI가 모든 것을 다 해주는 시대에, 우리는 꼭 기본기를 공부할 필요가 있을까?"

코치님은 이에 대해, 기본기를 어떻게 정의하는가에 따라 답이 달라질 수 있을 것 같다고 말씀해주셨다.

기본기라고 하면 흔히 JavaScript, React, TypeScript 같은 것을 떠올리기 쉽지만, 강의에서는 이것을 하나의 층으로 보지 않고 계층처럼 바라보고 있었다.

기본기 계층
- 최상위 : 문제 정의, 논리력, 학습력, 탐구력, 실행력
- 상위   : 설계 역량, 웹 환경에 대한 이해, 소프트웨어 개발에 대한 이해
- 중간   : JS, React, TS 에 대한 깊은 이해
- 하위   : axios, react-query, jotai 등 라이브러리 역량

이전에 켄트 백이 대부분 기술의 가치가 0달러가 됐고, 그중 일부의 가치는 1000달러가 됐다는 말을 했었는데, 여기서 대체될 수 있는 하위 계층의 기술들은 그 가치가 정말 낮아진다. 반대로 상위 계층에 있는 능력들은 더 중요해진다. 문제를 정의하고, 논리적으로 생각하고, 스스로 배우고 탐구하고, 실행하는 힘은 오히려 더 가치가 높아질 것이다.

그러면 이러한 고수준의 역량은 어떻게 기를 수 있을까? 이는 결국 하위 계층을 열심히 공부하고, 직접 부딪히고, 깊게 이해해본 경험이 있어야 자연스럽게 상위 계층을 키울 수 있다. 예를 들어 알고리즘 공부도 비슷하다는 생각이 들었다. 문제를 푸는 행위 자체가 중요한 것은 아닐 수 있다. 하지만 그 과정을 통해 사고력과 문제 해결력을 기를 수 있다면, 그 경험은 분명 의미가 있다. 결국 하위를 공부하는 이유는 하위에 머무르기 위해서가 아니라, 더 위의 역량을 기르기 위해서인 것이다.

다만 하위 계층에만 온전히 얽매이는 것은 분명 경계해야 할 것 같다. 단순히 JavaScript를 깊게 공부했다는 사실만으로 끝나는 것이 아니라, 내가 왜 이것을 배우고 있는지, 이것이 어떤 더 큰 역량으로 이어져야 하는지를 계속 의식해야 한다. 상위의 것을 기르기 위해 지금 나는 어떤 노력을 해야 하는지를 계속 생각해봐야 한다는 말이 인상 깊었다.

나 역시 JavaScript를 딥다이브하며 공부했던 시간이 떠올랐다. 이후에 AI가 코드를 다 짜준다고 해서, 그때 깊게 탐구했던 경험이 의미 없어지는 것은 아닐 것이다. 오히려 하나를 깊게 파본 경험이 있다면, 다른 것도 깊게 파고들기 쉬워진다. 결국 남는 것은 지식 하나가 아니라, 끝까지 파고드는 힘이기 때문이다.

그래서 이 말을 듣고, 나도 괜히 흔들리지 말고 계속 해보자는 생각이 들었다. AI가 잘한다고 해서 내가 해온 공부가 무의미해지는 것은 아니다. 오히려 지금처럼 하나하나 깊게 이해하려고 노력했던 시간들이 앞으로 더 중요한 힘이 될 수도 있다. 그러니 조급해하지 말고, 하던 것을 계속 열심히 해봐야겠다.

이번 2주 동안에는 원정대 활동으로 클로드 코드를 깊게 파봤다.

우리 원정대는 클로드 코드를 공부해서 짧게나마 해커톤도 열어보고, 하네스 공부를 하면서 프로젝트를 하나 진행하기로 했다. 바로 우리만의 공식 문서를 만드는 것이었다.

생각보다 하네스 환경을 만드는 일은 정말 어렵고 시간이 많이 들었다. 이게 맞다 저게 맞다 하면서 정말 많은 논의를 했다. claude.md에 넣어야 할 것들은 무엇인지, 길이는 얼마나 되어야 하는지, 무엇이 훅이고 무엇이 룰인지, 혹은 무엇이 스킬인지, 그리고 어디까지가 훅이고 룰이고 스킬인지를 나누는 데에만 며칠이 걸리기도 했다.

그렇게 협업을 하면서 나름의 방식을 하나 정리할 수 있었다. 함께 하네스를 처음부터 구축해야 한다면 이런 순서가 정배가 아닐까 싶다.

• 프로젝트의 기술적인, 기획적인 부분을 대략적으로 확립한다.
• 이후 claude.md를 개괄적으로 짠다. (처음부터 완벽하게 짜려고 하지 않는다.)
• 클로드에게 자동화시킬 일들과, 무조건 사람이 해야 할 일들의 경계를 나누고 settings.json을 짠다.
• 그 위에서 훅과 룰을 분리하고, 적절한 스킬과 에이전트를 만든다.

흥미로웠던 점은, 이렇게 진행하다 보니 오히려 사람은 하네스적인 부분보다 전체적인 설계에 더 집중할 수 있었다는 것이다. 결국 AI는 도구였다. 게다가 하네스를 잘 짜려면 결국 기술을 잘 알아야 했다. 여기서 사람마다 엄청난 차이가 났다. 기술을 잘 아는 사람이 하네스도 더 잘 짰다.

앞서 기본기 계층 이야기에서 느꼈던 것과 정확히 맞닿는 경험이었다. 도구가 좋아질수록, 그 도구를 다루는 사람의 상위 역량이 더 도드라진다는 것을 직접 체감할 수 있었다.

그렇게 레벨 1이 끝났다.

진짜 많이 배우고 성장했다. 소프트 스킬적으로나 하드 스킬적으로나. 두 달을 돌아보았을 때 가장 크게 바뀐 한 가지를 꼽자면, 나는 망설임 없이 문제를 대하는 자세라고 말할 것 같다.

• 요구사항을 받았을 때 : 어떻게 사고해야 하고, 작업을 완료하기까지 어떤 자세를 가져야 하는지. README로 해야 할 일을 명시하고 작업하는 습관이 생겼다.
• 팀원들과 함께 문제를 해결해야 할 때 : 어떻게 해야 우리가 더 효율적으로, 더 잘, 더 성장하며 나아갈 수 있을까? 완벽한 답을 알지는 못했지만, 이에 대한 많은 고민을 하게 되었다.
• 새로운 개념을 만났을 때 : 어떻게 해야 이 개념을 익힐 수 있을까? 이 개념이 왜 필요할까? 어떻게 이 개념에 잘 접근하고, 내 것으로 만들 수 있을까?

요즘 들어 다른 크루들이, 내가 생각이 깊고 가치관의 핵심 코어가 단단하다는 말을 종종 해준다. 그만큼 질문에 대한 답변이 거침없고, 발표를 하더라도 막힘이 없다는 말을 많이 해준다.

내가 우아한테크코스에 오지 않았다면 이런 생각의 깊이를 얻을 수 있었을까? 정말 엄청난 열정을 가진 사람들과 함께하지 못했다면, 그리고 좋은 커리큘럼과 사람으로서도 개발자로서도 교육자로서도 멋진 코치분들이 없었다면, 지금처럼 많은 인사이트를 얻고 스스로 깊이 생각해볼 수 있었을까. 그런 환경 속에서 나만의 정답과 가치관을 만들어 나갔던 것 같다.

아, 이게 우아한테크코스구나. 사람을 만드는 교육.

혼란스러운 세상 속에서 나만의 정답을 만들어 나간다. 이걸 결국 해나가는 모습을 스스로 볼 수 있어서, 앞으로 더 성장해 있을 내가 정말 기대되는 레벨 1이었다.