본문으로 건너뛰기

Google 엔지니어의 검증형 Prompt 설계

Google 엔지니어들은 AI를 동의하는 도구보다 코드와 계획의 허점을 찾는 검토자로 활용합니다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Google Cloud 엔지니어들이 공유한 업무용 prompt의 공통점은 AI에게 빠른 코드 생성을 맡기는 대신 반론, 감사, 등급 평가, 외부 조사, 단계별 재검토를 요구한다는 데 있습니다. 요구사항을 만들기 전 skeptical architect로 질문하게 하고, 테스트 가능성과 보안 공백을 먼저 검사하며, 코드 리뷰에서는 production 실패 조건과 수정안까지 강제합니다. 글은 Python script와 GitHub Actions를 이용해 이러한 adversarial review를 모든 Pull Request에 자동 적용하는 방법도 제시합니다. 최종적으로 directed acyclic graph의 seams까지 점검하면 정상 경로에 가려진 권한 누락, race condition, 계층 간 결합을 더 체계적으로 찾을 수 있습니다.

섹션별 상세

01
Google Cloud 개발자 관계 팀이 열 명의 엔지니어와 리더에게 업무에서 없으면 안 되는 prompt를 물었고, 답변들은 서로 다른 표현보다 공통된 작업 방식으로 모였습니다. 핵심은 AI를 사용자의 첫 판단에 동의하는 assistant가 아니라 반론을 제기하는 adversarial second opinion으로 배치하는 것입니다. 이 관점은 입력을 더 빨리 코드로 바꾸는 대신 계획과 구현에 숨어 있는 인간의 가정을 드러내는 데 초점을 둡니다.
02
Maja Bilić의 방식은 코드를 요청하기 전에 모델에게 냉소적인 principal architect와 technical PM 역할을 부여하는 것입니다. 모델은 반복 작업 기능의 기술, 데이터 모델, UX 고려 사항을 먼저 나열하고 각각에 필요한 질문을 던진 뒤, 답변을 요구사항 문서와 구현 계획으로 변환합니다. 이렇게 하면 daily, weekly, custom RRULE과 timezone 같은 조건을 초기에 확인하면서 과도한 설계와 지나친 단순화를 함께 피할 수 있습니다.
03
Andrew Brogdon의 prompt는 테스트를 곧바로 생성하지 않고 먼저 코드베이스의 검증 공백과 testability를 감사하게 만듭니다. 외부 호출이 주입되는지, scheduling logic이 HTTP 계층과 분리됐는지 확인한 뒤 이미 검증된 범위와 우선순위가 높은 누락 테스트를 구분하고 구현합니다. 이 순서는 작성하기 쉬운 코드만 테스트하는 문제를 줄여 실제 위험이 큰 endpoint와 business logic에 검증 역량을 집중시킵니다.
04
Aja Hammerly는 넓은 하나의 review 요청 대신 새 대화에서 두 개의 좁은 prompt를 순서대로 사용합니다. 첫 번째는 기존 테스트를 실행하면서 empty recurrence rules, timezone boundaries, 동시 업데이트에 따른 race conditions 같은 구조적 누락을 찾고, 두 번째는 unused code, 오래된 debug comments, 불일치하는 comments, TODOs를 찾습니다. 구조적으로 빠진 것과 남은 정리 대상을 분리하면 하나의 포괄적 요청이 만드는 일반적인 답변보다 각 검토의 초점이 선명해집니다.
05
Rich Hyndman의 compliance 점검은 선언된 권한과 실제 집행 지점을 전부 수집해 서로 대조하는 흐름을 사용합니다. task-tracker API에서는 route decorators, middleware config, API gateway rules에서 OAuth scope를 모은 뒤 코드의 검사 위치와 비교해 선언됐지만 강제되지 않는 scope와 반대로 선언이 없는 검사까지 표시합니다. 결과를 markdown 보고서와 suggested diffs로 만들되 승인을 받기 전에는 편집하지 않도록 제한해 자동 수정으로 인한 권한 변경을 막습니다.
06
Shir Meir Lador는 모델의 정중한 code review가 production 위험을 놓치는 문제를 줄이기 위해 엄격한 principal engineer 역할과 A부터 F까지의 등급을 결합합니다. 모델은 redundant database queries, missing caching, scheduler의 silent failure, error boundary 부재, recurrence logic과 HTTP layer의 결합을 점검하고 각 문제가 production에서 어떻게 실패하는지와 수정용 git diff를 함께 작성합니다. A를 받을 조건을 실제 견고성으로 제한하면 이름이나 docstring을 칭찬하는 수준을 넘어 효율성, resilience, architecture의 실패 지점을 찾도록 유도할 수 있습니다.
07
James O'Reilly의 짧은 후속 prompt는 모델이 방금 만든 implementation plan을 스스로 방어하게 만듭니다. performance, cost, security, maintainability 관점에서 최소 하나의 대안과 비교해 무엇을 포기하는지 밝히게 하면, 잘 정리된 첫 계획이 유일한 정답처럼 굳어지는 현상을 막을 수 있습니다. 최종 선택권은 모델이 아니라 trade-off를 확인한 사람에게 남습니다.
08
Emma Twersky의 방식은 모델이 외부 자료를 조사한 뒤 프로젝트에 맞는 수동 검토 checklist로 변환하게 합니다. 글은 2022년 GitHub Copilot 연구가 89개 보안 관련 시나리오에서 생성 프로그램 1,689개를 분석했고 약 40%에서 실제 취약점을 발견했다고 전하며, AI가 만든 코드가 컴파일되고 겉보기에는 정상일 수 있다는 위험을 연결합니다. FastAPI 코드의 scheduling 또는 cron logic, webhook signature verification, update 요청의 task ownership 검사처럼 고위험 영역을 구체적으로 지정하면 일반적인 버그 검토보다 근거 있는 점검 항목을 얻을 수 있습니다.
python
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 diff

