핵심 역량 목표

정글 과정을 통해 길러야 할 10가지 핵심 역량(문제해결, 설계, 구현, 품질, 유지보수, 협업, 태도, 비즈니스 이해, AI 활용, 학습 민첩성)을 기준으로 이번 주의 목표를 설정하고, 실제 과정과 결과를 돌아봅니다.

목표 1. 3가지 핵심 개념을 먼저 정리하고, 이를 기준으로 과제를 Top-Down으로 공부하기

관련 역량: 문제해결, 설계, 학습 민첩성

계획

최소 단위의 핵심 요소 세 가지를 먼저 짧게 정의한 뒤, 각 요소를 반복해서 점차 구체화하는 Top-Down 접근을 시도해 보려고 했다.

이 방법은 지난주 김현수 코치님과의 커피챗에서 들은 방식이다.
처음부터 구현으로 들어가기보다, 과제가 최소한 무엇을 해야 하는지 3가지 정도로 정의하고, 그 정의를 다시 쪼개며 전체 구조를 잡는 식이다.

과정

학습 대상을 크게 Heap AllocatorOS/가상 메모리 쪽으로 나누고, 각 내용의 핵심 내용을 Top-Down으로 물어보면서 학습했다.

결과 및 피드백

전체 구조를 잡고 설명할 때 확실히 도움이 됐다.
원래 학습 스타일은 하나의 개념을 잡고 계속 아래로 파고드는 편이라, 전체 구조를 먼저 그리는 데에는 익숙하지 않았다.
이번에는 큰 틀을 먼저 잡아두니 과제 설명을 읽거나 팀원에게 설명할 때 덜 막히는 느낌을 받았다.

앞으로도 생소한 개념을 처음 잡거나 남에게 설명할 문서를 만들 때는 이 방식을 계속 사용할 것 같다.

그것과 별개로 수강 전 기대하던 과제였지만, 흥미를 영 붙이지 못해서 시간을 많이 낭비했다. 이에 대한 내용은 WIL의 흥미가 떨어지는 과제는 꼭 하지 않아도 된다 를 참고하자.

목표 2. 3가지 핵심을 기준으로 수요코딩회 프로젝트를 Top-Down으로 진행하기

관련 역량: 학습 민첩성, 구현, 태도

계획

지난주 수요코딩회에서 가장 크게 느낀 문제는 인지 부하와 시간 부족이었다.

AI를 잘 활용하고 이해 가능한 코드를 작성하고 싶었지만, 동시에 GitHub 사용, 코드 리뷰, 프롬프트 로그 분석, 발표 준비까지 하다 보니 한 번에 너무 많은 것을 시도하게 됐다.

그래서 이번에는 수요코딩회에서 작은 목표를 정하고, Top-Down 접근을 적용해 보려고 했다.

과정

초반에는 서로 학습한 후 화이트보드에 그림을 그려가면서 개념을 잡았다.

이후 회의실에서 한 컴퓨터의 화면을 공유하며 프롬프트를 작성하고 구체적인 구현 계획을 작성하였다.

해당 계획으로 핵심 요구사항을 만족하는 코드를 개발한 후, 각자 원하는 기능을 개발하거나 코드를 더 분석하는 등의 작업을 수행했다.

결과 및 피드백

Top-Down 방식 자체는 도움이 됐다. 적어도 의사코드를 보고 기능에 대한 이야기를 할 수 있었다.

하지만 이번 결과가 Top-Down 덕분인지, 기능을 줄인 건지, 새로운 팀원들이 적응력이 빠른 건지는 모르므로 순수하게 평가하기에는 어렵다.

또한 팀원들과의 이야기나 회고를 통해 리드하는 방식에 대한 고민이 생겼고, 이 내용은 아래의 회고 파트에서 이어서 정리한다.

그 외 작업

핵심 역량 목표와 직접 연결되지는 않지만, 이번 주에 따로 진행했거나 정리할 만한 활동을 작성합니다.

jungle-utils 만들기

jungle-utils라는 작은 도구 모음 저장소를 만들었다. 정글 과정에서 반복적으로 필요한 스크립트나 유틸리티를 한곳에 모아두려는 목적이다.

Jungle Bell 기능 추가

Jungle Bell은 이번 주에도 조금씩 다듬었다. v0.2.5를 배포했고, PostHog 기반 이벤트 수집, 식단표 보러가기 메뉴 항목 기능이 생겼다.

컨디션 관리와 운동

이번 주 초반에 컨디션 관리가 잘 되지 않았다.

식사 뒤 피로감과 수면 부족 때문에 집중이 잘 안 되는 경우가 많았다. 그러다 갑자기 심하게 어지러워져 일찍 기숙사에 들어간 날을 계기로 월요일(04/13)부터 시간을 내서 신체 활동을 하고 있다.

그래서 매일 로잉머신과 식후 10분 이상의 산책을 항상 하려고 하는데, 로잉머신의 경우 수요코딩회처럼 바쁜 날은 못했지만, 산책은 꼭 하려고 한다.

