‘피그마와 정책서’ 대신 PR이 날아왔다 : AI와 가장 먼저 맞닿은 FE팀의 이야기

비개발자가 AI로 8,900줄 PR을 올렸다. 피그마도 정책서도 없이. 고위드 FE팀이 이 상황을 시스템으로 풀어낸 과정과 두 번의 시행착오를 공유합니다.

Mar 19, 2026

‘피그마와 정책서’ 대신 PR이 날아왔다
: AI와 가장 먼저 맞닿은 FE팀의 이야기

Contents

8,900줄의 코드가 날아오다 첫 번째 시도: "역할" 기반 시스템 두 번째 시도: 역할에 맞는 "권한" 체계 지금, 그리고 앞으로의 우리

안녕하세요! 고위드에서 지출관리 서비스를 개발하고 있는 Frontend Engineer(FE) 이수정입니다.

최근 고위드에서는 AI를 이용해서 다양한 시도들을 해보고 있는데요. 같은 팀 디자이너 선주님의 AI 디자인 경험기에 이어서, 기획 > 디자인 > 개발 단계를 단축시킬 AI 워크플로우에 대해 고민했던 FE팀의 이야기를 공유드려보려고 합니다.

8,900줄의 코드가 날아오다

Claude Opus 4.5가 일하는 방식을 완전히 뒤집을 거라던 어느 날, 저희 사무실에서 가끔씩 들려왔던 말이 있었습니다.

우스갯소리인 줄로만 알았던 잠깐 사이에 Pull Request(PR)가 연달아 올라왔습니다. 음? 변경사항이.. 1500줄.. 4400줄..? 8900줄..?!

익숙하지 않은 분들을 위해 설명을 덧붙이자면, 그동안 개발자들 사이에서 리뷰를 위해 권장되는 PR의 크기는 500줄 내외였어요. 상황에 따라 다르지만 그 이상은 한번에 이해하기 힘든 범위라고 봤거든요.

모두 Claude Code로 작성된 코드였고, 정책서도 명세서도 피그마 시안도 없었어요. 함께 전달된 건 이것이 무엇을 위한 작업이라는 간단한 설명과, 코드뿐이었습니다. 이맘때는 FE팀에서도 AI를 어떻게 하면 더 잘 써볼 수 있을지에 대한 고민을 하던 차였어요. 그래서 몇 가지 규칙들을 설정해놓긴 했지만, 비개발자가 코드를 작성했을 때 원하는 수준으로 뽑힐 수 있는 만큼은 아니었죠. FE가 어느 정도의 검토를 하면서 진행한다는 가정 하의 규칙이었어요. 이렇게 아직 개발자의 자동화도 완전하지 않았던 단계에서, 이보다 먼저 비개발자의 코드 기여가 시작되어 버린 거예요.

그래도 일단 8,900줄 PR을 열어봤습니다. 일부는 고위드의 디자인 시스템 컴포넌트를 이용하는 등 괜찮아 보이는 부분들도 있었어요. 그런데 문제는 다른 곳에 있었습니다. 저희가 규칙으로 삼아왔던 코드 스타일이나 클린코드 패턴이 지켜지지 않은 거였죠. DOM을 직접 조작하거나, 전체 상태 흐름을 따라가기 어렵다든지 — 유지보수하기에 꽤 난해한 패턴들도 곳곳에 숨어 있었습니다. 하지만 그렇다고 해서 피그마로 다시 만들어달라고 요청할 수도 없었어요. 원하는 퀄리티가 될 때까지 코드로 작업하셨던 시간이 있으니까요.

막을 수 있을까, 막아야 할까

"앞으로 이런 일을 막을 수 있을까?"

솔직히 처음엔 막아야 한다고 생각했습니다. 그런데 곧 이건 막을 수 없는 수순이겠다는 걸 깨달았어요. 완전한 울타리를 치려면 그걸 만드는 비용과 시간이 꽤 드는데, 리소스는 부족하고, 만들어야 할 것은 산더미였고, 해내야 하는 런칭 속도는 너무 빨랐거든요. 넘치는 일을 같이 해줄 리소스를 당장 확보하기도 어려우니, 좀 더 간단해 보였던 AI를 잘 굴릴 수 있는 체계를 만들어 보기로 했습니다.

첫 번째 시도: "역할" 기반 시스템

처음 만들어졌던 역할 기반 시스템. "안녕", "일하자", "하이" 같은 키워드를 입력하면 세션의 역할을 고를 수 있습니다.

처음 아이디어는 단순했어요. Claude에게 역할을 부여하고, 지켜야 할 규칙들을 명시해서 전문가처럼 작동하게 만들어 보는 거죠. 각자 직군에 맞는 역할을 선택하면 적합한 제약과 안내가 적용되는 방식이었어요. 예를 들어 디자이너 역할에는 스타일·텍스트 수정 같은 작업을 허용하고, 큰 작업은 원하는 방향에 대한 컴포넌트와 명세서를 만들어서 FE에 전달하도록 설정했습니다. 일정 규모 이상이면 PR을 올리라고 알려주는 시스템도 만들었어요.

