부제 : 컴퓨터 전공자로서의 바이브 코딩의 우울
오늘 전 클로드 코드에게 물었습니다. 내가 하는 방식이 맞아 ?
늘 그렇듯이 장황하게 근거를 대며 "잘 하고 계십니다"라고 했습니다. 전 또 의심의 눈초리로 쳐다 보고 "내가 칭찬을 하도록 훈련되있는걸 알기에 별로 위로가 안된다." 라고 대답했습니다. 하지만 그래도 없는 위로보다는 낫고, 그 구체성에 대해 계속 파고들었습니다. 학부생때와 달리 정답을 가르쳐줄 교수님이나 선배님들도 없으니까요.
저는 요즘 코드를 짜지 않습니다. 요구사항을 전달하고, 진행 사항을 감독합니다.
특히 요즘 고민은 개발 프로세스와 품질 입니다. sw란 규모가 커질 수록 ai가 읽어들일 수 있는 컨텍스트양을 쉽게 넘어버립니다. 컨텍스트 안에서도 혼란해 하는데 이를 넘는 커다란 코드를 작은 ai의 정신줄을 가지고 지속적으로 컨트롤 하는 것은 쉬운 일이 아니고, 컨텍스트 엔지니어링이란 용어에 이어 최근 하네스 엔지니어링이라는 용어도 등장했습니다.
저는 그래서 소셜에서 좋은 레퍼런스가 있다고 하면 우선 ai 에게 주고 naia 프로젝트에 반영할 점이 있는지를 분석시키고 이를 적용하고 있습니다. 그러면서 모르는 용어에 대해 물어보고 배우는 바도 많습니다.
하지만 잘하고 있는지 정말 최선을 이야기한건지는 늘 의심이듭니다. 이 의심에는 근거가 있었습니다. 어느 날 AI가 리뷰를 했다고 했는데 실제로 파일을 읽은 흔적이 없었습니다. 코드를 빼먹고, 범위를 잘못 잡고, 보지도 않고 봤다고 합니다. 2회차 클린 될때까지 반복 리뷰하라고 했더니, 3회차 정도 되면 답변 뒤에 그대로 리뷰했다고 하고 발견 안했다고 하는 대답을 덧 붙여서 통과해버립니다. 생각해보면 LLM구조상 그게 그럴듯한 대답이니 까 덧 붙힌거겠죠. 이쯤되면 끝나는게 보통이겠지 ? 하고 자기가 대답하고 자기가 진실인양 믿어버리는거죠.
오늘은 moai sdk를 개발하신 구스킴님의 발표를 들었습니다. 해당 프로젝트를 받아서 또 분석을 시켰으며 프로젝트의 개선점을 찾았습니다. #87이슈 이번에 찾은건 EARS라는 걸 쓰고 있었습니다. Rolls-Royce에서 나온 항공우주 요구사항 표준인데(IEEE RE'09), Amazon이 2025년에 AI-native 개발에 채택했습니다. AI가 "완료"의 기준을 이슈마다 다르게 해석하는 문제를 구조화된 문법으로 막는 방식이라고 합니다.
이러한 행위를 반복 하며 프로젝트의 ai기반의 개발프로세스를 계속 개선해보고 있습니다. jikime-adk, arXiv 논문들, Google Cloud의 Dueling LLMs, Thoughtworks의 Spec-Driven Development을 분석 개선 시켰습니다.물론 이걸 제가 다 알아서 라기보다는 이것 역시 클로드가 분석한 내용들입니다.
LangChain의 open-swe를 분석시켜 AI가 빈 응답으로 리뷰를 때우는 걸 막는 패턴인 ensure_no_empty_msg 패턴을 적용했었고 jikime-adk에서는 커밋 메시지에 ## AI Context 섹션을 넣어 세션이 끊겨도 git log가 복원 소스가될수 있도록 AI가 내린 결정과 발견한 함정을 기록하는 패턴을 적용했습니다.
공통적으로 각자 독립적으로 비슷한 문제를 풀고 있었습니다.
그런데 이 방법이 맞나.. 싶은게 여전합니다. 프랑켄슈타인이 되어가는건 아닌지 걱정스럽고 전공자로서 이상합니다. 어쨌던 교과서가 없고 최선이라는 근거가 부족합니다.
우리가 쓰던 소프트웨어 공학 방법론은 전부 수십 년 실패가 쌓여서 나온 겁니다. Agile이 나온 건 Waterfall이 계속 실패해서고, TDD도 테스트 없이 개발하다 계속 터져서 나왔기에 근거가 있습니다.
하지만 제가 지금 합쳐놓은 것들은 서로를 위해 설계된 게 아닙니다. 항공우주 표준이랑 한국 인디 개발자랑 LangChain 에이전트가 한 시스템 안에 있습니다.
이러한 불안함에 외부 연구들을 뒤져보게도 시켰습니다. V-Bounce 논문(arXiv 2408.03416)은 AI 시대에 인간 역할이 구현자에서 검증자로 바뀐다고 주장합니다. 맞는 말인데 이론만 있고 구현체를 찾지 못했습니다. Thoughtworks의 Spec-Driven Development는 특정 도구에 종속됩니다. Anthropic 내부에서는 Claude Code 코드의 90%를 Claude Code가 작성한다고 하면서 방법론은 공개 안 했습니다.
결국 지금 AI로 진지하게 개발하는 사람은 전부 각자 만들어가고 있습니다. 기준이 없습니다.
그래서 요즘 하는 게 이 프랑켄슈타인이 실제로 작동하는지 측정하는 방법을 찾는 겁니다. CI가 실패해도 머지가 됐고, 리뷰했다는 텍스트가 있는데 파일을 읽은 흔적이 없었습니다. 방법론은 설계됐는데 강제가 안 됩니다. 시스템이 있는 것 같은데 작동하는지 모릅니다. 그걸 확인하는 유일한 방법은 LLM이 아닌 코드가 만드는 정직한 숫자를 만들거나 LLM을 쓰더라도 통계적으로 좋아지고 있음의 "숫자"를 도출해야 할것 같습니다. 프로젝트에서 반복되는 실패를 주기적으로 분석하여 ai 가 개선을 제안하게 하고, 컨텍스트와 하네스엔지니어링의 성능 평가를 통해 나아지고 있음을 측정하게 하는 일에 대한 고민이 있습니다.
지금은 그저 고삐 꽉 잡고 앞으로 가는 중입니다. 어디로 가는지는 아직 모르겠지만 장님이 아니길 바랍니다. 고삐를 만들고 있는
데 사실 말을 처음 탔거든요. 그게 바이브 코딩을 붙들고 있는 하네스 같습니다.
