프론트엔드 개발자가 백엔드 건드려야 했을 때의 경험

개발자 현직자 솔직 경험담

프론트엔드 개발자가
백엔드 건드려야 했을 때의 경험

Next.js API Routes 하나 고치는 데 이틀 걸렸던, 백엔드 담당자 부재 시기의 기록.

스타트업 특성상 백엔드 개발자 한 명이 이직하면서 잠깐 공백이 생긴 적이 있다. 그때 리드가 "일단 급한 API는 프론트에서도 좀 봐줄 수 있을까요?"라고 물었을 때, 나는 별생각 없이 "네, 할 수 있을 것 같아요"라고 답했다. 실제로는 단순한 API 하나 고치는 데 이틀이 걸렸고, 그 과정에서 프론트엔드 개발자로서 얼마나 좁은 시야로 일하고 있었는지 뼈저리게 느꼈다.

프론트엔드 개발자가 백엔드 건드려야 했을 때의 경험

2일첫 API 수정 소요 시간

3주백엔드 공백 담당 기간

4개직접 고친 API 엔드포인트 수

1. 첫 번째 벽 — "프론트에서 보던 API가 이렇게 복잡했나"

맡은 작업은 상품 상세 페이지에서 재고 수량이 잘못 표시되는 버그였다. 프론트에서는 그냥 GET /api/products/:id를 호출해서 받은 값을 렌더링하기만 하면 됐는데, 실제 원인은 API 내부에 있었다.

평소 익숙한 영역

Next.js

React 컴포넌트

Zustand 상태 관리

Tailwind 스타일링

→

처음 마주한 영역

Prisma 스키마

트랜잭션 처리

DB 인덱스

동시성 문제

Prisma 스키마를 열었는데, 재고 관련 테이블이 상품 테이블과 어떻게 관계를 맺고 있는지부터 이해가 안 됐다. 평소 프론트에서는 그냥 API가 던져주는 JSON만 믿고 썼는데, 그 JSON이 어떤 쿼리를 거쳐 나오는지는 완전히 블랙박스였다는 걸 그제야 실감했다.

⚠ 그때 느낀 것 프론트엔드 개발자로서 API 명세만 보고 개발하는 것과, 그 API가 실제로 어떻게 동작하는지 이해하는 것은 완전히 다른 차원의 일이었다. 평소 "백엔드가 알아서 해주겠지"라고 생각했던 부분이 얼마나 많았는지 깨달았다.

2. 원인을 찾는 과정 — 낯선 언어로 대화하는 느낌

결국 이직한 백엔드 개발자에게 연락해서 스키마 구조를 간단히 설명받았다. 그 대화가 아직도 기억에 남는다.

전 백엔드 담당자 재고 감소 로직이 트랜잭션 안에서 처리되는데, 동시에 두 명이 같은 상품을 주문하면 레이스 컨디션이 생길 수 있어요. 그래서 낙관적 락을 걸어뒀는데, 아마 그 부분이 문제일 거예요.

나 낙관적 락이요...? 그게 뭔지부터 좀 설명해주실 수 있을까요.

솔직히 이 대화에서 절반은 이해하지 못했다. 프론트엔드에서는 거의 다룰 일이 없던 동시성, 트랜잭션, 락 같은 개념들이 낯선 외국어처럼 느껴졌다. 결과적으로 그날은 개념 공부만 하다가 하루가 다 갔다.

// 문제였던 부분 - 재고 확인과 감소가 원자적이지 않음 const product = await prisma.product.findUnique({ where: { id } }); if (product.stock > 0) { // 이 사이에 다른 요청이 끼어들면 재고가 마이너스가 될 수 있음 await prisma.product.update({ where: { id }, data: { stock: { decrement: 1 } }, }); } // 수정 후 - 트랜잭션과 조건부 업데이트로 원자성 확보 const result = await prisma.product.updateMany({ where: { id, stock: { gt: 0 } }, data: { stock: { decrement: 1 } }, }); if (result.count === 0) throw new Error("재고 부족");

