📕 428커밋의 기록이 상품이 됐습니다 →
agenwiki

프롬프트

개발 프롬프트

테스트 케이스·에러 로그 분석·PR 설명 등 개발 실무 프롬프트. 아래 5개를 한 화면에 모았습니다. 변수 자리({like_this})만 채우면 바로 쓸 수 있고, 각각 언제 쓰는지와 주의점을 함께 적었습니다.

general

에러 로그 분석 프롬프트 (원인 가설과 검증 순서까지)

스택 트레이스나 로그를 붙여 넣으면 원인 가설을 확률 순으로 정리하고 무엇부터 확인할지 알려주는 프롬프트입니다.

복사 대상 프롬프트

당신은 장애 대응 경험이 많은 백엔드 엔지니어입니다. 아래 로그를 분석하세요. 1단계 요약: 무슨 일이 일어났는지 두 문장으로. 2단계 핵심 라인: 로그에서 실제로 의미 있는 줄만 골라 인용하고, 각 줄이 무엇을 뜻하는지 한 줄로 풉니다. 노이즈는 버립니다. 3단계 원인 가설: 가능성이 높은 순으로 3개까지, 각각 (가) 가설 (나) 이 로그의 어느 부분이 근거인지 (다) 맞다면 함께 나타났을 다른 증상 을 적습니다. 4단계 확인 순서: 가장 적은 노력으로 가설을 갈라낼 수 있는 순서대로 확인할 항목을 나열합니다 — 각 항목에 실행할 명령이나 볼 화면을 구체적으로 적습니다. 5단계 조치: 즉시 멈춤을 막는 임시 조치와, 재발을 막는 근본 조치를 나눠 제시합니다. 규칙: 로그에 없는 코드나 설정을 있다고 단정하지 마세요. 추정에는 '추정'이라고 표시하고, 근거가 부족하면 어떤 로그를 더 받아야 하는지 요청하세요. 실행 환경: {environment}. 로그: {log}

언제 쓰나

스택 트레이스는 길고 진짜 원인 줄은 한두 개일 때, 또는 새벽에 알림을 받고 어디부터 봐야 할지 판단이 서지 않을 때 씁니다. 가설을 나열만 하는 게 아니라 "무엇부터 확인하면 가설이 가장 빨리 갈라지는지" 순서를 받기 때문에, 헤매는 시간이 줄어듭니다.

사용법

  1. {environment} 에 실행 환경을 적습니다. (예: Node.js 20 / Docker / AWS ECS, Spring Boot 3 / RDS MySQL)
  2. {log} 에 로그를 붙여 넣습니다. 에러 발생 직전 20~30줄까지 함께 넣어야 맥락이 잡힙니다.
  3. 출력의 4단계 확인 순서를 위에서부터 실행하고, 결과를 다시 붙여 넣으면서 대화를 이어가면 범위가 좁혀집니다.

사용 예시

입력

실행 환경: Node.js 20 / Docker / AWS ECS, DB는 RDS PostgreSQL
로그:
2026-08-02T03:14:07Z INFO  request GET /api/orders
2026-08-02T03:14:37Z ERROR TimeoutError: Connection terminated due to connection timeout
    at Client._connectionCallback (/app/node_modules/pg/lib/client.js:132:24)
2026-08-02T03:14:37Z ERROR pool has 10/10 connections in use

출력 (요약)

요약: 주문 조회 요청이 DB 커넥션을 얻지 못하고 30초 뒤 타임아웃했습니다. 풀이 정원(10)까지 찬 상태입니다.

가설 1 (가능성 높음) — 커넥션 누수
  근거: 풀 10/10 포화 + 타임아웃이 연결 획득 단계에서 발생
  동반 증상: 시간이 갈수록 실패율 증가, 재배포 직후 정상화

가설 2 — 느린 쿼리가 커넥션을 오래 점유 (추정)
가설 3 — RDS 측 max_connections 도달 또는 페일오버

확인 순서
  1. pg_stat_activity 에서 idle in transaction 세션 수 확인 — 가설 1과 2를 즉시 구분
  2. RDS 콘솔의 DatabaseConnections / 이벤트 로그 확인 — 가설 3 배제
  3. 최근 배포 diff 에서 client.release() 누락 경로 확인

임시 조치: 해당 태스크 재시작으로 풀 초기화
근본 조치: finally 블록에서 release 보장, 풀 획득 타임아웃을 30초에서 5초로 축소

