TODO

다음 내용은 녹음한 내용을 AI가 정리한 글로, 나중에 더욱 실제 의도에 맞게 다듬을 필요가 있다.

특히 핀토스 이전 주차의 회고나, 팀/개인적인 전체 경험과 성장 등의 내용은 추가해야 함.

Pintos를 마치며: 운영체제 이해와 서버 개발자로서의 학습 방향

1부. Pintos를 통해 얻은 것

Pintos는 이제 발표 직전 단계이므로 사실상 마무리했다고 봐도 될 것 같다. 하지만 “Pintos를 통해 운영체제를 많이 배웠다”고 말하기에는 솔직히 조심스럽다. 아직도 운영체제가 전체적으로 어떤 흐름을 통해 구체적으로 동작하는지 완전히 이해했다고 하기는 어렵다. 운영체제의 전체 구조를 명확하게 설명할 수 있을 정도로 깊게 이해한 상태는 아니다.

그럼에도 불구하고 분명히 얻은 것은 있다. 운영체제 전체를 깊게 이해한 것은 아니지만, 특정 부분에 대해서는 이제 어느 정도 설명할 수 있을 정도의 이해가 생겼다. 실제 구현의 세부나 하드웨어 수준까지 완전히 알고 있다고 말할 수는 없지만, 적어도 운영체제 안에서 어떤 흐름으로 이야기가 전개되고, 각각의 기능이 어떤 역할을 하는지는 어느 정도 감을 잡게 되었다. Pintos 프로젝트 자체에서 얻은 성과는 바로 이 지점에 있다고 생각한다.

하지만 Pintos를 통해 얻은 것은 운영체제 지식만은 아니었다. 오히려 더 크게 얻은 것은 내가 개발자로서 앞으로 무엇을 공부해야 하는지, 그리고 내가 사용하는 기술들이 어떤 추상화 위에 쌓여 있는지를 볼 수 있게 되었다는 점이다.

나는 실무에서 일을 하다가 퇴사하고 정글에 오게 되었다. 정글에 온 이유는 단순히 코딩을 더 잘하기 위해서만은 아니었다. 내가 개발자로서 하고 있는 일의 더 깊은 곳으로 들어가 보고 싶었다. 내가 사용하는 기술들이 어떤 이론과 개념 위에 서 있는지, 그리고 실제 시스템은 어떤 구조로 동작하는지 알고 싶었다. 그런 욕심과 궁금증이 있었기 때문에 개발자로서 깊이 있는 성장을 하고 싶었고, 그 과정에서 크래프톤 정글에 지원하게 되었다.

나는 서버 개발자로 커리어를 이어가고 싶기 때문에, 실무에서 접하는 기술들에 대해 늘 궁금한 점이 많았다. 예를 들어 Spring은 어떤 구조 위에서 동작하는지, Apache와 Tomcat은 무엇이 다른지, 어떤 경우에는 Tomcat 기반이라고 하고 어떤 경우에는 Netty 기반이라고 하는데 그 차이가 무엇인지, Node.js에서 말하는 싱글 스레드 I/O는 정확히 무슨 의미인지 잘 몰랐다. 각각의 기술이 성능 면에서 어떤 차이를 가지는지, 그리고 그 차이가 어디에서 비롯되는지도 명확히 이해하지 못했다.

Pintos를 구현하면서 이런 것들이 어느 정도 큰 그림으로 연결되기 시작했다. 결국 서버 프레임워크나 런타임이 하는 일의 밑에는 운영체제가 있고, 운영체제와 유저 프로그램 사이에는 시스템 콜이 있다. Pintos에서는 내가 직접 운영체제 입장에서 시스템 콜을 구현했다. 즉, 유저 프로그램이 운영체제의 기능을 사용할 수 있도록 시스템 콜 인터페이스를 제공하는 위치에 서 본 것이다.

이를 통해 하드웨어, 운영체제, 시스템 콜, 유저 프로그램, 프레임워크, 그리고 프레임워크 위에서 개발하는 응용 프로그램 개발자까지 이어지는 계층 구조를 볼 수 있게 되었다. 대부분의 응용 프로그램 개발자는 가장 위쪽 레이어에서 개발하지만, 그 아래에는 하드웨어와 운영체제, 시스템 콜, 런타임과 프레임워크가 층층이 쌓여 있다. 이번 프로젝트를 통해 그 아래쪽 레이어들이 어떤 식으로 이어지는지 큰 구조를 잡을 수 있게 되었다.