확실히 산책을 하면 혈당 스파이크로 인한 피곤함이 줄고, 운동 이후에 개운해지는 등 효과가 괜찮다. 주 단위로 인바디를 찍어보는 것도 좋을 듯하다.

WIL (What I Learned)

페어프로그래밍과 직접 디버깅

이번 주 막바지에 (이번 주차 팀원은 아니지만) 해건님의 malloc 구현 작업을 보다가 자연스럽게 페어프로그래밍을 하게 됐다. 한 시간 넘게 같이 문제를 추적했고, 개인적으로 이번 주에 가장 인상 깊었던 경험이었다.

무엇보다 AI 없이 끝까지 파고들어 문제를 해결해 본 성취감이 컸다. 혼자였다면 막히는 순간 짜증이 나서 AI에게 넘기거나 멈췄을 것 같은데, 페어로 같이 보니 문제를 끝까지 붙잡을 수 있었고 그 과정 자체가 퍼즐을 푸는 것처럼 재미있었다.

처음으로 디버깅에서 메모리 뷰를 의미 있게 사용해 본 것도 좋았다.

수요코딩회뿐만 아니라 일반 주차에서도 AI 도움 없이 페어프로그래밍으로 문제를 추적해 보는 시간이 꽤 도움이 될 것 같다.

AI가 없던 고등학생 때는 이런 식으로 함께 작업하곤 했는데, 오랜만에 그 감각이 떠올라서 조금 그립기도 했다.

흥미가 떨어지는 과제는 꼭 하지 않아도 된다

솔직히 이번 과제인 malloc lab은 처음 이론을 공부하고 allocator의 기본 구조를 만들 때는 재미있었지만, 일정 점수 이후부터는 흥미가 많이 떨어졌다.

되돌아보며 생각을 해보았는데, 내가 흥미를 느끼는 조건을 가지지 못해서 그런 것 같다.

내 생각에 나는 보통 두 가지에서 의지를 얻는다.

  1. 나를 위한 깊은 이해, 이론 공부, 저수준 토이 프로젝트, 오픈소스 기여 같은 성취감 위주 활동
  2. 남을 위한 서비스 개선, 오픈소스 기여, 페어프로그래밍처럼 실제로 누군가에게 도움이 되는 성과

이번 과제는 처음 돌아가는 것을 만들 때까지는 첫 번째 조건을 어느 정도 충족했다. 하지만 일정 수준 이후의 점수 최적화는 의미를 찾기 어려웠다. (개선의 이유가 점수인데, 정글에서 점수는 자기만족 이상의 평가가 없다. 다른 작업 대비 성취감도 떨어짐.)

그렇다고 과제를 대충 넘기는 것이 맞다는 뜻은 아니다. 다만 모든 과제에서 같은 정도의 흥미와 몰입을 기대하기는 어려운 것 같다.

흥미가 낮은 과제에서는 필요한 수준을 정하고, 남은 시간은 배경 이론이나 더 관심 있는 쪽의 학습에 쓰는 것도 시간 관리 전략이 될 수 있다고 느꼈다.

회고

수요코딩회 후기

잘 된 점 / 유지할 점

  • Top-Down으로 초반 구조 잡기
    • 처음부터 구현에 들어가지 않고 핵심 개념과 구현 단위를 먼저 나눈 것은 도움이 됐다.
    • 팀원들이 같은 단어로 이야기할 수 있게 되고, 모르는 부분을 드러내기도 쉬워졌다.
  • 회고 시간에 프롬프트 로그를 함께 비교하기
    • 각자 AI에게 어떻게 질문하는지 비교하면서, 좋은 프롬프트가 무엇인지 더 구체적으로 이야기할 수 있었다.

아쉬운 점 / 개선할 점

  • 결과물의 품질과 학습 목표는 일치하지 않을 수 있음
    • 이번에 내가 리드하면서 주로 신경 쓴 것은 읽기 쉬운 코드를 작성하는 일이었다.
    • 하지만 이번 수요코딩회의 핵심은 결과물 자체보다 B+Tree를 이해하는 데 있었다.
    • 지난주에는 제품 자체의 완성도가 목표와 잘 맞았지만, 이번 주차는 그렇지 않았다. 되돌아보면 B+Tree 이해도를 충분히 높였는가에 대해서는 아닌것 같다.
  • 수요코딩회에서의 내 역할이 고정됨
    • 회고를 하면서 지금의 방식이 항상 좋지만은 않을 수 있다는 생각이 들었다.
    • 자세한 내용은 아래의 고민: 리드하는 협업 방식을 계속 가져가도 되는가? 이어서 정리한다.

고민: 리드하는 협업 방식을 계속 가져가도 되는가?

회고 중에도 내가 계속 리드하는 형태가 반복되고 있다는 이야기를 했다. 의식적으로 힘들다고 느끼지는 않았지만, 주변에서는 그런 방식이 지쳐 보인다는 피드백도 있었다.