결국 updateMany로 조건부 업데이트를 걸어서 원자성을 확보하는 방식으로 고쳤다. 개념적으로는 어려웠지만, 막상 코드로 보니 프론트에서 다루던 비동기 처리 감각과 완전히 무관한 건 아니었다는 게 위안이 됐다.

3. 3주간 겪은 것들 — 프론트 개발자의 시야가 넓어진 순간들

1주 차

재고 관련 버그 수정. 트랜잭션과 락 개념을 처음 실전에서 다뤄봄. 프론트에서 당연하게 여기던 데이터가 얼마나 정교하게 관리되는지 체감.

2주 차

간단한 신규 API 엔드포인트(찜 목록 조회) 추가. Prisma 쿼리 최적화를 몰라서 N+1 문제를 그대로 배포했다가 다음날 응답 속도 이슈로 리팩토링.

3주 차

새 백엔드 개발자 입사. 인수인계를 도우면서, 그동안 겪은 시행착오를 문서로 정리해 공유. 이 과정에서 오히려 API 설계 전체 그림이 명확해짐.

백엔드 경험 전

API는 블랙박스

응답 느리면 "서버가 느리네" 정도로만 생각

백엔드 경험 후

쿼리 구조까지 유추 가능

N+1, 트랜잭션 등 원인을 구체적으로 의심할 수 있게 됨

4. 이후 프론트엔드 작업 방식이 달라진 부분

3주가 끝나고 다시 프론트엔드 위주로 돌아왔지만, 이 경험 이후로 API를 다루는 태도 자체가 달라졌다. 예전엔 응답이 느리면 그냥 로딩 스피너만 예쁘게 만들었는데, 이제는 "이 API가 왜 느릴까"를 먼저 의심하게 됐다.

💡 실전에서 달라진 습관 API 명세를 받을 때 응답 필드만 확인하는 게 아니라, 어떤 테이블을 조회하는지, N+1 문제가 있을 만한 구조는 아닌지 백엔드 개발자와 미리 논의하는 습관이 생겼다. 덕분에 배포 후 발견되는 성능 이슈가 눈에 띄게 줄었다.

백엔드 경험 전 — API 문제 파악 자신감3 / 10

 

3주 경험 직후 — 자신감5 / 10

 

현재 (반년 후) — 자신감7.5 / 10

 

3주 후 결론

백엔드를 완벽히 다루게 된 건 절대 아니었다. 다만 API 너머에 어떤 결정과 트레이드오프가 있는지 짐작할 수 있게 된 것만으로도, 프론트엔드 개발자로서 훨씬 넓은 관점에서 협업할 수 있게 됐다.

"API는 경계선이 아니라, 두 세계가 만나는 접점이었다."

2026년 현재 Next.js의 Server Actions와 API Routes가 널리 쓰이면서, 프론트엔드 개발자가 가벼운 백엔드 로직까지 직접 다루는 풀스택형 역할이 늘고 있다는 이야기를 주변 개발자들에게 자주 듣는다. 다만 팀 구조와 서비스 규모에 따라 요구되는 범위가 크게 다르므로, 절대적인 기준으로 받아들이기보다는 참고 정도로 봐야 한다.

결론

프론트엔드 개발자로서 백엔드를 직접 건드려본 3주는 힘들었지만, 그 이후 코드를 보는 시야가 확실히 넓어졌다. API를 그냥 주어진 것으로만 받아들이지 않고, 그 너머의 구조와 트레이드오프까지 상상할 수 있게 된 게 가장 큰 변화였다. 지금 비슷한 상황에 놓인 프론트엔드 개발자가 있다면, 두려워하기보다 시야를 넓힐 기회로 받아들여 보길 권하고 싶다.

여러분도 영역을 넘나든 경험이 있으신가요?

프론트엔드 개발자로서 백엔드를, 혹은 그 반대의 경험을 해보신 적이 있다면 댓글로 나눠주세요. 비슷한 상황에 놓인 다른 개발자분들께 큰 도움이 될 것 같습니다.