학부 과제 코딩보다 배포와 운영 한 번이 남긴 것

학부 프로젝트의 공허함: 점수용 코딩이 남긴 것

컴퓨터공학과 4학년이 되었을 때 손에 남은 건 공허함뿐이었다.

솔직히 학점이 썩 좋지도 않았다. 수학에 별 흥미가 없어서 알고리즘이나 이산수학 같은 과목은 늘 버거웠고, 학부 프로젝트도 교수님이 준 평가표와 시연 시나리오에 맞춰 점수만 채워 넣는 식이었다. 정해진 목표와 예시 코드만 기계적으로 따라가다 보니, 왜 이 구조를 골랐는지 고민하고 설계하는 과정은 쏙 빠져 있었다.

돌아보면 이것저것 손댄 건 제법 많았다. 컴파일러도 직접 깎아봤고, 제안요청서를 받아 데이터베이스 설계부터 웹 서비스 구축까지 해봤다. LLM 기반 자격증 정보 챗봇도 만들었다.

그런데 프로젝트가 끝나고 깃허브 레포지토리를 둘러보면 막상 포트폴리오에 올릴 만한 게 없었다. 코드는 어떻게든 돌아갔지만, 왜 이렇게 설계했는지 근거가 없었다.

제출하고 나면 다시는 열어보지 않는 과제들 속에서, 코딩은 그저 요구사항을 타이핑해 옮겨 적는 노동에 지나지 않았다.

AI 쇼크와 무력감, 그리고 부사관 고민

21학번으로 입학해 2022년에 입대했고, 전역 후 복학했을 때 개발 판은 딴 세상이 되어 있었다. 이미 AI가 코드를 술술 짜내고 있었다.

충격이었다. 객체지향 프로그래밍이나 특정 프레임워크 문법을 깊게 파는 게 대체 무슨 의미가 있나 싶었다. 그때까지 내가 알던 개발자는 ‘코드를 쳐서 프로그램을 돌아가게 만드는 사람’이었는데, 그 일은 이미 AI가 나보다 훨씬 빠르고 정확하게 끝내고 있었다.

코드를 치는 속도와 정확도로 AI를 이길 수 없다면, 앞으로 개발자로 밥벌이나 할 수 있을까 하는 불안이 엄습했다.

AI에게 완전히 밀렸다는 생각이 머릿속을 떠나지 않았다. 4학년이 되도록 서비스를 직접 배포하거나 운영해 본 경험이 없었으니 무력감은 더 깊었다.

진로에 회의감이 들어 실제로 부사관 입대를 진지하게 고민할 정도였다. 4학년 2학기가 되어야 클라우드 인프라 과목이 열린다는 걸 알았지만, 학교 정규 수업만 듣고 있어서는 이 갈증을 채울 수 없다는 결론이 섰다.

배포와 운영이 가르쳐준 현실: 에러가 없는데 왜 터지는가

전환점은 3학년 겨울방학에 불쑥 찾아왔다. 방학 때 너무 심심해서 들어갔던 마인크래프트 서버에서 운영진과 친해진 게 시작이었다.

서버 유저 온보딩 과정을 옆에서 보니 일일이 손으로 처리하느라 비효율이 이만저만이 아니었다. 저걸 자동화해주면 서버에도 도움 되고 내 공부도 되겠다는 생각에 가벼운 마음으로 rpg-sync 개발을 시작했다.

처음에는 웹 풀스택과 디스코드 봇 개발에 매달렸지만, 유저를 받고 서비스를 굴리려니 자연스레 클라우드 인프라를 공부해야 했다. 그리고 여기서 1학년 때 코딩을 처음 배웠을 때 느꼈던 재미가 다시 살아났다.

내 컴퓨터 안에서 도는 코드와 실제 운영 환경 사이의 격차는 생각보다 아팠다.

로컬에서는 컴파일 에러나 런타임 에러만 안 나면 그만이었다. 네트워크 지연(RTT), 데이터베이스 I/O 병목, 캐시, 서버 리소스 한계 따위는 안중에도 없었다.

하지만 바깥 네트워크에 올라가 실제로 숨 쉬는 서비스는 딴판이었다. 코드에는 오타 하나, 문법 에러 하나 없는데 트래픽이 몰리면 병목이 생기고 프로세스가 죽었다.

로컬에서 에러 없이 도는 코드와, 네트워크 위에서 살아남는 서비스는 전혀 다른 이야기였다.

