Grok 4.7 프롬프트 모음: 5가지 시나리오 바로 복사하기

TL;DR: 5가지 시나리오 전부 grok-4.7로 HiAPI 프로덕션 환경에서 실제 실행했고, 출력 원문을 그대로 첨부했습니다. 1회 비용은 $0.007–0.021이며 5개를 모두 실행하면 약 $0.06입니다. 각 프롬프트 아래 링크를 클릭하면 동일한 프롬프트가 모델 페이지에 자동 입력되어 전송만 하면 재현됩니다. Grok 4.7은 HiAPI에 출시되었으며, 모델 페이지 열기에서 바로 체험할 수 있고 신규 가입 시 200 포인트를 제공합니다.

시나리오 1: 동시성 교착 상태 진단

근본 원인은 응답 객체가 해제되지 않아 연결이 계속 connector 풀의 슬롯을 점유하고 있기 때문입니다.

session.get()이 반환하는 ClientResponse는 release() / close()(또는 비동기 컨텍스트 관리자 종료) 시에만 연결을 TCPConnector에 반환합니다. 현재 코드는 async with도 없고 명시적 release()도 없습니다. body를 읽는 것만으로는 연결이 반환되지 않으며, 응답과 connection 사이에 순환 참조가 있어 순환 GC의 __del__이 실행될 때까지 해제되지 않습니다.

기본적으로 각 ClientSession의 연결 상한은 100입니다. 20개의 worker가 각각 session을 하나씩 보유하고 요청을 직렬 전송하며, 각 worker는 약 250개의 URL을 처리합니다. 연결이 반환되지 않으면:

1. 점유된 연결이 서버 측 유휴 타임아웃이나 연결 수 제한으로 RST되면 aiohttp가 프로토콜 계층에서 ConnectionResetError를 발생시킵니다(반드시 여러분의 await에서 던져지는 것은 아니므로 except로 잡지 못하고 정리도 못 합니다).
2. 슬롯은 여전히 점유된 상태입니다. 100개가 차면 다음 session.get()은 connector.acquire()에서 멈추며, 이 대기는 대개 timeout 제약도 받지 않습니다.
3. 모든 worker가 acquire에서 막혀 더 이상 queue.get()도 task_done()도 하지 않습니다. 이벤트 루프에 새로운 할당이 없으니 순환 GC도 실행되지 않고 __del__이 연결을 회수하지 못해 교착 상태가 됩니다. queue.join()도 영원히 기다리게 됩니다.

except Exception: pass는 사용자 코루틴의 예외만 삼킬 뿐 연결을 해제하지 못하므로 「오류」와 「교착」이 함께 나타납니다.

최소 변경:

async def fetch(url, session):
    async with session.get(url) as r:
        return await r.json()

async with는 정상 반환과 예외 두 경로 모두에서 __aexit__ → release()를 수행합니다:

• 연결이 즉시 풀로 반환되어 슬롯이 100까지 쌓이지 않고, session.get()이 더 이상 acquire에서 영구적으로 막히지 않아 worker가 큐 소비를 계속할 수 있습니다. 이것이 교착을 해결합니다.
• 연결이 장시간 점유되어 서버 RST를 기다리는 일이 없어지므로 프로토콜 계층의 ConnectionResetError도 사라집니다. body를 읽다가 실제로 연결이 끊기더라도 컨텍스트 관리자가 해당 연결을 반환/종료하므로 한 번의 실패가 풀을 고사시키지 않습니다. 이것이 오류를 해결하고, 오류 이후에도 큐가 계속 진행되도록 보장합니다.

전체 프롬프트:

아래 Python 코드는 동시성이 조금만 커져도 무작위로 ConnectionResetError가 발생하고, 이어서 worker 전체가 교착되어 큐를 더 이상 소비하지 않습니다. 근본 원인을 찾고, 최소 변경으로 수정한 뒤, 왜 그 수정이 「오류」와 「교착」 두 문제를 동시에 해결하는지 설명해 주세요.

```python
import asyncio, aiohttp

async def fetch(url, session):
    r = await session.get(url)
    return await r.json()

async def worker(queue):
    session = aiohttp.ClientSession()
    while True:
        url = await queue.get()
        try:
            data = await fetch(url, session)
            print(data)
        except Exception:
            pass
        queue.task_done()

async def main():
    queue = asyncio.Queue()
    for i in range(5000):
        queue.put_nowait(f"https://api.example.com/item/{i}")
    workers = [asyncio.create_task(worker(queue)) for _ in range(20)]
    await queue.join()

asyncio.run(main())
```

