TL;DR
Google Cloud 엔지니어들이 공유한 업무용 prompt의 공통점은 AI에게 빠른 코드 생성을 맡기는 대신 반론, 감사, 등급 평가, 외부 조사, 단계별 재검토를 요구한다는 데 있습니다. 요구사항을 만들기 전 skeptical architect로 질문하게 하고, 테스트 가능성과 보안 공백을 먼저 검사하며, 코드 리뷰에서는 production 실패 조건과 수정안까지 강제합니다. 글은 Python script와 GitHub Actions를 이용해 이러한 adversarial review를 모든 Pull Request에 자동 적용하는 방법도 제시합니다. 최종적으로 directed acyclic graph의 seams까지 점검하면 정상 경로에 가려진 권한 누락, race condition, 계층 간 결합을 더 체계적으로 찾을 수 있습니다.
섹션별 상세
def get_diff() -> str:
"""Pulls the actual staged diff from git, falling back to unstaged."""
result = subprocess.run(
["git", "diff", "--staged"], capture_output=True, text=True, check=True
)
diff = result.stdout
if not diff.strip():
result = subprocess.run(["git", "diff"], capture_output=True, text=True, check=True)
diff = result.stdout
return diffstaged 변경 사항을 먼저 가져오고 비어 있으면 unstaged 변경 사항을 반환해 리뷰 대상 diff를 확보합니다.
def review_diff(diff: str) -> str:
"""Sends the diff to the model and returns the markdown review."""
client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=2000,
messages=[{"role": "user", "content": REVIEW_PROMPT.format(diff=diff)}],
)
return "".join(block.text for block in response.content if block.type == "text")환경 변수의 API 키로 Anthropic client를 만들고 실제 git diff를 평가 프롬프트에 넣어 모델의 markdown 리뷰를 반환합니다.
def main():
diff = get_diff()
if not diff.strip():
print("No changes to review.")
sys.exit(0)
report = review_diff(diff)
with open("review_report.md", "w") as f:
f.write(report)
print(report)검토할 변경 사항이 없으면 API 호출 없이 종료하고, 변경 사항이 있으면 리뷰 결과를 파일에 저장한 뒤 출력합니다.
이미지 분석

기사의 열 가지 기법이 공통적으로 목표와 맥락을 분명히 하고, 제약과 출력 형식을 지정한 뒤 반복 검토를 거쳐 신뢰할 수 있는 결과를 얻는다는 점을 시각화합니다. 특히 단순한 요청보다 역할, 검증 조건, 승인 시점을 명시해야 한다는 글의 prompt 설계 원칙과 직접 연결됩니다.
이미지는 prompt를 Goal, Context, Constraints, Format 네 요소로 구조화한 뒤 코드 실행과 reliable output으로 이어지는 흐름을 표현합니다.
용어 해설
- 적대적 검토(Adversarial Review)
- — AI를 사용자의 의견에 동의하는 보조자가 아니라 반론을 제기하는 검토자로 활용하는 방식입니다. 구체적인 역할과 실패 조건을 부여해 계획, 코드, 테스트에서 놓친 위험을 찾고, 첫 제안이 그대로 확정되는 문제를 줄이는 데 목적이 있습니다.
- 테스트 가능성(Testability)
- — 코드의 구성 요소를 독립적으로 검증하기 쉬운 정도를 뜻합니다. 외부 의존성 주입, 도메인 로직과 HTTP 계층의 분리처럼 테스트 격리를 가능하게 하는 구조를 먼저 점검해야 실제로 중요한 검증 공백을 찾을 수 있습니다.
- 경쟁 조건(Race Condition)
- — 여러 요청이나 작업이 같은 데이터를 동시에 처리하면서 실행 순서에 따라 결과가 달라지는 문제입니다. 이 글에서는 동시에 같은 작업을 수정하는 상황을 누락된 테스트의 사례로 제시하며, 단순한 정상 경로 검증만으로는 발견하기 어렵다는 점을 짚습니다.
- 유향 비순환 그래프(Directed Acyclic Graph)
- — 노드와 방향성 있는 간선으로 작업 흐름을 표현하되 순환을 허용하지 않는 그래프 구조입니다. 요청, 인증, 소유권 검사, 반복 일정 확장, 데이터베이스 기록, Webhook 전송을 연결하면 구성 요소 사이의 경계와 장애 전파 지점을 체계적으로 우선순위화할 수 있습니다.
- OAuth Scope
- — 인증된 애플리케이션이나 사용자가 접근할 수 있는 권한 범위를 나타내는 값입니다. 선언된 Scope 목록과 실제 코드에서 검사하는 위치를 대조하면 선언만 되고 집행되지 않는 권한이나 반대로 누락된 선언을 찾을 수 있습니다.
기술
- Google Cloud
- Gemini CLI
- GitHub Actions
- Python
- Anthropic API
- Claude Sonnet 4-6
- FastAPI
- Git
활용 사례
- 반복 작업을 지원하는 task-tracker REST API 설계
- AI가 생성한 코드의 보안 검토
- Pull Request 자동 code review
- OAuth scope와 실제 권한 검사 대조
- Scheduler와 Webhook 사이의 경계 테스트
- AI 지원 개발 계획의 trade-off 검증
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
