AI 홍수 시대, 프론트엔드 개발자가 Rule을 설계해야 하는 이유

AI를 '도구'가 아니라 '팀원'으로 만드는 방법

 

AI는 왜 이렇게 내 말귀를 못알아듣지?

최근 프론트엔드 개발에서 AI는 더 이상 선택지가 아니다.

코드 생성, 리팩토링, 구조 제안까지... 이미 개발 흐름 깊숙이 들어와있다.

 

 

하지만, 막상 실무에서는 이런 생각이 든다.

 

"AI가 있는데 왜 아직도 이렇게 일이 느리지?"

"분명 같은 말을 했는데, 왜 매번 결과가 다르지?"

.

.

.

"대체 왜 이렇게 말을 못 알아듣지?"

 

이 글은 바로 이 질문에서 출발했다.

 

AI를 단순한 코드 복사기가 아니라,

우리 팀의 방식으로 일하는 하나의 팀원처럼 만드려면 어떻게 해야할까?

 

주니어 프론트엔드 개발자인 본인은 이래저래 시행착오를 겪으며

팀 레포지토리에 룰 시스템을 세팅했다.

 

그 경험에서 얻은 인사이트를 이 글에서 나눠보고자 한다.

 

---

AI: 아니 안가르쳐줬는데 어떻게 잘 짜요!!!

 

실무에서 AI와 함께 일할 때 자주 마주치는 장면이 있다.

기획서는 방금 바뀌었고
기존 코드에는 레거시 패턴이 섞여 있고
아... 이거 비슷한 거 저번에 짰었는데

 

이런 경우에, 사람은 어떻게 할까?

머릿속에 있는, 그리고 팀에서 일하며 얻은

"맥락"을 바로 떠올릴 것이다.

 

그리고, AI에게 시킨다

 

"이 작업 해줘"

 

AI는 대게 이런 답변을 줄 것이다

 

팀에서 쓰지 않는 패턴으로 이번에만 쓰고 버릴 것 같은 패턴을 제안하거나
프로젝트 구조를 잘못 추측하거나
그럴싸~하지만 지금 맥락에서 벗어난 코드를 주거나

 

경경수 개발만화. 5화.AI 코딩 (네이버 웹툰)

 

그런데, 사실 AI는 바보여서 그런게 아니었다.

우리가 AI에게 충분한 맥락을 주지 않았기 때문이다.

(AI: 억울;;)

 

---

그럼 AI를 어떻게 가르치지?

 

 

웹 개발을 한창 공부하던 대학생 시절 봤던 짤이다

이 짤만 보면 저항없이 웃음

 

사람은 '코딩 잘하는 사람을 커비처럼 삼켜서' 코딩을 잘할 순 없지만,

AI는 가능하다

 

AI Rule을 먹여서 맥락을 단시간에 전달할 수 있다

커비처럼 와아앙

 

하지만 대충 짜서는... 안된다.

 

아주머니: "가능한 빨간색이 보이게~ 한 번 해봐요~"
김종민씨: "가능한!"
아주머니: "누가 말 따라해라 했나!!!!!!(극대노)"

 

이 짤도 참 유명한데...

잘못 설계한 AI룰을 먹은 AI,

그리고 이걸 보는 답답한 개발자로 대입해보면 어떨까

 

"You are what you eat"

이런 말도 있지 않는가...

잘못 짠 AI 룰은 오히려 걸림돌이 될 것이다

 

---

AI 룰도 하나의 제품이다

AI룰은 단순히 코드를 생성하는 용도일까?
아니면 적당히 결과물이 좋았던 프롬프트를 뭉쳐놓으면 될까?

 

처음엔 단순히

"내가 대충 지시해서 그랬나"라고 생각했다

 

설명을 길게 써보고, 예시도 붙여보고, 구구절절 나열도 해봤다

 

하지만 매번 긴 프롬프트를 넣는 것도 리소스 소모가 컸고

결과는 여전히 세션마다 일관되지 않았다

 

그렇다면, AI가 일할 환경 기반 자체(AI 룰)를 구축해줘야겠구나!

 

프론트엔드에서는 UI 구조와 팀 패턴이 곧 사용자 경험으로 이어지기 때문에,
AI가 일관된 방식으로 구현하도록 Rule 기반의 실행 환경을 설계하는 것이 중요하다.

 

AI 룰도 하나의 제품으로 생각하자.

 

이 제품의 기능은,

"기획과 구현 사이 간극을 줄여주는 자동화 레이어"

 

이 제품이 우리 팀의 방식으로 일할 수 있도록

명확하게, 구체적으로 작성하고, 실제 사례를 반영하자!

 

---

Rule도 코드처럼 설계한다

 

Rule을 크게 두 파트로 나눴다.

AI가 판단해야 할 기준 + 실행 가이드

 

 

프로젝트 세계관을 먼저 알려준다

"이 프로젝트는 어떤 곳인가?"를 설명하는 문서로부터 시작한다.

 

이 프로덕트는 어떤 특성을 가지고 있는지?
아키텍처는 전반적으로 어떤지?
절대적으로 따라야 하는 기준과 규칙이 있는지?

 

이런 정보들을 설명해서 AI가 '맥락'을 가지게 한다.

우리가 머릿속에 있는 맥락을 AI에게 그대로 넣는 것이다.

 

작업이 들어오면 작업 유형부터 분기한다.

'이 작업 좀 해줘'

개발자의 요청을 받았을 때는 AI는 어떻게 할까?

먼저 '작업 유형'을 파악한다.

 

이 작업은?

- 레거시 개선인가?
- 신규 기능 구현인가?

 

이에 따라 AI가 들어갈  경로를 정확히 나눈다