GCP 무료 티어 VM의 팍팍한 하드웨어 리소스 안에서 프로세스가 뻗지 않도록 쥐어짜는 최적화를 계속했다. 서버가 멈출 때마다 지나간 로그를 뜯어보며 병목을 쫓았고, DB 커넥션 풀이 마르지 않게 설정을 조율했으며, 초기에 짠 JWT 매직링크 인증 흐름에서 예외가 터지지 않는지 확인했다.

단순히 코드를 쳐내는 일에서 벗어나, 시스템이 실제로 살아서 버티게 만드는 엔지니어링의 기본기를 몸으로 부딪치며 배운 시간이었다.

도구의 하청을 넘어 시스템의 통제자로: 하네스 파이프라인

rpg-sync를 운영하며 4학년 1학기를 마쳤지만, 학교 수업에는 여전히 내가 목말라하던 실전 인프라 내용이 없었다. 2학기 등록을 미루고 부트캠프를 택했다.

부트캠프에서 배운 내용을 블로그로 정리해보라는 조언을 받았다. 하지만 강의 교재를 그대로 베껴 치는 건 시간 낭비였고 배울 점도 없었다. 무엇보다 그렇게 쓰면 귀찮아서 며칠 못 가 포기할 게 뻔했다.

그래서 배운 내용을 기록하는 일 자체를 에이전트 자동화 파이프라인으로 짰다.

수업 시간에 따로 찾아본 기술 자료나 이전 프로젝트를 하며 겪었던 고민을 코드 주석(''' ... ''')과 분석 메모로 적어두었다. 그리고 에이전트가 공식 강의 요약과 내 메모를 교차검증해서 깊이 있는 글을 뽑아내도록 만들었다.

하지만 에이전트를 실제 파이프라인에 얹어보니 온갖 문제가 튀어나왔다.

• 규격의 왜곡: 처음에 모든 글에 다이어그램을 강제했더니, 명령어 몇 줄 적는 글에도 억지 플로우차트를 그려댔다. 표와 구조화 차트까지 허용하도록 규격을 넓혔다.
• 주객전도: 네트워크 패킷 분석 글인데도 린터를 통과하겠다고 보조 파이썬 코드를 끌고 와 엉뚱하게 코드 diff에 매달리는 일이 벌어졌다. 과목 성격에 맞춰 주 산출물 무게중심을 다시 잡았다.
• 가상 코드 날조: 자율성을 조금만 넓게 주면 존재하지도 않는 파일 경로와 함수를 진짜인 양 지어냈다. 로컬 레포지토리에 실제 파일이 있는지 파이썬으로 직접 대조하는 하드 가드를 심어 원천 차단했다.

프롬프트로 주의를 주는 수준(소프트 가드)으로는 AI의 환각을 막지 못했다. 셸 스크립트와 파이썬 코드로 단단한 하드 가드를 걸고, 배포 직전 내가 직접 확인하는 컨펌 단계를 두고 나서야 비로소 믿고 쓸 수 있는 파이프라인이 됐다.

AI가 코드를 대신 짜주는 걸 보며 무력감에 빠졌던 내가, 이제는 에이전트가 딴길로 새지 못하게 규칙을 걸고 다루게 된 것이다.

회고: 아직 이룬 것은 없지만, 건져 올린 기준 하나

솔직히 나는 아직 졸업장도 없고 어디 번듯하게 취업한 개발자도 아니다. 여전히 매일 모니터 앞에서 밑천이 드러나는 걸 실감하며 공부하는 4학년 휴학생이자 취준생일 뿐이다.

하지만 제출용 과제 코딩에서 벗어나 배포와 운영을 겪어보고, 에이전트를 통제하는 하네스를 직접 만들며 기준 하나만큼은 확실히 세웠다.

개발자의 일은 단순히 키보드로 코드를 빠르게 찍어내는 데 있지 않았다. 코드가 돌아가는 걸 넘어, 시스템이 어디서 어떻게 터질지 실패 지점을 먼저 의심하고 버텨내게 만드는 게 진짜 엔지니어링이었다. 학부 과제 점수는 정해진 시나리오를 통과했다는 확인서에 불과했다. 진짜 공부는 에러가 없는데도 터지는 실전 환경을 마주하고, 그 불확실성을 기계적인 시스템과 규칙으로 통제해 나가는 과정에서 시작됐다.

대단한 성과를 자랑할 순 없지만, 적어도 무엇을 경계해야 하고 어디를 파고들어야 하는지는 분명해졌다. 앞으로의 준비와 프로젝트 역시 단순히 코드 줄 수를 늘리는 데 급급하지 않고, 내가 만든 시스템이 과연 살아남을 수 있는지 집요하게 의심하는 태도로 채워가려 한다.