팁

  • 같은 에러가 반복된다면 "이 로그 3건의 공통점과 차이점만"이라고 요청해 패턴을 먼저 잡으세요.
  • 민감정보(토큰, 개인정보, 내부 도메인)는 붙여 넣기 전에 가려야 합니다. {log} 안의 값은 그대로 모델에 전달됩니다.
  • 원인이 좁혀졌으면 그대로 코드 리뷰 프롬프트로 넘겨 해당 함수의 수정안을 받으면 이어서 처리됩니다.

general

PR 설명·커밋 메시지 작성 프롬프트

변경 diff를 넣으면 리뷰어가 읽기 좋은 PR 본문과 규칙에 맞는 커밋 메시지를 함께 받는 프롬프트입니다.

복사 대상 프롬프트

당신은 리뷰를 많이 받아 본 시니어 개발자입니다. 아래 변경분을 설명하는 PR 본문과 커밋 메시지를 작성하세요. 1단계 변경 파악: diff 에서 실제로 달라진 동작을 정리합니다 — 포맷팅이나 이름 변경 같은 무해한 변경은 한 줄로 묶습니다. 2단계 PR 본문: (가) 배경 — 왜 이 변경이 필요했는지 2~3문장 (나) 변경 내용 — 리뷰어가 이해할 순서로 불릿 정리, 파일 나열이 아니라 동작 단위로 (다) 리뷰 포인트 — 특히 봐 주었으면 하는 부분과 그 이유 (라) 테스트 — 무엇을 어떻게 확인했는지 (마) 영향 범위와 롤백 방법. 3단계 커밋 메시지: {convention} 규칙에 맞춰 제목 한 줄(50자 내외, 명령형)과 본문(무엇이 아니라 왜)을 작성합니다. 여러 관심사가 섞여 있으면 커밋을 어떻게 쪼갤지 제안합니다. 규칙: diff 에 없는 사실을 지어내지 마세요 — 배경이나 테스트 내용을 알 수 없으면 '작성자 확인 필요'라고 자리표시자를 남기세요. 과장이나 홍보 문구를 넣지 마세요. 커밋 규칙: {convention}. 변경 diff: {diff}

언제 쓰나

코드는 다 짰는데 PR 본문에서 손이 멈출 때, 또는 급하다는 이유로 "fix bug" 한 줄만 남기게 될 때 씁니다. 배경과 리뷰 포인트가 갖춰진 PR은 리뷰 왕복을 줄이고, 반년 뒤 git log 로 이유를 되짚을 때도 남습니다.

사용법

  1. {convention} 에 팀의 커밋 규칙을 적습니다. (예: Conventional Commits, [JIRA-123] 접두어, 없음 — 자유 형식)
  2. {diff} 에 git diff main...HEAD 결과를 붙여 넣습니다. diff가 너무 길면 핵심 파일만 넣고 나머지는 "그 외 테스트 파일 5건 추가"처럼 요약해 적어도 됩니다.
  3. 출력에 "작성자 확인 필요"가 남아 있으면 그 부분만 직접 채웁니다. 대개 배경과 테스트 항목입니다.

사용 예시

입력

커밋 규칙: Conventional Commits
변경 diff:
--- a/src/api/orders.ts
+++ b/src/api/orders.ts
@@
-  const conn = await pool.connect();
-  const rows = await conn.query(sql);
-  return rows;
+  const conn = await pool.connect();
+  try {
+    return await conn.query(sql);
+  } finally {
+    conn.release();
+  }
(그 외: pool 획득 타임아웃 30s → 5s, 관련 테스트 2건 추가)

출력 (요약)

## 배경
주문 조회 경로에서 예외 발생 시 커넥션이 반환되지 않아 풀이 포화되는 문제가 있었습니다.

## 변경 내용
- 쿼리 실행을 try/finally 로 감싸 예외 경로에서도 커넥션을 반환합니다.
- 풀 획득 타임아웃을 30초에서 5초로 줄여 장애를 빨리 드러냅니다.
- 예외 발생 시 반환을 검증하는 테스트 2건을 추가했습니다.

## 리뷰 포인트
타임아웃 5초가 피크 트래픽에서 짧지 않은지 봐 주세요. 근거 수치는 작성자 확인 필요.

## 영향 범위 / 롤백
주문 조회 API 한정. 되돌리려면 이 커밋만 revert 하면 됩니다.

커밋 메시지
fix(orders): 예외 경로에서 DB 커넥션 반환 누락 수정

풀 포화로 인한 타임아웃의 원인이었습니다. 획득 타임아웃도 함께 축소해
장애를 조기에 노출시킵니다.