물론 아직 부족한 부분도 분명하다. 이번에 구현한 것은 운영체제였기 때문에, 하드웨어가 어떤 방식으로 운영체제를 실행하게 하는지, 운영체제는 어떤 책임을 가지는지, 하드웨어와 운영체제의 책임은 어떻게 나뉘는지, 시스템 콜은 유저 프로그램과 운영체제를 어떻게 연결하는지 등을 일부 이해하게 되었다. 하지만 실제 운영체제가 어떤 시스템 콜들을 제공하는지, 시스템 콜을 활용해 고성능 프레임워크를 만들려면 어떻게 해야 하는지, Spring, Tomcat, Netty, Node.js 같은 프레임워크들이 내부적으로 운영체제 기능을 어떻게 활용하는지는 아직 부족하다.

그럼에도 중요한 변화는 앞으로 무엇을 공부해야 하는지가 훨씬 선명해졌다는 점이다. 운영체제, 시스템 콜, 유저 프로그램, 프레임워크, 응용 프로그램으로 이어지는 레이어가 보이기 시작했기 때문이다. 앞으로 실제 프레임워크들을 공부하거나 직접 만들어본다면, 내가 궁금해했던 “서버 개발자로서 모든 추상화 아래에 무엇이 있는가”를 더 구체적으로 이해할 수 있을 것 같다. 깊이는 아직 얕지만, 전체 구조를 그릴 수 있는 상태가 된 것이 가장 큰 성과다.

Pintos를 하면서 운영체제와 하드웨어의 책임도 조금 더 명확해졌다. 이전에는 어디까지가 하드웨어의 책임이고 어디부터가 운영체제의 책임인지 잘 몰랐다. 둘 사이의 경계가 숨겨져 있는 영역처럼 느껴졌다. 하지만 작은 운영체제를 직접 구현해 보면서 그 경계가 조금 해소되었다.

예를 들어 CPU는 단순히 레지스터 값에 따라 명령어를 실행하는 장치처럼 보인다. 실제로 CPU는 주어진 레지스터와 명령어에 따라 실행을 진행한다. 하지만 들여다보면 그렇게 단순하지만은 않다. 가상 메모리처럼 프로세스마다 다른 가상 주소 공간을 제공할 수 있는 기능은 운영체제만의 추상화가 아니라 CPU 하드웨어의 지원을 받아 동작한다. 이전에는 이런 기능을 CPU가 제공한다는 사실 자체를 잘 몰랐다. 이 경험을 통해 하드웨어가 제공하는 기능과 운영체제가 그 기능을 활용해 만들어내는 추상화 사이의 관계를 조금 더 이해할 수 있었다.

파일 시스템에 대해서도 비슷한 감각을 얻었다. 파일 시스템은 아직 더 공부해야 하지만, 이것이 얼마나 강한 추상화인지 느낄 수 있었다. 하드웨어 입장에서는 결국 디스크에 데이터를 읽고 쓰는 것뿐이다. 더 낮은 관점에서는 큰 섹터들의 집합이 있고, 거기에 데이터를 저장할 뿐이다. 그런데 운영체제는 그 데이터에 특정한 형식을 부여한다. 정해진 단위와 구조에 맞춰 데이터를 저장하고, 어떤 데이터가 다른 데이터를 가리키면 디렉토리가 되고, 그렇지 않으면 파일이 된다. 즉, 파일과 디렉토리는 하드웨어가 원래 제공하는 개념이라기보다 운영체제가 정해진 형식과 규칙을 통해 만들어낸 추상화다.

이처럼 운영체제를 구현해 본 경험은 의미 있었다. 만약 정글에 오지 않고 계속 일을 했다면, 3개월 혹은 정글 전체 기간까지 포함한 5개월 정도의 시간 동안 이 정도로 CS를 깊게 학습했을까 생각해 보면 그렇지 않았을 것 같다. 또한 앞으로 무엇을 배워야 서버 개발자로서 내가 사용하는 모든 추상화의 아래를 들여다봤다고 말할 수 있을지 스스로 답할 수 있었을까 생각해 봐도, 아마 그렇지 않았을 것이다.

결국 Pintos 자체만 놓고 보면 “운영체제의 동작을 직접 구현하면서 이해해 본 시간”이라고 정리할 수 있다. 하지만 그로부터 파생된 배움은 더 크다. 운영체제부터 서버 프레임워크까지 이어지는 추상화 계층을 드러내고, 서버 개발자로서 앞으로 무엇을 공부해야 하는지 큰 구조를 잡게 된 시간이었다.

