기술은 생각보다 빨리 세팅된다
솔직히 말할게요. Cursor 세팅하는 데 하루, CodeRabbit PR에 붙이는 데 두어 시간이면 충분합니다. Claude를 아키텍처 설계에 끼워 넣는 것도 생각보다 장벽이 낮아요. dev.to에 올라온 한 테크 리드의 고백처럼, AI 도입의 기술 커브는 지난 20년 커리어 중 가장 완만했다고 해도 과언이 아닙니다.
그런데 왜 팀은 안 바뀔까요?
진짜 병목은 리더십 레이어에 있다
"AI가 생성한 솔루션이 작동하긴 하는데 우리 팀 코드 패턴이랑 안 맞아요. 속도를 택할까요, 표준을 지킬까요?" 이게 기술 문제처럼 들리지만, 사실 리더십 판단 문제입니다. 주니어가 AI 덕분에 코드를 두 배 더 많이 ship하고 있다면, 그 성장을 어떻게 평가해야 할까요? 세 가지 프로토타입을 동시에 돌릴 수 있게 됐을 때, 무엇에 집중해야 할지 결정하는 건 누구 몫인가요?
이 질문들에 AI는 답을 못 줍니다. 팀장이 줘야 합니다. AI는 경험적 판단의 필요성을 줄이지 않습니다. 오히려 그것을 한 곳으로 집중시킵니다.
'솔선수범'의 의미가 바뀌었다
예전의 솔선수범은 "내가 직접 짜 보일게요"였습니다. 지금은 다릅니다. "내가 어떻게 오케스트레이션하는지 보여줄게요"가 됐어요. 팀원들에게 Cursor 사용법을 가르치는 게 아니라, 어디에 Cursor를 겨냥하고, 어떤 컨텍스트를 줘야 하고, 어떤 출력을 거절해야 하는지—그 판단 과정을 소리 내어 보여주는 것이 지금 시대의 리드입니다.
저도 요즘 AI 문제 해결 과정을 팀원들 앞에서 실황 중계하곤 해요. "이 컨텍스트는 넣고 저건 왜 뺐는지", "기술적으로는 맞는데 왜 우리 운영 환경에 안 맞는지", "AI가 더 빠른데 왜 이건 직접 했는지"—이게 지금 제가 할 수 있는 가장 중요한 멘토링입니다.
시니어가 AI를 잘못 쓰는 패턴
NDC Manchester 2025에서 Aleksander Stensby가 꽤 불편한 진실을 꺼냈습니다. AI가 나쁜 코드를 뱉어내고 있다면, 모델 문제가 아니라 워크플로우 문제라는 거예요. 경험 많은 시니어 개발자들이 가장 자주 저지르는 실수는 역설적으로 AI를 너무 믿거나, 반대로 너무 방치하는 겁니다.
구체적으로 보면 이렇습니다. 긴 채팅 스레드에서 LLM의 컨텍스트 윈도우가 흐릿해지도록 방치하거나, 구현 단계로 바로 점프시켜서 AI가 아키텍처 결정을 대신 내리게 두거나, CLAUDE.md나 .cursorrules 같은 rule 파일을 일회성으로 쓰고 업데이트를 안 하는 것들이죠. Stensby는 이걸 "Compounding Engineering"으로 교정할 수 있다고 봅니다—AI를 주니어 인턴처럼 온보딩하고, 매주 더 나아지도록 피드백을 쌓아가는 방식으로요.
"AI slop을 욕하는 사람치고, AI에게 제대로 리뷰 피드백 준 사람 못 봤어요." 도구 탓을 하기 전에 워크플로우를 점검해야 합니다.
AI가 생성한 코드는 기본적으로 '무결하지 않다'
AI 코드의 보안 문제는 이미 구조적입니다. 수백 개의 AI 생성 코드 샘플을 분석한 한 보안 스캐너 개발자에 따르면, ChatGPT·Claude·Copilot 가릴 것 없이 동일한 취약점 패턴이 반복됩니다. 하드코딩된 시크릿(약 70%), 입력 값 미검증(약 65%), 빈 catch 블록의 무음 처리(약 50%)—이건 특이 케이스가 아니라 AI 코드 생성의 기본값에 가깝습니다.
더 불편한 건, Snyk나 SonarQube 같은 기존 정적 분석 도구가 이 패턴의 절반도 못 잡는다는 겁니다. AI가 만든 코드는 겉보기엔 컨벤션을 따르는 듯 보이지만, 보안 로직이 미묘하게 틀려 있습니다. 팀장이 AI 코드를 리뷰 없이 merge 허용한다면, 그건 리더십 실패입니다.
코딩 에이전트가 빛나는 영역은 따로 있다
그렇다면 AI 코딩 에이전트를 어디에 써야 할까요? 한 가지 명확한 답이 있습니다. 내부 도구(Internal Tooling). dev.to에 공유된 Tiger Den 사례가 좋은 참고가 됩니다. Next.js + Drizzle ORM + tRPC로 마케팅팀 전용 콘텐츠 관리 시스템을 직접 만든 건데, Airtable이나 Notion으로 억지로 끼워 맞추던 워크플로우를 팀에 딱 맞게 새로 설계한 거예요.
내부 도구는 리스크 프로파일이 다릅니다. 사용자가 적고 알려져 있고, 버그의 파급 범위가 작고, 80% 완성 상태에서 deploy하고 다음 주에 나머지를 고쳐도 됩니다. AI 에이전트의 빠른 이터레이션이 진짜 빛나는 조건이죠. 프로덕션 외부 시스템과 연결되거나, 고객 데이터를 건드리는 순간 이 계산식은 완전히 달라집니다. 그 경계를 명확히 긋는 것도 팀장의 일입니다.
테크 리드가 지금 당장 해야 할 것
요약하면 이렇습니다.
- 판단력을 공개하세요. AI 활용 결과물이 아니라, AI와 협업하는 '과정'을 팀원들에게 노출하세요. 무엇을 주고, 무엇을 거절하고, 왜 손으로 했는지를요.
- AI 도입을 트레이닝 문제로 보지 마세요. 이건 멘토링 문제입니다. 경험 있는 사람이 판단하는 장면을 경험 없는 사람에게 실시간으로 보여주는 것이 핵심입니다.
- 보안 검증 레이어를 의무화하세요. AI가 생성한 코드는 검증 전까지 신뢰하지 않는 게 기본입니다. PR 단계에서 자동화된 보안 스캔이 없다면, 지금 붙이세요.
- 에이전트를 쓸 영역을 의도적으로 정하세요. 내부 도구부터 시작해서, 리스크와 가치가 명확히 보이는 곳으로 확장하세요.
마지막으로
"AI 도입에서 기술은 가장 쉬운 부분"이라는 말이 이제 클리셰처럼 들릴 수도 있어요. 하지만 이 말이 클리셰가 됐다는 건, 그만큼 많은 팀이 기술만 도입하고 나머지를 놓쳤다는 방증이기도 합니다.
AI는 경험 있는 판단력을 증폭합니다. 판단력 없는 팀에게는 잘못된 것을 매우 빠르게 만드는 도구가 됩니다. 팀장이 먼저 AI-First로 사고하고, 그 사고 과정을 팀에 전파하는 것—그게 AI 시대 테크 리드의 가장 중요한 역할입니다. 툴 예산 집행보다 훨씬 중요한 일이에요.