핵심 역량 목표
-
문제해결
- 책 내용을 먼저 학습하고, 우리가 구현해야 하는 함수나 기능이 어떤 역할을 하는지 스스로 명확히 설명할 수 있도록 한다.
-
구현
- 최대한 책을 읽고, 책에 나온 코드를 이해한 뒤 이를 참고하여 직접 구현한다.
-
태도
- 지각하지 않고 아침 10시까지 꼭 교육장에 도착한다.
-
협업
- 혼자 나가서 공부하기보다 팀원들과 함께 교육장에서 공부하며 동료 학습과 협업을 적극적으로 진행한다.
-
AI 활용
- 구현 단계에서는 AI 사용을 최소화하고, 학습 단계에서는 AI를 적극적으로 활용한다.
핵심 역량 목표 평가
1. 문제해결
proxy를 제외한 책의 내용은 전부 학습했다. 단순히 읽고 넘기는 것이 아니라 코드를 직접 따라 쳐 보면서 확인했고, 각 함수가 어떤 역할을 하는지에 대해서도 어느 정도 설명할 수 있게 되었다.
2. 구현
처음에는 책의 코드를 그대로 따라 치기보다는, 책을 참고해 초반 틀만 잡고 내가 이해한 개념대로 직접 구현해보려고 했다.
그런데 막상 진행해보니 쉽지 않았다. 이전 장에서 등장했던 RIO, 파일 디스크립터, 여러 시스템 콜과 관련된 함수 및 변수들을 충분히 이해하지 못한 상태였기 때문에, 혼자 힘으로 코드를 작성하는 것이 거의 불가능했다.
그렇다고 책을 무작정 그대로 따라 치는 방식도 큰 도움이 되지 않는다고 느꼈다. 왜 이런 코드가 필요한지, 각 흐름이 어떤 의미를 가지는지 이해하지 못한 채 입력만 반복하는 느낌이 강했기 때문이다.
그래서 중간부터는 방식을 바꾸었다. Codex에게 바로 코드를 짜달라고 하기보다는, 먼저 자연어 의사코드 형태로 정리해달라고 요청했다. 그리고 그 의사코드를 바탕으로 전체 흐름을 이해한 뒤, 실제 코드는 내가 직접 작성하는 식으로 진행했다.
이 방식이 현재 내 수준에서는 가장 적절한 타협점이라고 느꼈다.
3. 태도
하루 공부량 자체는 적지 않았지만, 생활 패턴에서 아쉬운 점이 있었다.
기숙사에 너무 일찍 들어가면 스스로에게 보상을 주고 싶은 심리가 생겨 유튜브를 보게 되었고, 그 결과 잠드는 시간이 점점 늦어졌다.
그러다 보니 아침 9시에 일어나더라도 바로 준비하지 못하고, 룸메이트가 씻는 시간과 겹치면 다시 침대에 누워 있다가 9시 30분쯤이 되어서야 움직이게 되었다. 그렇게 씻고 준비해서 나오면 교육장 도착 시간이 대략 10시 5분 정도가 되곤 했다.
결국 공부 자체도 중요하지만, 일찍 자고 일찍 일어나는 생활 습관을 만드는 것이 반드시 필요하다는 점을 느꼈다.
4. 협업
이번 주에는 한 번도 혼자 밖에 나가서 공부하지 않았고, 계속 팀원들과 함께 교육장에서 공부했다.
덕분에 막히는 부분이 생겼을 때 바로 의견을 주고받을 수 있었고, 혼자 고민할 때보다 훨씬 빠르게 문제를 이해할 수 있었다. 동료들과 함께 학습하고 구현하는 방식이 확실히 더 효율적이라는 것을 다시 느꼈다.
5. AI 활용
구현 단계에서는 AI 사용을 최소화하려고 했지만, 실제로는 완전히 배제하지는 못했다.
특히 코드 자체를 맡기기보다는 의사코드 작성을 맡기는 방식으로 활용했다. 결과적으로 목표를 완벽히 지키지는 못했지만, 적어도 AI가 만들어준 결과물을 그대로 가져다 쓰기보다는, 내가 이해하고 소화할 수 있는 형태로 변환해서 활용하려고 노력했다는 점에서는 의미가 있었다.
회고
이번 주에는 tiny.c, echo.c 등을 구현하면서 소켓부터 서버까지 이어지는 네트워크 프로그래밍의 흐름을 직접 경험해볼 수 있었다.
백엔드 개발자를 희망하면서도, 그동안은 네트워크의 로우 레벨 동작 과정에 대해 깊게 생각해본 적이 많지 않았는데, 이번에는 개념 학습과 구현을 함께 진행하면서 이전보다 훨씬 구체적으로 이해할 수 있었다.
특히 단순히 HTTP 요청을 주고받는 수준이 아니라, 서버가 소켓을 열고 연결을 받고 요청을 처리하는 흐름을 코드로 따라가 보면서 “백엔드 서버가 실제로 어떻게 동작하는가”를 조금 더 현실감 있게 느낄 수 있었다.
이번 주 학습은 앞으로 백엔드 개발을 공부하는 데 있어서 꽤 중요한 기반이 될 것 같다는 생각이 들었다.
수요 코딩회
이번 수요 코딩회에서는 저번 주에 만들었던 SQL Processor와 B+ Tree를 기반으로, 클라이언트와 HTTP 통신이 가능한 DB 서버로 발전시키는 작업을 진행했다.
이번 프로젝트를 진행하면서 가장 크게 느낀 점은, AI를 어떻게 활용해야 프로젝트가 블랙박스가 되지 않는가에 대해 나름의 기준이 생겼다는 것이다.
예전에는 AI에게 바로 구현을 맡기면 결과물은 빨리 나오지만, 팀원 모두가 그 코드를 충분히 이해하지 못하는 경우가 많았다. 그러다 보니 개발 속도는 빨라질 수 있어도, 정작 발표나 디버깅, 기능 수정 단계에서는 오히려 비효율이 생기곤 했다.
그래서 이번에는 Codex의 플랜 모드를 그대로 쓰기보다는, 먼저 GPT를 활용해 plan.md를 만든 뒤, 그 문서를 기준으로 구현을 진행하는 방식을 택했다.
우리가 작성한 plan.md는 크게 세 가지를 중심으로 구성했다.
-
AI가 절대 해서는 안 되는 행동을 명시한다.
예를 들어, 기존 구조를 임의로 무너뜨리거나, 요구사항에 없는 과도한 리팩토링을 하거나, 우리가 이해하지 못할 수준으로 코드를 한 번에 크게 바꾸는 행동을 금지했다. -
AI에게 시킬 일을 최대한 명확하게 명세한다.
단순히 “이 기능 구현해줘”가 아니라, 어떤 파일에서 어떤 함수와 어떤 역할을 추가해야 하는지를 최대한 구체적으로 적었다. -
무조건 단계별로 진행하게 하고, 각 단계마다 통과 조건을 둔다.
한 번에 큰 범위를 맡기는 대신, 작은 단위로 끊어서 진행하고, 각 단계가 끝날 때마다 “이 상태면 통과”라고 볼 수 있는 기준을 설정했다.
추가로 plan.md 안에는 구현해야 할 함수와 기능들에 대한 자연어 의사코드도 자세히 작성했다.
팀원들은 이 의사코드를 함께 읽고, 각 단계의 흐름과 의도를 먼저 이해했다. 이해가 잘 안 되는 부분이나 수정이 필요한 부분이 있으면 AI에게 맡기기 전에 먼저 팀원들끼리 수정했다.
이 과정을 거치면서 느낀 점은, plan.md를 팀원 전체가 충분히 이해한 상태라면, 이후 AI가 작성하는 코드 역시 더 이상 블랙박스가 아니라는 것이다.
왜냐하면 AI는 결국 우리가 정리한 계획에 따라 구현하게 되고, 우리는 그 계획의 의도와 단계별 목적을 이미 알고 있기 때문이다.
결국 이번 수요 코딩회를 통해 얻은 가장 큰 수확은 단순히 기능을 구현한 것이 아니라, AI를 팀 단위 개발에서 이해 가능한 도구로 활용하는 방법을 조금씩 정립하게 되었다는 점이다. 앞으로도 AI를 사용할 때는 무작정 구현을 맡기기보다, 먼저 계획을 구조화하고 팀원들과 이해를 맞춘 뒤 사용하는 방식을 계속 발전시켜 나가고 싶다.
