tech lead로서 일상 업무에 AI 도구를 어떻게 활용합니까?

Question

Accepted Answer

저는 AI를 **빠르고 지치지 않는 junior pair**로 다룹니다 — 초안과 탐색에는 훌륭하지만 결코 최종 권위는 아닙니다. 작업 속도를 높여 주지만 **판단과 검증은 제 몫으로 남습니다.** 리드로서 제가 그것을 쓰는 방식은 팀에게 본보기도 됩니다.

## 일상에서 도움이 되는 곳

- **코드와 테스트 초안 작성.** function의 초안, boilerplate handler, unit test 표를 생성한 뒤 — 모든 줄을 읽고 고치고 책임집니다.
- **diff 리뷰.** 본격적인 리뷰에 앞서 명백한 버그, 누락된 edge case, 모호한 네이밍을 잡는 1차 스캔.
- **낯선 코드 탐색.** "이 module이 무엇을 하고 X가 어디서 처리되는지 설명해줘"는 맹목적으로 grep하는 것보다 훨씬 빠르게 새 영역에 적응시켜 줍니다.
- **docs와 RFC 작성.** 불릿 포인트를 읽기 좋은 초안으로 바꾼 뒤, 제가 논리를 다듬고 사실을 확인합니다.
- **논의 요약.** 긴 thread나 회의록을 결정 사항과 액션 아이템으로 압축합니다.
- **설계 rubber-ducking.** 접근 방식을 풀어 설명하고 허점을 찌르게 합니다 — 결정 전 값싼 second opinion.

## 판단을 루프 안에 유지하기

실패 모드는 유창한 output을 믿는 것입니다. 그래서 저는:

- **주장과 API를 검증합니다** — 실행하고, 테스트하고, docs를 확인합니다. AI는 자신만만하게 hallucinate합니다.
- **이해하지 못한 것은 절대 merge하지 않습니다.** 설명할 수 없으면 출시하지 않습니다.
- **책임 포기가 아니라 leverage로 씁니다** — 그것이 초안을 쓰고, 제가 결정합니다.

## 솔선수범

효과가 있었던 prompt를 공유하거나, 리뷰에서 hallucinate된 API를 잡아낸 방법을 보여줄 때 팀은 도구가 아니라 **좋은 실천**을 배웁니다. 제가 보여주는 규범은 이렇습니다: AI는 가속하지만, 엔지니어가 책임진다.

## 왜 중요한가

잘 쓰면 AI는 잡일을 없애고 사람만 할 수 있는 판단 중심 작업에 팀을 풀어줍니다. 맹목적으로 쓰면 그럴듯해 보이는 버그로 codebase를 가득 채웁니다. 그 차이는 전적으로 리드가 그것을 어떻게 쓰고 무엇을 본보기로 보이는지에 달려 있습니다.