[Pintos] Pintos 학습 프로세스 ver2.0

Pintos 학습 프로세스 ver2.0

들어가며

이번에 실제로 계획했던 학습 프로세스 ver1.0을 통해 Pintos의 실제 카테고리(Advance Scheduler)를 진행하였고, 이를 나름 성공적으로 마치게 되었다. 그러면서 초기에 이론적으로만 계획했던 부분과 일치했던 부분도 있었지만, 실제로 프로젝트를 진행하면서 다소 달라진 부분도 존재했기에 이를 반영하여 개선된 학습 프로세스 ver2.0을 정리해보고자 한다.

 

 

Pintos 학습 프로세스 소개

0. 개요

해당 카테고리의 전체 흐름을 보는 것은 프로젝트 진행에 있어 가장 중요하다. 그래서 사전에 이를 파악하고 준비 세션에서 다함께 카테고리의 지형도를 그리게 된다. '이걸 왜 만들었나?', 또는 '기존에 어떤 문제가 있어서 어떤 부분을 바꿔야 하는가?'를 아는 것은 결국 '내가 뭘 하고 있는지', '무엇을 해결하고 있는지'를 명확히 하는 데에 큰 도움이 된다. 그리고 이를 알고 하는 것과 모르고 하는 것은 크나큰 차이가 있다고 생각한다.

 

이를 통해 각 팀원의 작업 이해도를 통일되게 높은 상태로 끌어올릴 수 있게 된다. 그러면서 이는 자연스럽게 해결해야 할 문제에 대한 갈피를 잡은 상태에서 합심하여 목표를 세우고 프로젝트 완수를 위해 몰입하는 것으로 이어진다.

 

1. 사전 학습 및 분석

이 단계에서는 팀원 각자가 전체 흐름을 그리기 위한 재료를 수집한다. 공통적으로 해당 카테고리에 대해 기본적인 학습을 마친 후, 나눠진 테스트 파일들을 분석해본다.

• 카테고리 기본 개념 학습 및 이해
  • 기본적인 개념과 구성 요소
  • 공식 문서, 인터넷(블로그), GPT 등 가용 가능한 모든 수단 활용
  • 이걸 왜 만들었나?
• 현재 시스템에 대한 문제 상황과 개선 필요성 인식
  • 현재 시스템의 문제 분석
  • 해당 카테고리의 도입 필요성 인식
  • 기존에 어떤 문제가 있어서 어떤 부분을 바꿔야 하는가?
• 테스트 파일 분석
  • 어떤 부분을 테스트하나?
  • 이를 통과하기 위해 어떻게 되어야 하나?

기본 개념 학습 및 문제 정의는 공통적으로 진행하고, 테스트 파일은 팀원 별로 적절히 분배해서 분석을 진행한다.

 

2. 준비 세션

각자 사전 준비가 끝났다면, 함께 모여 이를 공유하고 토론하면서 전체적인 큰 그림을 그리는 시간을 가진다. 이를 통해 기존에 무엇이 문제가 있어서 해당 카테고리를 구현해야 하는지, 어떤 부분이 어떤 흐름으로 변화하게 되는지를 각자가 명확히 알게 된다. 그 다음에는 그려진 큰 그림을 바탕으로 구체적으로 어떤 식으로 해결해 나가게 되는지에 대한 세부적인 흐름들을 토의해 본다.

 

그렇게 세부적인 흐름들을 짚어봤다면, 이를 바탕으로 공통으로 사용할 초기 코드인 공유 템플릿을 작성한다. 여기에는 공통 인터페이스(구조체)나 함수 시그니처가 포함되어 있다. 그래서 구체적인 구현은 되어있지 않더라도 상호 호출이 가능해지기에 팀원 간 작업 의존도를 효과적으로 줄일 수 있다.

 

템플릿의 각 함수 정의 부분에는 TODO 주석을 붙여 놓는다. 이를 통해 초기 해당 카테고리 구현이라는 추상적인 목표가 각자 맡은 부분의 TODO 해결이라는 구체적인 목표로 바뀌게 된다. 이 과정이 끝난 뒤 팀원 별 역할 분담을 진행하면 된다.

 

3. 구현, 통합 및 디버깅

각 팀원은 공유 템플릿에서 시작해 브랜치를 파서 각자 맡은 부분을 구현하게 된다. 구현 후 단일 테스트가 가능하다면 진행한다. 이후 하나의 브랜치에 통합을 하면 된다. 작업 간 의존성을 최대한 낮추고 시작했기 때문에 통합은 병렬적으로 가능할 것이라고 예상되지만, 구현 진행 중에 예상치 못한 의존적인 작업이 발생한 경우 알맞은 순서에 따라 통합을 진행한다.

 

