프론트엔드와 백엔드를 한 팀으로 합치면 어떤 일이 일어날까?

안녕하세요. 당근 광고실 광고주플랫폼팀에서 엔지니어링 매니저를 맡고 있는 일택(Iltaek)이에요.

제가 속한 광고주플랫폼팀은 광고주가 당근의 내부 구조를 몰라도 광고를 만들고, 운영하고, 결과를 이해할 수 있는 플랫폼을 만들어요. 광고를 시작하려고 광고 만들기 버튼을 누른 순간부터 집행 결과 리포트를 확인하기까지, 광고주가 만나는 모든 여정을 저희가 책임지고 있죠. 그리고 그 경험이 매끄럽게 흘러가려면, 웹 화면부터 그 뒤의 서버까지가 하나의 흐름으로 이어져야 해요.

그런데 올해 초까지만 해도, 저희의 일상은 이 흐름과 사뭇 달랐어요. 광고주가 보는 화면을 만드는 게 프론트엔드(FE), 그 뒤에서 데이터를 처리하는 서버를 만드는 게 백엔드(BE)인데, 저희는 이 두 직군이 서로 다른 팀이었거든요.

기능 하나를 내려면 할 일 단위인 티켓이 프론트엔드와 백엔드에 따로 만들어졌고, 두 팀의 스프린트 일정도 서로 맞춰야 했어요. 화면과 서버가 주고받을 약속인 API 스펙이 정해질 때까지, 화면 작업은 기다려야 했고요. 한쪽이 급한 일로 밀리면 반대쪽도 같이 밀렸죠. 서로 잘하고 있는데도 직군의 경계에서 조율과 대기가 계속 생기는 구조였어요.

그러다 이런 발상이 나왔어요. 아예 두 팀을 하나로 합쳐보면 어떨까? 그럴듯한 발상이면 일단 실험해 보는 게 저희가 일하는 방식이라, 이번에도 우선 해보기로 했던 거죠.

그렇게 지난 4월, 저희 팀은 백엔드 엔지니어 4명과 프론트엔드 엔지니어 4명, 직군이 다른 두 팀을 하나로 합쳤어요. 화면부터 서버까지가 한 팀의 일이 됐죠. 그렇게 한 분기를 보낸 지금은, 엔지니어 한 명이 화면부터 서버까지 문제를 끝까지 해결하는 일이 흔해졌어요.

사실 이 실험은 걱정과 함께 시작됐어요. 작은 팀이라면 애초에 직군의 경계가 옅죠. 초기 스타트업에서는 한 사람이 프론트엔드와 백엔드를 오가며 개발하는 게 흔한 일이니까요. 저희 상황은 달랐어요. 이미 많은 광고주가 쓰는 서비스를 두 팀이 나눠 운영하고 있었고, 각자 쌓아온 전문성과 지켜야 할 안정성이 있는, 말하자면 잃을 게 많은 조직이었거든요. 이런 조직이 잘 돌아가던 것들을 흔들지 않으면서 직군 통합에 적응한 사례를, 저희는 들어보지 못했어요. 그래서 걱정이 먼저였어요.

걱정을 키운 건 시스템의 규모였어요. 두 팀은 마이크로서비스 구조 위에서 각자 여러 개의 서비스를 운영하고 있었고, 팀을 합친다는 건 서로가 그만큼 많은 낯선 서비스를 새로 배워야 한다는 뜻이기도 했죠. 걱정은 두 갈래였어요. 하나는 안정성이었어요. 장애가 나면 당번을 서며 대응하는 온콜을 이제 여덟 명이 함께 서야 하는데, 잘 모르는 서비스에서 장애가 나면 제때 대응하지 못할 수 있으니까요. 다른 하나는 속도였고요. 낯선 영역을 배우느라 팀 전체가 느려질 수 있으니까요.

결론부터 말하면, 속도 걱정은 기우였어요. 안정성 걱정은 4월에 실제로 현실이 됐는데요. 그 이야기는 뒤에서 다시 들려드릴게요.

그대로였던 속도, 그리고 두 가지 원칙

먼저 이 두 걱정 중 속도부터 짚어볼게요. 비교 기준은 이렇게 잡았어요. 통합 전에 스프린트마다 끝낸 일의 양, 그러니까 완료량을 기록해 온 건 백엔드 팀(4명)이라, 그 기록을 기준선으로 삼았어요. 인원이 두 배가 됐으니 기대치도 그만큼 높여 잡고, 새로 합류한 지 얼마 안 된 멤버의 몫은 보수적으로 계산해서 나란히 놓고 봤어요. 결과는요?

