cllaude99 | AI를 사용해보고 느낀점에 대한 정리

저는 개발할 때 Cursor, Claude Code, Anitigravity등의 AI를 적극적으로 사용하고 있습니다. 동시에 어떻게 하면 AI를 더 잘 사용할 수 있을지에 대해 고민하면서 사용하고 있는데요. 이번 글에서는 Cursor Claude Code, Antigravity를 사용하면서 느꼈던 경험과 AI를 더 잘 사용하기 위해 접근하고 있는 방법을 적어보려고 합니다.

Cursor

저는 현재 Cursor를 기본 코드 IDE로 사용하고 있습니다. Cursor를 사용하면서는 아래의 특징이 있었습니다.

장점

개인적으로 느꼈던 장점으로는 아래와 같습니다.

.cursor폴더안에 rule을 적용하여 cursor에 요청 시 rule이 적용된 코드의 형태로 반영됩니다.
use multiple models를 활성화여 하나의 명령에 대해 여러 모델의 결과를 확인하고 비교할 수 있습니다.
코드베이스에 존재하는 파일의 코드 형태에 맞게 자동으로 코드를 추천하고 탭을 통해 반영할 수 있습니다.
agent모드를 제공하고, composer1모델의 경우는 다른 모델에 비해 빠르게 요청사항을 반영해줍니다.
undo, redo, keep 등을 제공하여 Cursor의 작업을 확인한 후에 반영할 지를 결정할 수 있습니다.
work tree를 체크하여 원하는 브랜치에 적용할 수 있습니다.
브라우저 모드도 지원합니다.
mcp도 설정해줄 수 있습니다. (Context7, Figma MCP, Supabase MCP등을 사용하고 있습니다. 다만 한 번에 켤 수 있는 MCP Tool 개수에 제한이 있어서 Context7의 경우는 항상 켜놓고 다른 tool들은 필요할 때마다 선택적으로 켜서 사용하고 있습니다.)

피그마 MCP의 경우 Bun를 통해 아래와 같이 연결하고 작업해보았습니다.


1. 터미널에 curl -fsSL https://bun.sh/install | bash 을 통해 bun을 설치

2. cursor 터미널에 bunx cursor-talk-to-figma-mcp 실행

3. 2번과는 다른 터미널을 열고 bunx cursor-talk-to-figma-socket 실행

4. 3번과정에서 아래처럼 뜨는지 확인 (아래처럼 뜨면 정상 연결 된것)
   WebSocket server running on port 3055
   **New client connected**

5. Figma에서 Cursor Talk To Figma Plugin을 검색 후 실행

6. 로컬호스트 활성화 후 채널코드 복사

7. 커서 새로운 채팅을 열고 Agent에 "피그마 채널 연결해줘. 채널: <6번에서 얻은 채널 코드>" 입력

8. 커서 채팅에 '피그마 문서 정보' 라고 입력하여 피그마 연결 여부 확인

사용해보니 화면 디자인이 잘 되어있다면, 디자인 시스템 적용 및 화면 디자인이 꽤 훌륭할 것 같다고 느꼈습니다.

plan mode를 사용하여 명령시 구현 전에 계획을 짜도록 할 수 있고, 계회은 md파일로 보여줍니다. 이때 계획이 원하는 방향과 일치하지 않으면 수정 요청도 할 수 있습니다.

저는 개인적으로 마지막 특징인 plan mode를 잘 사용하고 있는데요. plan모드의 경우 agent모드와는 다르게 사전에 cursor가 어떠한 작업을 하려고 하는지를 미리알고 방향을 결정해줄 수 있다는 장점이 있습니다. 실제로 agent모드를 사용했을때는 cursor의 작업이후 추가로 요청해야했던 사항이 많았던 반면, plan mode를 사용한 후에는 추가 질문의 개수가 더 줄어들게 되었습니다. 계획과정에서 plan.md파일을 만들어주는데 해당 파일을 보고 계획을 수정하고 다시 요청할 수도 있습니다.

단점

개인적으로 느꼈던 단점으로는 토큰이 Claude code에 비해 빨리 소모된다고 느꼈습니다. 하지만 그 외에는 별다른 큰 단점은 느끼지 못했던 것 같습니다.

Claude Code

장점

Claude Code를 사용하면서 아래의 장점이 있었습니다.