제품에 녹여본 화면이 궁금하실 수도 있으니, 안정적으로 실험해볼 수 있는 공간도 제공했습니다. 서비스되고 있는 코드는 절대 수정할 수 없도록 설정된 격리 공간이었는데, 디자이너분들은 "놀이터"라고 부르시더라고요. 🫣

예상 밖의 일들

그런데 원래 하던 역할을 선택할 것이라고 생각했던 최초 방향과는 다르게, 예상 밖의 일들이 벌어지기 시작했습니다. 지출관리 서비스 개편 직후, 빠르게 변경된 정책에 대한 안내와 추가 기능 개발이 필요한 상황이 생겼어요. 급한 차에 시스템도 만들어졌겠다, PM이 FE 역할을 선택해서 직접 기능을 구현해 버린 거예요. 😖 검토해보니 놓친 케이스들이 꽤 보였고, PM, 디자이너와 얘기하면서 하나씩 채워갔어요. 결과적으로 빠르긴 했지만 정책, UI/UX, 코드 모두에 대한 검토 부담이 FE에게 집중되는 구조가 돼버렸죠.

첫 번째 교훈: 맥락을 잃으면 통제도 무너진다

더 근본적인 문제도 있었습니다. Claude Code에는 대화가 길어지면 이전 맥락을 압축하는 기능이 있는데, 이 과정에서 역할 설정 자체가 잊혀졌어요. PM으로 시작했지만 컨텍스트가 압축되면서 제약도 함께 사라져 버린 겁니다. 결국 PM은 의도하지 않았는데도 제한 없이 작업이 진행돼버렸어요. AI에게 규칙을 아무리 잘 알려줘도, 기억을 잃어버리면 소용이 없었습니다.

AI는 규칙을 따르는 존재가 아니라, 맥락을 잃으면 통제가 무너지는 존재라는, 첫 번째 교훈이었어요.

여러 번의 비개발자 코드 이어받기 경험들을 하면서 한 가지 더 깨달은 게 있었는데요. 사용자가 모르거나 신경 쓰지 않는 부분은 AI도 굳이 신경 쓰지 않는다는 거였어요. 성공 케이스의 기능 동작에 집중하다 보니 오류 상황, 엣지 케이스에서의 화면, 상태 관리 방식 같은 개발자가 챙기던 영역엔 소홀했고, 그 빈틈을 메우기는 쉽지 않았습니다. 이렇게 다른 직군이 FE 역할을 쓰기엔 아직 코드에 개발자의 판단이 필요한 영역이 너무 많았고, 결국 FE팀부터 제대로 쓸 수 있어야 다른 직군에도 안정적으로 쓸 수 있겠다는 결론에 이르게 되었습니다.

두 번째 시도: 역할에 맞는 "권한" 체계

버전2에서는 접근을 바꿨습니다. 역할이라는 시스템은 남았지만, 권한이라는 체계가 생겼어요. FE가 잘 동작한다고 판단한 범위에 대해서만 열어주는 방향으로 변경했죠.

그렇게 역할별 등급 시스템이 도입됐어요. 사용자의 역할은 git 기반으로 자동 감지해서 FE는 레벨3, BE는 레벨2, PM·디자이너는 레벨1로 배정되도록 했습니다. 하위 역할로 선택은 가능하지만 상위로는 올라갈 수 없도록 권한이 설계되었고, FE에서 검증된 스킬만 단계적으로 개방해보는 방식으로 운영했어요.

두 번째 교훈: AX는 DX 위에서 결정된다

쏟아지는 PR 속에서 빠르게 배포할 수 있는 작업을 찾기 위해서, 운영 인프라도 함께 보강됐습니다. 제목만으로는 프로토타입인지 운영 반영 요청인지 알 수 없어 라벨 시스템을 도입하고, PR 스킬을 만들어서 한눈에 분류할 수 있게 했어요. 일일이 체크아웃해서 확인해야 했던 PR도, 브랜치별 배포 파이프라인을 구축해서 프리뷰와 빌드 확인이 바로 가능하도록, 리뷰의 장벽 자체를 낮출 수 있도록 지속적으로 다듬었어요.

AI 생산성(AX)은 잘 구성된 DX 위에서 결정된다는 두 번째 교훈도 얻었습니다.

작은 성공, 그리고 격리의 한계

이렇게 안착된 버전2에서도 희비가 갈렸는데요. 먼저 좋았던 부분은 의도한 범위 안에서 비개발자의 기여가 안정적으로 이루어지기 시작했다는 것이었어요. 개발자에게 요청하기 사소하고 애매했던 작업들을 디자이너가 직접 수정해서 PR을 올리기 시작했거든요.

