입사 직후엔 매번 야근하면서 몸빵으로 때웠다.
지금은 정규 근무 시간 안에 업무를 쳐내고, 빠퇴해서 헬스장에 간다.
달라진 건 딱 하나, Cursor IDE에 MCP를 붙여서 쓰기 시작한 것 뿐이다.
지난 번 AI rule 글에서 예고한 대로,
내가 실제로 MCP를 업무에 어떻게 연결해서 쓰고 있는지, 업무 유형별로 정리해본다.
내 세팅
모델은 Opus 4.6(Claude 모델)을 Cursor IDE에서 사용하고 있다.
(4.5를 쓰고 있었는데 최근 업데이트 됨)
연결해둔 MCP는 다음과 같다.
1. Chrome DevTools - 브라우저에서 직접 디버깅
2. Framelink Figma MCP - 디자인 시안 참조
3. mcp-atlassian - Jira 티켓 생성/상태 변경
4. Notion - 기획서 읽기, Slack에서 검색
5. Sentry - 에러 로그 분석

운영 업무: Slack 요청 -> 분석 -> Jira 티켓 -> 작업
운영 업무는 대부분 Slack에서 시작된다.
흐름은 이렇다.
1단계: Slack 업무 요청 Ctrl C+V
- Slack의 업무 요청 맥락을 복사해서 Cursor에 붙여넣고, 작업 내용을 설명해달라고 한다.
2단계: atlassian mcp로 Jira 티켓 생성
- 관련 Jira 티켓 링크를 Cursor에 붙여넣고, 1단계 분석 내용을 바탕으로 하위 작업 티켓을 생성해달라고 한다
- 여기서 팁 하나!
티켓 삭제 권한이 없다면, 꼭 피드백을 최소 한 번 한 후에 하위 작업 목록 생성을 confirm 하자.
잘못 생성된 티켓이 남아있으면 귀찮아진다.
3단계: 생성한 하위 티켓 순서대로 작업 시작
- Agent 모드(기획+실행 동시)를 쓰면 빠르게 작업할 수 있다.
- Build 모드(설계 후 컨펌)를 쓰면 Cursor가 단계별로 역질문을 하면서 꼼꼼하게 진행할 수 있다
티켓 상태 변경(진행/완료)도 MCP로 가능하다.
Jira 티켓 찾아서 여는 거 은근 번거로운데, 이거 되게 편하다.
소소하지만 확실한 시간 절약 ㅎㅎ
새 기획 업무: Notion 기획서 -> 구조 설계 -> Jira -> 구현
1단계: Notion MCP로 기획서 읽기
- Notion 기획서 링크를 Cursor에 붙여넣고, 작업 내용을 설명해달라고 한다.
2단계: 구조 설계
기획서 내용을 바탕으로 구조 설계를 제안해달라고 한다
이때 중요한 것:
- 확장 가능성/유지보수성 관점에서 문제를 직접 제기하며 피드백 사이클을 반복해야 한다.
- 이 과정에서 기획서 속 '판단하기 애매한' 단어들에 대한 피드백도 기획자에게 남긴다
(기획자님 '적당히, 약간, 느낌'보단 명료한 단어를 써주세욧...)
- 모호한 단어를 줄일 수록 개발-기획 커뮤니케이션 비용을 줄일 수 있다.
3단계: atlassian MCP로 Jira 티켓 생성
- 구조가 확정되면 이 설계를 기준으로 Jira에 Task를 생성해달라고 한다.
- 생성된 티켓 순서대로 작업을 진행해달라고 한다
4단계: AI rule+Figma MCP로 UI 구현
- AI rule 폴더를 읽으라고 하고, Figma 요소 링크를 같이 붙여넣는다.
(Figma에서 Frame 위에서 우클릭 - copy link to selection)
- 팀 컨벤션을 AI rule에 반영해두면, UI 구현 시 컨벤션을 따르면서도 생산성을 올릴 수 있다.
- AI rule 세팅 관련 글: https://developer-dreamer.tistory.com/210
5단계: Chrome DevTools MCP로 디버깅
- 구현 중 문제가 생기면 Chrome DevTools MCP나 Cursor Browser를 사용한다.
- Cursor가 스크린샷을 찍거나 콘솔 로그를 직접 확인하면서, 해결될 때까지 분석해준다
- Chrome DevTools 사용 사례: https://developer-dreamer.tistory.com/195
코드 리뷰: PR 코멘트 분석 + 리뷰 작성
개인적으로 코드 리뷰는 어려운 영역이었다.
어떤 부분을 짚어야 리뷰이에게 도움이 될지 잘 모르겠고,
이게 정말 유의미한 코멘트인지 매번 고민했다.
브랜치를 직접 실행시켜서 오류를 찾아주는 것도 리소스가 드는 일이었다.
리뷰 받을 때
1단계: PR 코멘트 링크 Ctrl C+V
- GitHub PR 코멘트 링크를 Cursor에 붙여넣고, 리뷰 내용을 분석해달라고 한다.
2단계: Cursor가 리뷰 맥락을 분석
- Cursor가 리뷰 코멘트만 읽는 게 아니라, 해당 코드의 실제 사용처까지 찾아서 분석해준다.
예를 들어, "이 필드를 Required로 잡으면 어떨까요?"라는 리뷰가 왔을 때,
관련 호출부를 전부 훑어보고 "실제로 모든 호출에서 이 필드를 포함하고 있으니 Required로 잡는 게 맞다"는 식으로 근거를 정리해준다.
3단계: 수정 방향 제안 → 반영
- 분석 결과를 바탕으로 수정 코드까지 제안해주기 때문에, 리뷰 반영 속도가 빨라진다.
리뷰를 받으면 "이게 맞나?" 하고 사용처를 하나하나 찾아보는 시간이 있는데, 그걸 Cursor가 대신 해주는 느낌이다.
리뷰 할 때
1단계: 동료의 branch로 이동
- 동료의 branch로 이동한 후, 코드 리뷰가 필요한 사항을 출력해달라고 한다.
2단계: 코멘트 내용 확정 → 리뷰 작성
- Cursor의 분석 내용 중 이해가 안 가는 부분을 질문하면서, 코멘트 내용을 확정짓고 리뷰를 단다.
이전에는 "주석 지울까요?", "변수명 바꿀까요?" 같은 단편적인 리뷰만 했는데,
Cursor와 함께 리뷰하면서 의존성 배열에 누락된 변수라거나, 값이 없는 경우를 고려하지 않은 부분 같은
실제로 코드 로직을 돌려봐야 알 수 있는 것들을 잡아낼 수 있게 됐다.
리뷰 속도만 빨라진 게 아니라, 리뷰 품질 자체가 올라간 느낌이다.
또, 동료의 구현을 겉핥기가 아닌 좀 더 깊이 있게 이해할 수 있었다.
버그 대응: Sentry -> 원인 추정 -> 에러 로깅 -> 해결
1단계: Sentry URL Ctrl C+V
- Sentry 링크를 Cursor에 붙여넣는다.
2단계: Sentry MCP로 원인 분석
- Cursor가 관련 코드를 분석해서 원인을 추정한다.
- 대부분은 여기서 해결되지만, 레거시 코드가 꼬여 있으면 추정이 빗나가기도 한다.
3단계: 추정이 불확실하면 Sentry Error Log를 달아본다.
4단계: 새로 잡힌 에러 로그를 확인한다
- 의문이 해결되었다면 -> 사건 종결
- 여전히 명료하지 않다면 -> 추가 로그를 달고 반복
이 방법으로 반년 넘게 원인을 못 찾던 VOC를 6시간 만에 해결했다.
그 전까지는 매번 '아마 이게 원인일 거야'라고 추정해서 코드를 고쳐봤다.
그런데, 결국 에러 로깅을 체계적으로 다는 게 답이었다.
매번 에러 로그를 보고 '이게 맞나?'라는 생각을 했는데,
AI로 분석하니까, 문제 상황과 원인을 2분 내로 파악할 수 있어 좋았다.
기획자도 이 방법에 대해 팀 전체 멤버를 멘션하며
'이런 식으로 로깅 달아서 근본적인 원인을 해결하는 방식 좋은 것 같다.
앞으로도 이렇게 해보자'라고 말했다.
(동의합니다. ㄹㅇ요)
폴더 너머 대응: 멀티 레포 분석
웹뷰 개발자 특성 상 여러 레포지토리를 넘나들며 작업해야 한다.
(아닐수도 있지만 일단 지금의 난 그렇다...)
RN 레포, 웹뷰 레포1, 웹뷰 레포2, 웹뷰 레포3 - ...
예전에는 창을 여러 개 열어두고 왔다 갔다 하면서 헷갈렸었다.
(동시에 5개까지 열어봄)
그런데, 이제는 Cursor 한 세션에서 해결한다.
WOW!
1단계. 핵심 레포 열기
- 핵심 분석이 필요한 레포를 Cursor IDE로 연다
2단계. 문제 지점 분석
- 문제 지점 파일이나 코드를 분석해달라고 한다.
- Cursor가 '이건 웹뷰 쪽 문제일 수 있어요', '이건 RN 쪽 문제일 수 있어요' 같은 판단을 내려준다.
3단계. 멀티 레포 분석 with Cursor
- 상위 폴더로 이동해서 'RN 레포를 같이 확인해줘' 또는 '웹뷰 레포를 확인해줘'라고 말한다.
최대 4개 레포까지 한 Cursor 세션에서 동시에 분석해봤는데,
컨텍스트 전환 없이 문제를 추적할 수 있어서 디버깅 속도가 확실히 빨라졌다.
보너스 팁: Notion MCP로 Slack 검색하기
Slack MCP를 직접 연결하지 않아도, Notion MCP로 Slack을 검색할 수 있다.
"오늘 내 팀 채널에서 있었던 일 요약해줘"
"오늘 내가 멘션된 메시지를 요약해줘"
연차 후 복귀할 때 특히 유용하다.
쉬는 동안 어떤 일이 있었는지 빠르게 파악하고, 업무에 바로 적용할 수 있다.
MCP와 함께 작업한 이후, 체감 생산성이 3배 가까이 늘었다.
3개 작업을 병렬로 동시에 진행해도 무리가 없고,
예전에 반나절 걸리던 운영 업무가 1-2시간 안에 처리하고,
반년간 잡지 못한 버그를 하루 만에 해결했다.
결과적으로 매일 야근해야 업무를 커버하던 상황에서,
정규 업무 시간 내에 여유 있게 작업을 마치는 생활로 바뀌었다.
핵심은 AI를 '코드 작성 도구'로만 쓰지 않는 것이다.
Jira 티켓 관리, 기획서 분석, 에러 로그 추적, 멀티 레포 디버깅까지
업무 흐름 자체에 AI를 연결하면, 코딩 외의 시간이 줄어든다.
뭐야 MCP가 다 해주네? 인간은 뭐하냐?
라는 생각이 들 수 있다.
인간은 행동을 할 때 기준을 세우고, 그에 맞는 여러 선택지를 만든 후, 최선을 고른다.
MCP가 보조해주는 것도 이 과정이다.
기준(설계)을 같이 세워주고, 여러 선택지(구현 방식)를 제시해준 후, 최선을 제안한다.
하지만 결국 그걸 적용하고, 판단하고, 책임지는 것은 인간이다.
티켓 생성, 코드 분석, 리뷰 맥락 파악 같은 반복 작업을 MCP가 처리해주면서,
인간에게 진짜 필요한 '판단과 결정'의 영역만 남게 된 것이다.
업무의 최적화라고 볼 수 있다.
개발자의 진짜 병목은 코드를 짜는 시간이 아닌,
코드 짜기 전/후에 있다.
작성: 2026.02.13. 00:07
'개발자 강화 > AI 활용' 카테고리의 다른 글
| 개발 블로그를 좀 더 쉽게 써보자 - Cowork로 흩어진 개발 맥락 모으기 (1) | 2026.02.18 |
|---|---|
| 쓰던 봇이 유료 전환? 그럼 직접 만들지 - 집중요정 슬랙봇 개발기 (1) | 2026.02.17 |
| 26년 1월 - 집중요정과 함께 회고 (1) | 2026.02.05 |
| AI 홍수 시대, 프론트엔드 개발자가 Rule을 설계해야 하는 이유 (0) | 2026.01.27 |
| Chrome DevTools MCP 써보기 (0) | 2025.11.29 |