기술 문서, 체인지로그, 커밋 메시지를 작성하는 데 AI를 어떻게 활용하나요?

Question

IT Interview Practice · Accepted Answer

핵심은 AI에 **원재료를 주는 것** — 실제 diff나 코드 — 그리고 구체적이고 관례적인 포맷을 요청하는 것입니다. AI는 변경을 명확한 산문으로 바꾸는 데 능하지만, 무엇이 바뀌었는지 볼 수 있을 때만 그렇습니다.

## 좋은 워크플로

- 막연한 설명이 아니라 **diff를 주세요**: `git diff --staged | <AI 도구>`.
- **알려진 관례를 요청** — Conventional Commits(`feat:`, `fix:`, `docs:`) 또는 당신의 changelog 스타일.
- **정확하고 간결하게** — 제목 줄은 ~50자 이하, 본문은 *왜*를 설명.
- **diff와 일치하는지 검증.** AI는 존재하지 않는 변경을 지어낼 수 있으므로 직접 확인해야 합니다.

## 전 / 후

게으른 커밋 메시지:

```text
fixed stuff
```

diff를 주고 Conventional Commit 스타일을 요청한 후:

```text
fix(auth): reject expired tokens in session middleware

The middleware only checked token signature, not expiry, so expired
sessions stayed valid. Added an `exp` claim check that returns 401.
```

두 번째 버전은 리뷰어에게 *무엇이* 바뀌었고 *왜* 바뀌었는지 알려줍니다 — 6개월 뒤 `git log`에서 훨씬 유용합니다.

## 여기서 AI가 잘하는 것

- **Docstring과 README** — 모듈의 목적과 사용법을 요약.
- **Changelog** — 커밋을 Added / Fixed / Changed 섹션으로 그룹화.
- **커밋 메시지** — diff를 깔끔하고 관례적인 메시지로 변환.

항상 **실제 변경과 대조하며 결과를 읽으세요**. AI는 당신의 의도를 모릅니다 — 보여준 코드만 압니다 — 그래서 `fix`를 `feat`로 잘못 라벨링하거나 실제로 없는 side effect를 주장할 수 있습니다.

## 왜 중요한가

좋은 커밋 메시지와 문서는 미래의 당신과 동료가 코드가 *왜* 존재하는지 이해하는 방법입니다. AI는 이를 잘 쓰는 마찰을 없애주지만, 정확성은 당신의 몫입니다. 자신 있게 틀린 changelog는 없는 것보다 나쁩니다. 실제 입력을 주고, 실제 관례를 요구하고, 커밋하기 전에 검증하세요.

좋은 워크플로

전 / 후

여기서 AI가 잘하는 것

왜 중요한가

관련 질문