인간처럼 코드를 검토하기
Source: Dev.to
내 강점 중 하나는 다른 사람의 코드에서 문제점을 찾아내는 것입니다 😜. 아래는 PR을 검토할 때 사용하는 체크리스트입니다. Copilot 같은 AI 도구가 도움이 될 수는 있지만, 여전히 인간의 판단이 필요한 미묘한 부분들을 놓치곤 합니다.
재사용성
반복 로직
- 로직을 재사용 가능한 컴포넌트나 함수로 추출할 수 있는가?
- 추출된 코드가 적절히 테스트되어 재작성하거나 재테스트 없이 재사용할 수 있는가?
- 한 곳에서 로직을 업데이트하면 자동으로 모든 곳에 반영되어 일관성 없는 구현으로 인한 버그를 줄인다.
하드‑코딩된, 반복되는 값
- 이러한 값들을 공유 파일의 상수로 저장한다.
- 상수를 사용하면 오타를 줄이고 향후 변경을 한 곳에서 편집할 수 있다.
- 최신 IDE는 가져온 상수를 자동 완성해 주어 오류를 더욱 최소화한다.
테스트 가능성
- 이전에 통과하던 테스트가 실패하거나 변경이 필요했나요?
- 실패한 테스트는 의도치 않은 수정, 오타, 혹은 부작용을 나타낼 수 있습니다.
- 먼저 구현을 검증하세요; 단순히 “테스트를 고치지” 마세요.
- 누락된 중괄호, 오타, 혹은 미묘한 논리 변경이 없는지 diff를 꼼꼼히 검토하세요.
가독성 / 이해도
명명
- 이름은 컴포넌트, 파일, 변수, 함수가 하는 일을 설명해야 합니다.
- 예시: 버튼을 표시할지 여부를 나타내는 불리언은
isButtonVisible와 같이 이름을 지을 수 있습니다. - 명확한 이름은 추가 주석 필요성을 줄이고 인간과 AI 모두가 코드를 이해하는 데 도움이 됩니다.
- 예시: 버튼을 표시할지 여부를 나타내는 불리언은
복잡한 로직
if/else문이 너무 많나요?switch문을 사용하거나 더 작은 헬퍼 함수로 리팩터링하는 것을 고려하세요.
함수 인자
- 인자가 너무 많나요?
- 긴 위치 기반 인자 리스트 대신 이름이 지정된 속성을 가진 단일 객체를 전달하세요.
- 이렇게 하면 순서 실수를 방지하고 선택적 인자를 더 명확하게 할 수 있습니다.
주석 및 비즈니스 로직
- 코드가 이해하기 어려운 경우, 기본 비즈니스 규칙을 설명하는 주석을 추가하세요.
- 중요한 로직은 단위 테스트와 엔드‑투‑엔드 테스트로도 커버되어야 합니다.
보안
정적 분석을 사용하더라도 일부 보안 취약 패턴이 놓칠 수 있습니다.
- 사용자 입력을 절대 신뢰하지 말 것 – 원시 입력을 서버에 전송하거나 브라우저에 렌더링하기 전에 정화(sanitize)하십시오 (XSS 방지).
- PII 보호 – 개인 식별 정보를 제3자 서비스에 전송하기 전에 마스킹하거나 암호화하십시오.
- 비밀 유출 방지 – API 토큰, 비밀키 및
.env파일이 커밋되지 않도록 하십시오. 노출된 자격 증명은 즉시 교체하십시오.
오류 처리
- 예상되는 오류 처리 – 네트워크 요청(e.g.,
fetch)을try/catch블록으로 감싸세요. - 예기치 않은 변형 방지 – 객체를 수정하기 전에 복제하거나, 읽기 전용 값을 반환하는 getter를 사용하세요.
- 사용자에게 표시되는 오류 메시지 – 스택 트레이스, 서버 세부 정보 또는 공격자에게 도움이 될 수 있는 기타 민감한 정보를 노출하지 마세요.
타입 안전성
- 모든 데이터, 특히 API 응답이 올바르게 타입 지정되도록 보장합니다 (예: TypeScript 인터페이스 또는 타입 사용).
- 잘 정의된 타입은 불일치를 조기에 포착하고 코드베이스를 유지 관리하기 쉽게 만듭니다.
Summary
철저함과 실용성의 균형을 맞추는 것이 핵심입니다. 인간의 판단을 통해 무엇이 “충분히 좋다”고 판단하고 무엇이 더 깊은 검토가 필요한지를 결정할 수 있습니다—이는 AI만으로는 완전히 재현할 수 없는 부분입니다. 이 체크리스트를 살아있는 문서처럼 활용하고, 팀과 코드베이스가 발전함에 따라 적응시켜 주세요.
실수 방지
실수를 할 가능성이 줄어듭니다. 예를 들어, 값을 대문자로 변환하기 전에 키가 특정 이름인지 확인할 수 있습니다. 잘못된 키 이름을 입력하면 코드가 예상대로 작동하지 않습니다.
또 다른 문제는 필드가 선택 사항일 때입니다; 선택 사항이라는 것을 모르면 정의되어 있는지 확인하는 과정을 생략하게 되고, 그 필드가 없을 때 런타임 오류가 발생합니다. 인터페이스를 정의해 두면 IDE가 정확한 키 이름을 식별하도록 도와주어 잘못된 가정으로 인한 실수를 방지할 수 있습니다.
최적화
저는 코드 라인이 최적화될 수 있는 부분을 찾습니다. 코드 라인이 적을수록 버그가 발생할 가능성이 줄어듭니다.
- 경우에 따라 이미 비슷한 로직을 가진 유틸리티 함수가 있는지 확인하고 재사용할 수 있습니다. 해당 유틸리티 함수를 약간 수정하거나 확장하여 새로운 구현을 지원할 방법을 찾아보세요.
- 객체 매핑이나 체이닝을 직접 사용할 수 있는 곳에 중간 변수를 할당할 필요가 있나요? 추가 변수는 메모리를 더 사용하지만(보통은 미미함) 이러한 작은 변화가 누적되어 시간이 지나면서 성능을 향상시킬 수 있습니다.
PR에서 제가 확인하는 항목이 더 있을 것이라 확신하지만, 현재 생각나는 가장 중요한 항목은 위와 같습니다. 중요한 것은 제품, 애플리케이션 사용자, 자신, 그리고 팀원을 신경 쓰는 것입니다. 충분히 신경 쓴다면 코드의 대부분 실수를 발견하고 고치려고 할 것입니다. 이것이 인간 리뷰어로서 우리를 특별하게 만드는 점입니다.