Week 10: 정글 끝까지(Pintos) - User Programs

Pintos User Programs 진행

이번 주차는 거의 Pintos에만 몰입해서 진행했다.

핵심 역량 목표

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

목표 1. AI 에이전트를 활용해 Pintos User Programs를 직접 구현하기

관련 역량: 문제해결, 구현, 품질, AI 활용, 학습 민첩성

계획

이번 주에는 Pintos User Programs 과제 구현에 집중한다.

개인적으로는 User Programs를 전부 직접 구현해 보는 것이 목표였다.
AI는 요구사항 분석, 테스트 해석, 피드백을 받는 보조 도구로 쓰고, 구현 단계에서는 최대한 직접 작성하려고 했다.

과정

이를 위해 과제 파일을 프로젝트에 넣고, AGENTS.md를 만들어 AI가 코드나 의사코드를 바로 제안하지 않도록 제한했다.

또, 팀 프로젝트와 별개로 개인 Pintos 레포를 병행하면서 진행했다.

다만 실제로는 목표만큼 지키지는 못했다. 팀원들과 함께 AI에게 작업을 역할 단위로 나눠 달라고 하고, 각자 맡은 파트를 구현하는 식으로 진행했다.

내가 맡은 부분은 비교적 직접 구현하고 디버깅했지만, 다른 팀원이 맡은 부분을 이해하거나 맞춰 갈 때는 AI와 팀원의 구현을 많이 참고했다.

결과 및 피드백

대부분의 요구사항은 구현했지만, 모든 요구사항을 내가 직접 분석하고 검증했다고 말하기는 어렵다.

AI는 내가 이해한 내용이 맞는지 확인하거나, 테스트 실패가 어떤 요구사항과 연결되는지 볼 때는 도움이 됐다.

반대로 요구사항 분석과 디버깅을 AI에게 너무 많이 넘기면 학습 효과가 줄어든다는 것도 느꼈다. 구현은 내가 하더라도, 판단과 설계를 AI가 하고 있으면 내가 AI의 실행자가 되는 느낌이 들었다.
(AI와 내 역할이 반대로 된 느낌)

이번에 가장 많이 남은 부분은 내가 직접 요구사항을 읽고, 직접 printf를 찍어보고, 테스트 실패를 따라간 부분이었다.

AI를 사용했던 방법을 주제로 발표하기도 했다.
AI와 AGENTS 학습 보조 발표 자료

그 외 작업

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

운동

바쁘고 생활 패턴이 뒤죽박죽이라 자주 못했다.
그래도 같은 교육실 사람들과 3km 러닝을 세 번 정도 했다.

Jungle Bell 작업

기능은 어느 정도 만들고 외부 홍보를 시작했다.

홍보 출력물을 사람들이 많이 오가는 정수기 앞이나 흡연실 등에 붙였고, 홍보 글을 슬랙에 올리기도 했다. 다른 코스 사람들과는 슬랙으로 소통할 수 있는 방법이 없었는데, 게임랩에 아는 사람이 있는 이시원님과 송영진님의 도움을 받아서 홍보했다.

아직 사용자 증가는 크지 않다. 확실히 우리 교육실 내부에서 한 것처럼 직접 1대1로 설명하는 방식이 더 확실한 것 같다. 아니면 시기가 너무 늦었을 수도 있고.

오픈소스 기여 준비

다시 오픈소스 기여를 해볼까 생각 중이다.

여전히 자신감이 크지는 않지만, 정글에서 다 완료하기 어려운 커리큘럼을 소화하려고 노력하고, 특히 Pintos를 하면서, 정말 낮선 언어와 분야의 코드에 적응하는 감각이 조금 늘었다고 느낀다.

이를 위해 각 레포마다 AI 관련 파일을 흩어 관리하지 않고, 한곳에서 관리하기 위한 프로젝트도 구상했다.

contribution-overlays

WIL (What I Learned)

10주차 피드백

전체 피드백에서 가장 크게 남은 내용은 AI 시대에도 요구사항 분석과 직접 설명할 수 있는 구현 경험이 중요하다는 점이었다.

장윤호 코치님

  • 발표 시간이 정해져 있다. 준비 기간 등으로 엄격하게 보지는 않지만 지켜주었으면 좋겠다.
  • AI 시대에는 요구사항 분석이 더 중요한 역량이 되는데, 특히 Pintos를 하면서, 그 연습을 하고 있는지 확인해봤으면 좋겠다.

김현수 코치님

  • AI를 사용하지 않을 수는 없겠지만, 의존하지 않고 설명 가능한 구현이 있는지 확인해야 한다.
  • 면접에서 Pintos 구현 과정을 5~10분 정도 설명할 수 있는지 되돌아보라, 실제로 그런 경험을 좋게 본 면접관이 많았다.

이동욱 코치님

  • 회고가 사람에 대한 평가가 되면 blame하게 되고, 이건 전혀 도움이 되지 않는다.
  • 회고의 목적은 다음 주차에 더 잘하기 위한 것이고, 팀 레벨의 시스템을 평가해야 한다.
  • 개인의 문제를 지적하려면 단기간에 해결 가능한 명확한 개선책이 있거나, 진행에 큰 영향을 주는 경우여야 한다.
  • 추가적으로 Facilitation 기반의 구체적인 회고 방식을 설명해주었다. 핵심은 의견을 모으고 해서 객관적인 평가가 가능하게 하는 것이다.

인프런 CTO 이동욱님 커리어 특강

특강 내용 요약

그 순간에는 최적처럼 보이는 선택을 계속해도, 전체 커리어에서 최적이라는 보장은 없다.
반대로 당시에는 별로라고 생각했던 경험이 나중에 중요한 기반이 되기도 한다.