1. 레거시 개선의 안전한 경로
2. 신규 기능 구현 경로

 

 

각 폴더는 AI의 관점을 정의한다

1. 새 기능

이 폴더에서 AI는 '처음부터 제대로 만드는 개발자'의 관점으로 작업한다

- 구현 순서를 강제하는 가이드

- 우리 팀의 훅, ui, 로깅 패턴 가이드 (굉장히 디테일하게)

 

2. 레거시 개선

이 폴더에서 AI는 '함부로 고치지 않는 리팩토링 개발자'의 관점으로 작업한다

- 레거시를 신규 구조로 맵핑하는 가이드

- 안전한 변환 순서 체크리스트

- Clean Code 기준 적용 (클린 코드 스터디할 때마다 업데이트 껴넣기)

 

AI에게 정답을 보여준다

AI는 규칙보다 '기준 예시'를 더 신뢰한다

각 팀원으로부터 '기존 코드 중 정답이 될만한 것'을 수집한다

 

기획자로부터 '지표로 삼을만큼 가장 잘 작성됐다 싶은 기획서'를,

프론트엔드 개발자 동료로부터 '우리가 정의한 구조를 잘 따른 기능'을 수집했다.

그리고, 내가 개발한 기능 중에서도 Best case를 하나 골랐다.

이를 AI 룰에 반영했다.

 

---

AI마다 역할이 다르다

같은 Rule이라도 AI 마다 잘하는 역할이 다르다

 

Cursor

코드를 직접 고치는 실행자 성향

지금 이 파일을 어떻게 고칠지 바로 실행한다

코딩 중 항상 적용
짧고 강제적인 규칙
"이렇게 해라" "이건 하지 마라"

 

Claude Code

맥락을 이해하고 정리하는 파트너

이 프로젝트가 어떤 곳인지 먼저 이해한다

기획, 구조, 의도 중심
맥락과 판단 기준 설명
"왜 이렇게 하는지"를 알려줌

 

---

그래서...진짜 됐을까?

한 파일에 모든 로직과 ui가 들어있는 레거시 파일을 제시하며

"이 파일 리팩토링 해줘"라고 입력했다.

 

AI: 리팩토링을 위해 먼저 프로젝트의 마이그레이션 가이드와 컴포넌트 패턴을 확인하겠습니다.

라는 답변이 나왔다.

(시작부터 전보다 훨씬 나아졌어!!!)

 

 

구조 분리 작업이 수 분 내에 완료되었고
기존 동작을 유지한 채

팀 패턴에 맞는 형태로 마이그레이션할 수 있었다.

(와! 리팩토링 3분 카레보다 짧다!)

 

사람이 하던 연결 작업
구조 파악
반복적인 변환

이런 것들을 AI에게 안전하게 넘길 수 있다니

생산성을 늘릴 수 있는 '가능성!!'이 보였다

 

요즘 나는 작업할 때 이렇게 활용하고 있다.

 

메인 작업은 가운데 모니터에 두고 내가 직접 손대고,

worktree를 따서 오른쪽 모니터에 ide를 하나 더 띄운다.

그리고, 거기에서 마이그레이션을 주구장창 돌린다.

병렬작업으로 업무 2배로 쳐내기~~

 

아직 디벨롭 할 부분이 많지만 AI 룰이 아예 없던 시기에 비하면

정말 장족의 발전이다

 

요즘은 일반 상시 업무를 쳐낼 때도

AI가 좀 더 '내가 시키려고 했던 의도에 잘 맞게' 응답을 내놔서 좋다

 

맥락은 짱이야!

 

---

AI를 쓰려면, 사람이 먼저 명확해져야 한다

 

그래서 여기에서 얻은 교훈은 이렇다

AI는 생각을 대신하지 않는다.
우리가 정리한 맥락을 연결해줄 뿐이다.

 

우리가 해야할 일은 다음과 같다

1. 일을 더 잘게 쪼갠다

- micro step으로 지시

 

2. 사람의 연결 작업을 AI에게 넘긴다

- 티켓 생성, 브랜치 전환, 구조 파악

 

3. 판단이 필요한 말을 없앤다

- "약간" "대충" "적당히" 같은 애매한 말

 

이때, 우리를 도와줄 수 있는 도구와 함께하면 더 좋다

MCP는 AI에게 맥락을 연결해주는 도구이다

 

Notion, Figma, Jira, Chrome DevTools를 써서

기획, UI, 업무 흐름, 개발 현황을 더 촘촘하고 빠르게 팔로업할 수 있다.

(이건 또 다른 글에서 자세히 다루겠다)

 

---

해당 Rule 시스템은 팀 내부 공유 이후,

챕터 차원의 공통 개발 Rule로 확장 논의가 진행되었다.

 

AI 홍수 시대에 살아남는 개발자는 이런 사람이라고 생각한다.

기준을 세우고
맥락을 정의하고
팀의 방식을 구조화할 수 있는 사람

 

이번 AI 룰 세팅으로 시야를 더 넓힐 수 있었다.

더 디벨롭해서 후속 글로 찾아오겠음

후속 글에서는 MCP 기반 업무 병렬화 경험을 정리할 예정입니다!

 

-> 후속 글 발행! 2026.02.13 00:07

https://developer-dreamer.tistory.com/216

MCP로 생산성 3배 올리는 법

 

---

읽어주셔서 감사합니다!

 

이 글을 재밌게 읽으셨다면!

작성자인 FE 개발자 심수연에게도 많은 관심 부탁드립니당

https://www.linkedin.com/in/shimsuyeon/

 

 

작성 시작: 2025.01.27. 22:04

작성 종료: 2025.01.27. 23:53