이 경험을 통해 앞으로 프로그램을 작성하거나 프레임워크를 공부할 때도 단순히 API 사용법만 보는 것이 아니라, 그 아래에서 운영체제와 하드웨어가 어떤 역할을 하는지 더 깊게 이해할 수 있을 것 같다. 한편으로는 운영체제와 하드웨어의 경계를 조금 들여다보면서 임베디드나 하드웨어에 가까운 분야도 재미있을 것 같다는 생각이 들었다. 다만 현재로서는 서버 개발자로서의 커리어를 이어가는 것이 중요하므로, 이 관심은 가능성 정도로 남겨두고자 한다.

정리하면, Pintos를 통해 운영체제 전체를 완전히 이해했다고 말할 수는 없지만, 특정 부분에 대해서는 설명 가능한 수준의 이해를 얻었다. 그리고 하드웨어, 운영체제, 시스템 콜, 유저 프로그램, 프레임워크, 응용 프로그램으로 이어지는 개발 생태계의 큰 구조를 볼 수 있게 되었다. 무엇보다 서버 개발자로서 앞으로 어떤 부분을 더 공부해야 하는지 방향이 선명해졌다. Pintos는 단순히 운영체제 과제를 끝낸 경험이 아니라, 내가 사용하는 기술들의 추상화 아래에 무엇이 있는지 처음으로 큰 틀에서 바라보게 만든 경험이었다.

---

2부. Pintos 이후의 학습 계획

Pintos를 통해 운영체제와 서버 개발 사이의 추상화 계층을 어느 정도 볼 수 있게 되었지만, 동시에 아직 부족한 부분도 명확해졌다. 특히 운영체제 전체 과정에 대해서는 아직 잘 이해하지 못했다고 느낀다. Pintos를 구현하기는 했지만, 완성된 전체 코드를 처음부터 끝까지 뜯어보기에는 분량이 너무 많았다. 그래서 운영체제가 전체적으로 어떤 흐름으로 동작하는지, 각 컴포넌트가 어떤 책임을 가지는지에 대한 이해는 아직 충분하지 않다.

이 부족함을 해소하기 위해 먼저 XV6를 학습해보려고 한다. XV6는 MIT에서 관리하는 유닉스 스타일의 교육용 운영체제다. Pintos처럼 과제 중심으로 빈 부분을 많이 구현하는 방식이라기보다는, 최소 기능이 이미 구현된 작은 유닉스 계열 운영체제에 가깝다. 물론 XV6에도 추가 기능을 구현해보는 랩이 있지만, 기본적으로 운영체제로서 최소 기능이 어느 정도 완성되어 있다. 따라서 Pintos보다 더 작은 범위에서, 완성도 있는 운영체제의 전체 구조를 빠르게 훑어보기에 적합하다고 생각한다.

XV6를 통해 확인하고 싶은 것은 운영체제가 최소한 어떤 구조로 동작하는지, 운영체제의 핵심 책임은 무엇인지, 프로세스, 메모리, 파일, 시스템 콜 등이 어떻게 연결되는지다. 유튜브 자료나 인터넷 자료도 많을 것이므로, 이를 활용해서 운영체제의 전체 과정을 빠르게 훑어볼 계획이다. 이 학습은 대략 일주일 내외로 진행할 수 있을 것 같다.

XV6를 통해 유닉스 스타일 운영체제의 큰 흐름을 잡은 뒤에는, 실제 서버 개발 환경과 더 가까운 Linux를 기준으로 학습을 이어가려 한다. 나는 주로 Linux 서버 개발을 하게 될 가능성이 높기 때문에, Linux에서 사용되는 POSIX API들을 많이 공부할 생각이다. Pintos를 통해 느낀 것은 결국 유저 프로그램이 하드웨어 자원을 직접 다루는 것이 아니라, 시스템 콜을 통해 운영체제에 요청한다는 점이었다. 파일을 읽고 쓰는 것, 네트워크 I/O를 하는 것, 프로세스를 만들고 기다리는 것, 메모리를 사용하는 것 모두 시스템 콜을 기반으로 한다. 따라서 시스템 콜을 효율적으로, 또는 정확히 사용하려면 각 시스템 콜이 실제로 어떤 동작을 수행하는지 알아야 한다. 이 부분이 앞으로의 최우선 학습 주제가 될 것 같다.