이 프롬프트로 생성하기 →

grok-4.7, 기본 high 추론 단계, max_tokens 상한 6000, 실제 실행 107.7s, 입력 3,572 / 출력 7,301 tokens, 약 $0.021.

증상, 코드, 그리고 「두 문제를 반드시 동시에 설명할 것」이라는 제약을 한 번에 다 줘야 모델이 표면적인 try-catch 수정에 그치지 않고 연결 풀 계층의 근본 원인까지 찾아냅니다.

시나리오 2: 코드 리뷰를 JSON으로 받기

{"issues":[{"severity":"high","line":8,"problem":"잔액 확인과 차감이 분리되어 TOCTOU 경쟁 조건이 존재: 동시 요청이 동시에 잔액 판정을 통과한 뒤 중복 차감되어 초과 인출 또는 이중 지불 발생","fix":"단일 조건부 업데이트(예: balance>=amount일 때만 $inc)로 바꾸거나, 트랜잭션 내 행 잠금/낙관적 잠금으로 확인과 차감을 원자적으로 처리"},{"severity":"high","line":9,"problem":"차감과 입금이 두 번의 독립 쓰기 작업이며 트랜잭션이 없음; 첫 단계 성공 후 두 번째 단계 실패 시 자금이 from에서 사라지고 롤백 불가","fix":"두 업데이트를 동일 데이터베이스 트랜잭션에 넣어 하나라도 실패하면 전체 롤백하고, to 계정 존재를 확인한 뒤 커밋"}]

,"summary":"이 송금 API는 원자적 트랜잭션, 인증, 입력 검증이 모두 빠져 있어 동시성 환경에서 이중 지불이나 자금 유실이 발생하며, 예외 경로에서 요청이 멈출 수 있습니다."}

(발췌: 원본 출력은 단일 행 JSON이며, 앞의 high 문제 2건과 summary만 남기고 나머지는 생략)

전체 프롬프트:

아래 Node.js 라우트 코드를 검토하여 프로덕션 장애를 일으킬 수 있는 모든 문제(보안, 동시성, 리소스 누수 포함)를 찾아 심각도 순으로 정렬해 주세요. 반드시 JSON으로 출력하고 형식은 다음과 같습니다: {"issues": [{"severity": "high|medium|low", "line": 줄번호, "problem": "문제", "fix": "수정 방법"}], "summary": "한 문장 요약"}.

```js
const express = require('express');
const db = require('./db');
const router = express.Router();

router.post('/transfer', async (req, res) => {
  const { from, to, amount } = req.body;
  const fromAccount = await db.findOne({ id: from });
  if (fromAccount.balance >= amount) {
    await db.update({ id: from }, { $inc: { balance: -amount } });
    await db.update({ id: to }, { $inc: { balance: amount } });
    res.json({ ok: true });
  } else {
    res.status(400).json({ ok: false });
  }
});

module.exports = router;
```

이 프롬프트로 생성하기 →

grok-4.7, 기본 high 추론 단계, max_tokens 상한 4000, 실제 실행 40.1s, 입력 3,576 / 출력 2,734 tokens, 약 $0.010.

원하는 JSON 골격(필드명, 정렬 규칙)을 프롬프트에 그대로 적으면 grok-4.7이 형식을 엄격히 지켜 출력하므로 바로 파이프라인에 투입할 수 있습니다.

시나리오 3: 기술 설계 비교

「활동 하트비트 + Redis TTL + 필요 시 짧은 폴링」을 권장하며, WebSocket/SSE로 전체 온라인 상태를 푸시하는 방식은 피하세요. 5분 후 회색으로 바뀌는 데 초 단위 푸시는 불필요하며, DAU 10만에서도 폴링으로 충분히 감당 가능하고 Next.js에도 더 잘 맞습니다.

설계 비교

	폴링	SSE	WebSocket
