AI를 개발 도구로 사용하기 시작했다
MyStock을 만들면서 AI를 활용한 개발 방식을 본격적으로 경험하게 됐다. 처음에는 단순한 호기심이었다.
AI에게 개발을 시키면 어디까지 가능할까?
처음에는 AI를 코드를 만들어주는 도구라고 생각했다. 하지만 프로젝트를 진행할수록 생각이 조금씩 바뀌었다. 설계 방향을 고민하고, 문제 상황을 설명하고, 결과를 검토하는 과정에서 AI는 단순한 도구가 아니라 함께 고민하는 협업 대상에 가까워졌다.
AI와 작업하는 방식에도 규칙이 필요했다
프로젝트가 커질수록 새로운 문제가 생겼다. 개발 자체보다 AI에게 현재 상황을 설명하고 원하는 결과를 전달하는 과정이 점점 커졌다. 예를 들면 이런 작업들이 반복됐다.
- 개발일지 작성
- GitHub PR 생성
- 블로그 발행
- 코드 리뷰 요청
사람 개발자와 협업할 때 프로젝트 규칙과 개발 방식이 필요한 것처럼, AI와 협업할 때도 기준과 규칙이 필요하다는 생각이 들었다.
프롬프트 저장소를 만들려고 했다
처음 생각했던 방향은 단순했다. 자주 사용하는 요청 문구를 Markdown 파일로 저장해두고 필요할 때 사용하는 정도였다.
AI Prompt Library
├── TPUB.md
├── PR.md
├── DEVLOG.md
└── REVIEW.md
그런데 TPublisher를 만들면서 생각이 달라졌다. 중요한 것은 프롬프트 자체가 아니었다. AI가 어떤 기준으로 결과물을 만들어야 하는지, 어떤 방식으로 작업해야 하는지를 정의하는 규칙이 필요했다.
AI에게 일을 시키는 방법도 결국 개발해야 하는 대상이었다.
TPublisher를 만들면서 예상하지 못한 문제가 생겼다
첫 번째 TPUB 테스트 결과는 예상과 달랐다. AI는 대화를 너무 성실하게 정리했다. 문제는 그 성실함이었다. 몇 시간 동안 나눈 고민과 질문, 설계 과정이 모두 포함되면서 결과물은 블로그 글이 아니라 회의록에 가까워졌다. 반대로 너무 압축하도록 규칙을 변경하니 중요한 개발 경험까지 사라졌다.
결국 필요한 것은 단순한 요약이 아니었다. 개발 과정에서 무엇을 고민했고, 왜 그런 선택을 했는지를 전달하는 편집 과정이었다.
AI와 일하는 방식을 다시 정의하다
TPUB 규칙을 다시 만들었다. AI의 역할을 단순한 변환기가 아니라 개발 블로그 편집자로 변경했다.
중요한 기준은 다음과 같다.
- 사람이 문제를 정의한다.
- AI와 해결 방향을 고민한다.
- 결과를 검토하고 방향을 조정한다.
- 최종 판단은 사람이 한다.
AI가 개발자를 대신하는 것이 아니다. 개발자가 더 많은 생각을 하고, 더 빠르게 실험할 수 있도록 옆에서 함께 작업하는 방식에 가깝다.
현재 내가 생각하는 AI 협업 방식
현재 AI Prompt Library는 단순한 프롬프트 모음이 아니다. AI와 협업하기 위한 개인 개발 환경의 규칙 저장소에 가까워지고 있다. TPUB를 시작으로 앞으로는:
- PR 작성 규칙
- 개발일지 생성 규칙
- 코드 리뷰 요청 방식
- 프로젝트별 AI 작업 기준
까지 확장할 예정이다. 재미있는 점은 프로그램을 만들려고 시작했는데, 결국 AI와 함께 일하는 방법 자체를 만드는 방향으로 발전하고 있다는 것이다.
AI 시대에는 어떤 도구를 사용하는지보다, 그 도구와 어떻게 협업할 것인지 정의하는 능력이 중요해질지도 모르겠다.