팁

  • 커밋을 아직 안 나눴다면 "3단계에서 커밋 분리안을 먼저"라고 요청해 쪼갠 뒤 작성하는 편이 리뷰가 훨씬 쉬워집니다.
  • 팀 PR 템플릿이 있으면 {convention} 뒤에 템플릿을 통째로 붙이고 "이 템플릿 항목에 맞춰"라고 덧붙이세요.
  • 사내 코드가 외부로 나가면 안 되는 환경이라면 diff 대신 변경 요약 문장만 넣어도 본문 골격은 나옵니다.

general

정규식 생성·해설 프롬프트 (패턴과 반례 함께 받기)

원하는 패턴을 말로 설명하면 정규식과 조각별 해설, 그리고 통과·실패 예시를 함께 받는 프롬프트입니다.

복사 대상 프롬프트

당신은 정규식에 능숙한 개발자입니다. 아래 요구사항을 만족하는 정규식을 만드세요. 1단계 요구 정리: 무엇을 매치하고 무엇을 매치하지 않아야 하는지 목록으로 다시 정리합니다 — 제 설명에서 애매한 부분이 있으면 어떻게 해석했는지 명시합니다. 2단계 패턴: {flavor} 문법에 맞는 정규식을 한 줄로 제시합니다. 3단계 해설: 패턴을 조각으로 쪼개 각 조각이 무슨 일을 하는지 표로 설명합니다. 4단계 검증 예시: 매치되는 문자열 5개와 매치되지 않는 문자열 5개를 제시하고, 특히 헷갈리는 경계 사례를 포함합니다. 5단계 주의: 이 패턴이 놓치는 경우, 성능상 위험한 부분(중첩 수량자로 인한 백트래킹 폭발 등), 정규식보다 파서를 쓰는 편이 나은 경우를 짚습니다. 규칙: 동작을 확인하지 않은 문법을 단정하지 말고, {flavor} 에서 지원 여부가 불확실한 기능은 '확인 필요'로 표시하세요. 가독성이 필요하면 확장 모드(주석 포함) 버전도 함께 주세요. 정규식 문법: {flavor}. 요구사항: {requirement}

언제 쓰나

로그 파싱, 입력 검증, 대량 치환처럼 패턴 하나면 끝나는데 그 패턴을 짜는 데 30분이 날아갈 때 씁니다. 결과만 받는 게 아니라 조각별 해설과 반례를 함께 받기 때문에, 나중에 그 정규식을 읽어야 하는 사람(대개 미래의 자신)이 덜 고생합니다.

사용법

  1. {flavor} 에 쓰는 문법을 적습니다. (예: JavaScript, Python re, PCRE, RE2 (Go), POSIX grep -E) 문법마다 지원 기능이 달라 이 값이 정확도를 좌우합니다.
  2. {requirement} 에 원하는 패턴을 말로 씁니다. 매치되면 안 되는 예까지 적으면 정확도가 크게 올라갑니다.
  3. 4단계 검증 예시를 실제로 돌려 보고, 어긋나는 케이스가 있으면 그 문자열을 그대로 붙여 "이건 매치되면 안 된다"라고 알려 주면 패턴이 교정됩니다.

사용 예시

입력

정규식 문법: JavaScript
요구사항: 로그 한 줄에서 ISO 8601 타임스탬프와 로그 레벨을 뽑고 싶습니다.
형식 예: 2026-08-02T03:14:07Z ERROR 메시지
레벨은 DEBUG/INFO/WARN/ERROR 만 인정합니다. 소문자 레벨은 매치하지 않습니다.

출력 (요약)

패턴
/^(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z)\s+(DEBUG|INFO|WARN|ERROR)\b/

해설
  ^                     줄 시작
  (\d{4}-...Z)          그룹 1 — 타임스탬프 전체
  \s+                   공백 하나 이상
  (DEBUG|INFO|...)      그룹 2 — 허용된 레벨만
  \b                    ERRORS 같은 접두 일치 방지

매치됨:   2026-08-02T03:14:07Z ERROR 결제 실패
매치 안 됨: 2026-08-02T03:14:07Z error 결제 실패  (소문자)
매치 안 됨: 2026-08-02 03:14:07 INFO ...          (T 구분자 없음)

주의: 밀리초(.123)나 +09:00 오프셋 형식은 이 패턴이 잡지 못합니다. 필요하면 알려 주세요.

팁

  • 이미 있는 정규식을 이해하고 싶을 때는 {requirement} 에 패턴을 그대로 넣고 "이 정규식을 해설해 줘"라고 쓰면 3단계 표만 받을 수 있습니다.
  • 대상 문자열이 HTML이나 중첩 구조라면 5단계 주의를 꼭 읽으세요. 정규식으로 풀면 안 되는 문제일 때가 많습니다.
  • 패턴이 길어지면 "확장 모드(x 플래그) 버전으로 주석 달아서"라고 요청해 코드에는 그쪽을 넣는 편이 유지보수에 낫습니다.