방향	클라이언트가 당김	서버 단방향 푸시	양방향
「5분 무활동 시 회색」과의 적합성	높음. 30–60초 갱신이면 녹색 점에 충분	중간. 푸시는 더 빠르지만 타임아웃 회색 처리는 직접 계산해야 함	낮음~중간. 연결 유지 ≠ 사용자 활동
Next.js 적합성	최고. 일반 Route Handler	나쁨. 장기 연결은 Serverless/다중 인스턴스에 불리	최악. 별도 WS 프로세스, 스티키 세션 또는 서드파티 필요
연결 비용	장기 연결 없음	온라인 사용자당 1개	온라인 사용자당 1개, 하트비트 유지 필요
확장	무상태, 수평 확장 간단	끊김, 재연결, 다중 인스턴스 팬아웃 관리 필요	동일하며 더 무거움
실패 모드	특정 요청 실패 시 다음에 다시 당김	끊기면 상태 갱신 중단, 보충 조회 필요	동일하며 게이트웨이가 복잡
DAU 10만에서 가치 있는가	가치 있음, 기본 설계로 채택	기존 푸시 채널이 있을 때만 가치 있음	기존 채팅/협업 게이트웨이가 있을 때만 가치 있음

대략적 피크 계산: DAU 10만, 동시 접속을 5%–15%로 추정하면 약 5천–1만 5천. 하트비트를 45초에 한 번이면 약 100–300 쓰기/초, 사용자마다 30초에 한 번 표시 대상 사용자 상태를 당기면 읽기도 Redis의 편안한 범위입니다. 병목은 「녹색 점」에 생기지 않습니다.

권장안과 근거

Redis를 온라인 상태의 기준으로 삼고, PostgreSQL은 콜드 last_seen만 저장하며, 클라이언트는 현재 화면에 보이는 사용자만 폴링합니다.

1. 제품 의미는 「5분 무활동」이며 「TCP가 아직 연결됨」이 아닙니다. 페이지를 그대로 두면 회색으로 바뀌어야 하므로 WS를 쓰더라도 별도 활동 하트비트가 필요합니다. 연결 자체로는 요구사항을 해결할 수 없습니다.
2. 녹색 점은 수십 초 오차를 허용합니다. 폴링 간격 30–60초는 5분 창에 비해 충분합니다.
3. Next.js(특히 Vercel / Serverless)는 장기 연결 유지에 적합하지 않습니다. WS/SSE는 별도 실시간 서비스, 스티키 라우팅, 끊김 보상까지 끌어들이는데 이득은 작습니다.
4. 누가 누구의 상태를 봐야 하는지는 대개 국소적입니다(친구, 대화 목록, 현재 페이지 아바타). 전역 브로드캐스트가 아니므로 id로 Redis를 일괄 조회하는 편이 구독 관계 유지보다 한 자릿수 배 더 단순합니다.
5. Redis key 만료가 「타임아웃 오프라인」을 자연스럽게 표현하므로 keyspace notification이나 전체 테이블 스캔이 필요 없습니다.

사용자 단위 존재=온라인(권장 주 설계):

```text
presence:u:{userId}   STRING  값 = 서버 unix 밀리초
                      TTL = 300초
                      하트비트 시 SET key value EX 300
                      온라인 = key 존재
```

클라이언트 시간을 쓰지 마세요. TTL을 하트비트 간격의 2–3배보다 크게 잡을 필요는 없습니다. 여기서는 하트비트 45–60초, TTL 300초로 두어 두세 번 하트비트를 놓쳐도 온라인으로 간주되어 「5분 무활동」에 부합합니다.

(발췌: 권장 결론과 앞의 5가지 근거, Redis key 설계 중 사용자 단위 주 설계)

전체 프롬프트:

DAU 10만인 웹 애플리케이션에 「실시간 온라인 상태」 기능(사용자 아바타 옆에 녹색 점 표시, 5분 무활동 시 회색)을 추가하려 합니다. 기술 스택은 Next.js + PostgreSQL + Redis입니다. 먼저 설계 비교(WebSocket / SSE / 폴링)를 제시하고, 어느 것을 권장하는지와 이유를 설명한 뒤, 구현 단계와 Redis key 설계를 나열해 주세요. 전체 코드는 쓰지 말고 핵심 조각은 붙여도 됩니다.

이 프롬프트로 생성하기 →

grok-4.7, 기본 high 추론 단계, max_tokens 상한 6000, 실제 실행 69.8s, 입력 3,429 / 출력 4,247 tokens, 약 $0.014.