8명이 함께 보낸 첫 분기의 완료량은 줄지 않았습니다.

스프린트 단위로 측정했을 때도 유의미했어요. 저희 팀은 2주 단위의 스프린트로 일해요. 할 일을 티켓으로 만들어 그 기간 안에 소화할 만큼 계획하고, 끝나면 돌아보고 다시 계획하는 방식으로 움직여요. 통합 후 네 번의 스프린트 동안 완료량은 큰 변동 없이 비슷한 수준으로 유지됐어요. 낯선 직군을 배우는 과도기였는데도 결과가 그대로였다는 게, 저희에게도 가장 뜻밖이었어요.

물론 완료량은 스토리 포인트라는 팀 내부 추정 단위로 집계해요. 다른 팀과 비교할 수 있는 절대적인 숫자는 아니라서, 저희는 늘었는지 줄었는지 유지됐는지, 전체적인 흐름을 중점으로 파악했어요. 그 기준으로 확인한 사실은 딱 하나예요.

"떨어질 줄 알았는데, 떨어지지 않았다."

참고로 2분기가 한가한 분기였던 것도 아니에요. 새 기능 개발이 아니라 서비스를 유지하는 일, 즉 운영성 업무가 완료량의 3분의 1을 차지했고, 인시던트(장애) 대응도 여러 건 있었어요. 이 과도기를 버티게 한 거창한 온보딩 프로그램은 없었어요. 대신 두 가지를 지켰어요.

첫 번째는 배분 이에요. 모든 팀원이 스프린트마다 최소 1개는 반대 직군 티켓을 맡았어요. 저희 팀 과제는 애초에 프론트엔드와 백엔드가 세트로 움직이는 일이 많아서, 억지로 만들 필요 없이 일의 흐름 속에서 자연스럽게 고를 수 있었어요. 크기도 각자 소화할 수 있는 것부터 시작했어요. 프론트엔드 엔지니어에게는 온콜에서 나온 간단한 운영·유지보수 티켓이나 제품 과제의 간단한 백엔드 티켓을 배정했고, 백엔드 엔지니어는 자기 작업에서 파생되는 프론트엔드 개발을 직접 진행했어요. 억지로 기회를 만든 게 아니라, 일의 흐름에 이미 있던 기회를 나눈 셈이죠.

두 번째는 시범 이에요. 팀 리드이자 백엔드 엔지니어인 제가 프론트엔드 작업을 먼저 해 보였습니다. 간단한 티켓부터 어느 정도 규모가 있는 마이그레이션(시스템을 옮겨 다시 만드는) 작업까지 직접 진행했고, 그 과정에서 만든 검증 도구는 팀이 재사용할 수 있도록 남겨뒀어요. "백엔드 엔지니어인 나도 하니까 된다"를 말이 아니라 결과로 보여주고 싶었거든요. 반대 직군 작업을 향한 막연한 두려움과 거부감을 낮추는 데 이 시범이 도움이 됐다고 생각해요.

팀의 지식이 AI의 연료가 되기까지

돌이켜보면 두 원칙이 통한 건, 팀의 기본기가 이미 갖춰져 있었기 때문이라고 생각해요. "우리는 어떻게 일하는 팀인가"에 대한 기본 합의가 문서로 있었어요(팀 매니페스토와 Working Agreements). 1분기에 도입한 2주 스프린트는 통합 시점엔 팀의 습관으로 자리잡고 있었죠. 모든 일이 티켓으로 보이고, 크기가 추정되고, 각자 소화할 수 있는 업무량에 맞춰 분배되니, 새 멤버에게 반대 직군 일을 "적정한 크기로" 맡기는 운영이 가능했던 거죠.

작업마다 기획서와 설계 문서를 쓰고 시작하는 습관도 있었죠. 시스템 구조를 그린 아키텍처 다이어그램이나 데이터 구조를 정리한 DB 스키마 문서 같은 도메인 지식도 1분기부터 각 서비스 저장소에 쌓여 있었고요. 이 문서들은 뒤에서 말할 AI의 연료이기 전에, 새로 합류한 사람의 온보딩 자료이기도 했어요. 새 멤버들은 백지에 합류한 게 아니라, 이미 돌아가는 시스템 위에 올라탄 쪽에 가까웠어요.

이 기본기 위에서 두 가지가 맞물렸어요. 하나는 AI예요. 백엔드 엔지니어가 프론트엔드 코드를, 프론트엔드 엔지니어가 백엔드 코드를 작성할 때 AI 코딩 도구가 초안의 대부분을 만들어 주면서, 낯선 영역에 들던 진입 비용이 크게 줄었죠. 두 팀이 쓰는 언어부터 다른데 가능하냐 싶으실 수 있어요. 저희도 백엔드는 JVM 계열, 프론트엔드는 주로 React를 기반으로 쓰는데, AI와 일해 보니 언어나 기술 스택은 더 이상 큰 걸림돌이 아니었어요.