나는 돕거나 알려줄 수 있는데 지나치는 것을 별로 좋아하지 않는다. 상대적으로 내가 다른 팀원들보다 아는 게 많다 보니 자연스럽게 리드하는 식으로 되는데, 특히 수요코딩회처럼 시간이 중요한 경우 더욱 그렇다.

하지만 다른 반 사람들(특히 구름님, 태정님)의 생각을 보면 결과물보다 수요코딩회는 서로 다른 협업 방식을 경험하는 시간으로 생각하는 것을 보았다.

그래서 되돌아보니, 내가 리드하다 보니 이 리드하는 방식을 개선하는 경험도 좋지만, 매번 흐름이 똑같아지는 것 같았다.

다음에는 리드하는 것보다, 방향성은 팀원들을 따라가고, 의견을 자주 내는 식으로 참여해보려고 한다. 이러면 다른 팀원의 장점도 많이 배울 수 있다고 기대하고 있다.

코어타임 / 협업 회고

좋았던 점

  • 개념 공부하고 각자 발표하기
    • 이번 주 코어타임에서 동일한 과제 개념을 공부하고, 그중 특정 부분을 맡아 서로 짧게 발표한 것이 생각보다 괜찮았다.
    • 내가 모르는 부분을 알게 되기도 했고, 설명하면서 내 이해도 함께 정리됐다.
    • 팀원들의 성향에 따라 다르겠지만, 도입해 볼 만한 방식인 것 같다. (주도적인 리더가 없는 경우 + 강제성 부여 + 소통 기회)
  • 충분한 회고 시간 가지기
    • 큰 의견 차이 없이 전반적으로 잘 진행된 것도 좋았지만, 무엇보다 회고나 느낀 점을 많이 나눌 수 있어서 좋았다.
    • 특히 이번 주차 팀원들은 지금까지 만났던 팀원들 중 회고나 느낀 점을 가장 많이 이야기해 주었다.
    • 구름님은 진행 중에도 자주 이야기해 주었고, 다른 팀원들도 주차 마지막 즈음에는 회고와 느낀 점을 많이 말해주어 도움이 되었다.
    • 기술적인 기여뿐 아니라 솔직한 고민, 서로의 개선점, 긍정적인 피드백까지 오래 이야기할 수 있었다.
    • 인상 깊은 피드백
      • 초심자에게 필요한 기본 설명은 AI도 꽤 잘해주기 때문에, 잘 아는 사람이 공유할 때는 초심자가 접하기 어려운 깊이나 관점을 주는 쪽이 더 가치 있을 수 있다.
      • 내가 이전부터 수요코딩회에서 계속 리드하는 모습을 보고 지쳐 보였다. 원래 리드하는 성향이 강한 사람이 아니라면, 매번 무리해서 이끄는 역할을 맡을 필요는 없다고 생각한다.

아쉬운 점

  • 과제 내용에 대한 대화가 생각보다 적었음
    • 각자 구현과 학습을 하다 보면 생각보다 대화가 줄어든다.
    • 회고에서도 malloc과 수요코딩회 과제에 대해 더 많이 이야기했으면 좋았겠다는 의견이 나왔다.
    • 회고 중에 나온 의견처럼, 굳이 정리하는 시간을 내서 공유할 필요 없이 외부 모니터를 연결해 각자의 작업(코드, 문서 등)을 함께 보는 식으로라도 자주 공유하면 더 좋을 것 같다.
    • 그러면 과제 내용뿐 아니라 개발 도구나 사용하는 앱처럼 서로의 작업 방식도 자연스럽게 확인할 수 있을 것 같다.

핵심 역량 목표 회고

잘 된 점

Top-Down 방식은 앞으로도 쓸 만한 것 같다.

고민

핵심 역량 목표를 어떻게 세워야 하는지는 여전히 어렵다.

과제를 모르는 상태에서 목표를 세우면 실제 과제와 어긋나기 쉽고, 상황이나 흥미에 따라 주차 중간에 방향성이 바뀌기도 한다.

그래서 앞으로는 어떤 식으로 진행되든 유지될 수 있는 목표를 세우는 편이 나을 것 같다.

예를 들면 "다른 사람이 리드하는 흐름을 따라가 보기", "페어프로그래밍 해보기", "팀원들의 장점을 관찰하고 배워보기" 같은 목표.

다음 주차에 시도할 것

학습에서는 기초 내용보다는 관심있는걸 파보고 공유해보려고 한다. 잘 모르는 팀원이더라도 AI를 활용해서 이해하는 모습을 보았으니 충분히 도움이 될 수 있을 것 같다.

수요코딩회에서는 내가 먼저 리드하기보다 다른 사람이 주도하는 흐름을 따라가 보려고 한다.

생활 면에서는 수면과 운동을 조금 더 안정적으로 가져가는 것이 목표다. 평균 수면시간 7시간 이상, 수요일을 제외한 매일 로잉머신 20분 이상을 목표로 하고 있다.