시스템 콜 학습은 짧은 단위로 빠르게 진행하려 한다. 처음에는 C를 사용할 계획이다. 시스템 프로그래밍 자료가 C 기준으로 가장 많고, Pintos를 통해 C의 기초적인 사용 능력은 어느 정도 익혔기 때문이다. 가능하다면 단순히 API를 읽는 데서 끝내지 않고, 간단한 프로젝트를 직접 만들어보며 학습하고 싶다. 파일 I/O 관련 시스템 콜을 직접 사용해보고, 프로세스 생성과 종료 흐름을 실습하고, pipe, fork, exec, wait 같은 Unix 계열 API를 다뤄보는 방식이 될 수 있다. 또한 socket 기반 네트워크 I/O, blocking과 non-blocking I/O의 차이, 멀티플렉싱 API 같은 것도 직접 확인해보고 싶다.

최근에는 시스템 프로그래밍이나 성능 민감한 영역에서 Rust도 많이 사용되기 때문에, C로 먼저 이해한 뒤 Rust에서는 어떻게 대응되는지 비교해보고 싶다. C에서 POSIX API를 호출하는 방식과 Rust에서 같은 기능을 감싸는 방식, 두 언어의 추상화 차이, 저수준 API가 고수준 언어에서 어떻게 표현되는지를 비교하면서 학습할 생각이다.

이 학습이 얼마나 걸릴지는 명확하지 않다. 주제가 꽤 넓기 때문이다. 단순히 시스템 콜을 짧게 배우는 정도라면 2주 안에 빠르게 가져갈 수 있을 것 같다. 하지만 직접 프로젝트를 많이 하게 된다면 2~3주, 길게는 4주 정도까지도 필요할 수 있다고 본다. 우선은 시스템 콜 자체를 짧은 단위로 빠르게 학습하는 것을 목표로 하고, 가능하면 2주 내에 핵심 흐름을 잡는 방향으로 진행하려 한다.

시스템 콜의 기본 사용법을 익힌 뒤에는, 실제 시스템 코드를 사용하는 프로젝트나 대학 과제형 자료들을 활용해보고 싶다. 예를 들면 데이터베이스나 Mini-LSM, 미니 프로젝트형 시스템 과제처럼 운영체제 기능과 시스템 콜을 실제 프로그램의 목적에 맞게 사용하는 자료들이 있을 것이다. 이런 프로젝트들은 단순히 API를 배우는 것이 아니라, 시스템 콜과 운영체제 기능이 실제 프로그램에서 어떻게 사용되는지 배우는 데 도움이 될 것 같다.

Pintos를 해보면서 알게 된 것은, 이런 어려운 프로젝트들도 혼자서 완전히 불가능한 것은 아니라는 점이다. 물론 Pintos는 코치와 동료들이 있는 환경에서 진행했지만, Pintos 자체가 굉장히 난이도 높은 프로젝트였다는 점을 생각하면, 비슷한 학습도 혼자 해볼 수 있을 것 같다. 특히 지금은 AI라는 학습 보조 도구도 있기 때문에, 혼자서도 어느 정도 접근할 수 있다고 본다.

시스템 콜을 어떤 식으로 사용하는지 이해하게 되면, 실제로 많이 쓰이는 프레임워크나 라이브러리도 더 잘 분석할 수 있을 것 같다. 예전에는 프레임워크를 볼 때 단순히 API 사용법이나 내부 구조 정도만 보게 되었다면, 이제는 그 프레임워크가 어떤 시스템 콜을 사용하는지, blocking I/O를 사용하는지 non-blocking I/O를 사용하는지, 스레드 모델은 어떻게 구성되어 있는지, 커널과 유저 영역 사이의 비용을 어떻게 줄이는지, 파일과 네트워크와 메모리 자원을 어떻게 관리하는지까지 볼 수 있을 것이다. 이런 이해는 앞으로 프레임워크나 기술을 선택할 때 좋은 판단 기준이 될 수 있다. 특히 성능에 관한 이야기를 할 때, 단순히 “빠르다”, “느리다”가 아니라 왜 그런 차이가 발생하는지 더 잘 이해할 수 있을 것 같다.

