코드 리뷰를 그만두었다: 백엔드 개발자의 Google Gemini 실험
Source: Dev.to
Google Gemini와 함께 만들기: 글쓰기 챌린지
제출: Google Gemini와 함께 만들기: 글쓰기 챌린지
개요
🦄 저는 이제 거의 1년째 AI에 공식적으로 집착하고 있습니다. 머신러닝 연구 관점도 아니고, 순수 구현 관점도 아닙니다. 저에게 스릴은 사용자의 입장에서 한계점을 찾아내고, 그 한계에 기대어 무언가가 무너지기를 기다리는 데 있습니다. 제가 가장 좋아하는 헌터 S. 톰프슨의 명언 중 하나는 “가능한 한 멀리 밀어붙이는 경향”에 관한 것입니다. 바로 그 것이 올해 내내 제가 따르고 있는 운영 원칙이었습니다.
이 프로젝트는 포트폴리오 실험으로 시작되었습니다. 그런데 전혀 다른 무언가로 변모했습니다. 도전 과제는 구현 루프를 벗어나 모델이 스스로 세상을 구축하도록 할 때 실제로 어떤 일이 일어나는지를 가장 깔끔하게 테스트할 수 있는 환경을 찾는 것이었습니다.
Google Gemini로 만든 것
New Year, New You 포트폴리오 챌린지를 보았을 때 UI가 필요하다는 것을 알았습니다. 그것은 놀라운 일이 아니었습니다. 놀라웠던 점은 작업이 진행되면서 내가 무엇을 보고 있는지 금방 이해하지 못했다는 것이었습니다.
저는 백엔드 개발자입니다. 분산 시스템 문제를 주면 기꺼이 몇 시간을 들여 풀어냅니다. 브라우저에서 div를 보이게 해 달라고 하면 뇌가 바로 탈출구를 찾으려 합니다. 일주일에 단 하루만 투자해서 만들다 보니 “눈을 뜨고 지나치는” 단계에 여유가 없었습니다. Google Gemini가 구현하고 제가 감독한다—그게 전부 계획이었습니다.
저는 Antigravity가 주로 Gemini Pro에 의해 구동될 것이며, 지금까지 테스트해 본 모든 AI 시스템처럼 예측 가능하고 가드레일 안에 머무르기 쉬울 것이라고 기대했습니다. 저는 이미 그 가드레일이 어떤 모습인지 알고 있다고 생각했습니다: 엄격한 타입, 린팅, 그리고 익숙한 코드 리뷰 루틴.
전환점: 코드‑리뷰 의식 버리기
처음에는 “책임감 있는” 패턴을 따랐습니다: 프롬프트, 차이점 검토, 테스트 실행, 승인. 규칙적인 느낌이었고, 전문적으로 보였습니다.
하지만 곧 프론트엔드 스택에서 내가 검토하고 있는 내용에 대한 의미 있는 맥락이 없다는 것을 깨달았습니다. 결과물을 개선하고 있는 것이 아니라 의식에 참여하고 있는 것이었습니다. 그래서 코드를 전혀 리뷰하지 않기로 했습니다.
코드 라인을 검증하는 대신, 결과를 검증했습니다. UI가 올바르게 렌더링되고 기능 테스트를 통과하면 그것이 성공이었습니다. 자율성을 높이고, Antigravity에게 내 저장소 기대치를 가르쳐 주며 그대로 진행하게 했습니다. Copilot이 내 대신 코드를 리뷰하고, Gemini는 폐쇄 루프에서 응답했습니다. 나는 구현에서 물러나 시스템 감사자의 역할을 맡게 되었습니다.
데모
이 포트폴리오 반복은 정의된 시스템 안에서 에이전트를 풀어놓았을 때 어떤 일이 일어나는지를 문서화합니다.
이번 빌드에서는 Antigravity 패널이 주요 인터페이스였습니다. 저는 그곳에 저장소 규칙과 테스트 기대치를 정의했고, Gemini는 그 구조 안에서 직접 구현되었습니다. 이것은 전체 루프의 제어 표면이 되었습니다.
- V1 릴리스: 보존된 버전 v1.1.0
- 실시간 포트폴리오:
신뢰를 시스템으로 대체하기
나는 단순히 감시를 없앤 것이 아니라 라이트하우스 감사와 확대된 테스트 커버리지를 도입했다. 내 가정은 간단했다: 브라우저가 정상적으로 동작하고 테스트가 통과하면 코드가 “안전”하다는 것이었다. 나는 코드에 대한 신뢰를 시스템에 대한 신뢰로 바꿨다고 믿었다. 하지만 나는 틀렸다—테스트 통과와 구조적 완전성을 혼동한 것이다.
Source: …
배운 점
고급 추론은 선택 사항이 아니다
자율 개발에서는 추론 깊이가 안정성 요구사항이다. 낮은 추론 모드(예: Flash)를 사용할 때는 변경 사항이 종종 부분적이었으며—파일의 2/3를 업데이트했지만 테스트나 문서를 “잊어버렸다”.
Gemini Pro에서 High Reasoning 모드로 전환하면서 패턴이 바뀌었다. 런타임 오류가 감소했고 파일 간 일관성이 향상되었다. Gemini는 결국 코드 변경에 맞춰 문서를 정렬하는 것을 “기억”하기 시작했으며, 지속적인 재촉이 필요 없었다.
추론 깊이는 순수 지능과는 관계가 없었다—자율성 하에서의 신뢰성에 관한 것이었다. Gemini의 더 깊은 추론과 컨텍스트 유지 덕분에 폐쇄 루프 워크플로가 가능해졌으며, 그렇지 않으면 파일 간 일관성이 자율성 하에서 빠르게 무너졌다.
현실 점검: Sonar
성공적인 빌드의 흥분이 가라앉은 뒤, 나는 회고 감사로 Sonar를 도입했다. UI는 정상적으로 렌더링되었고, 테스트도 통과했다. 모든 것이 안정적으로 보였다.
Sonar는 13개의 신뢰성 문제를 보고했으며 프로젝트에 C 신뢰성 등급을 부여했다. 이 문제 중 66 %는 고위험으로 분류되었다. 보안 검토에서는 기본 Python 이미지를 루트 사용자로 실행하는 컨테이너와 전체 커밋 SHA를 고정하지 않은 종속성 참조 등 세 가지 핫스팟이 드러났다.
유지보수성은 A 등급을 받았지만 여전히 70개의 유지보수성 문제가 존재했다—동작을 깨뜨리지는 않지만 장기적인 복잡성을 증가시키는 구조적 패턴들이다.
그 순간 자신감이 면밀한 검토로 바뀌었다.
애플리케이션은 동작했고, 테스트는 통과했다. 하지만 신뢰성, 보안 태세, 구조적 무결성은 다른 이야기를 전했다. 테스트는 동작을 검증했으며, Sonar는 가정을 검증했다. 그리고 그것들은 같은 것이 아니다.
# Son?
**AI가 생성한 테스트는 구현을 만족하도록 작성되었기 때문에 통과할 수 있지만, 이를 도전하게 만들지는 않는다.**
구조적 검증은 생성 루프 외부의 독립적인 검토 레이어를 필요로 한다.Google Gemini 피드백
잘된 점
- 통합 구현: 고‑추론 Gemini Pro가 저장소의 의도를 존중하는 파일 간 변경을 수행했습니다.
- 에이전트형 오케스트레이션: 모델 전환이 매끄러웠으며, 오케스트레이션 인터페이스를 통해 기대치를 명확히 정의하고 일관되게 적용할 수 있었습니다.
마찰이 있었던 부분
- 쿨다운 투명성: 인터페이스가 현재 크레딧이 언제 갱신되는지는 보여주지만, 다음 쿨다운 기간은 알 수 없습니다.
- 도구 성능: MCP 응답성이 반복 속도에 큰 영향을 미쳐, 때때로 작은 빠른 증분 작업 대신 요청을 일괄 처리해야 했습니다.
💡 팁: 모델 페이지에 다음 쿨다운이 정확히 얼마나 길지(예: “다음 쿨다운은 X시간입니다”) 표시된다면 UX가 크게 개선될 것입니다. 잠금 기간이 1시간인지 96시간인지 아는 것은 개발자 계획에 필수적입니다.
최종 결론: 자율성은 여전히 감사를 필요로 한다
교훈은 Gemini가 실패했다는 것이 아니라, 시스템‑레벨 신뢰는 테스트 통과만으로는 충분하지 않다는 것이다. 앞으로의 빌드에서는 자율성이 명시적인 적대적 감시 없이는 출시되지 않을 것이다. 이는 필수 Sonar 게이트, 레드‑팀 프롬프트 통과, 혹은 첫 번째 모델의 단축을 찾아내도록 지시된 두 번째 고‑추론 모델을 의미하든—루프는 반드시 도전받아야 한다.
이 프로젝트는 프런트엔드 개발의 “텔레포테이션” 안개에서 벗어나기 위한 주말 실험으로 시작되었다. 결국 시스템‑레벨 신뢰의 얇은 가장자리를 탐구하는 과정으로 끝났다. 실제 빌드는 포트폴리오가 아니라, AI의 한계에 기대어 그 한계가 결국 무너지게 될 때 무슨 일이 일어나는지를 발견하는 것이었다.
구현 루프에서 나를 배제했다고 해서 책임이 사라진 것은 아니다; 오히려 책임이 재정의된 것이다. 에이전트에게 자유를 많이 줄수록 감사는 더 엄격해야 한다.
🛡️ 커튼 뒤의 도구들
이 글은 저와 구글 제미니 한 잔, 그리고 챗GPT 한 스푼을 섞어 만들었습니다. 편향이나 실수가 보이면 알려 주세요. AI도 완벽하지 않으며, 저도 마찬가지입니다.