AI 시대에서 프론트엔드 개발자는 어떻게 일해야할까? (mdc, mcp 사용 후기)

전 회사 동료분들과 저녁 약속을 하는데 이런 얘기를 들었습니다.

"요즘에 개발 일은 안 하고 claude code rules 파일만 작성해요."

그러면서 개발자가 아닌 것 같다는 푸념을 들었는데..

저는 rule 파일 없이 LLM을 쓰고 있었는데, 사용해 보면 어떨까 싶어서 직접 사용해 봤습니다.

그리고 마지막에 앞으로 프론트엔드 개발자가 AI 시대에서 어떻게 일해야 하는지 든 생각을 정리해 볼게요.

 

저는 Cursor를 사용하고 있어서 Cursor 기준으로 설명해 보겠습니다.

 

mdc 파일이란?

mdc 파일이란 cursor의 AI가 응답을 만들 때 참고할 수 있는 가이드라인 혹은 규칙을 정리한 파일입니다. 프로젝트 내부에 mdc 파일을 생성하면 AI 가 이를 참조하여 대답해 줍니다.

 

mdc 파일 작성 방법

직접 작성하는 방법도 있겠지만 저는 AI를 활용했습니다.

1. 개발 스펙 문서 정리
   PM, 디자이너로부터 이번 프로젝트의 목표와 필요한 기능을 전달받습니다.
   이를 토대로 개발 기능을 정리합니다.
   기획 혹은 피그마 문서에 적혀있지 않은 숨겨진 요구 사항들도 잘 정리합니다. → 이 부분이 작성하는데 많은 시간이 소요됩니다. (ex: 컴포넌트 설계, 기존 기능과 합쳐졌을 때 문제가 없는지, 더 쉬운 기술적인 대안이 있는지, 기획 문서에는 없었지만 추가로 필요한 기능이 무엇인지 등)
2. Cursor에게 해당 노션 문서의 URL을 전달하며 mdc 파일로 정리해 달라고 요청합니다. 아래 좋은 mdc 파일 작성 방법을 참고해서 만들어 달라고 하는 것도 좋은 방법입니다.
   Cursor에 Notion mcp를 연결하면 문서 내용을 복사 붙여넣기 하는 것이 아니라 URL만 전달하면 Cursor가 알아서 잘 가져옵니다. (저는 복사 붙여넣기보다는 이 방법이 더 편하게 느껴졌습니다. mcp 연결 방법은 아래에 정리했습니다.)

제가 정리한 개발 스펙 문서와 mdc 파일은 비밀이라 여기에 첨부하진 않았습니다.

 

좋은 mdc 파일 작성 방법

공식 문서에 따르면 아래와 같이 작성하는 게 좋다고 합니다.

이와 더불어 영어로 작성하는 것이 더 좋다는 얘기를 들어서 (한국어를 영어로 번역하는 과정에서 생기는 문제가 있을 수도 있겠죠?) 저는 영어로 작성하였습니다.

Good rules are focused, actionable, and scoped.

• Keep rules under 500 lines
• Split large rules into multiple, composable rules
• Provide concrete examples or referenced files
• Avoid vague guidance. Write rules like clear internal docs
• Reuse rules when repeating prompts in chat

 

mdc 폴더 구조

폴더 구조는 공식 문서대로 생성하였습니다.

.cursor/rules 안에 생성하면 됩니다.

프로젝트 전체에 적용되야 하는 파일은 rules 하위에

feature에 해당하는 파일은 feature 폴더 안에 일감 번호를 함께 적었습니다.

 

mcp 연결 방법

Cursor에 Notion mcp를 설치하면 cursor가 public 하게 접근이 불가능한 notion, figma, sentry 등에 접근이 가능해집니다. (설치 가능한 mcp 목록)

특히나 figma나 sentry는 mcp를 연결해서 사용하는 게 더 편했습니다.

notion은 문서 내용을 제가 직접 복사, 붙여넣기 하는 것과 비슷할 텐데

figma와 sentry는 모든 내용을 복사, 붙여넣기 하기가 힘드니까요.

 

Github Readme 반영

그리고 작성한 mdc 파일은 github repository README.md에도 반영하여

다른 개발자분들이 코드를 파악하기 용이하게 하였습니다.

 

