11명의 바이브 코더와 함께 사내 플랫폼 만들어봤습니다

지난 2월, "개발자가 비개발자의 바이브 코딩을 옆에서 보며 느낀 점"이라는 글을 썼습니다. 요약하면 “비개발자도 바이브 코딩으로 화면은 금방 만들지만, 배포(인프라)와 DB 쪽에서는 거의 다 막히더라. 그래서 그 두 지점만 개발자가 잡아주면 서비스는 완성될 수 있다”는 내용이었습니다.

글을 쓰고 나서, 개발자로서 자연스럽게 다음 질문이 떠올랐습니다. “그럼 비개발자가 못 하는 부분을 아예 플랫폼이 대신해주면, 서비스는 완성될 수 있는 것 아닌가?” 처음에는 막연했습니다. 그런데 사내에서 “나도 뭐 만들어보고 싶다”는 팀원들이 한둘씩 나오기 시작했습니다. 비슷한 시점에 전자결재, 근태관리, 평가 관리처럼 그동안 따로따로 외주로 맡겨왔던 사내 시스템을 한곳에 모아보면 어떻겠냐는 이야기도 나왔고요.
 

두 흐름이 묘하게 맞아떨어졌습니다. “만들어보고 싶은 사람들”과 “한데 모아질 곳”이 같은 시기에 생긴 거죠. 그래서 아예 본격적으로 판을 짜기 시작했습니다. 오늘은 그 플랫폼을 만들면서 부딪힌 문제들, 그리고 그 과정에서 “개발자의 역할”에 대해 다시 생각하게 된 이야기를 해보려 합니다.
 

미리 요점만 콕 집어보면?

• 비개발자 한두 명을 도와주던 경험에서 출발해, 여러 사람이 동시에 바이브 코딩할 수 있는 사내 플랫폼을 직접 만들어봤습니다.
• 11명이 들어오자 한두 명일 땐 안 보이던 문제들이 줄줄이 나왔고, 공통 규칙·가드레일·모드라는 세 가지 장치로 풀어갔습니다.
• 이 과정에서 개발자의 역할이 "코드를 짜는 사람"에서 "AI가 일할 환경을 설계하는 사람"으로 옮겨가고 있다는 걸 체감했습니다.

플랫폼 세팅: 인프라부터 API까지

처음 설계할 때 목표는 단순했습니다. AI와 채팅하면서 사내 시스템을 만들 수 있는 환경. 비개발자 입장에서 “뭘 만들고 싶다”만 말하면 되는 환경을 만들고 싶었습니다. 서버, 배포, DB 접속 정보… 이런 단어가 아예 나오지 않게요.

그래서 비개발자가 손대지 않아도 되는 부분을 먼저 세팅했습니다.

• CI/CD 파이프라인: Bitbucket Pipeline → Harbor → ArgoCD로 이어지는 한 줄짜리 파이프로 구성했습니다. Git에 push만 되면 알아서 배포가 끝까지 가게 했습니다.
• DB: PostgreSQL을 기본으로 깔아두고, 프로젝트 하나를 만들면 별도 세팅 없이 바로 붙어서 쓸 수 있게 했습니다.
• 도메인·인증: 회사 SSO에 미리 붙여두었습니다. 도메인은 시스템팀과 미리 협의해, 프로젝트가 생기면 자동으로 따라붙게 했습니다.
• api-gateway: 프로젝트마다 백엔드 서버를 따로 띄우지 않고, 가운데 gateway 하나로 모았습니다. “휴가 데이터 좀 가져오고 싶은데요” 같은 요청이 오면, 여기에 API 한 줄만 꽂아두면 됩니다. 같은 데이터를 여러 프로젝트가 쓸 때도 gateway 한 곳만 손대면 끝입니다.

전체 흐름은 이렇게 그려두었습니다.

• 비개발자가 AI와 채팅한다 → 서버 안의 소스코드가 수정된다 → 서버가 가진 Git 권한으로 자동 push → pipeline이 돌면서 CI/CD로 배포 완료

여기까지 깔아두고 나니까 스스로도 꽤 괜찮은 판을 만든 것 같았습니다. 다음은 사람을 모으는 일이었죠.

