엔지니어링 매니저로서 사용하는 10가지 AI 프롬프트

저는 엔지니어링 팀을 충분히 오래 관리해 왔기에 하나의 패턴을 알고 있습니다. 업무의 절반은 기술적 결정이며, 나머지 절반은 그 결정들을 둘러싼 글쓰기입니다. 1:1 (1:1 meetings) 의제, 성과 검토 (Performance reviews), 사후 분석 (Postmortems), VP가 고집하는 상태 업데이트 (Status updates), 후보자에 대해 논쟁할 때가 되어서야 비로소 읽게 되는 채용 루브릭 (Hiring rubrics) 같은 것들 말이죠.

여기 제 업무를 실제로 수월하게 만들어 준 10가지 프롬프트가 있습니다. 각 프롬프트는 마지막에 설명할 4단계 구조를 따릅니다. 아래의 모든 예시 출력은 실제 사례이며, 길이 조절을 위해 편집만 거쳤습니다.

1. 진짜 주제를 드러내는 1:1 의제

1:1 미팅에서 저지르는 가장 큰 실수는 본인만의 의제를 가지고 들어가는 것입니다. 이 프롬프트는 그 방식을 뒤집습니다. 모델에게 지난 1:1 이후 발생한 일들을 바탕으로, 팀원이 아마도 이야기하고 싶어 할 내용이 무엇인지 생성하도록 요청합니다. 여러분은 주제 목록이 아니라, 그 초안을 가지고 미팅에 임하는 것입니다.

역할: 20명 이상의 팀원을 관리해 온 Staff engineer.
컨텍스트: 2시간 후에 [팀원 이름]과 30분간의 1:1 미팅이 있음.
그들의 역할은 [역할]임. 지난 1:1(일주일 전) 이후 상황:
...

실제 출력 결과 (팀원 = 미드 레벨 IC, 지난주에 걱정했던 리팩토링 작업을 완료함):

1. 리팩토링 사후 분석 (Postmortem). 그들은 목요일에 발생한 운영 환경의 문제(production hiccup)가 본인에게 불이익으로 돌아올지 알고 싶어 함.
2. 새로운 프로젝트 할당. 당신이 새로운 이니셔티브를 언급했기에, 자원할지 여부를 결정 중임.
3. 주니어의 페어 프로그래밍 (Pair-programming) 요청. 이것이 시간 낭비인지 아니면 성장을 위한 움직임인지 확신하지 못함.
4. 급여 범위 (Pay band) 질문 (이번 주에 levels.fyi 게시물을 읽음).
5. 그들이 먼저 꺼내지 않을 이야기. 그들은 당신이 자신을 시니어급으로 생각하는지, 그리고 기다려야 할지 아니면 밀어붙여야 할지를 조용히 확인하고 있음.

다섯 번째 항목이 바로 모든 1:1 프롬프트가 끌어내야 할 핵심입니다. 나머지 네 가지는 준비 과정입니다.

2. 칭찬 샌드위치(Praise Sandwich) 없는 성과 검토

대부분의 성과 검토(performance reviews)는 마치 빈칸 채우기 게임(Mad Libs)처럼 읽힙니다: "[이름]은 [일반적인 동사] [일반적인 명사]를 수행하는 강력한 기여자입니다." 이 프롬프트는 구체적인 내용을 강제하며, "성장할 영역(areas for growth)"이라는 식의 모호한 회피성 표현을 거부합니다.

역할: 보정(calibration) 준비가 된 검토서를 작성하는 엔지니어링 매니저.
맥락: [이름], [레벨]에 대해 [기간] 동안의 검토서를 작성하십시오.
이번 기간 동안의 구체적인 업무 내용 (5개 불렛 포인트):
...

실제 출력 결과 (영향력 = p95 지연 시간을 40% 단축한 마이그레이션 주도):

