지난 1년간 AI를 실제 업무에 적용하며 느낀 점

지난 1년간 AI를 활용해 문서 작성, 설계 정리, 코드 구현까지 실제 업무에 적용해 왔다.

처음에는 대부분이 그렇듯 프롬프트를 어떻게 쓰느냐, 어떤 모델을 쓰느냐, 얼마나 빠르게 코드를 만들어 주느냐에 관심이 쏠려 있었다.

하지만 업무에 깊게 적용할수록 느낀 점은 조금 달랐다.

AI는 코드를 잘 만들어주지만, 문제를 대신 정의해주지는 않았고 설계를 대신 책임져주지도 않았다.
이 점은 코딩뿐 아니라 문서 작성에서도 동일하게 느껴졌다.

프롬프트 중심으로 접근할수록 설계가 없는 상태에서 결과물이 먼저 만들어졌다.
코드에서는 잘 동작하던 기능이 의도치 않게 제거되거나 불필요한 기능이 섞였고,
문서에서는 읽는 사람의 입장이 명확하지 않은 채 그럴듯한 문장만 늘어나는 경우가 많았다.

문서를 쓰면서도 비슷한 패턴이 반복됐다.
이 문서가 누구를 설득하기 위한 것인지, 공감을 얻기 위한 것인지,
아니면 단순히 사실과 기준을 남기기 위한 것인지가 정해지지 않으면
AI는 그럴듯하지만 방향이 흔들리는 문서를 만들어냈다.

돌이켜보면, 이는 AI의 문제가 아니라 우리가 AI를 사용하는 순서가 바뀌었기 때문이었다.

원래의 소프트웨어 개발은 요구사항 분석, 설계, 구현, 테스트라는 사전 예방 중심의 흐름을 전제로 한다.
문서 또한 마찬가지로, 목적과 독자, 전달 방식이 먼저 설계되어야 한다.

하지만 AI를 사용하면서 우리는 설계 단계를 압축하거나 생략한 채
곧바로 구현이나 문장 생성, 수정과 리뷰로 진입하는 습관을 강화하고 있었다.

이 과정에서 내가 선택한 방식은 단순했다.

코드든 문서든 먼저 기준을 문서로 정리했다.
무엇을 만들 것인지뿐 아니라,
누가 읽을 것인지, 무엇을 설득할 것인지, 어디까지를 범위로 할 것인지를 먼저 고정했다.

그 이후 AI에게는 구현이나 작성이 아니라
설계의 모호점과 위험을 찾게 했다.
여러 AI의 결과 차이는 오류가 아니라 설계 빈틈의 신호로 받아들였고,
기준이 고정된 이후에만 코드 구현이나 문서 작성을 진행했다.

AI는 설계를 대신하는 주체가 아니라
설계를 검증하고 흔드는 도구로 사용할 때 가장 효과적이었다.

이 글은 그 과정에서의 개인적인 정리이며,
곧 진행할 발표에서는 이 경험을 바탕으로
AI 시대에 설계가 코드와 문서에서 각각 어떤 역할을 가져야 하는지,
그리고 실제로 어떤 방식이 유효했는지를 사례 중심으로 공유하려 한다.