동료 11명이 모이기까지

처음부터 거창한 공지를 올린 건 아니었습니다. 인사팀의 한 직원분이 “전자결재를 만들어보고 싶다”고 하셨거든요. 잠깐 티타임을 하자고 해서 만났습니다. 그분이 자리에 앉으면서 연습장을 꺼내시더라고요. 거기에는 손글씨로 “어떤 화면이 있고, 어떤 흐름으로 결재가 흘러가면 좋겠는지”가 적혀 있었습니다.

이야기를 다 듣고 제가 이렇게 말했습니다. “그럼 제가 플랫폼을 만들어드릴게요. 거기서 직접 만드시면 됩니다.” 그분이 플랫폼에 들어와 뭔가 만들기 시작하자, 옆에서 보던 분들이 하나둘씩 “저도 껴주세요” 하기 시작했습니다. 입소문이 돌면서 한 명씩 늘더라고요.

그렇게 쌓이다 보니 어느새 11명이 됐습니다. 인사팀, 영업팀, 재무팀… 부서도 다 달랐습니다. 그분들을 한 분, 두 분 만나 이야기를 나눴고, 모두 자신의 업무에서 만들고 싶은 기능이 있었습니다. 제가 만든 플랫폼에 한 명씩 들어와 각자의 메뉴를 만드는 걸 보는 게 묘하게 설렜습니다. 지난번 글에서는 한두 명 옆에 붙어 일대일로 도와주는 느낌이었다면, 이번에는 같은 판 위에서 여러 동료가 각자의 것을 올리고 있었거든요. 혼자서는 절대 못 볼 그림이었습니다.

마치 마인크래프트 서버를 직접 연 기분이었달까요. 사람들이 들어와 각자 자기 집을 짓고, 누군가는 농장을 만들고, 누군가는 큰 성을 짓고, 또 누군가는 이웃집과 길을 연결하는 모습이었습니다. 저는 그냥 서버를 열어둔 것뿐인데, 그 안에서 도시가 만들어지더라고요.

제가 만든 플랫폼에 들어와 사내 시스템 메뉴를 직접 만드시는 걸 보는 게 딱 그 기분이었습니다. 그중에서도 가장 놀란 게 하나 있었는데요. 인사팀 직원분이 회사 문화와 규정을 모아두는 메뉴를 만드셨습니다. 원래는 노션에 정리해두던 내용인데, 노션 비용이 부담돼 사내 시스템으로 옮기신 겁니다. 그런데 그 결과물이 너무 스타일이 좋았습니다. “어, 이걸 이렇게 만든다고?” 싶을 정도로요.

그런데 사람이 많아지자, 한두 명일 때는 보이지 않던 문제들이 따라왔습니다.

문제 1. AI에겐 공통의 약속이 필요하다

한두 명이 쓸 때는 보이지 않던 것이, 열 명이 쓰자 한꺼번에 드러나기 시작했습니다. 가장 컸던 문제는 AI가 컨텍스트를 읽다가 엉뚱한 정책을 끌어다 쓴다는 점이었습니다.

예를 들어, 저희 플랫폼에는 “결재”라는 개념이 두 군데에서 쓰입니다. 근태관리에도 결재가 있고, 전자결재에도 결재가 있죠. 근태관리에서는 연차 신청 같은 결재가, 전자결재에서는 품의서 같은 결재가 쓰입니다. 둘은 비슷해 보여도 정책이 다릅니다. 근태는 단계가 짧고, 전자결재는 부서장과 재무까지 거쳐야 하는 식이죠.

문제는 어느 날 누군가 전자결재 쪽을 수정하려고 했을 때였습니다. AI가 컨텍스트를 읽다가 근태관리의 결재 정책을 끌어와 작업을 진행하려고 하더라고요. 두 곳에 비슷한 단어가 흩어져 있으니, AI 입장에서는 “어, 결재가 여기에도 있네?” 하고 가져온 거죠. 결과는 당연히 이상해졌습니다. 전자결재 화면인데 근태 결재의 흐름이 섞여 있었거든요.

