바이브 코딩 사전

린터

바이브 코딩 사전

린터

소스 코드를 실행하지 않고 정적으로 분석하여 프로그래밍 오류, 코딩 스타일 위반, 의심스러운 패턴, 잠재적 버그를 자동으로 감지하는 도구이다. '린터(Linter)'라는 이름은 1978년 Bell Labs에서 Stephen C. Johnson이 만든 C 언어 분석 도구 'lint'에서 유래했으며, 세탁기의 보풀 제거기(lint remover)처럼 코드의 '보풀(문제점)'을 제거한다는 의미이다. 바이브 코딩에서 린터가 특히 중요한 이유는, AI가 생성한 코드가 '동작'은 하지만 코딩 표준을 위반하거나 잠재적 문제를 내포하는 경우가 빈번하기 때문이다. ESLint(JavaScript/TypeScript), Pylint(Python), RuboCop(Ruby) 등이 대표적이며, 하네스 엔지니어링에서 품질 게이트(Quality Gate)의 첫 번째 관문으로 설정된다. AI 에이전트가 코드를 생성한 후 린터를 자동으로 실행하여, 위반 사항이 있으면 에이전트에게 피드백을 돌려보내 스스로 수정하도록 하는 것이 에이전틱 워크플로의 표준 패턴이다.

예시

ESLint가 TypeScript 코드에서 any 타입 사용을 감지하고 경고 → AI 에이전트가 이를 수정.

참고

하네스 엔지니어링에서 Quality Gate의 핵심 구성 요소.

카테고리

코드 품질·리뷰

난이도

basic

태그

린터 · 코드분석

함께 읽기

연관 용어

코드 품질·리뷰

코드 리뷰

코드 변경 사항을 다른 개발자(또는 AI)가 검토하여 품질, 보안, 일관성, 가독성, 비즈니스 로직 정확성을 확인하는 과정이다. AI 시대에 코드 리뷰는 두 가지 형태로 진행된다: 첫째, 'AI가 작성한 코드를 인간이 리뷰'하는 형태로, 이것이 에이전틱 엔지니어링의 Verify 단계에 해당하며, AI Slop이 프로덕션에 도달하지 않도록 막는 마지막 방어선이다. 인간 리뷰어는 AI가 놓치기 쉬운 비즈니스 로직 오류, 아키텍처 부적합, 사용자 경험 문제를 검출할 수 있다. 둘째, 'AI가 인간(또는 다른 AI)의 코드를 자동 리뷰'하는 형태로, CodeRabbit 같은 AI 코드 리뷰 도구가 PR(Pull Request)을 자동으로 분석하여 잠재적 버그, 스타일 위반, 보안 문제를 코멘트로 제시한다. 바이브 코딩에서는 개발자가 코드를 직접 작성하지 않았기 때문에 '자신이 작성하지 않은 코드를 이해하고 검토하는 능력'이 핵심 역량으로 부상했으며, 이는 전통적 코드 리뷰와는 다른 스킬셋을 요구한다.

코드 품질·리뷰

기술 부채

빠른 해결책을 선택함으로써 미래에 추가 작업이 필요하게 되는 개발상의 숨겨진 비용이다. Ward Cunningham이 1992년에 처음 사용한 비유로, 금융의 '부채'처럼 당장은 빠르게 결과를 얻지만 나중에 '이자(추가 작업)'를 갚아야 한다는 의미이다. 바이브 코딩은 기술 부채를 유례없이 빠른 속도로 축적할 수 있다. AI가 '동작하는' 코드를 몇 분 만에 생성하지만, 에러 처리 누락, 로깅 부재, 타입 안전성 미흡, 보안 검증 미수행, 하드코딩된 설정값, 중복 로직, 문서화 부재 등의 문제를 내포하여, 나중에 기능 추가나 버그 수정 시 전체 리팩토링이 필요해지는 상황이 빈번하다. AI Slop이 기술 부채의 직접적 원인이며, 바이브 택스(Vibe Tax)는 이 기술 부채를 해소하는 데 드는 비용을 의미한다. 하네스 엔지니어링의 품질 게이트(Quality Gate)가 기술 부채 축적을 방지하는 가장 효과적인 수단이며, '동작하면 된다'에서 '유지보수 가능해야 한다'로 기준을 높이는 것이 핵심이다.

코드 품질·리뷰

리팩토링

외부에서 관찰 가능한 동작(기능, API, 사용자 경험)을 변경하지 않으면서 코드의 내부 구조를 개선하는 체계적 작업이다. Martin Fowler의 1999년 저서 『Refactoring: Improving the Design of Existing Code』에서 체계화된 개념으로, 가독성 향상, 중복 제거, 복잡도 감소, 성능 개선, 테스트 용이성 향상 등을 목적으로 한다. 바이브 코딩에서 리팩토링은 특별한 의미를 가진다. AI가 초기에 생성한 코드는 기능적으로 동작하더라도 구조적으로 최적이 아닌 경우가 많으므로, AI와 협업하여 리팩토링을 수행하는 것이 일반적인 워크플로이다. 예를 들어, Claude Code에게 '이 컴포넌트를 더 작은 컴포넌트로 분리하고, 공통 로직을 커스텀 훅으로 추출해줘'와 같은 리팩토링 지시를 내릴 수 있다. 2026년 기준으로 AI 도구는 단일 서비스 내 리팩토링(파일 분할, 함수 추출, 타입 개선 등)은 잘 수행하지만, 마이크로서비스 간 크로스 시스템 리팩토링(서비스 경계 재정의, 데이터 모델 마이그레이션 등)은 아직 인간의 아키텍처 판단이 필수적인 영역이다.