작은 단위로 요청이 끊어서 오다 보니, 요청이 올라온 지 20분 만에 배포되는 작업도 있었을 만큼 간단한 개선이 빠르게 이뤄지기 시작했습니다. 격리 실험 공간도 예상 외로 잘 활용되었어요. 특히 같은 팀 디자이너 선주님이 실제 데이터로 작업하면서, 피그마에서는 보이지 않던 UX 문제를 발견하시는 일이 생겼거든요. 브라우저 너비에 따른 테이블 시인성 문제라든가, 조회 기간과 다운로드 기간의 불일치로 인한 혼동 같은 것들이요. (이 경험은 선주님의 "피그마 없이 3개월, 디자이너가 AI로 디자인하며 배운 것"이라는 글을 통해 좀 더 자세히 확인하실 수 있어요.)

하지만 격리 실험 공간의 명확한 단점도 존재했습니다. 기존 서비스의 비즈니스 로직에 대한 변경이 제한되어 있으니, 일부 기능만 변경해보는 실험이 거의 불가능했죠. "이 화면이랑 똑같이 만들어줘"라는 요청에 AI가 기존 컴포넌트를 가져오지 않고 모양만 비슷하게 새로 만들어버리거나, "불가능하니 FE에게 요청하세요"라고 해버리는 상황이 생겼어요. 살짝만 수정하려던 건데 전체를 복사해 오기 위한 핑퐁을 거치는, 배보다 배꼽이 더 큰 일도 생긴 거죠.

그렇게 의도된 변경과 의도되지 않은 변경이 뒤섞이면서, FE가 살릴 것과 버릴 것을 파악하고 분류하는 "2차 정리 작업"이라는 새로운 프로세스가 생기기도 했습니다. AI로 작업할 수 있는 범위 설정에 대한 적절한 균형이 필요하다고 느낀 지점이었어요.

지금, 그리고 앞으로의 우리

이렇듯 저희 팀은 AI Driven 작업의 장점을 최대화하기 위해서, 계속해서 여러 실험들을 진행하고 있습니다.

디자인 팀: Let's Design 워크플로우

디자인 팀에서는 복잡한 플로우 작업엔 지금의 시스템이 맞지 않다는 결론에 이르렀어요. 아직 정리되지 않은 상태의 UI를 코드로 뽑아낸 다음 고도화하는 건 생각보다 오래 걸리는 일이었거든요.

그래서 캔버스에서 먼저 일정 수준의 플로우를 만든 다음 팀원들과 UX 논의를 거치고, 코드로 옮기는 Let's Design이라는 워크플로우를 만들어서 문제를 풀어보려고 하고 있어요.

FE 팀: 운영 전환 기준 만들기

FE 팀에서는 코드 격리 범위를 줄이면서도, 서비스가 받는 영향도는 낮추고, 분해하기 쉬운 코드를 이어받을 방안을 찾고 있습니다. AI로 코드를 이어받았을 때 개발자가 검증하는 단계가 꽤나 복잡했거든요.

그래서 운영에 바로 적용 가능한 코드인지 판단할 기준을 만들고, 점수를 부여해서 운영으로 전환하는 과정을 체계화해보려고 하고 있어요. 또 유저 시나리오 기반으로 디자인 의도를 기록하는 등 여러 가지 방법으로 실험을 진행하고 있습니다.

쓸 곳과 쓰지 않을 곳

이런 워크플로우가 맞는 방법일지는 아직 모르겠지만, 조금 더 빠르게 더 좋은 제품을 만들기 위해 시도하고 고쳐나간다는 방향에는 변함이 없는 것 같아요. 사실 이 글을 마무리하는 오늘도, AI로 작성했던 코드에서 발견하지 못했던 버그가 발생했고, "AI 없이 하는 게 더 빠르고 안전했을지도"라는 대화가 오가기도 했어요.

AI를 잘 쓰는 것만큼 어디에선 쓰지 않을지 판단하는 것, 그리고 그 판단이 틀렸을 때 빠르게 알아차릴 수 있는 장치를 만드는 것이 더 중요하다는 것을 여실히 배우고 있습니다.

AI로 더 빠르게 필요한 것을 만들 수 있다는 기대와, 조만간 대체될 것이라는 두려움이 공존하는 시대에서 제가 설정한 목표가 있다면, "언제 밀어붙이고, 언제 멈출지 판단할 줄 아는 사람이 되는 것"이에요. 아직 그곳에 도달하진 못했지만, 균형점을 맞춰가며 점점 가까워지고 있다고 생각합니다.

AI를 팀 워크플로우에 도입해 보려는 분들이나, 비개발자의 코드 기여에 관심 있는 분들께 이 과정이 작게나마 도움이 되었으면 좋겠어요. 성장하는 팀과 함께 새로워질 지출관리 서비스에도 앞으로 많은 기대 부탁드립니다 😊