그래서 접근을 바꿨습니다. AI에게 코드를 더 잘 짜라고 다그칠 것이 아니라, AI가 매번 보고 따를 수 있는 문서를 따로 만들어주자는 방향이었습니다. 먼저 서버에서 읽어갈 수 있게 두 개의 프로젝트를 추가했습니다. 하나는 design-system프로젝트입니다. 버튼, 입력창, 테이블 같은 기본 컴포넌트부터 레이아웃 패턴, 색·간격 토큰까지 한곳에 모아뒀습니다. AI든 비개발자든 화면을 만들 때 무조건 이걸 먼저 참고하게 했죠. 덕분에 프로젝트마다 화면이 제각각으로 나뉘지 않고, “같은 플랫폼에서 나온 티”가 나기 시작했습니다.

다른 하나는 docs 프로젝트입니다. 우리 플랫폼의 구조, 공통 정책, 네이밍 규칙, 그리고 각 프로젝트별 기능 명세를 쌓아뒀습니다. AI가 작업을 시작할 때마다 이 문서를 먼저 읽고 들어가도록 세팅했고요. 여기서 효과가 가장 컸던 건 스키마를 문서화했을 때였습니다. 사실 그전에는 AI가 API를 만들다가 자꾸 실패했거든요. 처음에는 이유를 몰랐는데, 열어보니 단순했습니다. 컬럼명을 제대로 가져오지 못하는 문제였습니다. 프론트에서 쓰는 변수명과 DB 컬럼명이 다르다 보니, AI가 그 사이에서 헷갈리고 있었던 거죠.

그래서 스키마를 문서로 정리해줬습니다. 단순히 “users 테이블에는 이런 컬럼이 있다”가 아니라, “이 필드는 이런 의미이고, 이런 상황에 쓰며, 값은 이 타입으로 들어온다”까지 적었습니다. 그랬더니 그 이후로는 API를 만들 때 에러가 거의 나지 않더라고요. 컬럼 이름만 던져주는 것보다, 의미가 붙어 있는 스키마가 AI에게는 훨씬 좋은 재료였습니다.

반복되는 실수가 보이면 그때마다 한 줄씩 추가했습니다. “이런 건 하지 마세요” 조항이 계속 쌓여가는 거죠. 어떻게 보면 이 두 프로젝트가 우리 플랫폼의 공통 약속이 되어가고 있었습니다. 그때 이런 생각이 들었습니다. AI에게 진짜 중요한 건 똑똑함이 아니라 맥락이구나. 그러면 개발자가 할 일은 “그 맥락을 어떻게 빠짐없이, 또 안정적으로 전달할 수 있을지 설계하는 거구나”라고 말이죠.

문제 2. 품질을 유지할 방법이 필요하다

이렇게 공통 약속으로 구조는 맞춰졌는데, 그다음은 품질이었습니다.

사람이 늘어나니 코드가 빠르게 쌓이기 시작했습니다. 그러면 누군가는 전체 그림을 한 번씩 봐줘야 하는데, 저 혼자 모든 프로젝트를 다 모니터링할 수는 없었거든요. 안 보면 어느 순간 어딘가가 망가져 있었습니다. A 프로젝트에서 손댄 공통 모듈이 B 프로젝트에서 터지는 식으로요.

비개발자분들 쪽에서도 비슷한 신호가 왔습니다. “제가 뭘 잘못 건드렸는지 모르겠어요”라는 메시지가 한두 분이 아니라, 여러 곳에서 들어오기 시작했습니다. 본인 프로젝트 안에서는 잘 돌아가는데, 플랫폼 전체에서 보면 어딘가 어긋나 있었던 거죠. 그쯤 되니 머릿속에 한 줄이 또렷해졌습니다. “아, 이거 품질을 관리해야겠다. 이대로 가다가는 안 되겠다.”