cursor에 rule이 존재하는 것처럼 클로드코드에서는 CLAUDE.md파일에 명령전에 필요한 컨텍스트를 넣어줄 수 있습니다.
.claude/commands폴더안에 만들고자 하는 커멘드를 md파일에 작성할 수 있습니다. ( 실제로 몇 가지 커스텀 커멘드를 만들었지만 잘 사용하고 있지는 않아서 어떻게 하면 이것을 잘 활용해볼 수 있을 지 고민중입니다. )
.claude/agents폴더에 agents들을 만들 수 있습니다. 저는 실제로 기획 전문가 에이전트, threejs에이전트등을 만들어 보았고 이를 통해 작업을 진행해보았습니다. ( 나름 준수하게 잘 만들어줬습니다. )
hooks 기능을 통해 명령전, 명령후에 필요한 작업을 진행할 수 있습니다. 하지만 매번 명령마다 실행하기 때문에 토큰을 많이 잡아먹게 됩니다. hooks를 통해 명령이후 매번 타입 에러를 확인하고 처리하도록 한 적이 있는데 이때 토큰이 너무 빨리 소모되어서 그 이후로 부터는 잘 사용하고 있지 않습니다.
cursor에 plan mode가 있는 것처럼 Claude code에서도 shift+tab을 통해 모드를 바꿀 수 있습니다.
mcp 설정이 가능합니다. 저는 Filesystem MCP, Memory MCP를 사용하고 있습니다. ( 프로젝트 파일을 탐색할때 좋고 세션 간 정보기억 및 컨텍스트를 유지해준다는 장점이 있어서 해당 MCP들을 추가하였습니다. )
Cursor IDE위에 올려서 같이 사용할 수 있다. ( 둘의 장점을 뽑아서 쓸 수 있음 )

Claude Code에서는 subagent의 기능을 잘 사용하고 있습니다. 하나의 명령에 여러 agent를 사용하여 작업을 병렬적으로 처리할 수 있어서 좋았습니다. 이러한 장점 덕분에 이전과 달리 여러 작업에 대해 병렬로 처리하여 작업 시간을 조금 줄일 수 있었습니다.

단점

아직 단점은 잘 모르겠습니다. 개인적인 바람으로는 이미지를 첨부할 때 이미지가 미리보기로 보였으면 좋겠다고 생각했습니다. Claude Code에서는 [Image 1] 처럼 텍스트로 들어가서 살짝 아쉬웠습니다. 또, Cursor처럼 브라우저 기능도 제공해준다면 좋을 것 같습니다.

Antigravity

가장 최근에 나온 IDE입니다. 구글에서 만들었고 Gemini3 Pro 뿐만 아니라 Claude Sonnet 4.5등 다른 모델도 무료로 지원하고 있습니다.

장점

Cursor, Claude Code에서 룰을 적용하는 것과 같이 .agent 폴더안에 룰을 적용할 수 있습니다.
브라우저 기능을 제공합니다. Cursor와 다른점이 있다면 Antigravity의 경우, 크롬 확장 프로그램을 설치해야 한다는 점과 Antigravity 자체적으로 테스트 값을 입력하고 화면을 녹화한다는 특징이 있습니다.
agent manager에서 playground 기능을 제공합니다. 이를 통해, playground에서 개발하고 마음에 있다면 워크스페이스로 옮겨서 작업을 구체화 할 수 있습니다. 기존의 경우, 폴더를 만들고 해당 폴더안에서 작업을 하는 플로우였다면 playground에서는 만들고 싶은 기능을 만들다가 괜찮은듯 싶으면 워크스페이스로 옮겨서 실체화할 수 있다는 특징이 있습니다.
여러 워크 스페이스를 동시에 실행할 수 있습니다. A프로젝트, B프로젝트 등을 동시에 작업할 수 있는 구조입니다.
Gemini 3을 통해 이미지를 무료로 만들어줍니다.

단점

토큰이 굉장히 빨리 소모되어서 아쉬웠습니다. 질문을 5개정도 했는데 모두 소모되어서 아쉬웠습니다. Cursor와 비교했을때 눈에 띄는 차이점을 느끼지 못했습니다. 또, 초기버전이어서 터미널 위치 수정 후 반영안됨등의 버그도 존재하는 것 같습니다. 결론적으로 Cursor에 비해 특별하게 좋은 점이 존재하지 않아서 저는 아직 Cursor를 사용할 것 같습니다.

최종 사용

현재는 IDE로 Cursor를 사용하고 있고 그 위에 Claude Code를 실행시켜 사용중입니다. 그 외에 필요할 때 나노 바나나를 통해 에셋 이미지를 생성하고 있습니다. Antigravity는 조금 더 지켜봐야 할 것 같습니다.

AI를 잘쓰는 방법에 대한 고민

요즘 AI를 사용하면서 어떻게 하면 이를 잘 사용할 수 있을지에 대해 고민하고 있습니다.

