AI 코딩 툴 어떤 거 쓰세요?
구글 IO 2023은 제 커리어에서 정말 기억에 남는 순간이었습니다. 구글 CEO 순다 피차이가 무대에서 보여준 데모 코드의 일부는 제가 리뷰했던 코드였거든요.
당시 구글의 플래그쉽 모델이었던 PaLM이 버그를 고쳐줄 뿐만 아니라, 주석을 한국어로도 달아줄 수 있다는 데모였습니다. 당시 Bard(현 Gemini App)가 처음으로 지원하는 외국어로 한국어와 일본어로 발표되기도 했습니다.
이 15초짜리 데모를 준비하는 비하인드 스토리를 말하자면, 몇몇 한국인 구글러들과 단톡방을 만들어 “LLM이 버그를 고치는 최고의 데모”가 뭔지 스프레드시트에 모아 놓고, 잘 되는지, 실수한 것은 없는지, 그리고 너무 쉬운 것은 아닌지 토론했었습니다. 저는 개인적으로 자주 헷갈리던 DFS 예시를 해보았는데, PaLM이 깔끔하게 고치는 걸 보고 바로 후보로 올려 놓았습니다.
그 다음 주, 제가 넣은 예시 후보가 전 세계 앞에서 순다의 라이브 데모로 나가는 것을 보고 정말 짜릿했던 기억이 납니다. 구글 커리어에서 그 전이나 앞으로나 제가 쓰거나 리뷰한 코드 중, 가장 많은 사람들에게 임팩트가 간 코드가 될꺼라고 농담하곤 했습니다.
그게 벌써 2년 전 이야기이네요. 2025년 현 시점, 위 예시를 생각하면 비웃음이 나올 정도로 AI 코딩 에이전트의 능력과 사람들이 쓰는 방식은 정말 믿기 힘들 정도로 빨리 변하고 있습니다. “소프트웨어 엔지니어라는 직업이 사라질 것이다”라는 말도 나오죠. 바이브 코딩만으로 소프트웨어를 뚝딱 만든다면, 비싼 엔지니어가 왜 필요하냐는 말이 나올 정도로 성능이 좋습니다.
소프트웨어 엔지니어의 직업 안정성에 대한 주제로 들어가기 전에, 제가 요즘 AI 코딩 툴을 어떻게 쓰는지 경험 상아 공유해보려 합니다. 아마 저보다 더 효율적으로, 양적으로 더 많이 쓰시는 분들이 많을거라 생각됩니다.
저는 오히려 코딩 경력이 오래 되기도 해서 조금 보수적인 편이지 않을까 싶기도 합니다만, 현재 제 경험을 기록해 놓는게 저 개인적으로도 미래에 봤을 때 재밌을 것 같아 이 글을 쓰게 되었습니다.
구글의 개발 문화와 생태계
구글은 독특한 개발 문화와 생태계를 갖고 있습니다. 그렇기 때문에 항상 구글에서 일하는 소프트웨어 엔지니어는 이 생태계에 갇혀버릴 있을 위험도 가지고 있죠.
관심 있다면 Software Engineering at Google책 (영어, 한국어)을 추천드립니다.
AI 코딩 툴 관점에선, 지난 1~2년 동안 외부 생태계가 훨씬 더 빠르게 발전해왔다고 보입니다. GitHub Copilot, Cursor, Windsurf, Claude Code 등 수많은 제품이 등장했습니다.
구글은 엔지니어가 많다 보니 내부 툴을 개선할 인센티브가 큽니다. 여기에 Gemini 2.5의 코딩 능력이 많이 올라오면서, 최근에 내부 도구들도 빠르게 따라잡았습니다. 지금은 사내 IDE(Cider), 코드리뷰 툴(Critique) 등에 외부 툴들과 유사한 기능들이 들어가 있고, 외부에도 공개된 제품들이 있습니다.
그 중 제가 자주 쓰는 툴은:
Gemini-cli — 터미널 기반 코딩 어시스턴트(Claude Code와 유사).
google-gemini
Gemini Code Assist — 공개 제품과 사내 도구의 기능은 완전 같지는 않지만, 유사한 경험을 IDE와 리뷰 툴에서 제공합니다.
AI 코딩 툴이 가장 효과적이었던 워크플로우
1. 코드 베이스 이해하기
저는 7월에 새로운 팀에 합류하면서 완전히 낯선 코드베이스를 빠르게 이해해야 했습니다. 문제는 데이터 쪽(C++/Python) 경험이 대부분이었기에, 제가 자바 백엔드도, Angular.js 프런트도 제대로 써본 적이 없었다는 점이었습니다.
팀 동료들이 정말 친절하게 온보딩을 도와주었지만, 바쁘신 분들께 사소한 것까지 매번 물어보고 싶진 않았습니다. 그래서 gemini-cli에 많이 의지했어요.
“이 함수의 실행 흐름을 설명해줘. 다이어그램으로도 그려줘.”
“이 링크는 어떤 파일과 연결되고, 왜 이렇게 와이어링되어 있어?”
마치 인내심 무한대의 멘토가 옆에 붙어 있는 느낌이었습니다. 화이트보드에 흐름을 그려가며 전체 그림과 세부를 동시에 잡을 수 있었고, 그 덕분에 온보딩 속도가 확 올라갔어요. 어느 정도 익숙해진 뒤엔 현재 컴포넌트 상태와 개선 아이디어를 정리해 팀에 발표하기도 했습니다.
2. 리팩토링
빠르게 움직이는 프로젝트에서 리팩토링은 미뤄지기가 쉽습니다. 함수 파라미터 이동, 함수 쪼개기, 네이밍 변경처럼 구조적이고 지루한 작업을 안전하게, 컴파일와 현 기능을 깨지 않으며 해야 하니까요.
LLM은 이런 작업을 지루해 하지도 않고, 프로그래밍 문법에도 엄청 강합니다. 코드 한두 군데를 바꾸면 연쇄적으로 필요한 import/헤더/호출부 수정까지 전반적으로 훑어 고쳐줍니다. 그 결과, 예전엔 발목을 잡던 “소소한 리팩토링”이 더 이상 큰 장애가 아니게 되었어요. 체감상 리팩토링으로 시간이 1/10로 줄었기에, 하고 싶은 리팩토링을 그때그때 하기가 좋아졌습니다.
3. 유닛 테스트 생성
리팩토링을 효율적으로 하려면, 테스트가 뒷받침되어야 합니다. 대충이라도 있는 테스트가 아예 없는 것보다 훨씬 낫죠. 하지만 mocking/test case 작성 같은 것들은 문법이 번거로워 종종 생략되곤 합니다. 여기서도 LLM이 큰 도움이 됩니다.
아무 생각 없이 “테스트 다 써줘”를 맡기진 않습니다. 다만 무엇을 검증할지 범위를 제가 정하고, 문법적/패턴적 피로를 LLM이 덜어주는 방식으로 속도를 끌어올립니다.
4. 신규 코드 작성
LLM 덕분에 코딩을 할 때 제 정신은 특정 언어 문법에서 벗어나 “로직”에 더 집중하게 됐습니다. OOP, 비동기 처리 같은 기본기는 머릿속에 있지만, 15년 넘게 안 쓴 자바 문법을 일일이 생각하면서 쓰려면 시간이 2~5배는 더 걸렸을 겁니다.
이젠 원하는 로직을 자연어로 풀어 쓰거나, 필요하면 제가 익숙한 파이썬이나 pseudo-code로 스케치한 뒤 “자바로 구현해줘”라고 요청합니다. 파일 전체 맥락을 보며 팀의 기존 스타일을 최대한 따라준다는 점도 장점입니다.
프런트엔드에서도 효과가 큽니다. 최근 Angular.js를 쓰다 보면 JS/CSS/HTML을 동시에 만져야 하는데, LLM이 이렇게 여러 파일들을 딱딱 맞게 변경해주는 경우에 매우 강합니다.
5. 셀프 코드리뷰
성격상 제 코드에 대한 자가검열 리뷰를 꼼꼼히 하는 편인데요, 이제는 LLM을 통한 셀프 코드리뷰 기능을 자주 씁니다. 특히 익숙치 않은 언어에서 저지르기 쉬운 사소한 실수를 줄여줘서, 제 시간과 제 동료 리뷰어의 시간을 모두 절약해줍니다.
6. 에러 메시지 해석
C++나 Java는 에러 메시지는 길고 난해할 때가 많은데, 요즘은 LLM에게 요약과 원인/수정 제안을 같이 받습니다. 정말 디버깅 시간이 확 줄어요.
7. 가독성 제안(Readability)
구글은 가독성 (Readability) 리뷰가 무척 강조되는 문화입니다. 이러한 엔지니어링 문화의 장점은 전체 코드 품질이 올라간다는 점이지만, 전반적인 개발 속도가 느려질 수 있죠. 신제품 프로젝트의 페이스에선 사소한 Readability 코멘트까지 달기 망설여질 때가 있는데, 요즘은 코멘트와 함께 LLM 수정을 붙여서 제안할 수 있는 기능이 생겨서 애용하고 있습니다. 원 코드 저자는 버튼 클릭 한번이면 수정 사항을 적용할 수 있어 코드의 품질과 속도를 동시에 챙길 수 있습니다.
8. AI가 붙은 Colab
Colab(주피터 노트북)은 데이터 분석/프로토타입에 굉장히 잘 쓰이는데요. 보통 프로덕션 코드처럼 우아하거나 테스트가 다 붙을 필요가 없기에 “바이브 코딩”의 여지가 큽니다. 최근 Colab UI 안에 AI 코딩 어시스턴트가 붙으면서 Colab을 쓰는 생산성이 더 올라갔습니다.
Nick Sharma
9. 바이브 코딩 프로토타이핑
대부분의 경우, 말이나 슬라이드로 설명하는 것보다 데모가 더 설득력 있습니다. 어떤 피쳐 (feature) 아이디어를 브레인스토밍할 때 바이브 코딩으로 빠르게 형태를 만들어보는 게 재미도 있고 효과도 있습니다. PM, 사업 개발, UX 같은 비개발 직군도 엔지니어링 팀의 시간을 거의 쓰지 않고도 아이디어를 검증할 수 있다는 점에서 임팩트가 큽니다.
다만, 요즘 바이브 코딩 툴들의 성능 발전 속도라면 “엔지니어팀 대체”라는 말이 과장만은 아닐 수도 있겠지만, 아직은 여러모로 시기상조라고 생각합니다. 이 점은 다음 글에 더 풀어보겠습니다.
저는 Gemini App의 Gemini Canvas나 Google AI Studio를 자주 쓰지만, 외부에는 vibe coding 전용 툴들이 더 많은 툴들이 있다고 들었습니다.
AI 도구가 개발자를 오히려 느리게 만든다는 연구도 있고, 이제 개발자의 “생산성 미쳤다”는 사람들도 넘쳐납니다. 정말 다른 두 의견의 공존, 뭐가 맞을까요?
제 경험상, AI 코딩 툴들을 아무 생각 없이, "제대로" 쓰지 않으면 개발이 느려질 수 있습니다. 저도 아직까지도 여러 시행착오를 꽤 겪고 있고요. 잘 썼을 때 "미친" 생산성 향상도 느끼고 있습니다. 그렇기에 이 두 의견 중 뭐가 맞다고 잘라 말하기가 어렵네요.
다음 글에서는 그렇다면 AI 코딩 툴들을 "제대로", 어떻게 쓰면 좋은지에 대해 정리해보려고 합니다.
여러분들은 어떤 툴들을, 어떤 워크플로우에서 잘 쓰고 계신가요? 댓글로 달아주세요~