물론 시스템 콜과 운영체제 레이어를 이해한다고 해서 서버 개발에 필요한 모든 문제가 해결되는 것은 아니다. 실무적으로 마주해야 할 주제는 여전히 많다. 동기화 문제, 파일 I/O, 네트워크 I/O, 엔디안 문제, 메모리 캐시, 캐시 지역성을 고려한 코드 작성, 프로토콜 기반 라이브러리 사용법, 프레임워크별 내부 구조와 사용법, 대용량 트래픽 처리, 분산 환경, 데이터베이스 사용과 설계, 비즈니스 요구사항을 반영한 개발 등 공부해야 할 것은 많다. 다만 운영체제와 시스템 콜을 먼저 이해한 상태에서 이런 기술들을 접하면, 이전과는 큰 차이가 있을 것 같다. 겉으로 드러난 API만 보는 것이 아니라, 그 아래에서 어떤 OS 기능과 하드웨어 특성이 작동하는지 함께 볼 수 있기 때문이다.

시스템 콜과 OS 레이어를 이해하고 나면, 실제 프레임워크들을 뜯어보는 수준까지는 가능할 것 같다. 그 정도가 되면 다음 단계로 무엇을 공부해야 할지는 아직 확실하지 않다. 컴파일러 쪽으로 더 내려가 볼 수도 있고, 다른 시스템 영역을 공부할 수도 있고, 서버 프레임워크 내부 구현이나 데이터베이스, 분산 시스템 쪽으로 확장할 수도 있다. 하지만 일단 그 정도까지 가면, 서버 개발자로서 기초적인 추상화 레이어들은 한 번씩 훑어봤다고 말할 수 있을 것 같다. 그 이후에는 실무적인 영역에서 구현과 문제 해결에 더 집중하게 될 것이다.

정글에 있는 동안의 개인 학습 목표는 단순히 취업 준비를 위한 활동만 하는 것이 아니다. 물론 취업을 전혀 고려하지 않을 수는 없다. 하지만 정글이라는 환경에서는, 평소라면 취업 준비 때문에 시도하지 않을 학습이나 혼자서는 하기 어려운 학습을 해보는 것이 중요하다고 생각한다. 그래서 개인 시간을 쓴다면, 단순히 면접 준비나 포트폴리오용 구현만 하기보다는 운영체제 전체 흐름 복습, XV6 학습, Linux와 POSIX API 학습, 시스템 콜 기반 미니 프로젝트, C와 Rust 비교, 프레임워크 내부 분석처럼 서버 개발의 추상화 레이어를 정리하는 방향으로 학습하고 싶다.

운영체제나 시스템 학습과 별개로 오픈소스 기여도 생각하고 있다. 다만 현재로서는 우선순위가 조금 떨어지는 것 같다. 아직 기초가 충분히 탄탄하지 않다고 느끼기 때문이다. 오히려 지금 계획한 학습을 통해 시스템 콜, OS, 프레임워크 내부 구조에 대한 이해가 생기면, 이후 오픈소스 기여도 더 빠르게 할 수 있을 것 같다. 특히 관심 있는 쪽은 Apache 계열이다. 하지만 지금 당장 Apache 쪽 오픈소스에 기여할 만큼의 기술력을 갖고 있느냐고 하면, 아직은 아닌 것 같다. 물론 직접 부딪히면서 익숙해지는 영역도 분명히 있지만, 지금 더 집중해야 한다면 먼저 기초를 다지는 쪽이 맞다고 본다.

다만 오픈소스 기여를 당장 목표로 삼기보다는, 프로젝트 한두 개를 정해서 내부를 뜯어보는 방식은 가능할 것 같다. 이 경우 목적은 기여 자체라기보다, 실제 프로젝트에서 시스템 콜과 OS 기능이 어떻게 사용되는지를 역으로 학습하는 것이다. 관심 있는 서버나 네트워크 오픈소스 프로젝트를 고르고, 시스템 콜을 사용하는 부분을 찾고, 파일 I/O, 네트워크 I/O, 스레드 모델을 분석하면서 POSIX API가 실제 코드에서 어떻게 추상화되는지 확인해볼 수 있을 것이다.

Java 쪽에서도 POSIX API가 어떤 식으로 활용되는지 확인해보고 싶다. Java는 POSIX API와 1:1로 매핑되는 구조는 아니기 때문에 직접 찾아봐야 할 부분이 많을 것이다. 하지만 Java 기반 네트워크 통신이나 파일 I/O를 더 깊게 이해하려면, 내부적으로 OS 기능을 어떻게 사용하는지 확인해보는 것이 도움이 될 것 같다. 관련해서 인프런 사전 강의가 있으므로 참고할 수 있을 것이다. Java 네트워크 API가 OS의 소켓 API와 어떻게 연결되는지, Java NIO는 내부적으로 어떤 OS 기능을 활용하는지, JVM은 파일과 네트워크 I/O를 어떤 방식으로 처리하는지, POSIX API와 Java 추상화 사이의 차이는 무엇인지 확인해보고 싶다.