general

릴리스 노트 작성 프롬프트 (사용자 언어로 번역하기)

커밋 목록이나 머지된 PR 제목을 넣으면 사용자가 읽을 수 있는 릴리스 노트로 정리해 주는 프롬프트입니다.

복사 대상 프롬프트

당신은 제품 릴리스 노트를 쓰는 테크니컬 라이터입니다. 아래 변경 목록을 {audience} 가 읽을 릴리스 노트로 정리하세요. 1단계 분류: 각 항목을 새 기능, 개선, 버그 수정, 호환성 변경(Breaking), 내부 변경 중 하나로 나눕니다. 내부 리팩터링처럼 사용자에게 의미 없는 항목은 '노출 안 함'으로 빼고 목록 끝에 따로 보여 줍니다. 2단계 다시 쓰기: 각 항목을 개발자 용어가 아니라 사용자가 겪던 상황과 달라진 점으로 바꿔 씁니다 — 함수명, 모듈명, 티켓 번호는 지웁니다. 한 항목은 한 문장으로. 3단계 배치: 사용자에게 영향이 큰 순서로 정렬하고, 호환성 변경은 맨 위에 두고 무엇을 해야 하는지 조치 방법을 함께 적습니다. 4단계 헤드라인: 이번 버전을 한 문장으로 요약해 맨 앞에 둡니다. 규칙: 변경 목록에 없는 기능을 지어내지 마세요. 성능 수치나 개선율은 입력에 명시된 것만 쓰고, 없으면 '더 빨라졌습니다' 같은 표현 대신 무엇이 달라졌는지만 적으세요. 대상 독자: {audience}. 버전: {version}. 변경 목록: {changes}

언제 쓰나

배포는 끝났는데 릴리스 노트가 커밋 로그 복사본이 되어 아무도 읽지 않을 때 씁니다. 커밋 제목은 개발자 언어라 그대로 붙이면 사용자에게 전달되지 않습니다. 이 프롬프트는 "무엇을 고쳤는가"를 "무엇이 달라졌는가"로 바꿔 줍니다.

사용법

  1. {audience} 에 읽을 사람을 적습니다. (예: 앱 일반 사용자, API 를 쓰는 외부 개발자, 사내 운영팀) 이 값에 따라 용어 수위가 달라집니다.
  2. {version} 에 버전과 배포일을 적습니다. (예: v2.4.0 (2026-08-02))
  3. {changes} 에 git log --oneline 결과나 머지된 PR 제목 목록을 붙여 넣습니다.
  4. "노출 안 함"으로 분류된 항목을 확인하세요. 사용자에게 알려야 하는데 빠진 게 있으면 그 항목만 되돌려 달라고 요청합니다.

사용 예시

입력

대상 독자: 앱 일반 사용자
버전: v2.4.0 (2026-08-02)
변경 목록:
- feat(search): 검색 결과에 최근 조회순 정렬 추가
- fix(auth): 세션 만료 후 재로그인 시 첫 요청 401 반환되던 문제 수정
- refactor(core): OrderService 의존성 주입 정리
- feat(export)!: CSV 내보내기 기본 인코딩을 EUC-KR 에서 UTF-8 로 변경

출력 (요약)

v2.4.0 — 검색 정렬이 늘고, 로그인 직후 오류가 사라졌습니다. (2026-08-02)

먼저 확인하세요
- CSV 내보내기 파일의 문자 인코딩이 UTF-8 로 바뀌었습니다. 기존 방식으로
  엑셀에서 열면 글자가 깨질 수 있으니, 가져오기 시 인코딩을 UTF-8 로
  지정해 주세요.

새 기능
- 검색 결과를 최근 본 순서로 정렬할 수 있습니다.

버그 수정
- 로그인 세션이 만료된 뒤 다시 로그인하면 첫 동작이 실패하던 문제를
  해결했습니다.

노출 안 함 (내부 변경)
- 주문 처리 코드 구조 정리

팁

  • 사용자용과 개발자용 두 벌이 필요하면 {audience} 만 바꿔 두 번 돌리세요. 같은 입력으로 톤이 다른 결과가 나옵니다.
  • 항목이 30개를 넘으면 "영향이 큰 10개만 본문에, 나머지는 접이식 목록으로"라고 요청해 길이를 조절하세요.
  • 호환성 변경은 조치 방법이 빠지면 릴리스 노트의 의미가 없습니다. 조치 문장이 비어 있으면 반드시 직접 채우세요.

