Cursor와 함께 풀스택 블로그 만들기

저는 백엔드가 아직 어색한 프론트엔드 개발자입니다. 예전 블로그를 만들 때도 댓글 기능은 giscus로 처리하는 등 백엔드 지식이 필요한 부분은 대부분 간접적으로 해결했어요.

하지만 컨텐츠를 자유롭게 보여줄 수 있는 저만의 공간이 필요하다고 느꼈는데 이를 위해서는 블로그 백엔드가 필요했어요. 인스타 개발 계정을 운영하면서 개발 컨텐츠를 종종 올리는데 이미지/영상 중심의 플랫폼이다 보니 제약이 많았기 때문이에요.

이렇게 백엔드가 있는 블로그에 대한 니즈가 생기던 중 최근 등장한 Cursor 같은 AI 에디터 덕분에 풀스택 블로그의 가능성을 보게 됐어요. 이제 이것저것 물어볼 백엔드 개발자가 에디터 안에 있으니까요.

그래서 이번에 도전해봤습니다. 두 번의 주말을 바쳐 블로그를 완성했고, 그 과정을 공유해보려고 해요. 우선 직접 만든 댓글 컴포넌트 보고 가세요🙌 제 계정으로만 테스트해봐서 버그가 있을지도

커서로 아는 거 구현하기

제게 익숙한 프론트엔드 코드를 짤 때와, 익숙하지 않은 백엔드 코드를 짤 때 커서를 활용하는 방식이 꽤 달랐다는 점이 인상 깊었어요.

프론트엔드에서는 주로 귀찮은 부분을 커서에게 시켰습니다. 예를 들어 댓글 뷰어처럼 복잡하지 않은 컴포넌트는 꽤 잘 만들어주더라고요. 이미 방법을 알고 있는 작업을 커서가 대신 해준다는게 가장 큰 장점이었어요. 덕분에 저는 디테일에 집중할 수 있었죠.

예를 들어 네트워크 에러나 로그인 안 된 상태처럼 자주 나오는 에러 처리도 커서가 적당히 구현해줘서 저는 에러 처리를 위한 코드(try-catch, if...)보다 에러 처리를 위한 핸들러를 어떻게 구성할지, 유저에게 어떤 메시지를 보여줄지 더 고민할 수 있었습니다.

모달같은 기본적인 컴포넌트도 접근성이나 focus처리등을 고려하면 제대로 만드는게 어렵다는거 알고 계신가요? 그래서 radix-ui를 써보고 싶었는데 공부하기는 귀찮아서 커서에게 부탁했습니다! 자랑이다. 댓글 삭제 확인 모달을 잘 만들어주더라고요. 실무에서 이러면 안되겠지만 사이드 프로젝트에서 써보고 싶은 기술이 있는데 문서 읽어볼 엄두가 안난다면 이런 식으로 첫걸음을 내딛어도 좋은 것 같습니다.

이외에 주의할 점은 '댓글 기능 구현해줘'처럼 추상적이고 큰 단위로 요구하면 커서가 종종 의도하지 않은 코드를 와장창 쏟아낼 때가 많았습니다. 그래서 컴포넌트 단위로 요구사항을 잘게 나눠서 주는 방식으로 작업해야 했어요. 이렇게 단위가 작을수록 코드 리뷰하기도 훨씬 편했습니다. 헛소리하는 토큰을 아낄 수도 있고요.

예전에는 혼자 코드를 짠다는 느낌이었다면, 커서를 활용하면서는 혼자하는 사이드프로젝트인데 PR 리뷰하는 느낌이 들었습니다.

커서로 모르는 거 구현하기

백엔드 작업은 제게 낯선 부분이 많았기 때문에 커서에게 기능을 설명하고 그에 맞는 쿼리나 서버 액션 코드를 짜달라고 요청하는 방식으로 사용했습니다. 예를 들어 "유저별로 댓글을 관리하고싶은데, 이걸 담을 수 있는 테이블을 만들어줘"라고 설명하면 적절한 테이블 스키마와 쿼리를 생성해줬습니다.

종종 테이블을 만들 때 제 블로그에서는 불필요한 필드를 넣는 경우가 있어서 수정 요청을 하기도 했습니다. 사실 본격적인 서비스라면 넣을 법한 필드들이었는데 저는 최대한 단순하게 만들고 싶어서 쳐냈었어요.

(백엔드랑 같이 개발하니 서버 액션이 확실히 편하긴하네요. REST 엔드포인트 다 만들어야했으면 더 귀찮았을 듯...)

기본키나 외래키같은게 뭔지는 대충 알아서 테이블 설계까지는 이해했지만 DB function이나 trigger는 어떻게 돌아가는지 아직 잘 모르겠더라고요. 이런게 쌓이다보면 손도 못대는 이해 불가능한 프로젝트가 되어버리니 이런 부분들을 잘 캡슐화하고 관리하고 공부하는게 중요하겠다 생각했습니다.

Supabase를 썼기 때문에 RLS(Row Level Security) 같은 보안 설정도 함께 해줘야 했는데요 이 부분도 커서가 자동으로 짜줘서 굉장히 편리했습니다. Supabase의 단점으로 'RLS 설정이 번거롭다'는 얘기를 들었는데 저는 커서 덕분에 큰 스트레스 없이 넘어갈 수 있었습니다.

느낀점

전반적으로 저는 프론트엔드 작업에서는 코드의 디테일을 챙기는 역할을, 백엔드 작업에서는 요구사항을 커서 제대로 이해했는지 확인하는 역할을 맡았던 것 같아요.

좋은 결과물을 만들려면 “무엇이 가능한지를 아는 것”이 정말 중요하다는 걸 느꼈습니다. 백엔드는 제가 잘 모르다 보니, 커서가 이상하거나 비효율적인 코드를 짜줘도 그걸 눈치채지 못할 때가 있었어요.

예를 들어 이모지 반응 남기는 기능을 처음에는 서버 액션에서 개수 가져와서(요청 1번) 개수에 1을 더하는(요청 2번) 방식으로 구현헀는데 db function을 활용하면 db에서 이 작업을 해주니 요청 1번에 되더라고요. 나중에서야 깨닫고 최적화를 해줬습니다. 아무래도 커서는 서비스의 요구사항을 저만큼 모르니 일반적으로 잘 먹히는 코드를 짜야해 발생하는 문제라고 생각해요.

최적화는 요구사항에 대한 이해와 기술적인 이해가 동시에 있어야 가능하다고도 느꼈습니다. 이번에는 제가 요구사항을 알고 커서가 기술을 알았던 셈이지만, 다음에 더 주도적이고 효율적으로 커서를 활용하려면 백엔드 공부가 꼭 필요하겠다 느꼈습니다.

마지막으로 Supabase 설정이나 GitHub Auth처럼 환경 세팅 관련 트러블슈팅은 커서만으로 해결하기 어려웠어요. 개발 환경 전반을 이해하는 AI가 얼른 상용화되면 좋겠네요.