영향력(Impact): [이름]은 p95 지연 시간을 420ms에서 250ms(40%)로 줄인 API 마이그레이션을 주도했으며, 이로 인해 속도 제한(rate-limiting) 문제를 겪던 두 개의 다운스트림 팀의 병목 현상을 해결했습니다. 이들은 기능 플래그(feature-flag)를 사용하여 4단계에 걸쳐 배포를 진행했으며, 덕분에 단 한 번의 롤백(3단계)이 전체 장애(outage)가 아닌 20분간의 트래픽 저하로 마무리될 수 있었습니다. 또한 세 차례의 브라운백 세션(brown-bag sessions)을 운영하여, 다른 세 명의 엔지니어가 새로운 패턴을 바탕으로 독립적으로 배포할 수 있는 수준까지 끌어올렸습니다.

다음 기간에 개선할 점 한 가지: 3분기 설계 검토(design review) 당시, 하나의 옵션을 권장하지 않은 채 세 가지 옵션을 제시하여 회의 시간을 45분 연장시키고 의견을 분열시켰습니다. 다음에는 회의 시작 후 2분 이내에 본인의 권장안을 제시하고, 남은 회의 시간은 이를 방어하거나 수정하는 데 사용하십시오.

"일관되게(consistently)"라는 단어는 주의해야 할 신호입니다. 구체적인 사례를 명시할 수 없다면, 해당 검토를 뒷받침할 충분한 근거가 없는 것입니다.

3. 회의에서 살아남는 아키텍처 결정 기록 (ADR)

대부분의 ADR(Architecture Decision Record)은 누군가가 "잠깐, X를 고려해 봤나요?"라고 말하는 순간 회의실에서 사장됩니다. 이 프롬프트는 대안(alternatives) 섹션이 단순히 장식용이 아니라 실질적인 내용을 담도록 강제합니다.

역할: 회의적인 청중을 대상으로 ADR을 작성하는 수석 엔지니어(Principal engineer).
맥락: 우리는 [결정 사항]을 결정하고 있습니다. 제안된 옵션은
[옵션 A: 짧은 설명 + 우리가 이를 선택한 한 가지 구체적인 이유].
...

실제 출력 결과 (결정 사항 = 새로운 결제 서비스에 Postgres 채택):

상태: 제안됨
배경: 결제 서비스는 ACID를 준수하고 감사 가능해야 하며, 6개월 이내에 읽기 복제본(read replicas)을 지원해야 합니다.
결정: Postgres 16.
영향: 팀이 Postgres 운영 방식을 학습하게 되며; 테넌트 격리를 위해 행 수준 보안(row-level security) 기능을 얻게 되고; 플릿(fleet)에 데이터 스토어가 하나 더 추가됩니다.
대안:
MongoDB는 결제 문서가 스키마리스(schemaless)이고 추가 전용(append-only)이었다면 적절했을 것입니다. 금융 조정(financial reconciliation)에는 여러 컬렉션에 걸친 트랜잭션이 필요하며, Mongo는 이를 깔끔하게 지원하지 못하므로 기각합니다. 결제 모델이 이벤트 소싱(event-sourced)만으로 구성되는 경우 재검토할 수 있습니다.
DynamoDB는 접근 패턴이 높은 QPS에서 단일 키 조회인 경우 적절했을 것입니다. 보고 작업 부하가 날짜 범위로 스캔하는 것이기 때문에 (이는 Dynamo가 가장 취약한 케이스입니다), 기각합니다. 보고 기능이 별도의 OLAP 저장소로 이동할 경우 재검토할 수 있습니다.

대안 각각의 세 번째 문장, 즉 '재검토 트리거'가 6개월 후에

근본 원인 (5 Whys):

1. 왜 결제(checkout) 과정에서 500 에러가 발생했는가? 결제 제공업체의 웹훅(webhook) 타임아웃으로 인해 데이터베이스 연결(database connection)이 누수되었다.
2. 왜 연결이 누수되었는가? 웹훅 핸들러(webhook handler)에 타임아웃 시 연결을 해제하는 finally 블록(finally-block)이 없었다.
3. 왜 finally 블록이 없었는가? 해당 핸들러는 2분기 전에 트랜잭션이 없는 코드 경로(non-transactional code path)에서 복사되었다.
4. 왜 복사된 코드가 운영 환경(production)에 있었는가? PR 리뷰 체크리스트(PR review checklist)에 "타임아웃 시 리소스 정리(resource cleanup on timeout)" 항목이 포함되어 있지 않았다.
5. 왜 체크리스트에 해당 항목이 없는가? 체크리스트가 CRUD 엔드포인트(endpoints)용으로 작성되었기 때문이며, 외부 웹훅 핸들러(external-webhook handlers) — 지난 6개월 사이에 추가된 엔드포인트 유형 — 를 고려하지 않았다.