다른 하나는 팀에 쌓인 지식 이에요. 그런데 AI만으로 되는 일은 아니었어요. AI가 낯선 코드베이스에서 쓸 만한 결과물을 내려면 맥락이 입력으로 있어야 하는데, 저희에게 그 맥락이 바로 문서였거든요. 팀의 지식이 AI의 연료였습니다.

1분기에 만들어둔 것들의 덕도 톡톡히 봤어요. 대표적인 게 온콜 Runbook(장애 대응 매뉴얼)과 모니터링 대시보드죠. 낯선 서비스의 장애 알림을 받았을 때, 예전 같으면 그 시스템을 아는 사람부터 찾아야 했을 거예요. 이번 분기에는 Runbook을 열면 증상별 대응 절차가 정리돼 있으니 일단 혼자 움직일 수 있었죠.

온콜을 서 본 팀원들의 말도 비슷했어요. Aaron은 "팀이 합쳐지면서 특히 온콜이 걱정됐었는데, Runbook 덕분에 잘 처리할 수 있던 것 같아요"라고 했고, Kian은 "Runbook의 FAQ 섹션을 통해서 특정 누구에게 blocking되지 않고 팀이 일할 수 있어서 좋았어요"라고 했어요. 1분기에 쓴 문서가 2분기의 온보딩 역할까지 해준 거예요.

기존 지식을 꺼내 쓰기만 한 건 아니에요. 2분기에는 팀 기술 문서 저장소를 새로 만들어 흩어져 있던 도메인 지식을 한곳으로 모았어요. 한 분기 동안 문서와 수정 기록이 수백 개 단위로 쌓였는데, 흥미로운 건 만드는 일과 쓰는 일이 동시에 일어났다는 점이에요. 프로젝트를 진행하며 새로 남긴 문서가 곧바로 다음 작업과 포스트모템(사후 회고)에서 AI의 입력으로 쓰였거든요.

Aaron은 "LLM wiki를 활용하는 것, 프로젝트를 별도 레포로 진행하는 방식을 많이 배웠어요"라며 과거 경험상 비슷한 프로젝트보다 빠르게 완료한 것 같다고 돌아봤고, "글 쓰는 것이 비단 사람에게뿐만 아니라 에이전트에게도 도움이 되는 것 같아요"라는 Noel의 말이 이 발견을 한 줄로 요약해 줘요. 지식 구축과 활용은 순서대로가 아니라, 동시에 시작해도 복리가 붙더라고요. 요즘은 이 순환을 학습으로도 확장하는 중이에요. 챕터별 인터랙티브 자료로 각자 되는 시간에 공부하고 그 결과물이 다시 AI의 연료로 돌아오는 비동기 스터디를, 첫 책부터 한 챕터씩 채워가고 있어요. 같은 문서가 사람과 AI를 함께 가르치는 구조가 된 거죠.

문서가 쌓일수록 낡은 내용도 함께 남는 것 아니냐는 의문이 들 수 있어요. 맞는 걱정이라, 기획서와 테크스펙을 리뷰하는 단계마다 계속 보정하고 있어요. 아직까지는 실제로 문제가 될 만한 이슈를 만나지는 않았고요.

막연한 두려움이 "이게 되네요?"로

도입에서 말한 변화를 더 구체적으로 보여드릴게요. 배분 원칙대로 매 스프린트 전원이 한 번씩은 경계를 넘었으니 어찌 보면 자연스러운 결과인데, 갈수록 간단한 티켓의 범위를 넘어섰어요. 백엔드 엔지니어가 "[FE] 대행사 계정 예산 연동" 티켓을 완료하고, 프론트엔드 엔지니어가 "[BE] 세금계산서 정보 타입 전환 API" 티켓을 완료하는 식이에요. 글 첫머리에서 말한 그 비용, 그러니까 티켓이 직군 사이를 오가며 기다리던 조율과 대기가 크게 줄었죠.

다만 "혼자 끝까지"가 "혼자 다 안다"는 뜻은 아니에요. AI 덕분에 반대 직군 코드를 작성할 수는 있게 됐지만, 두려움은 각자에게 있었어요. 프론트엔드 엔지니어는 AI가 작성한 백엔드 코드를 보며 "이게 정말 맞나" 싶고, 백엔드 엔지니어도 프론트엔드 코드 앞에서 마찬가지였는데요.