써보니 어땠나

제가 만든 서비스는 SEO가 필요 없는 프로젝트인데요,

LLM과 대화할 때 SEO 최적화가 필요 없다는 것을 얘기해주지 않았는데도

mdc 파일을 참고하여 더 좋은 대답을 해주는 것을 볼 수 있습니다.

아쉬웠던 점은 노션의 스크린샷 이미지(ex: flow chart)는 못가져오는 것 같습니다.

그래서 스크린샷 이미지를 가져와서 이러이러한 내용으로 mdc 파일에 작성해 달라고 추가로 해줘야 했습니다.

 

번외: 딸깍으로 개발이 가능한가

실제로 mcp 이용하여 프론트엔드를 구현해 보니 굉장히 잘 만들어 줍니다.

위는 PRD에서 보여주고 있는 화면인데요

notion 개발 스펙 문서와 figma를 바탕으로 AI가 만들어진 UI 화면입니다. 완벽하진 않지만 초안으로 잡고 개발 시작하기에는 괜찮습니다. 덕분에 AI를 사용하지 않았을 때와 비교하면 개발 속도가 1.5~2배는 빨라졌다고 느꼈습니다.

 

AI의 결과물이 더 좋게 하는 한 가지 팁이라면

전체를 다 해달라고 요청하기보다는

섹션별로 나눠서 요청하면 좀 더 잘합니다.

복잡한 기능일수록 나눠서 여러번 물어보는 것을 추천드립니다.

 

그렇다면 AI 시대에서 앞으로 개발자는 어떻게 일해야 할까요?

저는 문서 작성이 더 중요해질 거라는 생각이 들었습니다.

특히, AI가 잘 이해할 수 있는 방향으로요.

 

1. 기획 문서
   기획 문서에서는 프로젝트의 목적과 기능을 정리합니다.
   ex: 용어 통일 / 구두 혹은 슬랙으로 이야기 한 내용도 전부 기록 / 긴 서술문보다 목차, 표, 리스트로 정리하기 / 이번 feature에 배포되지 않는 기능은 따로 기록 / 요구 사항은 문장이 아니라 원자 단위로 쪼개기 / 정책, 규칙을 별도 영역으로 빼서 숨은 요구 사항 알 수 있도록 하기
2. 디자인 문서
   mcp를 활용해서 figma를 확인할 때 AI가 이해하기 쉽도록 정리합니다.
   ex: 페이지 별로 디자인 나누기 / draft와 final 구별하여 정리해 두기 / 프레임, 레이어 이름을 일반적인 이름으로 쓰기 / variant 속성으로 표준화하기(sm, md, lg) / Spec Notes로 정책 기재
3. 개발 문서
   기획과 디자인 문서 내용을 개발 요구 사항으로 잘 변환하고
   숨은 요구 사항을 정리합니다.
   ex: 기존 컴포넌트를 사용할 경우 파일 경로 기재 / 어떤 상태를 사용할 건지 정하고 근거 적기 / 복잡한 로직은 flow chart 작성(이미지 보다 mermaid) / 사용할 외부 라이브러리 기재 / 발생할 수 있는 모든 경우의 수 작성
4. QA 문서
   잘 정리된 기획, 디자인, 개발 문서를 토대로 QA checklist를 작성합니다.

 

후기

개발을 빠르게 해야 하는 상황이라 mdc 파일은 필수로 작성하게 되더라고요.

덕분에 개발 스펙을 문서화할 수 있고, 이를 토대로 mdc 파일을 만들어 AI가 개발을 더 잘해주고, QA test case 생성까지 이어지는 게 업무의 효율이 좋아졌습니다.

 

이전과 달라진 또 다른 점은 코드를 직접 개발하는 일이 적어졌다는 거예요. 대신에 문제를 어떤 방법으로 해결할 지에 대한 설계하는 능력은 성장하는 것 같습니다.

이런 방향 속에서 코드를 개발하는 것을 까먹지 않도록 기본기를 다져야 할까요, AI가 더 일을 잘하는 방법을 찾아야 할까요? 제 생각엔 둘 다 해야 할 것 같습니다 😅

 

레퍼런스

https://cursor.com/docs/context/rules