결국 좋은 경험과 나쁜 경험이 따로 있다기보다는, 주어진 경험을 어떤 태도로 대하는지가 더 중요하다.

본인의 커리어와 경험

  1. 취준생 때, 남을 가르치며 공부했던 경험이 블로그로 이어졌고, 블로그가 이후 커리어 기회로 연결됐다.
  2. ZUM에서 시니어가 없는 환경에서 신입들을 이끌어야 했던 경험이 리더십의 기반이 됐다.
  3. 배민에 백엔드 개발자로 갔지만 인프라와 DB 운영을 많이 했고, 그 경험이 나중에 CTO 역할을 할 때 도움이 됐다.

질의 응답

  1. CS 기초와 특정 기술 숙련도 중 무엇을 우선해야 할까?
    • 둘 중 하나만 고를 필요는 없다. AI를 활용하면 둘 다 더 빠르게 학습할 수 있는 시대가 됐다.
  2. 새로운 주제를 빠르게 공부할 때 AI를 어떻게 쓰는가?
    • 피드백 대상이 사람에서 AI로 바뀌었을 뿐, 방법은 이전과 동일하다.
    • 먼저 직접 자료를 찾고 정리한 뒤, AI에게 피드백을 받는 방식이 좋다.
    • 이후 AI가 꼬리 질문을 던지게 하고, 답하면서 이해도를 점검할 수 있다.
  3. 인상 깊은 신입은 어떤 사람인가?
    • 모르는 질문에도 바로 포기하지 않고, 아는 지식과 힌트를 바탕으로 끝까지 추론하는 사람이다.
    • 면접에서는 정답보다 사고 과정을 보여주는 태도가 중요하다.
  4. 어떤 회사를 선택하는 것이 좋을까?
    • 개발 생산성이 비즈니스 성장으로 이어지는 회사가 개발자에게 더 많은 기회를 줄 수 있다.
    • 신입에게는 좋은 시니어와 사수를 만나는 경험도 중요하다.
  5. 레거시 환경에 적응하는 훈련은 어떻게 하면 좋을까?
    • 오픈소스 기여를 통해서 이슈를 보고, 남이 만든 코드를 읽고, PR을 올려보는 경험을 추천한다.
    • 익숙하지 않은 코드를 읽고 수정하는 과정이 실제 레거시 환경과 비슷하다.
  6. 공개 블로그와 프라이빗 노트는 어떤 차이가 있을까?
    • 공개 블로그는 남을 이해시키기 위한 글쓰기라 학습 효과가 다르다.
    • 틀릴 수 있다는 부담을 감수하고 공개하는 과정 자체가 공부가 된다.
    • 공개하는 것은 누군가 읽을 수 있는게 아니라, 실제로 읽어야 함.

느낀점

이전부터 블로그, 유튜브, X 등을 통해서 여러 정보를 얻고 있었는데, 실제로 보는건 처음이였음. (함께 사진도 찍었다.)

이전부터 불편함을 해결하려는 오픈소스 기여나 토이 프로젝트 개발 등 사소한 작업을 많이 하곤 했는데, 이런 접근을 좋게 봐주는걸 보고 자신감을 얻었다.

회고

Pintos 후기

요구사항 분석에 AI를 많이 썼는데, 이 방식이 맞는지 계속 의문이 들었다.

AI가 과제 문서와 테스트를 읽고 설계 방향을 정리해주면 구현하는 방식이였는데, 내가 고민하는 부분이 없이 단순히 구현하는 기계가 된 느낌이였다.

차라리 구현 마무리나 스타일 정리, 반복적인 디버깅 보조는 AI에게 맡기고, 그러한 분석과 공부를 내가 해야하는게 맞는 것 같다.

생각해보면 직접 삽질하고 디버깅한 부분은 기억에 오래 남지만, AI를 써서 구현에 도움을 받은 부분은 크게 기억나지 않는다.

코어타임 / 협업 회고

AI에게 작업을 역할 단위로 나누고, 각자 맡은 부분을 구현한 뒤 PR로 공유했다.

이전보다 분업은 잘 되었지만, 병목 문제나 작업 배정이 잘 되지 않았다.

PR 리뷰를 충분히 잘 수행하지 못한 점도 아쉬웠다. 요구사항을 제대로 이해하지 못한 상태에서 PR을 리뷰하다 보니, 핵심 로직에 대해 의미 있는 피드백을 주기 어려웠다.

예를 들어 파일 디스크립터 테이블을 thread 구조체 안에서 배열로 관리하고 있었는데, 배열을 사용할 경우 요구사항과 스택 크기를 고려했을 때 구조체가 지나치게 커질 수 있다는 문제가 있었다.

이러한 문제는 이후 복습하면서 인지하게 되었고, 당시 PR 리뷰에서는 짚고 넘어가지 못했다. 돌이켜보면 이처럼 놓친 부분이 꽤 많았다.

AI 활용 방식 회고

다음부터는 AI에게 역할 단위로 나누게 하기보다, 작은 티켓 단위로 작업을 나누게 하는 편이 좋을 것 같다.

그리고 요구사항 이해를 AI가 수행하는 것은 학습에 도움이 되지 않는 것 같아 직접 하려고 한다.

코드 작성을 피하기만 하는것도 별로인거 같고, 반복되는 디버깅 코드 추가 정도에는 속도를 높이기 위해 쓸 수 있을 것 같다.

다음 주차에 시도할 것

다음 주차에는 AI 사용 제약을 더 명확히 두고, 티켓 단위 분업을 적용해보려고 한다. 팀원들과 이러한 부분을 이야기 할 예정이다.