부족한 부분은 서로의 전문성으로 채웠어요. 초안은 혼자 끝까지 진행하고, 확신이 안 서는 지점만 옆자리 전문가에게 묻는 식이죠. 한 팀이고 옆자리니까, 물어보는 일은 특별한 이벤트가 아니었어요. 특정 장면을 꼽기 어려울 만큼 흔한 일상이었죠. 그렇게 묻고 확인하는 몇 분의 비용은, 티켓이 직군 사이를 오가며 기다리던 예전의 대기에 비하면 훨씬 작았고요.

물론 옆자리에 묻는 걸로 다 되는 것은 아니에요. 간단한 확인은 그렇게 하지만, 기술적인 변경은 설계 문서인 테크스펙을 작성해 팀과 실 단위의 리뷰를 거쳐요. AI가 작성한 코드가 그 직군 전문가의 눈에는 미흡하지 않냐는 질문도 받아요. 맞는 지적이라 AI를 쓰는 팀의 규칙과 도구인 하네스를 보강해가며 다듬고 있어요. 다만 완성도를 100%로 만드는 데 시간을 쓰기보다는, 80~90%를 받아들이고 대신 속도를 얻는 쪽으로 합의했어요.

그러면서 남는 리스크는 "문제가 생기면 빠르게 감지하고, 빠르게 대응하자"는 방식으로 감당해요. 앞서 말한 온콜 Runbook(장애 대응 매뉴얼)과 모니터링 대시보드가 그 안전망이고, 이 감지와 대응에도 AI를 붙이면서 예전보다 더 빠르고 효과적으로 움직이게 됐고요.

돌이켜보면 옆자리에 묻든 리뷰로 거르든, 무엇이 확신이 안 서는 지점인지 아는 것부터가 전문성이었어요. 저희 팀에서 전문성은 AI가 넘어서는 장벽이 아니라, AI의 결과물을 걸러내는 최종 검증자로 자리를 옮겨가고 있어요.

팀원들의 감각도 한 분기 사이에 달라졌어요. 프론트엔드에서 백엔드로 경계를 넘은 Sarah는 "해보지 않았던 일이라 불안함과 스트레스를 많이 받았지만, '하면 된다'는 생각이 들면서 부담이 적어지고 있어요"라고 했어요. "경계를 무너트리니까 빨리 작업할 수 있어서 좋았어요"라는 Henry.Koo의 말처럼, 스키마 변경을 백엔드에 바로 반영하는 속도가 일상이 됐고요. 반대 방향으로 넘은 Noel의 회고가 이 변화를 그대로 담고 있는데요.

"FE 작업이 처음에는 잘 될까 했지만, 직접 해보니까 잘 되네요? 업무 영역의 확장도 처음에는 두렵지만 막상 해보니까, 이게 되네요?" --- Noel

그럼 도입에서 말한 안정성 걱정은 어떻게 됐을까요. 4월, 결제(빌링) 시스템이 멈춘 장애를 포함해 인프라 인시던트가 몰렸어요. 원인은 통합과 무관했어요. 이전부터 쌓여 있던 인프라 문제가 하필 이 시기에 드러난 거였죠. 다만 서로의 시스템이 아직 낯선 팀에게는 이 시기가 첫 번째 큰 시험이었고, 저희는 분기 내내 온콜과, 장애를 줄이는 기반 시스템인 신뢰성 인프라에 투자하는 것으로 대응했어요.

6월에는 신규 인시던트가 0건 이었어요. 한 달간의 0건이 투자의 효과인지 운 좋게 조용한 달이었는지는 더 지켜봐야 알지만, 낯선 시스템을 안고 보낸 분기치고 잦아드는 방향이었다는 것까지는 말할 수 있을 것 같아요. 위에서 말한 상호 검증도 품질의 다른 축이었어요. 낯설다고 검증을 건너뛴 게 아니라, 확신이 없으니 오히려 더 묻게 됐거든요.

이득과 함께 따라온 비용들

물론 대가도 있었어요. 성공과 별개의 실패가 아니라, 이득과 함께 따라온 비용들이었죠. 먼저 혼자서 화면부터 서버까지 다 다루는 1인 풀스택 자체의 리스크예요. 직군 관점의 리뷰가 옅어질 수 있고, 특정 영역의 지식이 한 사람에게 쏠릴 수 있고, 길게는 각자의 전문성이 얕아질 수도 있어요. 상호 검증, 그리고 앞서 말한 스터디처럼 직군을 넘어 깊이를 다시 쌓는 투자가 저희의 대응이지만, 솔직히 말하면 관리하고 있다기보다 인지하고 과제로 안고 있는 단계에 가까워요.