결국 가장 중요한 것은 전체의 큰 틀을 훑어보는 것이다. 세부 주제는 많지만, 지금 시점에서 가장 필요한 것은 서버 개발자로서 사용하는 기술들이 어떤 레이어 위에 쌓여 있는지 전체 구조를 잡는 것이다. 따라서 앞으로의 학습 방향은 XV6로 운영체제 전체 흐름을 복습하고, Linux와 POSIX API를 학습하고, C 기반으로 시스템 콜을 실습한 뒤 Rust에서의 대응 방식을 확인하는 것이다. 이후 시스템 콜을 활용하는 미니 프로젝트를 진행하고, 실제 프레임워크와 라이브러리 내부를 분석하며, Java 네트워크와 I/O 추상화가 OS 기능과 어떻게 연결되는지 확인하고 싶다. 그 뒤에는 데이터베이스, 대용량 트래픽 처리, 분산 시스템, 실무 구현으로 학습을 확장해 나가게 될 것이다.

정리하면, Pintos를 통해 운영체제와 서버 개발 사이의 추상화 계층을 처음으로 큰 그림에서 보게 되었다. 하지만 운영체제 전체 흐름에 대한 이해는 아직 부족하므로, 먼저 XV6를 통해 작은 완성형 OS를 빠르게 훑어볼 계획이다. 그다음에는 실제 서버 개발 환경과 가까운 Linux와 POSIX API를 공부하고, C와 Rust를 활용해 시스템 콜 기반의 작은 프로젝트를 만들어보려 한다. 이를 통해 파일, 네트워크, 프로세스, 메모리 같은 OS 기능이 실제 프로그램에서 어떻게 사용되는지 이해하고 싶다.

이후에는 프레임워크와 라이브러리 내부를 분석하면서, 시스템 콜과 OS 기능이 고수준 서버 기술에서 어떻게 추상화되는지 확인할 계획이다. 오픈소스 기여도 생각하고 있지만, 당장은 우선순위가 낮다. 먼저 기초를 다지고, 이후 관심 있는 Apache 계열 프로젝트나 서버 프레임워크를 뜯어보며 실제 사용 방식을 학습하는 방향이 더 적절하다고 본다.

결국 남은 기간의 목표는 취업 준비만을 위한 학습이 아니라, 평소라면 하기 어려운 저수준 시스템 학습을 통해 서버 개발자로서 사용하는 기술들의 전체 추상화 레이어를 한 번씩 훑어보는 것이다.

아래는 이전 글에서 문장 순서, 반복 표현, 흐름이 늘어지는 부분을 정리한 개선본입니다. 내용은 유지하되, 같은 의미가 반복되는 부분은 묶고 글의 흐름이 자연스럽게 이어지도록 다듬었습니다.

3부. Pintos 이전 과정을 돌아보며

Pintos 회고는 이 정도로 마무리하고, 이제 Pintos 이전 과정들을 돌아보려 한다. Pintos 이전에는 크게 세 가지 과정이 있었다. 첫 번째는 미니 프로젝트, 두 번째는 자료구조와 알고리즘, 세 번째는 C언어와 컴퓨터 구조였다.

1. 미니 프로젝트: 정글에 적응하는 시간

먼저 미니 프로젝트는 솔직히 나에게 학습적으로 큰 의미가 있었던 활동은 아니었다. 정글이라는 환경이 어떤 분위기인지 빠르게 보여주기 위한 과정에 가까웠고, 그 이상의 의미를 크게 느끼지는 못했다.

물론 누군가는 이 프로젝트를 통해 많은 것을 얻었을 수도 있다. 하지만 내 경우에는 이미 익숙했던 개발 방식을 그대로 사용해 개발을 진행했기 때문에, 새로운 방식으로 성장했다는 느낌은 크지 않았다. 기술적으로 새로운 도전을 했다기보다는 기존에 해오던 방식으로 프로젝트를 수행한 것에 가까웠다.

다만 미니 프로젝트가 완전히 의미 없었던 것은 아니다. 정글에 빠르게 적응하는 데는 분명 도움이 되었다. 새로운 환경에서 사람들과 프로젝트를 진행하고, 정글의 진행 방식과 분위기를 파악하는 계기가 되었다. 정리하면, 학습적인 측면에서는 아쉬웠지만 적응의 관점에서는 필요한 과정이었다고 볼 수 있다.

