Week 06: 탐험 준비

C 실제 자료구조 라이브러리 분석, 수요코딩회 새로운 시도

핵심 역량 목표

목표 1. 자료구조를 직접 구현하고, 실제 라이브러리의 구현 방식과 동작 원리를 분석하기

관련 역량: 구현, 문제해결, 학습 민첩성

계획

기본 자료구조를 직접 빠르게 구현해 본 뒤, GLib 같은 대표적인 C 자료구조 라이브러리를 사용하거나 내부 구현을 살펴볼 계획이다.

외부 사용을 전제로 메모리가 어떻게 관리되는지, 어떤 인터페이스를 제공하는지 등을 분석하면서 C와 자료구조에 대한 이해를 더 깊게 가져가고자 한다.

과정

과제를 보지 못한 상태에서 설정한 목표라서 자료구조를 구현하는 줄 알고 이러한 목표를 설정했는데, 실제로는 자료구조를 사용한 코딩 테스트 문제 풀이와 비슷해서 자료구조 구현은 하지 않았다.

알고리즘 문제는 금, 토, 일요일까지 해서 다 구현하고 AI 기반 피드백으로 자체 평가까지 완료했다.

이후 월, 화에 기존에 존재하는 라이브러리를 분석했다.

이전부터 C에서 자료구조 사용법과 내부 메모리 관리가 궁금했던지라 찾아보고 가볍게 정리하여 글을 썼다.

그리고 그 과정에서 찾아본 Tsoding의 유튜브 내용에 대한 메모도 남겨두었다.

결과 및 피드백

목표했던 자료구조 직접 구현은 하지 못했고, 라이브러리 분석은 전부 완성하지 못했다.

하지만 자료구조 구현은 필요하긴 한데, 과제랑 연결되어서 설정한 면도 있어서 라이브러리 분석을 통해 자료구조의 메모리(더 크게 보면 C에서 메모리 관리에 대한 이해)를 익혔다는 점에서 의미가 있지 않나.

아직 완성하지 못한 자료구조 정리 글은 일요일의 자유 시간을 활용해서 완성할 계획임.

목표 2. 학습한 내용과 자료를 팀에 공유하기

관련 역량: 협업, 태도

계획

자료구조는 비교적 익숙한 분야라, 필요하면 개념을 설명하거나 관련 자료를 공유하는 식으로 좀 더 적극적으로 참여해 보려고 한다.

다만 팀원 분위기를 보니 다 같이 개념을 그리며 익혀 가는 스타일은 아닌 것 같았고, 다들 기본 개념도 어느 정도는 잡혀 있는 상태로 보인다.

그래서 팀원들이 부담을 느끼지 않는 선에서 참고할 만한 자료나 내가 괜찮았던 시도, 경험을 가볍게 공유하고 도움이 필요할 때 같이 고민해 보는 식으로 협업할 계획을 세웠다.

과정

CLion용 devcontainer 설정, AddressSanitizer와 Valgrind 같은 도구를 공유하였다. 또한 수요코딩회에서 참고하기 좋은 간단한 참고 자료들도 공유하였다.

결과 및 피드백

과제가 새로운 개념이나 익혀야 할 지식이 나오지 않고, 알고리즘적인 부분이 많아서 생각보다 많이 공유하지 못했다.

부분적으로 달성했지만, 팀원들에게 긍정적인 피드백을 받았으므로 강요하지 않도록 주의하면서 계속 진행하면 좋을 듯하다.

목표 3. AI를 활용해 Jungle Bell에 신규 기능을 추가하고 버전 0.3.0을 배포하기

관련 역량: AI 활용, 품질, 유지보수

메인 커리큘럼과 직접 연결되는 목표는 아니지만, AI를 활용한 유지보수와 제품 개선 경험을 쌓는다는 점에서 별도 목표로 두었다. 대신 우선순위는 앞선 두 목표보다 낮게 유지하려 했다.

계획

GitHub 이슈를 기준으로 필요한 기능을 하나씩 추가하고, 작은 단위로 버전 업데이트를 할 계획이다.

목표는 급식 알림 기능과 여러 편의성 패치를 포함한 v0.3.0까지 배포하는 것이다.

과정

실제로는 신규 기능보다 UI 수정, 내부 코드 리팩터링, 자잘한 편의성 개선 위주로 진행했고, 그 결과 v0.2.2까지 정리했다.

주차가 진행될수록 메인 커리큘럼과 수요코딩회 회고에 더 많은 시간을 쓰게 되어, 계획에서 생각했던 메뉴 알리미 기능까지는 진행하지 못했다.

