반복 제거의 유혹, 그리고 그 이면
Claude Code의 커스텀 스킬 기능은 솔직히 매력적이다. SKILL.md 파일 하나로 빌드 → 린트 → 타입체크 → 커밋 → 푸시까지 한 번에 묶어버릴 수 있다. velog에 공개된 실제 구현 사례를 보면, 패키지 매니저 자동 감지(npm/yarn/pnpm), git add . 금지, 커밋 메시지 승인 게이트까지 꽤 섬세하게 설계되어 있다. 매일 손으로 반복하던 체크리스트를 자동화했다는 것만으로도 팀 생산성에 즉각 체감이 온다.
그런데 나는 이 설계를 보면서 두 가지를 동시에 느꼈다. 하나는 '이건 실제로 써볼 만하다'는 긍정. 다른 하나는 '자동화가 검증을 대체한다고 착각하면 위험하다'는 경계심이다. 빌드와 린트가 통과했다고 해서 코드가 안전하다는 뜻은 아니니까.
AI가 쓴 코드가 '그럴싸하게' 보이는 이유
dev.to에 올라온 AI 생성 코드 보안 분석 글은 이 지점을 정확히 찌른다. 저자가 수백 개의 AI 생성 코드 샘플을 스캔한 결과, 가장 빈번하게 발견된 패턴 다섯 가지는 다음과 같다.
- 하드코딩된 시크릿 (약 70%): API 키, DB URL, 토큰이 소스에 그대로 노출
- 빈 catch 블록 (약 60%): 에러를 삼키고 undefined를 조용히 반환
- API 라우트 입력 미검증:
req.body를 바로 DB 쿼리에 투입 - 과도한 CORS 허용:
Access-Control-Allow-Origin: *가 프로덕션까지 유지 - 민감 데이터 콘솔 로그: 요청 바디, 유저 객체, 토큰이 로그 수집기에 그대로
핵심은 이 코드들이 '형식적으로 깔끔하다'는 점이다. 변수명도 읽기 좋고, 들여쓰기도 일관되고, 패턴도 익숙하다. PR을 빠르게 훑으면 통과시키기 딱 좋은 생김새다. AI가 나쁜 코드를 쓰는 게 아니라, AI가 즉시 실행되는 코드를 쓴다는 게 문제다. 환경변수 설정이나 입력 검증은 마찰을 일으키기 때문에 학습 분포에서 후순위로 밀린다.
'AI 오케스트레이터'로의 전환이 의미하는 것
dev.to의 또 다른 글은 개발자가 'AI 오케스트레이터'로 진화해야 한다고 주장한다. 요점은 단순하다. 코드 타이핑이 핵심 가치가 아닌 시대에, 개발자의 역할은 AI의 출력을 설계하고 검증하고 통합하는 쪽으로 이동한다는 것. 그리고 이 글은 한 가지를 명확하게 못 박는다. AI 출력에 대한 평가와 테스트는 더 엄격해져야 한다. AI가 더 많이 쓸수록, 사람이 더 날카롭게 봐야 한다.
Claude Code 커스텀 스킬 자동화와 연결해서 생각하면 이렇게 된다. 빌드·린트·타입체크는 문법적 정합성을 검증한다. 하지만 하드코딩된 시크릿은 타입체크로 잡히지 않는다. 빈 catch 블록은 린트 규칙 설정에 따라 통과한다. CORS 설정은 빌드와 무관하다. 즉, SKILL.md가 아무리 잘 설계돼 있어도, 보안 취약점 탐지 레이어는 별도로 존재해야 한다.
워크플로우 안에 검증 레이어를 끼워 넣는 법
내가 팀에 권장하는 구조는 세 단계다.
1단계 — SKILL.md 내부 게이트 (현재 잘 설계된 부분)
- 빌드/린트/타입체크 순차 실행
- 실패 시 자동 중단, 사용자 승인 후 커밋
- git add . 금지, 명시적 파일 지정
2단계 — 정적 분석 레이어 (추가 필요) - Semgrep 또는 커스텀 AST 기반 스캐너를 pre-commit 훅에 연결 - 하드코딩 시크릿, 빈 catch, 입력 미검증 패턴 탐지 - LLM 기반 스캔은 비결정론적이라 신뢰할 수 없다. 동일 코드에 5번 돌리면 5개의 다른 심각도 점수가 나온다는 건 실제 검증된 문제다. AST 파싱 + 패턴 매칭 기반의 결정론적 도구가 현실적이다.
3단계 — 사람이 봐야 하는 것 명확히 분리 - 자동화가 통과시킨 코드 = '형식 검증 완료', '보안 검증 완료'가 아니다 - 비즈니스 로직, 권한 설계, 인증 흐름은 여전히 사람이 리뷰해야 한다 - AI 생성 코드임을 PR 템플릿에 명시하면 리뷰어의 주의 수준이 달라진다
시사점: 자동화는 속도를 주지만, 책임은 설계에 있다
Claude Code SKILL.md 자동화의 가장 큰 장점은 반복의 제거다. 모든 프로젝트에서 동일한 검증 절차가 실행되고, 커밋 전 사람이 승인하는 구조가 강제된다. 이건 분명히 의미 있다. 하지만 이 자동화가 '보안 리뷰를 대신한다'고 착각하는 순간, 오히려 이전보다 더 위험해진다. 자동화가 통과시켰다는 신뢰가 리뷰의 긴장을 풀어버리기 때문이다.
앞으로의 방향
Claude Code의 커스텀 스킬은 계속 발전할 것이고, 팀 단위로 SKILL.md를 공유하고 버전 관리하는 관행도 곧 자리 잡을 것이다. 중요한 건 스킬 설계 자체에 보안 탐지 단계를 명시적으로 포함시키는 방향이다. 린트 다음에 semgrep --config auto 한 줄, secrets 스캔 도구 한 줄을 끼워 넣는 것만으로도 가장 빈번한 취약점 패턴 상당수를 자동으로 막을 수 있다.
속도는 AI가 줄 수 있다. 하지만 무엇을 자동화하고, 무엇은 사람이 봐야 하는지를 설계하는 건 여전히 오케스트레이터인 당신의 몫이다.