Cursor 실무 실험기: 댓글 기능까지 해보니 알게 된 자동화의 한계

LLM/Cursor

Cursor 실무 실험기: 댓글 기능까지 해보니 알게 된 자동화의 한계

Joonfluence 2025. 4. 11. 01:59

이 글은 Cursor 시리즈의 3번째 글입니다.

첫번째 글 : [기타] - AI가 코드를 짜는 시대, 개발자는 무엇을 해야 할까?
두번째 글 : [기타] - 10분 만에 세팅 끝! Cursor로 Java 백엔드 개발 환경 갈아타기
세번째 글 : [기타] - Cursor 실무 실험기: 댓글 기능까지 해보니 알게 된 자동화의 한계
네번째 글 : [기타] - Cursor가 짠 코드, 코드리뷰 통과 가능? 팀 컨벤션에 맞춰 룰 베이스 설정하기
다섯번째 글 : [기타] - Cursor의 잠재력 200% 활용하는 프롬프트 튜닝 방법

이런 분들에게 이 글을 추천합니다

Cursor를 사이드 프로젝트에서 써봤는데, 실무에서도 써도 될지 고민인 개발자
Cursor 무료 플랜으로 충분한지, 유료 결제가 필요한지 판단이 어려운 분
개발팀 생산성을 극대화하고 싶은 Tech Leader, 스타트업 CTO, 또는 CEO

Cursor, 어디까지 믿어도 될까?

지난 글에서는 Cursor가 Java/Spring 환경에서 실무 투입이 가능한지 실험해봤습니다. 결론은 이렇습니다:

"Cursor는 Java/Spring 개발에서도 충분히 실무 활용이 가능하며, 속도와 몰입감 측면에서 IntelliJ를 능가한다."

하지만 “실무 활용”이라는 말 속에는 다양한 전제가 숨겨져 있습니다. 이번 글에서는 그 중에서도 "코드 자동화"의 진짜 가능성과 한계를 파헤쳐보겠습니다.

실험 목적

Cursor는 어디까지 코드 자동 생성을 잘 해내는가?
반대로 개발자가 직접 개입해야 하는 영역은 어디인가?
특히 기존 코드에 새로운 요구사항을 추가하는 경우, 얼마나 잘 대응하는가?

이것만 알아도 여러분들의 개발 생활이 더욱 즐겁고 보람 차질 것이라 장담합니다.

왜 실무 도입 가능성을 따져야 할까?

개발자의 생산성은 단순한 속도 문제가 아닙니다. “주어진 시간 안에 얼마나 많은 가치를 만들어낼 수 있는가”가 핵심입니다.

특히 스타트업이라면

빠른 프로토타이핑, 반복 실험, 피벗이 필요합니다.

이직 준비 중이거나 내부 성과를 올려야 하는 개발자라면

시간을 효율적으로 써서 회사 내 성과 창출이 필요하죠.

그런 맥락에서 Cursor는 코드를 작성하는 시간을 줄이고, 생각하는 시간을 늘려주는 도구일 수 있습니다.

실험: 기존 기능에 새로운 기능 추가해보기

저희가 작성하는 코드는 대부분 2가지 경우일 것 입니다.

첫번째는 처음부터 코드를 쭉 작성해야 하는 경우
두번째는 이미 작성된 코드를 수정하여, 새로운 요구사항을 반영하거나 에러 등을 해결하는 경우

Cursor의 실무 활용성은 코드 수정 작업을 얼마나 효과적으로 처리하냐에 달려 있습니다.

왜냐면 대부분의 서비스 회사에서의 실무는 대부분 후자에 속하기 때문입니다.

따라서 해당 케이스를 얼마나 Cursor가 자동화 해주는 지 확인해보겠습니다.

기능 요구사항

게시글에 댓글을 생성/수정/삭제 할 수 있어야 한다.
댓글은 최대 500자까지 작성 가능해야 한다.
댓글에 대댓글을 달 수 있어야 한다 (계층 구조)

