엔지니어로서 막힘없이 업무를 진행하기 위해 매주 사용하는 10가지 프롬프트

일반적인 엔지니어링 업무 주간 동안 AI를 어떻게 사용하는지 의도적으로 기록한 5주를 거치며, 명확한 패턴 세트가 나타났습니다. 화려한 데모가 아니라, 실제로 업무를 진전시키는 조용하고 반복 가능한 패턴들입니다. 여기 제 근육 기억(muscle memory)이 된 10가지 방법이 있습니다.

1. 모호한 티켓을 범위가 정해진 작업 목록으로 변환하기

제품 티켓(Product tickets)은 종종 제대로 준비되지 않은 상태로 전달됩니다. 코드를 건드리기 전에, 티켓 텍스트를 붙여넣고 다음과 같이 요청합니다:

당신은 이 티켓의 구현 범위를 정하는 것을 돕는 시니어 엔지니어(senior engineer)입니다.
다음 티켓 설명을 바탕으로: "[티켓 내용 붙여넣기]"
출력: 개별적인 기술 작업의 번호가 매겨진 목록, 제품 팀(product)과 명확히 해야 할 모호한 점들

[Option A]와 [Option B] 중에서 [특정 문제]를 해결하기 위한 선택을 고민 중입니다.
현재 제 생각은 다음과 같습니다: [추론 내용].
제가 선호하는 옵션에 대해 반론을 제기해 주세요. 제가 놓치고 있거나 과소평가하고 있는 부분은 무엇인가요?

이렇게 강제로 악마의 대변인 (devil's advocate) 역할을 부여하는 프레임워크는 중립적인 "이 두 가지를 비교해 줘"라는 프롬프트보다 더 나은 반론을 이끌어냅니다.

## 5. 생소한 코드베이스 섹션 설명하기

한 번도 다뤄본 적 없는 모듈을 맡게 되었을 때:

이 코드가 무엇을 하는지, 예상되는 입력(inputs)과 출력(outputs), 부작용 (side effects), 그리고 누군가 코드를 완전히 이해하지 못한 채 수정했을 때 발생할 수 있는 문제점들을 설명해 주세요.
[코드 블록 붙여넣기]

## 6. 장애 사후 분석 (incident postmortem) 초안 작성하기

장애(incident)가 종료되면, 사후 분석 문서는 압박감 속에서 작성되곤 합니다. 저는 타임라인을 붙여넣고 다음과 같이 요청합니다:

다음 장애 타임라인을 바탕으로: [붙여넣기]
다음 항목을 포함한 사후 분석 (postmortem) 초안을 작성해 주세요: 요약, 타임라인, 근본 원인 (root cause), 기여 요인 (contributing factors), 영향 (impact), 잘된 점, 잘못된 점, 그리고 담당자 미정 (owners TBD) 상태의 조치 사항 (action items).
...

## 7. 까다로운 정규 표현식 (regex) 또는 SQL 쿼리 개선하기

AI에게 처음부터 작성해 달라고 요청하는 대신, 제가 가진 것을 보여줍니다:

대규모 데이터셋에서 속도가 느린 SQL 쿼리입니다: [쿼리 붙여넣기]
예상되는 성능 병목 지점 (performance bottlenecks)을 식별하고, 설명을 곁들여 재작성(rewrite)안을 제안해 주세요.

이 패턴은 제가 'The AI Leverage Playbook: 50 Prompts & Workflows for Engineers'에 담은 패턴 중 하나이지만, 위의 버전만으로도 충분히 가치를 얻을 수 있습니다.

## 8. 누락된 에러 핸들링(error handling) 찾아내기

저는 모든 PR(Pull Request)을 제출하기 전에 에러 핸들링만을 위한 전용 검토 단계를 거치기 시작했습니다:

이 함수에서 누락되었거나 불충분한 에러 핸들링이 있는지 검토해 주세요.
처리되지 않은 에러로 인해 침묵하는 실패 (silent failure), 크래시 (crash), 또는 잘못된 사용자 상태 (bad user state)가 발생할 수 있는 각 사례를 나열해 주세요.
[함수 붙여넣기]

모델은 제가 해피 패스 (happy path)를 먼저 작성하느라 머릿속으로 대충 넘겼던 엣지 케이스 (edge cases)들을 잡아냅니다.

## 9. 해결책이 생생할 때 런북 (runbook) 항목 작성하기

런북은 적절한 시점에 아무도 작성하지 않기 때문에 내용이 쓸모없게(stale) 변하곤 합니다. 저는 수정 직후에 바로 작성합니다:

방금 이 문제를 해결했습니다: [문제와 해결 방법을 2~3문장으로 설명]
온콜 (on-call) 엔지니어를 위한 런북 (runbook) 항목을 작성해 주세요. 다음 내용을 포함해야 합니다: 증상, 예상 원인, 단계별 복구 절차, 그리고 해결되었는지 확인하는 방법.

## 10. Slack 스레드를 결정 로그 (decision log)로 변환하기

의사결정이 이루어진 긴 Slack 스레드는 블랙홀과 같습니다. 저는 스레드 내용을 붙여넣고 다음과 같이 요청합니다:

이 Slack 스레드를 결정 로그 (decision log) 항목으로 요약해 주세요.
다음 내용을 포함해야 합니다: 결정하려는 질문, 고려된 옵션들, 내려진 결정, 결정자, 그리고 근거.
...

3개월 뒤의 당신은 스스로에게 고마워하게 될 것입니다.

## 공통점

이 프롬프트 중 어느 것도 "내 코드를 대신 작성해 줘"라는 식의 프롬프트가 아닙니다. 모든 프롬프트는 더 빠르게 명확성에 도달하는 것, 즉 더 좁은 범위 (scope), 더 나은 컨텍스트 (context), 더 깔끔한 인수인계 (handoff)에 관한 것입니다. 가치는 사고를 외주 주는 것이 아니라, 창의성을 요구하지 않으면서 시간을 소모하는 업무의 부분들을 압축하는 데 있습니다.

이번 주에 이 중 두 가지를 골라 시도해 보세요. 효과가 있는 것들은 계속 유지하세요.