AI 코드 점검

OpenClaw가 당신의 Senior Engineer —— 24시간 대기, 모든 코드를 꼼꼼히 봐요

Code Review의 현실

Review 기다리다 꽃까지 피어요

PR을 올렸는데, 시니어가 다른 프로젝트 때문에 바빠요. 이틀 지나서 겨우 Review했는데 "LGTM"이라고만 남겨요. 너무 오래 기다리거나, 아니면 제대로 안 봐요 —— 이런 Review가 뭐 하는 건지 모르겠어요.

더 짜증나는 건 팀 사람마다 기준이 달라요. 철수는 이렇게 코드 짜도 괜찮다고, 영희는 무조건 바꿔야 한다고 해요. 그럼 누구 말을 들을까? 기준을 통일하자고 3번 회의 해도 못 정해요.

OpenClaw: 24시간 대기하는 Senior Engineer

코드를 OpenClaw에 던지면, 업계 모범 사례로 한 줄 한 줄 점검해줘요: 보안 구멍, 성능 병목, 유지보수성, 엣지 케이스, 다 봐요.

줄을 서서 기다릴 필요 없고, 사람 눈치 볼 필요 없고, "바빠서" LGTM 하는 일도 없어요. 그리고 매번 Review 기준이 정확하게 같아요 —— 더 이상 "이게 문제인지 아닌지" 채팅에서 싸울 필요가 없어요.

3가지 Review Prompt, 복사하면 끝

보안 점검부터 설계 원칙까지, 필요한 걸 골라 쓰면 돼요.

Review PR: 보안 + 성능 전문 점검 골든 인스트럭션
아래 코드 변경사항 (PR diff)을 Review해줄래. 이 부분들을 집중해서 봐줄래:

1. 보안 구멍: SQL 인젝션, XSS, CSRF, 민감한 정보 유출, 안전하지 않은 역직렬화
2. 성능 문제: N+1 쿼리, 불필요한 메모리 할당, 인덱스 없는 쿼리, 블로킹 연산
3. 엣지 케이스: null 값 처리, 동시성 경쟁, 대용량 데이터 시나리오

각 문제마다:
- 심각도 (Critical / Warning / Suggestion)
- 구체적 위치 (파일명 + 줄 번호)
- 수정 제안과 예제 코드

마지막으로 종합 평가와 머지 권고 여부 줄래.
이 명령은 PR 제출 전에 자기 자신이 먼저 한 번 돌려보기 좋아요. 흔한 보안 문제 대부분을 잡을 수 있어요. Claude Opus 4.6 쓰는 걸 추천해요. 파일 간 보안 리스크를 더 잘 이해하거든요.
SOLID 원칙 준수 점검 고급 기법
아래 코드가 SOLID 원칙을 따르는지 점검해줄래:

- S (단일 책임): 이 클래스/함수가 너무 많은 일을 하는 건 아닐까?
- O (개방-폐쇄): 새로운 기능 추가하려면 기존 코드를 수정해야 하나?
- L (리스코프 치환): 자식 클래스가 부모 클래스를 안전하게 대체할 수 있나?
- I (인터페이스 분리): 인터페이스가 너무 뚱뚱하진 않나?
- D (의존성 역전): 고수준 모듈이 저수준 구현에 직접 의존하지 않나?

원칙을 위반하는 부분마다:
1. 구체적으로 뭘 위반했는지, 어디서
2. 왜 이게 문제인지
3. 리팩토링 방안과 코드 예제
핵심 비즈니스 로직이나 기반 구조 코드 Review할 때 써요. 일반적인 CRUD 작은 엔드포인트는 이 정도로 할 필요 없어요.
데이터베이스 쿼리 N+1 문제 점검 골든 인스트럭션
아래 코드에서 데이터베이스 쿼리를 분석해줄래:

1. N+1 쿼리 문제 찾아내기:
   - 루프에서 실행되는 쿼리 표시
   - 최악의 경우 얼마나 많은 쿼리가 실행될지 계산
2. 최적화 방안:
   - JOIN으로 합칠 수 있는 게 뭔지
   - eager loading / preload로 할 수 있는 게 뭔지
   - 캐시 필요한 게 뭔지
3. 최적화된 코드 작성
4. 최적화 전후 성능 차이 추정

사용하는 ORM 프레임워크는 [당신의 프레임워크, 예: SQLAlchemy / Prisma / ActiveRecord].
N+1은 가장 흔한 성능 킬러 중 하나예요. 리스트 페이지 느리면 먼저 이걸 확인해봐요. ORM 프레임워크 이름을 당신이 실제로 쓰는 걸로 바꾸는 거 잊지 말고요.

코드 점검: OpenClaw vs GitHub Copilot

둘 다 코드를 Review할 수 있지만, 방식이 완전 달라요.

OpenClaw
  • 전체 프로젝트 컨텍스트를 볼 수 있어서, 파일 간 비즈니스 로직을 이해해요
  • Prompt 완전히 커스터마이징 가능해서, 당신의 팀 규범대로 Review해요
  • 모델 자유롭게 전환 가능: 간단한 Review는 GPT-4o, 복잡한 아키텍처는 Opus 4.6
  • Review 결과를 내보내고, 저장하고, 팀 지식 기반으로 만들 수 있어요
VS
GitHub Copilot Code Review
  • GitHub PR 인터페이스에 통합되어서, 실행하기 편해요
  • 주로 diff 내용만 점검해서, 파일 간 이해도가 제한적이에요
  • 모델 고정되어서, Review 규칙을 자유롭게 바꿀 수 없어요
  • 중국어 주석과 변수명을 이해할 때 가끔 실수해요

실제 상황

스타트업: 백엔드 엔지니어 두 명이 모든 코드 담당
팀이 백엔드 두 명뿐이라 서로 Review하는데, 자주 놓쳐요. 온라인에 배포된 후 Bug로 발견되곤 해요.
OpenClaw 방안
PR 제출 전에 OpenClaw로 보안 + 성능 Review 한 번 하고, 명백한 문제를 필터링해요. 사람이 하는 Review는 비즈니스 로직에만 집중하면 돼요. 온라인 사고 비율이 반으로 줄고, Review 시간이 평균 2일에서 반나절로 줄었어요.
순수 인력 방안
두 명이 서로 Review해요. 바쁠 때는 그냥 LGTM만 눌러요. 코드 기준은 입으로만 약속하는데, 신입이 오면 또 처음부터 설명해야 해요.

몇 가지 실용적인 조언

💡 프로젝트 전체를 한 번에 AI에 Review 하지 말고, 모듈별로 나눠서 하되, 매번 한 가지 관점(예: 보안, 성능, 가독성)에 집중하면 효과가 더 좋아요.
🎯 AI Review는 사람 Review를 대체하는 게 아니고, 사람 Review 전에 먼저 거르는 단계예요. 머신이 포맷과 흔한 문제를 잡고, 사람은 설계와 비즈니스 로직을 보세요.
이 사례가 도움이 됐나요?