
요즘 개발자들 사이에서 '바이브 코딩(Vibe Coding)'이라는 말이 유행하더군요.
느낌 가는 대로, 흐름을 타면서 AI랑 코딩한다?
엔지니어링에서 '감'은 곧 비용 폭탄입니다.
측정되지 않은 코드는 그저 레거시일 뿐이죠.
오늘 아침, 꽤 흥미로운 실험 로그를 하나 뜯어봤습니다.
macOS용 타일링 윈도우 매니저를 만드는 프로젝트였는데, 여러분이 흔히 저지르는 실수와 그 해법이 적나라하게 담겨 있었습니다.
상황은 이렇습니다.
창 전환(Focus) 명령을 내렸는데 반응 속도가 130ms가 나옵니다.
목표치는 80ms 미만이고요.
보통의 주니어들은 이럴 때 프롬프트 창에 대고 무턱대고 빕니다.
"Claude, 이거 최적화해줘."
그럼 LLM은 신나서 코드를 난도질하기 시작하죠.
의심 가는 곳을 전부 수정하고, 배포하고, 실패하고.
그 과정에서 여러분 회사의 GPU 크레딧은 살살 녹아내립니다.
그런데 이 실험자는 달랐습니다.
Claude에게 두 가지 스킬을 '결합'하라고 지시했더군요.
하나는 (최적화), 다른 하나는 (가설 기반 디버깅)입니다.
이게 무슨 차이냐고요?
AI가 코드를 고치기 전에 스스로 '프로파일링 에이전트'를 띄웠다는 겁니다.
마구잡이로 수정하는 게 아니라, 먼저 로그(Log)를 심더군요.
같은 함수로 구간별 타임스탬프를 찍기 시작합니다.

결과는 충격적이었습니다.
사람이나 AI나 흔히 하는 착각이 있죠.
"프로세스 생성(Task spawning)이 느릴 거야."
"IPC 통신 오버헤드 때문일 거야."
하지만 로그를 뜯어보니 전혀 다른 범인이 나왔습니다.
은 0.05ms로 무시할 수준이었습니다.
진짜 병목은 JSON 인코딩이었습니다.
가 120KB짜리 구조체를 직렬화하는 데 혼자서 60ms를 잡아먹고 있었던 겁니다.
전체 지연 시간의 절반이 여기서 발생한 거죠.
이게 바로 '출현 행동(Emergent Behavior)'의 핵심입니다.
단순히 "코드 짜줘"가 아니라, "문제 원인을 추적하는 도구"와 "해결하는 도구"를 쥐여줬더니 시너지가 난 겁니다.
최적화 스킬만 썼다면?
엄한 IPC 로직만 건드리다가 밤샜을 겁니다.
디버깅 스킬만 썼다면?
원인은 찾았겠지만 해결책을 적용하는 데 또 한세월 걸렸겠죠.
이 실험자는 여기서 멈추지 않았습니다.
'Frontend-Design' 스킬과 'Brainstorming' 스킬을 결합하는 실험도 진행했더군요.
보통 디자인을 나중에 덧입히는데, 이 조합은 달랐습니다.
브레인스토밍 '과정' 자체에 디자인 사고(Design Thinking)를 개입시킵니다.
"이 블로그의 목적이 뭡니까?"
"기술적 가독성입니까, 아니면 포트폴리오용 심미성입니까?"
시작부터 엔지니어링의 본질인 '목적 정의'를 수행하게 만든 거죠.
결론은 명확합니다.
생성형 AI는 마법 지팡이가 아닙니다.
여러분이 엑셀 함수를 조합하듯, 'AI 스킬(Tool)'을 어떻게 조립하느냐에 따라 결과물은 하늘과 땅 차이입니다.
제발 그냥 "최적화해줘"라고 하지 마세요.
그건 "돈 벌지 못하는 모델은 GPU 난로일 뿐이다"라는 제 지론을 완벽하게 증명하는 행위입니다.
"측정하고, 증명하고, 그다음에 고쳐라."
이 엔지니어링의 기본 원칙을 AI에게 가르치세요.
그게 여러분이 '코더'에서 '아키텍트'로 넘어가는 유일한 길입니다.
오늘도 엉뚱한 가설로 서버비 태우고 있는 건 아닌지, 터미널 로그 한 번 더 확인하시길 바랍니다.


![[AI 연구소] 시니어 개발자가 코드 리뷰할 때 머릿속에서 일어나는 과정 [설계도 공개]](/_next/image?url=https%3A%2F%2Fstorage.googleapis.com%2Fpoooling-blog%2Fblog-images%2F2026%2F01%2F07%2F1781_d490277e.png&w=3840&q=75)