general

테스트 케이스 생성 프롬프트 (경계값·예외 강제)

함수나 기능 명세를 넣으면 정상·경계값·예외 케이스를 빠짐없이 뽑아 표와 테스트 코드로 돌려받는 프롬프트입니다.

복사 대상 프롬프트

당신은 테스트 설계에 능한 QA 엔지니어입니다. 아래 대상의 테스트 케이스를 설계하세요. 1단계 입력 분석: 대상이 받는 입력과 상태를 나열하고, 각각의 유효 범위와 타입을 정리합니다. 2단계 케이스 도출: 동등 분할과 경계값 분석을 적용해 (가) 정상 케이스 (나) 경계 케이스 — 최솟값, 최솟값-1, 최댓값, 최댓값+1, 0, 빈 값 (다) 예외 케이스 — null, 타입 불일치, 중복 호출, 권한 없음, 외부 의존 실패 순으로 뽑습니다. 3단계 표: 각 케이스를 번호, 분류, 입력, 사전 조건, 기대 결과 열의 표로 정리합니다. 4단계 코드: {framework} 형식의 실행 가능한 테스트 코드로 옮깁니다. 테스트 이름은 무엇을 검증하는지 읽히게 짓고, 한 테스트에 한 가지만 단언합니다. 규칙: 명세에 없는 동작은 추측해 채우지 말고 '명세 확인 필요'로 표시해 따로 목록화하세요. 커버리지 숫자를 지어내지 마세요. 마지막에 놓치기 쉬운 케이스 3개를 별도로 제안하세요. 언어/프레임워크: {framework}. 검증 대상: {target}

언제 쓰나

기능은 다 만들었는데 테스트를 어디까지 써야 할지 막막할 때, 또는 이미 쓴 테스트가 정상 경로만 덮고 있을 때 씁니다. 경계값과 예외를 프롬프트가 강제로 훑기 때문에, 사람이 습관적으로 빼먹는 "빈 배열", "최댓값+1", "외부 API 실패" 같은 구멍이 먼저 드러납니다.

사용법

  1. {framework} 에 언어와 테스트 프레임워크를 적습니다. (예: TypeScript / Vitest, Python / pytest, Java / JUnit 5)
  2. {target} 자리에 검증할 함수 코드나 기능 명세를 붙여 넣습니다. 코드가 있으면 코드를, 아직 구현 전이면 명세 문장을 그대로 넣어도 됩니다.
  3. 출력의 3단계 표를 먼저 읽고 불필요한 케이스를 지운 뒤, "남긴 케이스만 코드로 다시"라고 요청하면 군더더기 없는 테스트가 나옵니다.

사용 예시

입력

언어/프레임워크: TypeScript / Vitest
검증 대상:
function splitBill(total: number, people: number): number[]
  — 금액 total 을 people 명에게 1원 단위로 나눈다.
  — 나누어떨어지지 않으면 앞사람부터 1원씩 더 부담한다.
  — people 은 1 이상이어야 한다.

출력 (요약)

| # | 분류 | 입력 | 기대 결과 |
|---|------|------|-----------|
| 1 | 정상 | (10000, 4) | [2500, 2500, 2500, 2500] |
| 2 | 정상 | (10001, 4) | [2501, 2500, 2500, 2500] |
| 3 | 경계 | (0, 3) | [0, 0, 0] |
| 4 | 경계 | (10000, 1) | [10000] |
| 5 | 예외 | (10000, 0) | 오류 — people 은 1 이상 |
| 6 | 예외 | (-100, 2) | 명세 확인 필요 (음수 정의 없음) |

test('나누어떨어지지 않으면 앞사람이 1원 더 부담한다', () => {
  expect(splitBill(10001, 4)).toEqual([2501, 2500, 2500, 2500]);
});

명세 확인 필요: 음수 total, 소수점 total, people 상한

팁

  • 이미 테스트가 있다면 {target} 뒤에 기존 테스트 코드를 함께 넣고 "이미 덮인 케이스는 제외하고 빠진 것만"이라고 덧붙이세요.
  • "명세 확인 필요" 목록은 그대로 이슈나 PR 코멘트로 옮기면 됩니다. 대개 진짜 스펙 구멍입니다.
  • 테스트 데이터가 많이 필요하면 "3단계 표를 그대로 파라미터화 테스트(table-driven)로"라고 후속 요청하세요.

다른 묶음

관련 글

뉴스레터 구독

AI 에이전트, 도구, 프롬프트 업데이트를 정리해 보냅니다. 지난 호 보기 →