혼자서 모노레포를 운영하며 느낀 것 — AI 시대에도 병목은 사람이었습니다

일반 사용자를 위해서 제공되고 서비스가 운영되고 있는 것은, 현재의 기술 블로그와 글쓰기 플랫폼, 이렇게 두 개입니다. 그마저도 글쓰기 플랫폼은 다른 네이버나 티스토리, 워드프레스 같은 기존에 있는 서비스보다 더 나은 점이 없기 때문에 사용자가 없이 거의 운영을 안하는 느낌으로 방치되어 있기도 합니다. 그리고, 다른 협업자들과 함께 소통하기 위해 일부 사용자들에게만 공개된 페이지도 있고, 아직 운영에 배포되지 않고 소스코드 상태로 긴 잠을 자고 있는 서비스들도 여러개 있습니다.

이 모든 것이 하나의 모노레포 안에 들어있습니다. 혼자서 이것들을 운영하면서 최근에 느낀 것들을 정리해보려 합니다.

요구사항 정의가 곧 개발이 되었습니다

AI의 발전에 따라 모든 시스템을 생산성 있게 개발할 수 있게 됐습니다. 그래서 중요한 점은 제가 구현하고자 하는 기능을 얼마나 AI가 잘 알아들을 수 있게 요구사항을 잘 정의해서 요청을 했는지입니다.

그리고, AI가 개발한 내용이 기존의 시스템을 망가뜨리지 않고 잘 조화롭게 추가했는지에 대한 장치를 마련하는 것이 중요해지게 됐습니다. 유닛 테스트, API 테스트, E2E 테스트를 작성하게 해서 통과하는 것을 확인하고 나면 그때 PR을 생성해서 운영에 적용할 수 있는 준비를 하게끔 하는 것입니다.

AI의 시간을 병렬로 쓰려는 시도

수익화 할 수 있는 웹서비스를 꿈꾸며 만들어보면 좋을 웹서비스들을 이것저것 AI에게 요청했었습니다. 코드는 AI가 만들어주기 때문에, 제대로 동작된다는 것만 보장 받을 수 있다면, 문제는 AI가 소스코드를 만들어내는 시간을 최대한 빨리 쓰도록 하는 것입니다. AI가 소스코드를 작성하는 물리적인 시간은 정해져 있기 때문입니다.

병렬적으로 작업하기 위해 워크트리를 구성하고, 워크트리 마다 서버와 데이터베이스를 격리시켜서 하나의 로컬에서 여러가지 기능을 직접 검수해볼 수 있는 여건을 마련해보기도 했습니다.

가장 큰 병목은 사람이었습니다

하지만, 가장 큰 병목은 역시 사람일지도 모르겠습니다.

AI로 만들어낸 어떤 기능이든, 그걸 요구한 사람의 의도가 제대로 반영됐는지는 적어도 한번은 확인을 해야합니다. E2E 까지 테스트를 통과했으니, 꽤나 정확도 높은 코드라고 판단해서 믿고 배포를 해도 괜찮지 않겠냐는 생각이 들수도 있지만, 아직 프롬프트 엔지니어링 기술이 부족한 탓인지, 통과되는 테스트하고는 별개로 의외로 꽤 섬세한 부분들은 누락되는 경우가 많이 발생하는 문제를 겪고 있습니다.

이건, 처음에 요청을 그 섬세한 부분까지 당시에는 저도 생각하지 못했던 게 원인이 되겠죠.

만들고 싶은 것들이 여러개 있었지만, 어찌됐건 하나씩 공을 좀 들이다보면, 결국 여러 개를 동시에 사람이 검수할 수 있는 물리적 시간이 턱없이 부족한 것 같습니다. 가령, BullMQ를 이용해서 인프라를 개선하는 작업은 금방 AI가 만들어줄 수 있지만, 그래서 결국, 그게 의도에 맞게 레디스에 잘 적재가 되고 있는지를 로컬과 운영에서 모두 사람이 직접 잘 확인봐야하는 부분은 여전히 자동화할 수 없습니다.

결국 하나씩

그래서, 무턱대로 AI한테 이것저것 시켜봤자 어차피 검수할 사람이 한명이라는 사실을 인지하고, 너무 다방면으로 병렬처리를 하면 안되겠다는 생각이 들었습니다.

돌이켜 생각해보면, AI가 코드를 작성하는 속도가 아무리 빨라져도, 그 결과물이 의도에 맞는지 확인하는 속도는 사람에게 달려 있습니다. 동시에 진행할 수 있는 작업의 수는 AI의 성능이 아니라, 검수하는 사람의 수에 의해 결정되는 것이었습니다.