결과 및 피드백

결론적으로 목표인 v0.3.0 출시는 달성하지 못했다.

급식 알림 기능을 추가하는 건 투자 대비 리턴이 크지 않다고 판단했다. (특히 데스크톱 앱에선)

그래서 현재는 메뉴 알리미를 크게 확장하기보다는, 정글 오픈 채팅 바로가기 링크를 추가하는 정도의 작은 개선만 기획하고 있다.

애초에 Jungle Bell을 개발한 이유는, 오픈 소스에 본격적으로 기여하기 전에 AI를 활용한 유지 보수와 제품 개선 경험을 가볍게 익혀 보려는 데 있었다. 그런데 유지 보수와 추가 기능까지 계속 신경 쓰다 보니, 이대로라면 끝날 때까지 이 서비스를 계속 붙잡고 있게 될 것 같아 범위를 줄이려는 것도 있다.

WIL (What I Learned)

04/09 김현수 코치님 커피챗

회고가 끝난 뒤 1층 라운지에서 약 1시간 20분 정도 이야기를 나눴다. 자세한 내용은 개인적으로 정리했지만, 공유하고자 하는 내용만 작성해 보았다.

  1. 질문: 발표에서는 무엇을 공유하는 게 좋은가?
    • 발표는 같아도 되고 달라도 되지만, 중요한 것은 듣는 사람에게 본질적으로 도움이 되는 내용이냐는 점이다.
    • 특히 실패했던 지점, 왜 막혔는지, 어떻게 극복하려 했는지, 다음에는 어떤 전략을 시도할지 같은 내용은 실제로 해 본 사람만 말할 수 있어서 더 가치가 있다.
  2. 핵심: AI를 많이 써 봐야 비판적으로 볼 수 있다
    • AI 결과를 맹목적으로 받아들이지 않고, 왜 이런 결과가 나왔는지, 다른 선택지는 없는지, 지금 상황에 맞는 선택인지 따져보는 태도가 중요하다.
    • 이런 비판적 사고는 AI에게만 적용되는 것이 아니라, 원래 사람의 코드나 설명을 볼 때도 필요한 태도이다.
    • 하나의 정답만 붙드는 것이 아니라, 상황에 따라 다른 선택이 가능하다는 시각을 가져야 한다. (비용과 서버 안전성의 트레이드오프를 예시로 들었음.)
  3. 질문: 어려운 과제는 어떤 식으로 접근하면 좋은가?
    • 본인이 수요코딩회에서 톱다운으로 접근하는 방법을 소개했다.
      • 본인도 수요코딩회 과제를 해 보는데, 2시간 정도 하면 결과물이 나온다. 본인이 아무 핵심도 모른다고 생각하고 접근한다.
      • 처음부터 구현으로 들어가기보다, AI를 활용하면서 먼저 과제가 최소한 무엇을 해야 하는지 3가지로 짧게 정의해 달라고 하고, 그 정의를 다시 3가지 핵심으로 나누는 식으로 재귀적으로 들어간다.
      • 충분히 전체 구조가 구체적으로 잡히면 의사 코드나 더미 코드 수준으로 맞춘다. 그럼 구현에 들어가기 전에도 전체 구조를 이해할 수 있다.
      • 이러면 구현에 들어가기 전에도 전체 구조를 이해할 수 있고 협업할 때도 합의 지점이 생긴다.
    • 하지만 이게 유일한 방법은 아니며, 본인에게 잘 맞는 방법일 뿐임. 본인이 본 사람들 중에는 코드를 따라 치면서 전체 구조를 이해하는 사람도 있었다.
    • (내 생각: 이런 톱다운 접근은 구현이나 과제뿐만 아니라 학습 등 범용적으로 톱다운으로 접근할 때 써 볼 수 있을 것 같아 여러 부분에 적용해 볼 예정.)
  4. 핵심: 수요코딩회에서는 의심하고 다음 시도를 만드는 경험 자체가 중요하다
    • 이번 방식이 완벽했는지보다, 이번에는 잘 안 됐으니 다음에는 다르게 해 봐야겠다는 고민이 실제로 나오고 있다는 점 자체가 의미 있다.
    • 어떤 방법이 맞는지 스스로 의심하고 다른 시도를 해 보려는 흐름이 생기고 있다면, 기대했던 모습과 정확히 같지 않더라도 좋은 과정이라고 생각한다.
  5. 질문: AI를 써도 직접 코딩하며 익히는 과정이 왜 필요한가?
    • 톱다운 접근이나 AI 활용이 도움이 될 수는 있지만, 그것이 직접 부딪히며 익히는 경험 자체를 대체하지는 못한다.
    • 특히 익숙하지 않은 단계에서는 직접 코드를 읽고 쓰면서 익숙해지는 시간이 필요하다.
    • 생성된 코드를 오래 읽는 것과 실제로 코드를 써 본 경험은 다르며, 코드를 제대로 읽으려면 결국 직접 코딩해 본 경험이 있어야 한다.
    • 단순히 결과를 내는 수준을 넘어서 구조와 맥락까지 이해하고 싶다면, 직접 부딪히는 과정이 필요하다.
  6. 질문: AI를 도구로 본다면, sanitizer나 Valgrind 같은 도구를 사용하는 건 어떤가?
    • 조금 조심스럽지만 시대에 맞는 도구는 쓰는 게 맞고, 예전의 불편한 방식만 고집하는 것을 강요할 필요는 없지 않나 싶다.
    • 중요한 것은 도구를 쓰지 말아야 한다는 게 아니라, 도구를 딸깍 수준으로만 소비하지 않고 스스로 고민하면서 쓰는 상태에 도달하는 것이다.
    • 도구의 도움을 받더라도 그 결과를 해석하고, 다른 도구가 있더라도 무작정 의존하지 않으면서 문제를 이해하려는 태도가 있으면 그것도 충분히 의미가 있다.
    • 결국 AI나 도구가 없는 시대를 상정하기보다, 지금 시대의 도구를 쓰면서도 다른 사람보다 한 단계 더 고민하는 사람이 되는 쪽이 더 현실적인 방향이다.
    • (내 생각: 그렇게 따지면 IDE나 구글링도 쓰지 않던 시대가 있는데, 굳이 그럴 필요가 있나. 다만 예전의 도구나 도구가 없던 시절의 방식을 알면, 선택 가능한 방법 중 하나로 유용하게 쓸 수는 있겠다.)
  7. 핵심: WIL과 블로그 기록은 나중에 강한 증거가 될 수 있다
    • 매일의 시도, 실패, 성장 과정을 꾸준히 남긴 기록은 나중에 다른 사람이 보았을 때도 이 사람이 실제로 어떤 태도로 시간을 보냈는지 보여주는 증거가 될 수 있다.
    • 모든 글을 다 읽지는 않더라도, 일정 기간 동안 꾸준히 남아 있는 기록과 그 안의 밀도만으로도 좋은 인상을 줄 수 있는 경우가 있다.