2. 자료구조와 알고리즘: 기대보다는 작았지만 분명한 성장

그다음은 자료구조와 알고리즘 파트였다. 이 시기에는 대부분 알고리즘 문제를 많이 풀었다. 자료구조도 다루기는 했지만, 엄밀히 말하면 자료구조를 깊게 학습했다기보다는 자료구조를 직접 구현해보는 형태의 알고리즘 문제를 푼 것에 가까웠다. 그래서 실제로 진행한 활동은 자료구조 학습이라기보다 알고리즘 문제 풀이에 더 가까웠다고 생각한다.

이 과정에서 성장했느냐고 묻는다면, 효과는 분명 있었다. 문제를 읽고 접근하는 방식, 구현을 정리하는 방식, 시간 복잡도를 고려하는 감각은 이전보다 나아졌다. 다만 내가 기대했던 만큼 폭발적으로 성장하지는 않았다.

하지만 돌아보면 그 기대치 자체가 너무 높았던 것 같기도 하다. 알고리즘을 제대로 집중해서 한 기간은 약 2주 정도였고, 그 정도 시간 안에 눈에 띄게 큰 성장을 기대하는 것은 현실적으로 어려웠을 수 있다. 꾸준히 오래 쌓아야 하는 영역인데, 짧은 시간 안에 큰 변화를 기대했던 부분이 있었다.

한편으로는 내가 혼자 AI와 커리큘럼을 짜서 진행했다면 더 많이 성장할 수 있었을까 생각해보기도 했다. 그런데 꼭 그렇지는 않았을 것 같다. 정글의 구조 안에서 강제로 문제를 풀고, 다른 사람들과 풀이를 비교하고, 일정에 맞춰 학습했던 것이 어느 정도 도움이 되었기 때문이다.

그래서 이 파트는 자료구조 측면에서는 아쉬움이 남지만, 알고리즘 학습 자체는 괜찮았다고 정리할 수 있을 것 같다.

3. C언어와 컴퓨터 구조: Pintos를 위한 준비 과정

그다음은 C언어와 컴퓨터 구조 파트였다. 이 과정은 Pintos를 구현하기 전에 C언어와 저수준 개념을 준비하는 성격이 강했다. 사실상 CS:APP의 malloc 구현과 웹서버 구현 파트를 옮겨온 것에 가까웠고, Pintos에 들어가기 전 준비 과정으로는 충분했다고 생각한다.

이 과정에서는 C언어를 공부하고, malloc을 구현하고, 웹서버를 만들어보는 활동을 했다. 정확한 순서는 조금 헷갈리지만, 큰 흐름은 C언어와 메모리, 웹서버 구현을 통해 시스템 프로그래밍의 기초를 접하는 것이었다.

이 파트가 도움이 되었느냐고 하면, 도움이 된 것은 사실이다. C언어를 다루는 감각을 익히고, 메모리 할당이나 웹서버의 기본 동작을 직접 구현해보면서 이후 Pintos를 진행하기 위한 최소한의 기반을 만들 수 있었다.

다만 Pintos처럼 시야가 크게 넓어지는 느낌은 받지 못했다. 당시에는 각각의 과제를 구현하는 데 집중했기 때문에, 그것이 전체 시스템 구조 안에서 어떤 의미를 가지는지까지는 잘 연결하지 못했던 것 같다. 오히려 지금처럼 운영체제와 시스템 레이어에 대한 시야가 조금 생긴 상태에서 다시 보면, 훨씬 더 의미 있게 이해할 수 있을 것 같다는 생각이 든다.

웹서버를 구현하면서 웹서버의 역사나 동작 방식에 대해 알게 된 것도 사실이지만, 장기적인 성장이라는 관점에서 그 경험이 얼마나 큰 영향을 주었는지는 아직 명확하지 않다. 이 파트는 Pintos를 위한 준비로는 유효했지만, 그 자체만으로 깊은 전환점을 만들었다고 보기는 어렵다.

4. 기대만큼은 아니었지만, 성장은 있었다

이 과정을 거쳐 Pintos까지 진행하고 나니, 전체적으로 내가 처음 기대했던 목표치만큼 성장하지는 못했다는 생각이 든다. 하지만 그렇다고 해서 성장하지 않은 것은 아니다. 성장은 분명히 있었다. 다만 그 성장이 즉각적으로 체감되지 않았거나, 내가 기대했던 형태로 드러나지 않았을 뿐이다.