여기서 한 가지 더 짚고 가야 할 게 있습니다. 저희 플랫폼은 로컬 PC가 아니라 서버 안의 코드를 직접 수정하는 구조였습니다. 비개발자가 AI와 채팅하면, 그 결과가 곧바로 서버의 소스코드에 반영되거든요. 그러다 보니 한 사람이 실수로 잘못 건드리면 그 실수가 그대로 다른 사람 작업까지 퍼질 위험이 있었습니다. 내 PC가 아니라 서버 안에서 변경이 일어나니, 어디서 뭐가 꼬인 건지 추적하기도 쉽지 않았고요.

그래서 먼저 손댄 건 작업 공간 자체였습니다. AI 대화 세션이 하나 열릴 때마다 서버 안에서 해당 프로젝트의 코드베이스를 통째로 복제했습니다. 그리고 격리된 환경에서만 작업이 이뤄지도록 설정했습니다. 한 세션에서 뭘 실험하다 꼬여도 원본은 그대로 있는 구조입니다. 비개발자분들이 “이거저거 해봐도 돼요?”라고 물을 때, 안심하고 “네, 복제본이라 마음 놓고 하세요”라고 말할 수 있게요.

그다음은 품질을 잡아주는 장치였습니다. 저는 이걸 “AI를 위한 가드레일”이라고 부르기로 했습니다. 자동차 도로 옆에 가드레일이 있으면, 사고가 안 나는 것은 아니지만 사고가 나도 도로 밖으로 떨어지지는 않잖아요. 저는 비개발자와 AI에게 그런 걸 깔아주고 싶었습니다. 마음껏 시도하되, 절대 떨어지지는 않게요.

구체적으로는 하네스 엔지니어링 개념을 대입해 E2E 테스트 모듈과 테스트 스펙을 만들었습니다. 프로젝트마다 “이 기능은 이렇게 동작해야 한다”는 스펙을 먼저 적어두고, 그걸 기반으로 E2E 테스트가 자동으로 돌게 했죠. 누가 뭘 바꾸든, 이 테스트를 통과하지 못하면 배포가 안 되도록 막았습니다.

효과는 분명했습니다. 각자가 본인이 만든 기능을 직접 테스트까지 돌려보는 흐름이 자연스럽게 생긴 겁니다. 정확하게는 AI가 자동으로 테스트를 돌려보도록 설계했습니다. TDD 개념을 살짝 끌어와본 거죠. 그러면서 기능 개발이 조금씩 더 안정적으로 굴러가기 시작했습니다.

• 비개발자분들이 마음 놓고 시도할 수 있게 됐습니다. 테스트를 통과하지 못하면 배포가 안 되니까, 망해도 티가 나지 않습니다.
• AI도 뭘 지켜야 하는지 명확해졌습니다. 스펙이 있으니, 거기에 맞춰 코드를 짰습니다.
• 저는 품질을 매번 확인하지 않아도 됐습니다. 저 대신 테스트가 봐주니까요.

저 혼자 모든 프로젝트의 품질을 챙겨야 하는 시기에서, 플랫폼이 알아서 품질을 책임지는 시기로 넘어간 것이었습니다. 이게 개발자로서 꽤 큰 변화처럼 느껴졌습니다.

문제 3. 여러 모드를 만들게 됐습니다

품질을 챙겨야 하는 상황에서 플랫폼이 알아서 품질을 책임질 수 있는 단계로 넘어가자, 사람들도 더 자유롭게 쓰기 시작했습니다. 그러면서 새로운 욕심이 생긴 건 사실 저였습니다. 제가 직접 플랫폼을 써보다가 “이런 게 있으면 좋겠다” 싶은 게 두 가지 떠올랐거든요.

가끔은 AI가 조금 더 깊게 고민해줬으면 싶을 때가 있고, 또 어떤 작업은 퇴근하고 나서 자고 일어나면 결과가 와 있길 바랐습니다. 그래서 직접 두 가지 모드를 만들었습니다. Claude Code의 “skill” 같은 개념을 가져와 플랫폼에 붙였습니다.