회고

수요코딩회 후기

Week 6 수요코딩회 저장소 와 운영안 배경 정리 에 이번 시도의 배경을 정리해 두었다.

잘 된 점 / 유지할 점

  • 문제의식을 가지고 시도
    • 이번에는 기존의 널리 쓰이는 방식인 AI에 의존하는 문제를 해결하기 위해 새로운 시도를 했다.
    • 시행착오는 있었지만 이런 방향성 자체는 여전히 맞다고 생각한다.
  • AI 프롬프트 남겨서 회고 가능한 구조 만들기
    • 각 팀원의 AI 사용 흐름과 그 결과를 프롬프트와 코드로 묶어서 평가할 수 있게 되었다.
    • 해건님의 아이디어에서 시작해서, 구체화는 팀이 함께 진행했다.
  • 이 분석을 통해서 프롬프트를 쓸 때, 필요한 정보만 주는 것이 더 중요하다는 것을 알 수 있었다.
    • 우리는 프로젝트를 여러 단위로 쪼개서 개발을 했는데, 이때 전체 단위에 대한 컨텍스트를 준 팀원의 결과물은 불필요한 부분까지 구현한 반면, 개발하려는 단위만 제공한 경우에는 필요한 부분만 구현했다는 것을 실제 비교를 통해 알 수 있었다.
    • 이론적으로는 알고 있었지만, 이렇게 실제 경험과 비교하며 더 잘 알게 된 것 같다.