미니 프로젝트를 통해 정글에 적응했고, 알고리즘 문제 풀이를 통해 문제 해결 방식을 훈련했으며, C언어와 컴퓨터 구조 파트를 통해 Pintos에 들어가기 위한 준비를 했다. 각각을 따로 떼어놓고 보면 아쉬운 점이 있지만, 전체 흐름 안에서는 Pintos로 이어지기 위한 단계들이었다고 볼 수 있다.

특히 Pintos를 진행하고 나서야 이전 과정들이 조금씩 연결되기 시작한 느낌이 있다. 당시에는 잘 체감하지 못했던 학습들이 나름대로 쌓여 있었고, 운영체제를 구현하면서 그 의미가 조금 더 분명해졌다.

5. 다양한 사람들과의 협업에서 얻은 시야

학습적인 부분 외에도, 정글에서 시야가 넓어졌다고 느끼는 지점이 있다. 바로 다양한 사람들과 팀 프로젝트를 하고 대화를 나눈 경험이다.

실무에서 일을 하면서는 개발자 직무를 희망하는 다양한 사람들을 이렇게 많이 만나고 깊게 대화해볼 기회가 많지 않았다. 그런데 정글에는 정말 다양한 배경과 이유를 가진 사람들이 모여 있었다. 각자 개발자가 되고 싶은 이유도 달랐고, 학습 방식이나 문제를 바라보는 태도도 달랐다.

이전까지 내가 경험했던 학교나 회사 같은 환경에서는 사람들의 배경이 비교적 비슷한 편이었다. 그래서 사고방식이나 배경지식도 크게 다르지 않은 경우가 많았다. 반면 정글에서는 전혀 다른 배경을 가진 사람들과 함께 공부하고 프로젝트를 진행해야 했다. 그 경험 자체가 상당히 색달랐고, 생각보다 많은 인사이트를 주었다.

또한 같은 부트캠프를 거친 사람들끼리 생기는 공통의 경험이나 네트워크도 분명히 있을 것이라고 생각한다. 기술 학습만큼 직접적인 성장은 아닐 수 있지만, 개발자로서 시야를 넓히는 데는 의미 있는 경험이었다.

6. 수요 코딩회에 대한 아쉬움과 의미

Pintos 전까지는 학습 프로젝트 주차 사이에 수요 코딩회이라는 활동도 있었다. 이 활동에 대해서는 평가가 조금 복합적이다.

솔직히 말하면, 수요 코딩회을 통해 배울 수 있는 내용 중 일부는 강의 자료를 충분히 읽는 것만으로도 습득 가능한 지식이 아니었을까 하는 생각이 든다. 특히 AI를 활용한 바이브 코딩을 많이 하다 보니, 오히려 Pintos처럼 AI 없이 직접 부딪혀보는 시간이었으면 학습 면에서는 더 도움이 되었을 수도 있겠다고 느꼈다.

반면 AI를 사용하는 법을 익혔다는 측면에서는 도움이 된 것도 사실이다. 앞으로 개발 과정에서 AI를 완전히 배제하기는 어렵고, AI를 어떻게 활용할지 익히는 것도 중요한 역량이기 때문이다. 그런 점에서 수요 코딩회은 학습 효과 면에서는 아쉬움이 있었지만, AI 활용 경험이라는 측면에서는 의미가 있었다.

가장 아쉬웠던 부분은 시간 운영이었다. 수요일에 수요 코딩회을 하고, 목요일에 발표와 발제를 하면 목요일 오후 시간이 애매하게 비는 경우가 많았다. 발표와 발제가 끝난 뒤 점심 이후부터 저녁까지의 시간이 제대로 활용되지 않는 느낌이 있었다.

이렇게 되면 사실상 수요일과 목요일 이틀이 온전히 학습에 쓰이지 못한다. 여기에 일요일까지 쉬게 되면 한 주에 사흘이 빠지고, 실제로 집중해서 학습할 수 있는 시간은 나흘 정도밖에 남지 않는다. 이 점이 꽤 아쉬웠다.

차라리 수요 코딩회 같은 활동이 매주가 아니라 격주로 진행되거나, 학습에만 온전히 집중할 수 있는 하루나 이틀이 더 확보되었다면 더 많이 성장할 수 있지 않았을까 싶다. 물론 새로 도입된 활동이라 시행착오가 있었을 수는 있다. 하지만 학습 몰입의 관점에서는 개선의 여지가 있었다고 생각한다.