이 단계에서 전체 통합 전 본인이 맡은 구현이 먼저 끝났다면 본인이 작업한 부분을 정리하거나, 다른 팀원의 작업에 대해 클론 코딩을 진행해볼 수도 있다. 최종적으로 모든 팀원의 작업이 하나의 브랜치에 통합되면, 이를 바탕으로 전체 테스트를 진행하고 실패한 테스트에 대해 분석하고 이를 달성하도록 디버깅한다. 이를 통해 통합된 코드가 해당 카테고리의 전체 테스트를 통과하는 것을 최종 목표로 삼고 진행한다.

 

4. 회고 세션

카테고리에 대한 모든 테스트를 통과했다면, 각자의 작업 과정을 정리한 뒤 다함께 모여 회고하는 시간을 가진다. 우리가 지금까지 했던 건 무엇이었고 이를 통해 어떤 부분이 어떻게 바뀌게 되었는지 전체 흐름을 복습한다. 그리고 각자 맡은 부분에 대해 세부적인 구현 사항에 대한 정보를 공유함으로써 구현 단계에서의 지식 간극을 좁혀본다. 마지막으로 전체 학습 프로세스를 진행하면서 좋았던 점이나 개선할 점을 토의한 뒤 전체 과정을 종료한다.

 

 

마치면서

이전 학습 프로세스 ver1.0이 실제로 검증되지 않은 이론적인 프로세스였다면, 이번 ver2.0은 우리 조가 직접 해당 프로세스를 통해 카테고리 구현을 진행하며 검증한 뒤 이를 반영했다는 점에서 의미가 크다. 다만 이제 한 번 프로세스를 진행해보았을 뿐이기에 성공적인 프로세스라고 단정짓기는 힘들다. 그렇지만 막연하고 막막한 Pintos 학습과 프로젝트 진행에 있어 하나의 구체적인 진행 프로세스를 제시하고 하나의 카테고리를 성공적으로 마무리해봄으로써 많은 것을 배울 수 있었다.

 

뿐만 아니라 여전히 AI(Chat GPT 등)를 어디까지 활용해야 하는가에 대해서는 고민이 많다. 다만 가장 중요한 것은 AI를 답지로 활용하기보다는 나의 사고 확장을 도와주고 최소한의 방향성을 도와주는 코치로써 활용해야 한다는 점이다.

 

예를 들어 AI를 아예 쓰지 않고 본인 혼자 최대한 생각해서 프로젝트를 진행한다고 해보자. 방향성을 잃고 방황하다가 주어진 기간이 지나버리면 그것은 성공이라고 할 수 있는가? 그리고 팀원 모두가 작업을 분담한 상태에서 이러한 상황이 발생하여 전체 프로젝트가 실패한다면 그 책임은 누구한테 돌아가는가?

 

반대로 AI에 전적으로 의존해서 프로젝트를 진행하는 경우도 있을 수 있다. AI로부터 레퍼런스 코드를 그대로 베껴 모든 테스트를 통과한 뒤, 나름대로의 분석을 했다고 하면 그것은 성공이라고 할 수 있는가? 기한 안에 프로젝트 자체는 끝냈지만, 본인 스스로에게 있어 전체적인 흐름을 설명하고 세부적인 구현 팁과 디버깅 노하우가 생겼다고 자신할 수 있는가?

 

AI를 많이 쓸수록 학습에 걸리는 시간은 비약적으로 줄어들지만, 반대로 얻는 경험치도 비약적으로 줄어든다. AI를 쓰지 않을수록 그러한 경향은 반대가 된다. 때문에 본인이 정말로 경험치를 얻고 성장하는 것과, 주어진 시간 안에 프로젝트를 완료하는 것 사이에 적절한 균형을 찾는 것이 가장 중요할 것이다.

 

학습에 있어 무작정 AI를 멀리 하고 배척하기보다는, 최소한의 방향성을 잡아주고 본인의 생각을 끌어내주며 이를 검증해주는 멘토로써 활용한다면 그것은 분명 의미가 있다. 이를 통해 학습 시간은 효과적으로 단축하면서도 효율적으로 성장할 수 있다고 생각하고, 또 그렇게 실천하고 있다. AI는 결국 우리에게 있어 받아들여야만 하는 친구이기 때문이다.