아쉬운 점 / 개선할 점

  1. 한 번에 너무 많은 시도
    • GitHub 도구 사용법, 코드 리뷰, 로그 분석, 발표 개선, 구현 실험까지 새로운 시도가 많았다.
    • 그러다 보니 과제에 대한 이해도나 수행도 측면에서는 오히려 기존보다 부족했던 것 같다.
    • 시행착오 시간을 고려해서 목표를 낮추고, 목표를 조금 낮추더라도 작은 시도라도 완료하는 게 중요할 것 같다.
  2. 인지 부하를 줄이자
    • 팀원의 코드를 빠르게 리뷰하면서 동시에 구현 방향까지 함께 맞추려 했고, 시간에 쫓겨 후반부에는 날림으로 끝났다.
    • 페어 프로그래밍을 해서 코드 리뷰 양을 줄이거나, 의사 코드를 다 같이 짜고 각자 개발하는 등 인지 부하를 줄이는 방법이 필요하다.
  3. 프롬프트 로그 자체로는 의미가 없다 & 도구의 부족함
    • 프롬프트 로그와 커밋 내역 기반으로 피드백을 받은 건 좋았지만, 과정이 많이 자동화되어 있다 보니, 사용자의 행동이나 시행착오가 없이 결론만 받아서 잘 이해하고 오래 남는 느낌은 아니었다.
    • 더 적절한 수행/피드백 루프를 만들어야 하고, 지금으로선 큰 의미가 없는 것 같다.
    • 그리고 로그 수집 도구로서 Hooks나 Prompt History도 괜찮긴 한데, 더 다양한 정보와 편의성이 좋은 도구를 찾아봐야 할 것 같다.
    • 여러 주차를 반복하면서 꾸준히 개선해 봐야 할 것 같다.

코어타임 / 협업 회고

공식적인 코어타임은 없었지만, 우리끼리 짧게라도 진행 상황을 공유하는 시간을 만들었다.

이 시간에는 CLion용 devcontainer 설정, AddressSanitizer나 Valgrind 같은 도구처럼 바로 써먹을 수 있는 정보나 과제에서 실수하기 좋은 부분(구현과 무관한 과제 자체에서 잘못된 부분)을 주고받았다. 30분 이내로 끝낼 수 있어 부담 없이 할 수 있었다.

코어타임은 다음 주에도 도입하고 싶다. 강제하지 않으면 이런 식으로 현황과 정보를 공유하는 게 생각보다 잘 이루어지지 않을 것 같다.

핵심 역량 목표 회고

잘 된 점

하나라도 완벽하게 해낸 목표가 없었지만, 앞으로의 방향을 좀 더 명확하게 잡을 수 있었다.

특히 김현수 코치님과의 커피챗을 통해서 수요코딩회 운영 방식과 AI 활용 방식에 대해 어느 정도 확신이 생기게 되었는데, 의도하진 않았지만 아주 큰 의미가 있었다.

고민 1: 핵심 역량 목표에 사이드 프로젝트를 어디까지 포함할 것인가?

Jungle Bell처럼 의미 있는 활동이더라도, 메인 커리큘럼과 직접 연결되지 않으면 결국 우선순위에서 밀리게 된다. 개인적인 목표가 핵심 목표에 적절하진 않다고 느꼈다. 다음에는 별도 템플릿으로 관리하거나, 제외하는 게 나을 듯하다.

고민 2: 시간 관리와 수면 시간 확보하기

이번 주에는 늦게 들어간 날이 여러 번 있었고, 결국 이번 주차의 평균 수면 시간(일요일 제외)이 거의 5시간 수준으로 줄어들었다. 이 글을 쓰는 목요일 시점에는 커피를 마셔도 졸릴 정도로 피곤해서 상태가 좋지 않다고 느꼈다. 그리고 말하는 거나 이해하는 것에 있어서 평소보다 잘 되지 않고, 인지 능력 저하가 체감되었음.

여러 원인이 있겠지만, 과제가 어렵다기보다는 사람들과 이야기가 재미있어서 늦게 가거나(오전 12시가 넘어가면 노가리 까는 게 3배는 재밌어지는 것 같다), 보상 심리 때문에 30분씩은 폰을 보고 잔다거나 하는 필수적이지 않은 활동은 조절할 필요가 있을 것 같다.

하지만 멘탈 유지에는 이런 활동이 필요하다고 생각하기 때문에, 시간을 낮으로 옮기거나 제한 시간을 정하는 등의 최소한의 시간 관리는 해야 할 것 같다.

다음 주차에 시도할 것

평균 최소 수면 시간 7시간을 확보하도록 시간 관리에 신경을 쓸 예정이다.

핵심 계획을 과제를 모르는 상태에서 세우니 잘 지켜지지 않는 것 같았다. 다음 주부터는 초반 이해를 어느 정도 잡은 뒤, 늦어도 금요일 저녁까지 학습 목표를 정할 생각이다.

공부나 수요코딩회에서 김현수 코치님과 커피챗을 통해서 알게 된 것처럼 3가지 핵심 질문으로 이해하며 재귀적으로 TOP-Down 접근하는 방식이 좋아 보여 적용해 볼 계획이다.