네이밍 컨벤션
네이밍 컨벤션은 변수, 함수, 컴포넌트, 파일 이름을 어떤 규칙으로 지을지 정한 약속이다. 좋은 이름은 코드가 무엇을 하는지 설명하므로 주석보다 먼저 읽히는 문서가 된다. AI가 만든 코드는 임시 이름이나 비슷한 이름을 반복하기 쉬워 유지보수자가 흐름을 놓칠 수 있으므로, 팀 규칙에 맞는 네이밍을 리뷰 기준으로 삼아야 한다.
예시
AI가 data, result, handleClick처럼 모호한 이름을 만든 경우 userProfile, submitSignupForm, visibleQuestionCards처럼 역할이 드러나는 이름으로 바꾸고, 테스트 이름도 같은 도메인 용어로 맞춰 리뷰를 쉽게 만든다.
카테고리
코드 품질·리뷰
난이도
basic
태그
네이밍 · 가독성
함께 읽기
연관 용어
코드 품질·리뷰
린터
소스 코드를 실행하지 않고 정적으로 분석하여 프로그래밍 오류, 코딩 스타일 위반, 의심스러운 패턴, 잠재적 버그를 자동으로 감지하는 도구이다. '린터(Linter)'라는 이름은 1978년 Bell Labs에서 Stephen C. Johnson이 만든 C 언어 분석 도구 'lint'에서 유래했으며, 세탁기의 보풀 제거기(lint remover)처럼 코드의 '보풀(문제점)'을 제거한다는 의미이다. 바이브 코딩에서 린터가 특히 중요한 이유는, AI가 생성한 코드가 '동작'은 하지만 코딩 표준을 위반하거나 잠재적 문제를 내포하는 경우가 빈번하기 때문이다. ESLint(JavaScript/TypeScript), Pylint(Python), RuboCop(Ruby) 등이 대표적이며, 하네스 엔지니어링에서 품질 게이트(Quality Gate)의 첫 번째 관문으로 설정된다. AI 에이전트가 코드를 생성한 후 린터를 자동으로 실행하여, 위반 사항이 있으면 에이전트에게 피드백을 돌려보내 스스로 수정하도록 하는 것이 에이전틱 워크플로의 표준 패턴이다.
코드 품질·리뷰
코드 리뷰
코드 변경 사항을 다른 개발자(또는 AI)가 검토하여 품질, 보안, 일관성, 가독성, 비즈니스 로직 정확성을 확인하는 과정이다. AI 시대에 코드 리뷰는 두 가지 형태로 진행된다: 첫째, 'AI가 작성한 코드를 인간이 리뷰'하는 형태로, 이것이 에이전틱 엔지니어링의 Verify 단계에 해당하며, AI Slop이 프로덕션에 도달하지 않도록 막는 마지막 방어선이다. 인간 리뷰어는 AI가 놓치기 쉬운 비즈니스 로직 오류, 아키텍처 부적합, 사용자 경험 문제를 검출할 수 있다. 둘째, 'AI가 인간(또는 다른 AI)의 코드를 자동 리뷰'하는 형태로, CodeRabbit 같은 AI 코드 리뷰 도구가 PR(Pull Request)을 자동으로 분석하여 잠재적 버그, 스타일 위반, 보안 문제를 코멘트로 제시한다. 바이브 코딩에서는 개발자가 코드를 직접 작성하지 않았기 때문에 '자신이 작성하지 않은 코드를 이해하고 검토하는 능력'이 핵심 역량으로 부상했으며, 이는 전통적 코드 리뷰와는 다른 스킬셋을 요구한다.
코드 품질·리뷰
기술 부채
빠른 해결책을 선택함으로써 미래에 추가 작업이 필요하게 되는 개발상의 숨겨진 비용이다. Ward Cunningham이 1992년에 처음 사용한 비유로, 금융의 '부채'처럼 당장은 빠르게 결과를 얻지만 나중에 '이자(추가 작업)'를 갚아야 한다는 의미이다. 바이브 코딩은 기술 부채를 유례없이 빠른 속도로 축적할 수 있다. AI가 '동작하는' 코드를 몇 분 만에 생성하지만, 에러 처리 누락, 로깅 부재, 타입 안전성 미흡, 보안 검증 미수행, 하드코딩된 설정값, 중복 로직, 문서화 부재 등의 문제를 내포하여, 나중에 기능 추가나 버그 수정 시 전체 리팩토링이 필요해지는 상황이 빈번하다. AI Slop이 기술 부채의 직접적 원인이며, 바이브 택스(Vibe Tax)는 이 기술 부채를 해소하는 데 드는 비용을 의미한다. 하네스 엔지니어링의 품질 게이트(Quality Gate)가 기술 부채 축적을 방지하는 가장 효과적인 수단이며, '동작하면 된다'에서 '유지보수 가능해야 한다'로 기준을 높이는 것이 핵심이다.