다섯 번째 '왜'가 개발자가 아닌 체크리스트를 지목하고 있다는 점에 주목하세요. 이것이 바로 프로세스를 무용지물로 만들지 않으면서도 비난 없는(blameless) 문화를 만드는 방법입니다.

5. 느슨한 Slack 스레드에서 추출한 온콜 런북 (On-Call Runbook)

모든 팀에는 누군가가 특정 상황에서의 복구 방법을 설명해 놓은 Slack 스레드가 하나씩 있습니다. 하지만 그것이 문서로 기록된 적은 결코 없습니다. 이 프롬프트는 해당 스레드를 다음 온콜(on-call) 담당자가 새벽 3시에 실제로 따라 할 수 있는 런북(runbook)으로 변환해 줍니다.

역할: 새벽 3시에 호출을 받고 런북이 필요한 온콜 엔지니어(On-call engineer).
컨텍스트: 여기 [전문가]가 [장애 유형 (INCIDENT TYPE)]으로부터 복구하는 방법을 설명한 Slack 스레드가 있습니다:
...

실제 출력 결과 (장애 유형 = Redis 캐시 손상 (Redis cache corruption)):

즉각적인 조치 (Immediate Action):

1. 캐시 노드에 SSH 접속합니다 (runbook-redis-access 참조).
2. redis-cli -h <host> -a <password> INFO keyspace를 실행하고 출력 결과를 스크린샷으로 찍어둡니다. (이것이 작업 전 상태입니다.)
3. 알림 페이로드(alert payload)에서 손상된 키 접두사(key prefix)를 식별합니다.
4. redis-cli ... --scan --pattern '<prefix>*' | head -50를 실행하여 영향을 받은 키 목록을 나열합니다.
5. ⚠ 두 번째 작업자 필요: 접두사를 플러시(flush)할지(빠르지만 캐시 손실 발생), 아니면 개별 키를 삭제할지(느리지만 안전함) 결정합니다. 확신이 서지 않는다면 접두사를 플러시하십시오. 캐시는 다시 구축할 수 있습니다.
6. 플러시: redis-cli ... EVAL "return redis.call('del', unpack(KEYS))" 0 <prefix>* (잠깐 — 이것은 잘못되었습니다. '하지 말아야 할 일 #1'을 참조하세요).
7. 올바른 플러시: redis-cli ... --scan --pattern '<prefix>*' | xargs redis-cli ... del

하지 말아야 할 일 (What NOT to do):

1. EVAL "return redis.call('del', unpack(KEYS))" 0 <prefix>*를 사용하지 마십시오. unpack은 8,000개의 키에서 잘리며 나머지는 조용히 누락됩니다. 이것이 3월의 사고를 악화시킨 버그입니다.

"하지 말아야 할 일" 섹션이 가장 가치 있는 부분입니다. 모든 Slack 스레드에는 잘못된 시도들이 포함되어 있으며, 그 잘못된 시도들이야말로 실제 교훈입니다.

6. 단 하나의 실험을 만들어내는 스프린트 회고 (Sprint Retro)

회고는 아무도 책임지지 않는 12개의 실행 항목(action items)을 만들어냅니다. 이 프롬프트는 중단 기준(kill criterion)이 포함된 단 하나의 실험을 강제합니다.

역할: 200번의 회고를 진행했으며, 실행 항목 무덤(action-item graveyards)에 지친 애자일 코치 (Agile coach).
컨텍스트: 팀의 회고 보드:
...

실제 출력 결과 (회고 아이디어 = "더 짧은 스탠드업 미팅"):