• Ultra Mode는 조금 오래 걸려도 깊게 생각하는 모드입니다. 급하지 않지만 중요한 작업, 구조를 건드려야 하는 작업에 씁니다. AI가 바로 코드를 짜지 않고, 먼저 계획을 세우고, 영향 범위를 따져본 뒤에 손을 댑니다. AI에게 “천천히 일해줘” 버튼을 달아둔 셈입니다.
• Night Mode는 퇴근 시간 이후에 무거운 작업을 걸어두는 모드입니다. 자고 일어나면 결과가 쌓여 있는 구조죠. 예전에 긴 빌드를 걸어두고 퇴근하던 감성, 그거 아시잖아요. 그 느낌을 AI 작업에도 살려봤습니다.

사실 제가 쓰려고 만든 건데, 풀어놓고 보니 직원분들이 더 잘 쓰시더라고요. “어제 Night Mode 걸어놨는데, 아침에 와서 보니 이거 진짜 좋네요” 같은 후기가 종종 들어왔습니다. 이 모드들을 설계하면서 재미있는 걸 느꼈습니다. 제가 하고 있는 일이 더는 “AI를 쓰는 일”이 아니더라고요. 다른 사람들이 AI를 어떻게 쓸지를 설계하는 일에 가까웠습니다.

시사점: 개발자의 일이 조금씩 이동하고 있다

한때는 개발자를 “코드를 짜는 사람"이라고 생각했습니다. 지금 보면, 그건 일의 한 부분일 뿐입니다. 요즘 제가 하는 일을 한 줄로 요약하면 이렇습니다. AI가 일할 수 있는 환경을 설계한다. 문서를 쌓고, 가드레일을 걸고, 일하는 모드를 나눠주는 일. 예전의 “시스템 설계”와 닮은 작업인데, 대상이 사람 개발자가 아니라 AI와 비개발자로 바뀐 것뿐입니다.

이 분야에는 아직 정답이 없습니다. 문서를 어떻게 구조화해야 AI가 잘 따라오는지, 가드레일은 어디까지 깔아야 적당한지, 모드는 어떻게 쪼개야 자연스러운지 계속 고민해야 합니다. 제가 만든 것도 정답은 아니고, 만들면서 매주 조금씩 바꾸고 있습니다. 그게 오히려 재미있더라고요. 답이 없으니까, 만들면 만드는 만큼 그게 답이 될 수 있으니까요.

정리하며: "AI와 비개발자가 함께 일할 판을 얼마나 잘 깔아주느냐"

지난 글에서는 “개발자가 DB와 배포만 잡아주면 된다”고 썼습니다. 한 명을 도울 때는 그 말이 맞았습니다. 그런데 11명을 같은 판 위에 올려놓고 보니, 그것만으로는 한참 부족하더라고요. 맥락(공통 약속), 품질(가드레일), 일하는 방식(모드)까지 함께 설계해줘야 비로소 굴러갔습니다.

앞으로 개발자의 강점은 거기에 있지 않을까 싶습니다. 코드 한 줄을 얼마나 잘 짜느냐가 아니라, AI와 비개발자가 함께 일할 판을 얼마나 잘 깔아주느냐. 마인크래프트 서버를 여는 사람의 일과 비슷합니다. 뭘 짓는 건 다른 사람들이고, 저는 그들이 신나게 지을 수 있는 땅을 깔아두는 거죠.

플랫폼을 만들기 전과 지금의 저를 비교해보면, 한 줄이 또렷이 남습니다. 저는 이제 시스템 아키텍트로서 역할이 옮겨가고 있습니다. 한 줄 한 줄을 직접 짜는 사람이 아니라, AI가 어디서 어떻게 일하는지 점검하고, 리포트를 받고, 그 결과가 안전하게 배포되도록 판을 세팅하는 사람입니다. 그러면서 동시에 혼자서는 만들 엄두도 못 냈을 거대한 서비스를 만들 수 있는 사람이 된 것 같습니다.

재미있게도 코드를 덜 짜게 됐는데, 만들 수 있는 것은 더 커졌습니다. 요즘 개발자의 일이 그 방향으로 흘러가고 있다는 감각이, 이 플랫폼을 만들면서 가장 진하게 남았습니다. 앞으로 이 마을은 얼마나 커질까요? 다음에는 이 서버에 어떤 동네가 생길지 기대되는 마음으로 글을 마칩니다.

Q&A

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.