기술 스택과 업무 규모를 먼저 한정하고 「비교 먼저, 권장은 그다음」을 요구하면, 중립적인 설명이 아니라 바로 리뷰에 쓸 수 있는 설계가 나옵니다.

시나리오 4: 개념 설명

먼저 상황을 명확히 하겠습니다. 주문을 처리한다고 가정하면 주문을 데이터베이스에 기록해야 하고, 동시에 메시지 큐에 메시지를 넣어 재고, 포인트, 알림 같은 다운스트림이 작업하도록 해야 합니다. 이 두 동작은 같은 「트랜잭션」 안에 있지 않으므로 중간 어느 단계가 실패하든 시스템에는 「한쪽은 성공, 한쪽은 미발생」의 균열이 생깁니다.

DB를 먼저 쓰고 메시지를 보내면 메시지가 왜 유실되는가

데이터베이스 커밋이 성공해 주문이 이미 저장되었습니다. 이어서 프로세스가 메시지를 보내야 하는데 이때 다음과 같은 일이 발생할 수 있습니다:

• 네트워크가 잠깐 흔들려 전송 실패;
• 메시지 큐가 일시적으로 사용 불가;
• 더 흔하게는 프로세스가 DB 커밋 이후, 메시지 전송 이전에 바로 죽는 경우(머신 재시작, OOM, 배포 롤링).

주문은 DB에 있는데 메시지는 영원히 전송되지 않습니다. 다운스트림은 해당 주문이 있는지 전혀 모르고 재고도 차감되지 않으며 알림도 가지 않습니다. 나중에 재시도해도 소용없습니다. 죽은 프로세스는 이미 사라졌고, 별도로 신뢰할 수 있는 보상을 만들어 두지 않았다면 이 메시지는 유실된 것입니다. 모놀리식만 다뤄 본 사람에게는 이렇게 비유할 수 있습니다. 장부에 「입금 완료」를 적고 나서 우체국에 가서 통지서를 부쳤는데 편지가 도중에 분실되었고 장부는 이미 바뀌어 양쪽이 맞지 않는 상황입니다.

(발췌: 「DB 먼저 쓰고 메시지 전송」의 유실 메커니즘과 핵심 비유)

전체 프롬프트:

경력 3년이지만 분산 시스템을 전혀 접해 보지 못한 백엔드 엔지니어가 이해할 수 있는 언어로, 왜 「DB에 먼저 쓰고 메시지 큐에 보내기」가 메시지 유실을 초래할 수 있는지, 그리고 「메시지 큐에 먼저 보내고 DB에 쓰기」도 안 되는지 설명해 주세요. 업계에서 흔히 쓰는 두 가지 올바른 방식(로컬 메시지 테이블 / 트랜잭션 메시지)이 각각 어떤 상황에 적합한지 제시해 주세요.

이 프롬프트로 생성하기 →

grok-4.7, 기본 high 추론 단계, max_tokens 상한 4000, 실제 실행 41.3s, 입력 3,410 / 출력 2,478 tokens, 약 $0.009.

「더 자세히 설명해 줘」 대신 「구체적인 페르소나에게 설명해 줘」라고 하면 모델이 적절한 세밀도를 스스로 선택합니다. 장부와 우체국 비유가 바로 그렇게 나온 것입니다.

시나리오 5: 데이터 분석 스크립트

```python
import pandas as pd
import numpy as np

# 예시 데이터(실제 df로 교체 가능)
np.random.seed(42)
n = 500
df = pd.DataFrame({
    "order_id": range(1, n + 1),
    "user_id": np.random.randint(1, 80, n),
    "amount": np.round(np.random.uniform(20, 500, n), 2),
    "created_at": pd.date_range("2023-01-01", periods=n, freq="D").astype(str),  # 문자열 날짜 시뮬레이션
    "status": np.random.choice(["paid", "paid", "paid", "cancelled"], n),
})

# ---------- 0. 날짜 처리: 문자열을 datetime으로 ----------
df["created_at"] = pd.to_datetime(df["created_at"], errors="coerce")
df = df.dropna(subset=["created_at", "amount", "user_id"])

# 선택 사항: 유효 주문만 집계(실제 업무에 맞게 status 값 조정)
df_valid = df[df["status"] == "paid"].copy()

# ---------- 1. 월별 GMV와 주문 수 ----------
df_valid["month"] = df_valid["created_at"].dt.to_period("M")
monthly = (
    df_valid.groupby("month", as_index=False)
    .agg(GMV=("amount", "sum"), order_count=("order_id", "count"))
    .sort_values("month")
)
monthly["month"] = monthly["month"].astype(str)
print("=== 월별 GMV와 주문 수 ===")
print(monthly)
```