실험 가설

"Post와 독립적인 새로운 도메인(Comment)을 추가하는 경우, Cursor가 구조 설계부터 API 생성까지 충분히 커버할 수 있을 것이다."

Cursor에게 입력한 프롬프트 (기본 버전)

이번에도 마찬가지로 GPT에게 위 기능 요구사항을 기반으로 Cursor에게 명령 할 최적화된 프롬프트를 추출해봤습니다.

결과는 아래와 같습니다.

기존 Spring Boot 게시판 프로젝트(Post CRUD)에 아래 기능을 추가해줘.

요구사항:
1. 게시글(Post)에 댓글(Comment)을 추가할 수 있어야 해.
2. 댓글(Comment)은 다음 필드를 가져야 해:
   - id (Long, auto-generated)
   - content (String, 최대 500자)
   - createdAt (LocalDateTime)
   - post (Post 객체와 연관)
   - parent (대댓글일 경우 부모 Comment, nullable)
3. 댓글 생성/수정/삭제 API 구현
4. Thymeleaf로 댓글 목록 및 대댓글 구조 렌더링
5. 댓글 작성 시 Bean Validation으로 500자 제한

기존 코드 스타일, Entity 구조에 맞게 생성해줘.

커스터마이징한 프롬프트 (팀 컨벤션 반영)

여기에 실제 실무에 적용하는 룰을 몇 가지 적용해보겠습니다. 팀 컨벤션에 맞게, 프롬프트를 세부 조정해줘야 할 필요성이 있습니다.

- 댓글(Comment) 엔티티는 postId, parentId를 갖고, @ManyToOne은 사용하지 않아.
- Entity에는 @Setter를 사용하지 않고, 생성자 또는 Builder만 사용해줘.
- Join은 QueryDSL을 활용해서 처리할 거야.
- 불필요한 @Column 등은 생략해줘.

따로 수정해준 것 없이, 전부 반영해주니 API 관련 로직은 물론, 아래와 같이 글 작성 UI에 댓글 작성 UI가 추가된 것을 확인할 수 있었습니다.

그렇지만 역시, 한번에 작동하진 않았습니다 😢

결과: Cursor가 해준 것 vs 못 해준 것

🅾️ 자동화된 부분 : 잘 된 것

Comment 엔티티, Repository, Service, Controller 생성
Thymeleaf 템플릿 기본 구조 생성
API 테스트용 Form 및 HTML 코드 생성

백엔드 API 로직은 Post와 Comment가 각각 독립적 도메인이어서인지, 문제가 없었습니다. 문제가 발생한 영역은 기존 코드를 수정하여 처리하는 프론트엔드 영역이었습니다. 아래 화면에서 확인 할 수 있듯, UI 생성까지는 잘 처리해줬습니다.

❌ 개발자가 책임져야 하는 것

- Layout 구조 내 script 처리 등 템플릿 세부 구현
- 비동기 JS 이벤트 처리 (DOMContentLoaded 등)
- 기존 코드 수정 시 사이드 이펙트 고려
- JS, CSS 파일 경로 분기, DOM 조작 흐름 등

아래 사례에서 하나 하나 살펴보도록 하겠습니다.

Cursor가 작성한 로직의 문제점

문제는 기존에 없었던, 동작을 담당하는 Javascript 로직이 추가되어서인지 제대로 처리되지 않았습니다. 레이아웃 내 content 영역만 하위 페이지에서 로드하고 있어, 하위 페이지에서 추가한 script 태그가 제대로 로드가 되지 않았습니다. 그 결과, 웹 페에지의 동작을 담당하는 자바스크립트 파일이 제대로 동작하지 않았습니다.

<-- 공통영역 -->
<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" th:fragment="layout(content)">
...
<body>
  <nav class="navbar navbar-expand-lg navbar-dark bg-dark">
    <div class="container">
      ...
    </div>
  </nav>
  <div class="container mt-4">
      <div th:replace="${content}">
      </div>
  </div>
  <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/js/bootstrap.bundle.min.js"></script>
