'프차천국' 리빌딩: 커서(AI)의 개발적 한계

함께 it동아리를 했던 선배에게 전화가 왔습니다. '함께 살면서 잠시 도와줄수있냐고' 재밌어 보이는 마음에 전화받고 바로 갔습니다.  

기존 '프차천국'의서비스는 프론트는 버블로, 백엔드는 클라우드플레어의 서버리스 서비스로 구축되어있는 형태였습니다. 하지만 백엔드쪽에 전문적이시지 않으시니 기존에 커서를 적극적으로 활용하였습니다. 하지만 외부 데이터를 사용하고, 서비스의 로직이 복잡해지자 오류들이 발견되어도 빠르게 해결하기 어렵자 백엔드 개발자가 필요했던 것이었습니다.

저도 커서를 결제하며 적극적으로 활용하고있고 빠르게 개발해본 경험이 있는 사람으로서 커서는 기능 개발에는 강하다고 생각합니다. 하지만 커서로 개발할때의 문제는 다음과 같았습니다.

1. 커서는 토론하지 않는다.

이번 서비스는 정보공개서라는 공공데이터를 활용해야했습니다. 공공데이터의 특성과 서비스의 핵심 기능 특징등 다양한 요소를 고

려하고 반영하여 테이블을 설계해야합니다. 커서는 본인의 설계를 잘못했더라도 문제를 제기하지 않습니다. 또한 문제를 발견하여 해결책을 제시한다면 대부분 수용합니다. 이전에 왜 잘못 개발하였는지, 이러한 구조에 장점과 당점은 무엇일지, 또 다른 문제는 없을지 이야기 하지 않습니다.

예를 하나 들자면, 서비스에서는 데이터를 제공하는 주체로 정보공개서, 브랜드 관리자, 서비스 관리자가 있습니다. 브랜드 관리자가 입력한 데이터가 1순위, 서비스 관리자 데이터가 2순위, 정보공개서가 입력한 데이터가 3순위로 사용자에게 보여줍니다. 이를 그냥 하나의 데이터에 대해 데이터 제공주체 3개가 각각의 테이블로 존재했습니다. 그러다보니 기존에는 테이블이 11개면 될것이 33개가 존재했습니다. (현재는 이마저도 6개로 감소되었습니다) 테이블이 많은것도 문제이지만 특정 데이터를 조회하하거나 수정할때 마찬가지로 3개를 모두 고려해야합니다. 이렇듯 제가 생각하기에 더 좋은 방향이 있음에도 단순히 요구를 수용하고 개발하다보니 무식하게 테이블을 설계가 되었습니다.
서비스를 개발하는 입장에서 테이블 설계는 근간이고, 가장 많이 생각하고 고민해야한다고 생각하기 때문에 이것이 가장 큰 문제였습니다. 

2. 코드가 복잡해지고 많아지면 멍청해진다.

결국 커서를 포함한 ai는 서비스만의 로직에 약합니다. 이전에 말한 데이터 제공자3개의 우선순위를 만족하기 위해 별도의 수정이력 테이블을 만들었습니다. 이를 통해 3개의 반복되는 테이블을 1개로 통일 시켰습니다. 하지만 테이블과 로직을 잘 설계하더라도 커서에게 전달하면 제대로 활용하지 못합니다. (쓸데없는 데이터를 응답에 넣어주기도 하고 그냥 무시할때도있고...) 코드가 많아지고 서비스 로직이 복잡해지는 상황에서 코드를 제대로 작성하지는 못하였습니다. 

3. 개발 잘하는 사람이 바이브 코딩도 잘 할 수있다.

1, 2번은 프롬프팅능력과 모델에 따라 극심한 차이를 보여주곤 합니다. 하지만 토론을 통해 문제를 발견하고 해결책을 선택하는 것도, 많은 코드를 Ai에게 이해시키고 지시하는 능력도 결국에는 개발을 잘해야합니다. 여기서의 개발능력은 코드를 잘 짜는 능력보다는 코드를 읽고 문제를 발견하고, 그 문제에 대한 해결책을 제시하는 능력이 더욱 중요시될것 같습니다.

이러한 커서의 한계가 명확했기에 기존 서비스에는 여러가지 문제가 존재하였고 그대로 활용하여 개발하기에는 문제였습니다. 이 서비스를 어떻게 빠르게 새롭게 구축하였는지 자세하게는 다은글에서 작성하고자합니다.