초반에는 AI에게 단순하게 "~기능을 만들어줘." 라고 요청하곤 했었는데요. 이렇게 하다보니, 기능은 돌아가긴 했지만 코드의 형태가 마음에 들지 않았습니다. 컴포넌트의 관계가 불필요하게 복잡한 경우가 많았고 이로 인해 코드는 자연스럽게 읽히지 않았으며 변화에 유연하게 대응하기 어려웠습니다.

해당 부분에 대해서는 rule을 적용하여 해결해보려고 했습니다. rule 적용 이후에는 이전에 비해서는 괜찮아지긴 했습니다. 하지만 아직도 요청 이후 코드를 손봐야하는 경우가 많았고, 모르는 요청에 대해서는 계속 물어봐도 모르는 경우도 많았습니다.

특히 요청이후에도 내가 계속 손봐줘야 하는 과정이 많아지면서 피로함을 느꼈습니다. 그래서 어떻게 하면 "내가 손을 덜 볼 수 있을까?" 에 대해 고민해보게 되었습니다.

먼저 "내가 코드를 짤때 고민하는 것이 무엇인가?" 에 대해 정리해보기로 했습니다. 내가 코드를 바라보는 기준이 명확해야 AI에게 명확하게 요청할 수 있고 또, AI의 응답값에 대해서도 일관된 기준으로 판단할 수 있다고 생각했기 때문입니다.

저는 코드를 짤때 아래와 같은 것을 고려합니다.

코드 작성시에 위에서 아래로 자연스럽게 읽히도록 하자.
'어떻게'에 집중하지 말고 '무엇을'에 집중하며 선언적으로 코드를 작성하자.
하나의 컴포넌트는 하나의 역할만 하거나 하나의 역할만 하고 있는 컴포넌트의 조합으로 만들자.
3번이상 중복되는 비즈니스 로직의 경우에는 커스텀 훅을 사용하여 적절하게 추상화하자.
UI로직과 데이터로직을 분리하여 기획의 변경사항에 빠르게 대응할 수 있게 하자.
데이터는 상위 컴포넌트에서 관리하고 필요한 경우 하위컴포넌트에 props로 전달하자. 이때 하위컴포넌트에 넘겨주는 depth가 3개 이상이면 컴포넌트 구조를 다시 설계하자.
다른 사람이 코드를 봤을 때 직관적이고 빠르게 이해될 수 있도록 하자.

이후, "내가 이러한 생각을 가지고 있다는 것을 요청 전에 말하면 되지 않을까?" 라고 생각했습니다. rule에 적용해도 잘 반영이 되지 않았기에 코드로 적어보면 좋을 것 같다고 생각했습니다.

그래서 최종적으로는 어떻게 보였으면 좋겠는지에 대해 코드를 짰습니다. 즉 세부 구현에 대한 설계는 글로 풀어서 요청시 포함하고 최종 형태는 코드로 예시를 들어 요청했습니다. 추가로 인터페이스도 미리 정의하여 요청했습니다. 어떠한 인터페이스를 가지면 좋을 지등에 대해서 미리 작성하였습니다. 그 이유는 매번 응답에서 인터페이스등의 구조를 고친 적이 많았기 때문입니다. 마지막으로 이를 Plan mode로 요청하였습니다. 구현하고자 하는 작업을 여러 개의 작은 작업으로 나누고 해결하는 것이 경험상 더 좋았기 때문입니다. 이를 통해서 설계는 내가 명확히 하되, 세부적인 구현사항, 즉 코더의 역할은 AI에게 위임하였습니다.

결과적으로 이런 방식으로 진행하다 보니, 요청 이후 다시 재요청하는 작업이 줄었습니다. 또, 구현과정 자체에 소모되는 시간을 줄일 수 있어서 생산성을 높일 수 있었습니다.

사실 아직도 어떻게 더 잘 사용할 수 있을지에 대해 고민이 많습니다. 요청 이전에 "최종적으로 보여질 코드의 형태와 인터페이스를 미리 정의한다"는 것으로도 좋은 결과를 낼 수 있었지만 나의 기준이 꼭 정답이 아니듯 보다 더 변화에 유연하게 작성하는 것은 무엇일지에 대해 고민하고 있습니다.

한가지 얻은 점은 AI에게 모든 작업을 처음부터 끝까지 해달라고 하기보다는 첫 단추는 내가 잘 끼워주고 이후 작업은 AI를 통해 빠르게 진행하면 좋을 것 같다고 생각했습니다. 또, 아예 모르는 것에 대해 질문하기보다는 스스로 관련 개념에 대해 공식문서를 통해 어느정도 학습하고 구현하는게 좋을 것 같다고 생각했습니다.