들어가며
회사에서 AI 챔피언십이라는 사내 대회를 열었다. AWS의 AI 에이전트 Kiro를 활용해 아이디어를 직접 기획·구현하는 프로그램인데, 나는 Track B(신규 서비스 개발)에 프로덕트 디자이너와 2인 팀으로 출전했다. 기획부터 개발, 배포까지 12일이 걸렸고, 1차 심사에서 17팀 중 1등으로 통과한 뒤 최종 발표에서 2등으로 마무리하며 상금 200만원을 받았다.
이 글은 수상 자랑이 아니다. 12일 동안 직군의 경계를 넘어보면서 오히려 내 본업의 가치를 더 선명하게 깨달은 이야기를 써보려 한다. (신규 서비스 관련 대회이다 보니, 어떤 서비스를 만들었는지에 대해서는 다루지 않는다.)
직무의 경계를 허물기로 했다
2인 팀이라는 제약
보통 해커톤이면 기획자가 아이디어 내고, 디자이너가 시안 그리고, 개발자가 만든다. 근데 우리는 기획자도 없고 백엔드도 없는 2인 팀이었다. 처음엔 그래도 역할을 나눠보려 했다. 내가 전반적인 개발을 맡고, 디자이너가 기획과 디자인에 집중하는 형태였는데, 며칠 지나지 않아 이 구분 자체가 의미 없다는 걸 깨달았다. 12일 안에 결과물이 나와야 하는 상황에서, 잘 짜인 역할 분담보다 빠른 실행이 훨씬 중요했기 때문이다.
그래서 우리는 방향을 바꿨다. 먼저 큰 아이디어 하나를 정하고, 각자 2일 정도는 자기가 만들고 싶은 형태로 자유롭게 구현해보기로 했다. AI와 함께라면 직군의 경계를 어디까지 허물 수 있는지 직접 확인하고 싶기도 했다. 이후에 각자의 결과물을 하나로 합치는 회의를 했는데, 이게 생각보다 재밌는 작업이었다. 바이브로 만든 결과물이 예상보다 괜찮은 부분도 있었고, 예상보다 훨씬 엉망인 부분도 있었기 때문이다.
경계를 넘어보니 허들이 두 종류였다. 하나는 하면서 바로 느껴지는 것들이었다. 개발자 관점에서 기획을 하다 보니 사용자 흐름보다 구현 가능성을 먼저 생각하게 됐고, 디자인은 더 어려웠다. 다른 하나는 하고 나서야 보이는 것들이었는데, 이게 더 뼈아팠다.
내가 꽤 잘 만들었다고 생각한 UI를 디자이너가 한 번 터치하면 완전히 다른 물건이 됐고, 디자이너가 가져온 웹 서비스가 알고 보니 HTML 파일이어서 React로 마이그레이션해줘야 하는 일도 있었다. 결국 "얕고 넓게 아는 것"만으로는 전문가의 눈을 대체할 수 없다는 걸 몸으로 배웠다.
그래서 우리가 내린 결론이 "직무 구분 없이 전 과정에 참여하되, 각자 더 잘하는 영역에서 힘을 더 쓴다"였다. 경계를 없애되, 잘하는 사람이 결정권을 갖는 구조다.
넘어간 경계들
내가 실제로 한 일들을 나열하면 꽤 낯선 조합이다. 서비스의 큰 방향성부터 세부 기능까지 직접 기획했고, 사내 대회에서 제공하는 API와 데이터 스키마를 전수조사해서 "이 기능이 실제로 구현 가능한가"를 하나하나 체크했다. 구현 가능한 기능과 불가능하지만 다른 형태로 바꿀 수 있는 기능을 분리하는 작업이었는데, 이게 생각보다 중요한 단계였다.
디자인도 건드렸다. 처음엔 토스나 당근 같은 깔끔한 형태로 잡았다가, 요즘 화제가 되고 있는 DESIGN.md 방식과 디자이너의 리터치를 거치면서 완전히 다른 방향이 됐다. 거기다 Next.js에서 SQL 쿼리를 직접 짜서 24개 API 라우트를 구현하기까지 했다.
과거의 나라면 "프론트엔드 개발자가 왜 SQL을 짜고 있지?"라고 했을 것 같다. 근데 이번 경험을 통해 생각이 바뀌었다. AI 시대에 가장 빠르게 결과물을 내는 사람은 SQL 문법을 외우고 있는 사람이 아니라, 테이블 구조를 이해하고 "이 데이터로 이 UI를 만들 수 있다"를 판단할 수 있는 사람이다. 실제 쿼리는 Kiro가 짜준다. 내가 해야 할 일은 무엇을 만들어야 하는지 아는 것이었다.
디자이너도 마찬가지였다. Kiro로 코드를 작성하고, API 응답 데이터의 정합성을 검증을 혼자 해냈다. 개발자가 아닌 사람이 이걸 할 수 있었던 건, AI가 두 사람 사이에서 중간 다리 역할을 해줬기 때문이다.
디자이너와의 새로운 협업 방식
피그마를 안쓴건 처음이야
이번 프로젝트에서 가장 신선했던 건 디자이너가 피그마 시안 대신 동작하는 HTML 프로토타입을 줬다는 거다. 기존에 익숙했던 협업 방식과 비교하면 차이가 확연했다.
기존 협업:
[기존]
디자이너 → 피그마 시안 전달
개발자 → "이 간격 몇 px?" "호버 상태는?" "이 색상 코드?"
디자이너 → 답변
개발자 → 구현
디자이너 → "제가 의도한 거랑 다른데요"
(반복)[이번]
디자이너 → Kiro로 HTML 프로토타입 제작 (html-preview/ 폴더)
나 → 열어봄. 클릭해봄. 호버해봄. "아, 이렇게 동작하는 거구나."
나 → React로 재구현 (상태 관리 + API 연동 + 접근성 추가)간격이 궁금하면 HTML을 열어보면 됐고, 인터랙션이 어떻게 동작하는지 알고 싶으면 직접 클릭해보면 됐다. "제가 의도한 거랑 다른데요"라는 피드백도 사라졌다. 의도 자체가 이미 동작하는 형태로 전달됐으니까. 커뮤니케이션 비용이 체감상 80%는 줄었다.
다만 솔직히 말하면, 이 방식이 무조건 낫다고 단정하기는 어렵다. 피그마는 컴포넌트 단위 관리나 디자인 시스템 연동, 팀 단위 협업에서 HTML이 줄 수 없는 것들을 준다. 이번엔 12일짜리 해커톤이었고 2인 팀이었기 때문에 이 방식이 맞아떨어진 측면이 크다. 나조차도 일반적인 프로젝트라면 여전히 피그마가 훨씬 편하다고 생각한다. 그럼에도 "동작하는 프로토타입이 곧 스펙이다"라는 발상 자체는, 앞으로도 어떤 형태로든 써먹을 수 있겠다는 생각이 들었다.
AI를 "잘" 쓰기 위해 한 것들
바이브 코딩의 진짜 의미
요즘 "바이브 코딩"이라는 말이 돌아다닌다. AI에게 분위기를 설명하면 코드가 나온다는 건데, 이번 프로젝트를 하면서 느낀 건 그렇게 단순하지 않다는 거다.
바이브가 통하는 순간이 있다. "이 카드에 그라데이션 배경 넣어줘", "도넛 차트 만들어줘" 같은 건 진짜 5초 만에 나온다. 근데 "이 테이블에서 활성 유저 기준으로 경쟁사 앱도 쓰는 비율을 산출해줘" 같은 건? 이건 바이브가 아니라 정확한 스펙이다. 데이터 구조를 모르면 이 요청 자체를 할 수가 없다.
그래서 내가 깨달은 건 이거다. 바이브 코딩의 80%는 사전 작업이다. 나머지 20%가 실제로 "이거 만들어줘"라고 말하는 부분이다.
사전 작업이라는 것
1단계: 데이터 전수조사 (2일)
대회에서 제공한 DB에 4개 스키마, 36개 테이블이 있었다. 나는 이걸 하나하나 열어보면서 각 컬럼이 뭘 의미하는지, 이 데이터로 화면에 뭘 보여줄 수 있는지를 전부 매핑했다.
그리고 이걸 .kiro/steering/data-guide.md라는 파일에 정리해서 넣어뒀다. Kiro의 Steering이라는 기능인데, 여기에 넣어두면 이후 모든 작업에서 Kiro가 이 문서를 자동으로 참고한다. 잘못된 테이블명을 쓰면 알아서 잡아준다.
이 2일이 없었으면 이후 매번 "이 데이터 어디 있지?" 하면서 삽질했을 거다. 2일 투자해서 이후 8일을 절약한 셈이다.
2단계: 디자인 토큰 매핑 (반나절)
사내 디자인 시스템의 실측 스펙을 분석해서 Tailwind config에 text-primary, signal-success, brand-primary 같은 커스텀 토큰을 50개 넘게 매핑했다.
이건 내가 직접 한 작업은 아니었지만, 한 번 세팅해두면 효과가 컸다. 색상 코드를 기억할 필요가 없고, 다크모드 대응도 토큰 레벨에서 한 번에 해결된다. AI에게 스타일을 지시할 때도 "brand-primary 색상으로 해줘" 한 마디면 충분했다.
3단계: 컴포넌트 설계 (1일)
오후 9:01
40개 넘는 컴포넌트의 계층 구조, props, 상태 흐름을 구현 전에 먼저 설계했다. 어떤 컴포넌트가 어떤 Context에서 데이터를 가져오고, 부모에서 어떤 props를 내려받는지를 코드 한 줄 없이 문서로 먼저 정리한 것이다. 이걸 Kiro의 Specs에 넣어두면 구현 단계에서 Kiro가 설계서를 그대로 따라간다. 즉흥적으로 만들다 보면 컴포넌트마다 구조가 달라지고, 나중에 합치는 과정에서 무너지는데, 이 단계가 그걸 막아줬다.
이 3.5일의 사전 작업이 이후 5일간의 생산성을 완전히 바꿔놨다. Day 7부터는 "UserActivityChart 만들어줘" 한 마디면, Kiro가 data-guide에서 맞는 테이블을 찾고, 디자인 토큰으로 스타일을 입히고, Specs에 정의된 대로 props를 구성한 컴포넌트를 내놨다. 내가 매번 컨텍스트를 설명할 필요가 없었다. 시스템이 이미 알고 있었기 때문이다.
Kiro의 에이전트 기능
단순히 "코드 짜줘"가 아니라, 프로젝트 레벨의 규칙을 세팅할 수 있다는 게 Kiro의 핵심이었다.
Steering은 "이 프로젝트에서는 이렇게 해"라는 규칙이다. 데이터 가이드, 디자인 QA 절차, Git 규칙 같은 걸 넣어두면 매번 말 안 해도 알아서 따른다. Hooks는 "이 상황에서는 자동으로 이거 해"다. 파일 수정하면 테이블명 검증이 자동으로 돌아가고, push 전에 pull을 강제한다. Specs는 "이 기능은 이 순서로 만들어"다. 요구사항 → 설계 → 태스크를 구조화해서 단계적으로 구현한다.
사람이 까먹을 수 있는 걸 시스템이 잡아주는 구조다. 12일간 한 번도 잘못된 테이블명으로 API를 배포한 적이 없다. 이건 내 기억력이 좋아서가 아니라, 시스템이 잡아줬기 때문이다.
고민과 해결의 기록
실데이터 VS 목업
데이터 전수조사를 끝냈는데, 기획한 UI 컴포넌트의 60%만 실데이터로 구현 가능했다. 나머지 40%는 데이터가 없었다.
목업으로 채우고 "실제로는 이렇게 될 겁니다" 할 수도 있었다. 근데 우리는 외부 API를 추가 도입해서 100% 실데이터로 만드는 쪽을 골랐다. 이유는 단순하다. 시연할 때 브랜드를 바꿨는데 숫자가 진짜로 바뀌는 것과, 항상 같은 숫자가 나오는 것은 임팩트가 다르기 때문이다.
결과적으로 구현 가능성을 60% -> 90%로 끌어올렸고, 이게 1차 심사에서 "구현 완성도 9점"을 받은 핵심 이유였다고 생각한다.
하드코딩
그래도 10% 정도는 하드코딩으로 남겼다. 데이터 양이 너무 많아서 쿼리 응답이 지나치게 오래 걸리는 부분이었는데, 실제 서비스였다면 인덱싱이나 쿼리 최적화로 해결했겠지만 해커톤 시연 발표라는 특성상 현실적인 타협이 필요했다. 실제 데이터를 기반으로 하되, 쿼리는 직접 하지 않는 방식으로 구성했다.
아쉬움이 없는 건 아니었다. 백엔드 경험이 있는 사람이 있었다면 쿼리 레벨에서 해결했을 문제였고, 나는 그 경험도 시간도 부족했다. 다만 이번에 Next.js로 DB를 직접 쿼리해본 건 처음이었는데, SSR이나 Server Action을 통해 API를 호출하는 건 익숙했어도 실제로 SQL을 짜서 데이터를 꺼내보는 경험은 달랐다. 알고 있다고 생각했던 것과 직접 해본 것 사이의 거리를 실감한 부분이기도 했다.
마무리
AI가 개발을 쉽게 만들었다고? 맞다. 근데 "쉬워진 만큼 더 많은 걸 할 수 있게 됐다"가 더 정확한 표현이다. 예전에는 컴포넌트 하나 만드는 데 반나절이었으면, 지금은 그 시간에 20개도 만든다. 대신 그 20개를 "뭘로 채울지"를 결정하는 건 여전히 내 몫이다.
이번 12일 동안 경계를 넘어보면서 오히려 확신이 생긴 게 있다. 직군의 경계는 AI 덕분에 생각보다 쉽게 허물렸지만, 그 경계를 넘을 때마다 내가 기댄 건 결국 프론트엔드 개발자로서 쌓아온 것들이었다. 컴포넌트 계층을 설계할 수 있었기 때문에 Kiro에게 좋은 컨텍스트를 줄 수 있었고, 데이터 구조를 읽을 수 있었기 때문에 기획이 가능했고, API 아키텍처를 그릴 수 있었기 때문에 라우트들을 혼자 만들 수 있었다. 경계를 허무는 경험이 "더 넓어져야겠다"가 아니라 "더 깊어져야겠다"는 생각을 줬다.
상금은 맛있는 거 먹는 데 쓸 예정이다.