</body>
</html>

<-- 게시글 상세 페이지 -->
<body>
  <section>
    ...
  </section>
  <script src="/js/comment.js"></script>
</body>

직접 수정한 부분

Thymeleaf layout 구조에서 script 태그가 로드되지 않아 JS가 동작하지 않음
댓글 생성 버튼이 DOM 로드 이전에 바인딩되어 이벤트 작동 실패
추가적으로 DOMContentLoaded 이벤트로 JS 재정의

<-- 공통영역 -->
<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" th:fragment="layout(content, scripts)">
...
<body>
  <nav class="navbar navbar-expand-lg navbar-dark bg-dark">
    <div class="container">
          ...
    </div>
  </nav>

  <div class="container mt-4">
    <div th:replace="${content}"></div>
  </div>

  <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/js/bootstrap.bundle.min.js"></script>
  <div th:replace="${scripts}"></div>
</body>
</html>

저 같은 경우에는 script 태그 로드를 위하여, 추가로 layout을 담당하는 layout/default.html 파일을 수정하는 과정을 거쳤습니다.

<--- 게시글 상세페이지 -->
<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org" th:replace="~{layout/default :: layout(~{::section}, ~{::script})}">
<head>
    <title>게시글 상세</title>
</head>
<body>
  <section>
    ...
  </section>
  <script src="/js/comment.js"></script>
  <script>
    document.addEventListener('DOMContentLoaded', () => { 
    const commentBtn = document.getElementById('commentSubmitBtn'); // 댓글 작성
    commentBtn?.addEventListener('click', () => {
        const postId = commentBtn.dataset.postId;
        createComment(postId);
    });
     ....
   });
  </script>
</body>

결국 수정 후, 정상 작동을 확인하였습니다.

실무 기준 : 어디까지 자동화 가능한가?

Cursor는 완벽하지 않습니다. 특히 디버깅이 무척 어려웠습니다. Cursor는 생산성 향상을 가져오는 좋은 툴이지만, 프로그래머가 한 줄 한 줄 작성할 때에 비해, 주의력이 낮은 상태로 코드를 작성하게 됩니니다. 코드리뷰 하듯 눈으로 보고 문제가 없으면 코드를 승인하며 사용하게 됩니다. 대부분 거의 해주지만, 몇 개가 빠져 있었습니다. 문제는 이 빠져 있는 부분 찾기가 어렵다는 점입니다.

결론 : 어디까지가 자동화의 한계인가?

이번 실험에서 Cursor는 신규 기능 추가에 있어 꽤 만족스러운 결과를 보여줬습니다. 특히 API와 CRUD 기반 코드는 손도 안 대고 그대로 쓸 수 있을 정도였죠. 하지만 기존 코드에 복잡하게 얽힌 템플릿/레이아웃 구조까지 이해하고 수정하는 데에는 한계가 있었습니다.

"Cursor는 코드를 ‘대신’ 써주는 게 아니라, 빠르게 ‘초안’을 제공하고 개발자가 그 위에 로직을 쌓는 도구다."

이걸 명확히 인지하면, 어디까지 기대하고 어디서부터 내가 개입할지를 분명히 할 수 있습니다.

마무리

이번 글에서는 댓글/대댓글 기능을 추가하며 Cursor가 실무에서 얼마나 쓸만한지 검증해봤습니다.

다음 글에서는 “Cursor에서 팀 컨벤션을 반영하려면 어떻게 해야 하나?” 를 주제로 다뤄보려 합니다. 더 풍부한 예시 사례, 룰 베이스 설정 방법과 팀 내 코드 컨벤션에 맞춰 코드 자동화 수준을 더욱 정교하게 만드는 전략에 대해 공유해보겠습니다.

긴 글 읽어주셔서 감사합니다.

저작자표시 비영리 (새창열림)