이미 치른 비용도 있는데요. 정확히는 직군 통합 자체의 대가라기보다, 이 분기의 처리량을 만든 일하는 방식의 대가예요. AI의 도움으로 각자 여러 일을 동시에 진행하면, 실행 중에 발견되는 일과 급한 요청이 다음 계획을 기다리지 않고 바로 그 스프린트에 추가돼요. 그래서 계획했던 티켓은 대체로 기간 안에 끝냈는데도, 실제로 한 일의 3분의 2는 계획에 없던 일 이었어요. 앞에서 스프린트 완료량이 안정적이었다고 했는데, 그 총량을 채운 일의 내용이 계획과는 달랐던 셈이죠. 계획을 세우고 약속을 하는 입장에서는 아쉬움이 크게 남았어요.

팀이 AI에 숙련되며 실제 처리 시간은 줄었는데, 추정하는 감각은 아직 예전 속도에 맞춰져 있어요. 그래서 일을 실제보다 조금 크게 잡는 것 아닌가 하는 가설을 회고에서 검증하는 중이에요. 숫자로 보이지 않는 비용도 있었어요.

"각자 과제를 맡아 진행하는 방식으로 일하다 보니 다른 팀원들이 무슨 일을 하는지 잘 몰랐고, 1분기처럼 '팀으로서 일한다'는 느낌이 덜했던 것 같아요." --- Jake

이처럼 각자 병렬로 빨라진 만큼, 같이 일한다는 감각은 옅어졌어요. 작게는 회의와 추가 업무가 스프린트 중간에 끼어들어 야근으로 이어진 날이 있었고, 온콜 차례가 오면 고객 문의(CS) 처리에 생각보다 많은 품이 들었어요. AI 도구를 팀의 표준 습관으로 만드는 일도 아직 진행형이고요. 이런 날들이 반복되지 않게 이 방식을 지속가능하게 만드는 게, 특히 예측가능성을 되찾는 게 다음 분기의 숙제예요.

마지막으로, 이 경험이 성립한 전제를 적어둘게요. 비슷한 선택을 고민하는 팀이 있다면, 결과보다 이 전제부터 대조해 보시면 좋겠어요.

• 한 기능이 프론트엔드와 백엔드를 관통하는 제품 구조라, 경계를 넘는 만큼 직군 사이의 대기가 사라지는 팀이었어요.
• AI 툴링과 활용 습관이 팀에 이미 성숙해 있었어요. AI 레버리지가 낯선 팀이라면 그 장벽부터가 과제일 거예요.
• 지식을 문서로 남기는 습관이 있었어요. Runbook은 1분기의 투자였고, 기술 문서 저장소는 2분기에 일과 함께 만들었어요.
• 스프린트 주기와 일하는 방식에 대한 팀의 합의가 먼저 있었어요.
• 8명 소규모 팀이고, 통합이라는 시점의 맥락이 있었어요.

이런 팀의 맥락이 있었기에 가능했던 시도라고 생각해요. 그래도 저희가 가져가는 건 분명해요. AI가 직군의 진입장벽을 실제로 낮췄다는 것, 전문성이 "생산자"에서 AI의 결과물을 걸러내는 "검증자"로 옮겨가고 있다는 것, 그리고 그 AI의 연료는 팀이 쌓아둔 문서였다는 것이에요. 전문성이 검증자로 옮겨간다는 건, 코드에 한정된 이야기는 아닐 거예요.

직군 사이의 벽이 낮아지는 게 프론트엔드와 백엔드만의 이야기일지는, 각자의 영역에서 판단해 보시면 좋겠어요. 앞의 전제 다섯 개가 그 판단의 체크리스트예요.

돌아보면 경계 없이 일한다는 말은 그동안에도 많이 해왔어요. 그런데 말로 하던 것과 한 분기를 실제로 그렇게 살아보는 건 다르더라고요. 직접 해보니 배우는 것도 느끼는 것도 훨씬 많았고, 솔직히 왜 이제야 이렇게 일했나 싶은 순간도 있었어요. 한 분기를 지나고, 회고에 팀원이 남긴 문장으로 이 글을 마무리할게요.

"영역의 확장이 시작됐다."

정답이 아니라 저희가 겪은 경험입니다. 당근이 강조하는 경계 없음 이 저희 팀에서는 이런 모습이었고요. 비슷한 고민을 하는 팀에 참고가 되면 좋겠습니다. 더 궁금한 점이 있다면 댓글이나 제 링크드인으로 편하게 물어봐 주세요.

---

프론트엔드와 백엔드를 한 팀으로 합치면 어떤 일이 일어날까? was originally published in 당근 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.