AI 기능을 넣는 것과 AI가 일할 수 있는 구조

처음에는 내가 직접 쓰기 좋은 맥용 프로그램을 만들면 된다고 생각했다.

화면을 열고, 필요한 정보를 보고, 버튼을 누르고, 결과를 확인하는 방식.  혼자 쓰는 운영 도구라면 그 정도면 충분할 것 같았다.

그러다 맥용 프로그램 안에서 AI가 작동하게 만들었다.  앱 안의 데이터를 AI가 읽고, 분석하고, 정리하고, 필요한 결과를 생성하는 구조였다.

이 단계만 해도 꽤 큰 변화처럼 느껴졌다.  예전에는 내가 직접 해야 했던 정리와 판단의 일부를 프로그램 안의 AI가 도와줄 수 있었기 때문이다.

그런데 운영 업무를 조금 더 맡기려고 하자 다른 생각이 들었다.

맥용 프로그램 안에서 AI가 작동한다고 해서, 그 프로그램이 곧 AI 친화적인 것은 아닐 수 있다.  AI는 여전히 사람이 쓰는 앱 안에 들어간 기능에 가까웠다.  앱의 중심 사용자는 여전히 사람이었고, AI는 그 안에서 특정 기능을 수행하는 보조자에 가까웠다.

내가 점점 필요하다고 느낀 것은 조금 다른 구조였다.

AI가 단순히 앱 안에서 답을 생성하는 것이 아니라, 현재 상태를 읽고, 필요한 작업을 판단하고, 실행하고, 결과를 기록하고, 실패하면 그 원인을 남길 수 있는 구조.

그렇게 생각하자 질문이 바뀌었다.

“AI를 어디에 넣을까?”보다  “AI가 이 일을 실제로 수행하려면 어떤 구조가 필요할까?”를 더 생각하게 되었다.

사람에게는 화면과 버튼이 편하다.  하지만 AI에게는 명령, 데이터, 로그, 상태, 리포트, 검증 흐름이 더 중요할 수 있다.

운영 도구도 마찬가지다.

상태를 보여주는 대시보드만으로는 부족할 수 있다.  사이트 상태, 트래픽 변화, 검색 노출, 에러 로그 같은 것을 AI가 읽을 수 있어야 하고, 체크, 분석, 리포트 생성, 테스트 실행, 변경 요청 같은 작업을 호출할 수 있어야 한다.

그렇게 되어야 AI는 단순한 기능이 아니라 운영 흐름 안에서 작은 역할을 맡을 수 있을 것 같다.

이 과정에서 소스 코드와 프로젝트 구조도 다시 보게 되었다.

AI가 수정 제안이나 변경 요청까지 하려면, 프로젝트의 실행 방법, 테스트 방법, 배포 방식, 주의해야 할 파일, 변경 기준 같은 것들도 정리되어 있어야 한다.  사람에게 온보딩 문서가 필요하듯, AI에게도 프로젝트를 이해하기 위한 문서가 필요할 수 있다.

물론 AI에게 바로 많은 권한을 주는 것은 조심스럽다.

사이트 상태를 읽고 리포트를 만드는 것은 괜찮아 보여도, 코드를 수정하고 변경 요청까지 만든다고 생각하면 불안이 생긴다.

하지만 이것은 주니어 개발자나 운영 담당자에게 일을 맡길 때의 불안과도 비슷하다.  처음부터 모든 권한을 주는 것이 아니라, 읽기, 리포트, 수정 후보, 코드 수정, 테스트, 변경 요청, 사람 승인처럼 단계를 나누면 조금씩 맡길 수 있을지도 모른다.

결국 이번 변화는 단순히 맥용 앱을 다른 방식으로 만드는 문제가 아닌 것 같다.

처음에는 내가 쓰기 좋은 프로그램을 만들려고 했다.  그다음에는 그 프로그램 안에 AI를 넣었다.  이제는 AI도 하나의 사용자처럼 보고, AI가 읽고 실행하고 기록할 수 있는 구조를 생각하게 되었다.

AI를 잘 쓰는 것은 어쩌면 AI 기능을 많이 붙이는 것보다, AI가 일할 수 있는 환경을 조금씩 만들어가는 일에 가까울지도 모른다.