(발췌: 코드 전반부(날짜 처리 + 월별 GMV), 후반부의 사용자 순위와 첫 주문 추세는 생략)

전체 프롬프트:

pandas로 이커머스 주문 데이터를 분석하려 합니다. 데이터프레임 df에는 order_id, user_id, amount, created_at, status 열이 있습니다. 완전히 실행 가능한 Python 코드를 주세요: 1) 월별 GMV와 주문 수; 2) 사용자별 누적 소비 순위(상위 20명만); 3) 신규 사용자 첫 주문 평균 금액의 월별 추세. created_at이 문자열인 경우를 처리하고 핵심 단계에 주석을 달아 주세요.

이 프롬프트로 생성하기 →

grok-4.7, 기본 high 추론 단계, max_tokens 상한 5000, 실제 실행 18.5s, 입력 3,440 / 출력 1,427 tokens, 약 $0.007.

열 이름, 계산할 지표, 경계 상황(created_at이 문자열)을 항목별로 나열하면 생성된 코드를 그대로 실행할 수 있어 재작업이 필요 없습니다.

프롬프트 작성법

1. 실제 코드와 실제 열 이름을 붙여넣으세요. 「어떤 코드가 있다」고 설명하지 말고 바로 붙여넣으세요.
2. 출력 형식을 프롬프트에 쓰세요: JSON이 필요하면 JSON 골격을 주고, 코드가 필요하면 「완전히 실행 가능」이라고 명시하세요.
3. 제약은 구체적일수록 좋습니다: 정렬 규칙, 상위 20개만, 전체 코드 말고 핵심 조각만.

자주 묻는 질문

이 프롬프트들을 바로 써도 되나요? 됩니다. 5개 모두 HiAPI에서 실제 실행한 독창 프롬프트이며 출력은 실제로 나온 결과입니다. 각 항목 아래의 「이 프롬프트로 생성하기」를 클릭하면 모델 페이지에 자동으로 채워지므로, 자신의 코드나 데이터로 바꿔 바로 사용할 수 있습니다.

grok-4.7의 코딩 능력은 어떤가요? xAI가 내건 포지셔닝이 코딩과 지식 작업이며, 공식 자체 보고 기준 Terminal-Bench 4.0이 grok-4.6의 20.3%에서 38.0%로 올랐습니다(공식 수치). 위 시나리오 1의 근본 원인 진단과 시나리오 2의 검토 목록은 모두 저희가 실제로 실행한 결과이므로 직접 판단하실 수 있습니다.

한 번 호출에 대략 얼마인가요? HiAPI 플랫폼 가격(입력 $0.84 / 출력 $2.52 per 1M tokens) 기준으로 이 5개 합계는 약 $0.06입니다. 가장 저렴한 시나리오 5는 약 $0.007, 가장 비싼 시나리오 1은 약 $0.021입니다.

500K 컨텍스트는 어떻게 활용하나요? 중형 저장소 전체 파일이나 수백 페이지 분량의 로그를 한 번의 요청에 붙여 검토, 트러블슈팅, 리팩터링을 할 수 있어 직접 분할할 필요가 없습니다. 일상적인 짧은 프롬프트로는 다 쓰지 않아도 추가 과금이 없으며 실제 token 기준으로 청구됩니다.

더 읽기

• Grok 4.7 API 가격은 얼마인가?——세 단계 추론, 장문 문서 과금, 월별 예산 매트릭스
• Grok 4.7 vs Grok 4.6——같은 가격대, 언제 무엇을 쓸까
• Grok 4.7 API 연동 가이드——5분 만에 첫 요청 성공하기
• Grok 4.6 모델 페이지——이전 세대 플래그십의 전체 사용법
• Grok 4.7 모델 페이지——온라인 체험, 파라미터, 실시간 가격