실험: 인당 90초 제한을 둔 타이머 스탠드업 (Timed standup with a 90-second cap per person)
가설 (Hypothesis): 인당 제한 시간을 아무도 강제하지 않기 때문에 스탠드업 (Standup)이 길어집니다. 눈에 보이는 타이머를 사용하면 제한 사항이 실질적으로 체감될 것입니다.
변경 사항 (Change): 원형으로 둘러앉아 휴대폰 타이머를 돌려가며 사용합니다. 각자에게 90초를 부여합니다. 사람 사이에는 타이머를 리셋합니다.
측정 (Measurement): 스탠드업 (Standup) 시간 (목표: 6인 팀 기준 12분 미만). 2주 후 설문 조사: "자신의 의견이 충분히 전달되었다고 느꼈습니까?"
중단 기준 (Kill criterion): 2주 후에도 평균 스탠드업 (Standup) 시간이 여전히 15분을 초과하거나, "의견이 전달되었다

1. 부분적 장애 상황에서의 시스템 사고 (Systems thinking under partial failure)
   테스트: "체크아웃 API가 요청의 1%에 대해 500 에러를 반환하고 나머지는 200을 반환할 때, 무엇부터 살펴볼 건가요?"
   우수 인재(Strong hire): 로그로 바로 뛰어들기 전에 먼저 요청 분포(시간, 사용자 코호트, 지역 등)에 대해 질문한다. 가능성이 높은 순서대로 최소 세 가지 가설을 제시한다.
   부적합 인재(No hire): 1%의 에러가 배포인지, 기능 플래그인지, 아니면 다운스트림 제공업체 문제인지를 고려하지 않고 "서버를 재시작하거나" "로그를 확인하는" 식으로 접근한다.

2. 코드 리뷰 판단력 (Code review judgment)
   테스트: 미묘한 버그 하나와 스타일 이슈 하나가 포함된 200줄짜리 PR을 보여준다. "어떤 리뷰 코멘트를 남기겠어요?"
   우수 인재(Strong hire): 버그를 찾거나 그것을 드러낼 질문을 던진다. 스타일 이슈는 마지막에 언급하거나 아예 언급하지 않는다.
   부적합 인재(No hire): 스타일 이슈부터 꺼낸다. 로직 자체와는 관련 없이 이야기한다.

3. 트레이드오프 커뮤니케이션 (Tradeoff communication)
   테스트: "최근에 내렸던 기술적 결정 하나를 골라, 양쪽 입장을 모두 주장해 보세요."
   우수 인재(Strong hire): 거부했던 옵션의 장점까지도 논리적으로 설명할 수 있다. 결정을 바꿀 만한 구체적인 신호가 무엇인지 제시한다.
   부적합 인재(No hire): 자신이 내린 입장만 주장할 수 있다. 대안의 강점을 설명하지 못한다.

4. 결과에 대한 책임감 (Ownership of outcomes)
   테스트: "배포되었지만 잘못된 경험에 대해 이야기해 주세요."
   우수 인재(Strong hire): 결정에는 "I"를, 결과에는 "we"를 사용한다. 그 이후 자신의 프로세스에서 무엇을 변경했는지 설명한다.
   부적합 인재(No hire): 팀, 요구사항, 또는 운 탓으로 돌린다. 자신의 프로세스를 개선한 부분이 없다.

'문화 적합성 부족, 열정 부족'이라는 제약이 핵심이다. 이 두 가지 영역에 편향성이 숨어 있다. 관찰 가능한 신호가 보정을 시작하는 지점이다.

9. 비기술적 이해관계자를 위한 기술 부채 발표 (The Tech-Debt Pitch for Non-Technical Stakeholders)

엔지니어링팀은 "리팩토링이 필요하다"고 말한다. 프로덕트팀은 "그게 우리에게 뭘 가져다주나요?"라고 묻는다. 이 프롬프트는 거짓말을 하지 않으면서 리팩토링을 비즈니스 언어로 번역해준다.

Role: 제품 및 재무 부서 청중에게 기술 부채 투자를 제안하는 엔지니어링 매니저.
Context: 기술 부채는 [부채를 설명하세요 — 무엇인지, ...}

**실제 출력값** (기술 부채 = 트랜잭션을 지원하지 않는 billing-service ORM):