staged 변경 사항을 먼저 가져오고 비어 있으면 unstaged 변경 사항을 반환해 리뷰 대상 diff를 확보합니다.

python
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 리뷰를 반환합니다.

python
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 호출 없이 종료하고, 변경 사항이 있으면 리뷰 결과를 파일에 저장한 뒤 출력합니다.

09
Fred Sauer는 discovery, proof of concept, refinement, final review를 나누고 작업 단계에 따라 prompt의 구체성을 바꾸는 staged workflow를 사용합니다. 초기에는 지나친 제약이 모델의 질문 범위를 좁힐 수 있으므로 열어 두고, 구현 가능성을 확인한 뒤 점차 정밀하게 다듬으며, 마지막에는 새 대화에서 unhandled corner cases와 performance를 다시 점검합니다. 이후 특정 finding만 수정하도록 지시하면 모든 복잡성을 무조건 추가하지 않고 사람이 감수할 위험을 선택할 수 있습니다.
10
Remigiusz Samborski는 adversarial code review를 사람이 기억해서 요청하는 절차가 아니라 GitHub Actions의 모든 pull request에 연결된 자동화 단계로 바꿉니다. 글의 독립 구현 예시는 Python script가 staged diff를 먼저 읽고 없으면 unstaged diff를 가져온 뒤, Anthropic API에 엄격한 등급 기준과 함께 보내 review_report.md에 결과를 저장합니다. Python 3.9+, anthropic package, ANTHROPIC_API_KEY가 필요하며 CI에서 GitHub API로 결과를 PR comment에 게시할 수 있어 리뷰 누락을 구조적으로 줄입니다.
11
Karl Weinmeister는 테스트 아이디어를 평면적인 checklist로 나열하는 대신 애플리케이션 흐름을 directed acyclic graph로 표현하게 합니다. request, auth middleware, task-ownership check, recurrence-expansion logic, database write, webhook dispatch를 노드와 경계로 연결하고 구성 요소 사이의 seams에서 장애가 어떻게 전달되는지 별도로 평가합니다. 출력물을 seam, risk, suggested test 열을 가진 우선순위 markdown table로 만들면 단일 컴포넌트가 소유하지 않아 검증이 빠지기 쉬운 handoff 지점을 집중적으로 다룰 수 있습니다.

이미지 분석

이미지는 prompt를 Goal, Context, Constraints, Format 네 요소로 구조화한 뒤 코드 실행과 reliable output으로 이어지는 흐름을 표현합니다.
Diagram

기사의 열 가지 기법이 공통적으로 목표와 맥락을 분명히 하고, 제약과 출력 형식을 지정한 뒤 반복 검토를 거쳐 신뢰할 수 있는 결과를 얻는다는 점을 시각화합니다. 특히 단순한 요청보다 역할, 검증 조건, 승인 시점을 명시해야 한다는 글의 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 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 08. 27.수집 2026. 08. 27.출처 타입 RSS

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.