This post is not yet available in English and is shown in Korean.
나는 백엔드가 아직 어색한 프론트엔드 개발자다. 예전 블로그를 만들 때도 댓글 기능은 giscus로 처리하는 등 백엔드 지식이 필요한 부분은 대부분 간접적으로 해결했다.
하지만 컨텐츠를 자유롭게 보여줄 수 있는 나만의 공간이 필요하다고 느꼈는데 이를 위해서는 블로그 백엔드가 필요했다. 인스타 개발 계정을 운영하며 개발 컨텐츠를 종종 올리는데 텍스트보단 미디어 중심의 플랫폼이다 보니 제약이 많았기 때문이다.
이렇듯 백엔드가 있는 블로그에 대한 니즈가 생기던 중 최근 등장한 Cursor 같은 AI 에디터 덕분에 풀스택 블로그의 가능성을 보게 됐다. 이제 이것저것 물어볼 백엔드 개발자가 에디터 안에 있으니까.
그래서 이번에 도전해봤다. 두 번의 주말을 바쳐 블로그를 완성했고 그 과정을 공유해보려 한다.
내게 익숙한 프론트엔드 코드를 짤 때와 익숙하지 않은 백엔드 코드를 짤 때 Cursor를 활용하는 방식이 꽤 달랐다는 점이 인상 깊었다.
프론트엔드에서는 주로 귀찮은 부분을 Cursor에게 시켰다. 예를 들어 댓글 뷰어처럼 복잡하지 않은 컴포넌트는 꽤 잘 만들어주었다. 이미 방법을 알고 있는 작업을 Cursor가 대신 해준다는게 가장 큰 장점이었고 덕분에 나는 디테일에 집중할 수 있었다.
예를 들어 네트워크 에러같은 일상적인 에러 처리는 Cursor가 적당히 구현해줘서 나는 에러 처리를 위한 코드보단 유저에게 어떤 메시지를 보여줄지등을 더 고민할 수 있었다.
모달같은 기본적인 컴포넌트도 접근성이나 focus처리등을 고려하면 제대로 만드는 것이 어려움을 알고 있는가? 그래서 radix-ui를 써보고 싶었는데 공부하기는 귀찮아서 Cursor에게 부탁해보았다. 댓글 삭제 확인 모달을 잘 만들어주더라. 사이드 프로젝트에서 써보고 싶은 기술이 있는데 문서 읽어볼 엄두가 안난다면 이런 식으로 첫걸음을 내딛어도 좋은 것 같다.
이외에 주의할 점은 ‘댓글 기능 구현해줘’처럼 추상적이고 큰 단위로 요구하면 Cursor가 종종 의도하지 않은 코드를 와장창 쏟아낼 때가 많았다. 그래서 컴포넌트 단위로 요구사항을 잘게 나눠서 주는 방식으로 작업해야 했다. 이렇게 단위가 작을수록 코드 리뷰하기도 훨씬 편했다. 헛소리하는 토큰을 아낄 수도 있고.
예전에는 혼자 코드를 짠다는 느낌이었다면, Cursor를 활용하면서는 혼자하는 사이드프로젝트인데 PR 리뷰하는 느낌이 들었다.
백엔드 작업은 내게 낯선 부분이 많았기 때문에 Cursor에게 기능을 설명하고 그에 맞는 쿼리나 서버 액션 코드를 짜달라고 요청하는 방식으로 사용했다. 예를 들어 “유저별로 댓글을 관리하고싶은데, 이걸 담을 수 있는 테이블을 만들어줘”라고 설명하면 적절한 테이블 스키마와 쿼리를 생성해줬다.
종종 테이블을 만들 때 내 블로그에서는 불필요한 필드를 넣는 경우가 있어서 수정 요청을 하기도 했다. 사실 본격적인 서비스라면 넣을 법한 필드들이었는데 나는 최대한 단순하게 만들고 싶어서 쳐냈었다.
기본키나 외래키같은게 뭔지는 대충 알아서 테이블 설계까지는 이해했지만 DB function이나 trigger는 어떻게 돌아가는지 아직 이해하지 못했다. 이런게 쌓이다보면 손도 못대는 이해 불가능한 프로젝트가 되어버리니 이런 부분들을 잘 캡슐화하고 관리하고 공부하는게 중요하겠다 생각했다.
Supabase를 썼기 때문에 RLS(Row Level Security) 같은 보안 설정도 함께 해줘야 했는데 이 부분도 Cursor가 자동으로 짜줘서 굉장히 편리했다. Supabase의 단점으로 ‘RLS 설정이 번거롭다’는 얘기를 들었는데 나는 Cursor 덕분에 큰 스트레스 없이 넘어갈 수 있었다.
전반적으로 나는 프론트엔드 작업에서는 코드의 디테일을 챙기는 역할을, 백엔드 작업에서는 요구사항을 Cursor가 제대로 이해했는지 확인하는 역할을 맡았다.
좋은 결과물을 만들려면 “무엇이 가능한지를 아는 것”이 정말 중요하다는 걸 느꼈다. 백엔드는 내가 잘 모르다 보니 Cursor가 이상하거나 비효율적인 코드를 짜줘도 그걸 눈치채지 못할 때가 있었다.
예를 들어 이모지 반응 남기는 기능을 처음에는 서버 액션에서 개수 가져와서(요청 1번) 개수에 1을 더하는(요청 2번) 방식으로 구현헀는데 db function을 활용하면 db에서 이 작업을 해주니 요청 1번에 가능했다. 나중에서야 깨닫고 최적화를 해줬다. 아무래도 Cursor는 서비스의 요구사항을 나만큼 모르니 일반적으로 잘 먹히는 코드를 짜야해 발생하는 문제라고 생각한다.
최적화는 요구사항에 대한 이해와 기술적인 이해가 동시에 있어야 가능하다고도 느꼈다. 이번에는 내가 요구사항을 알고 Cursor가 기술을 알았던 셈이지만, 다음에 더 주도적이고 효율적으로 Cursor를 활용하려면 백엔드 공부가 꼭 필요하겠다 느꼈다.
마지막으로 Supabase 설정이나 GitHub Auth처럼 환경 세팅 관련 트러블슈팅은 Cursor만으로 해결하기 어려웠다. 개발 환경 전반을 이해하는 AI가 얼른 상용화되면 좋겠다.