아임웹의 백엔드 엔지니어는 100만 개가 넘는 브랜드와 그 고객들로부터 발생하는 대용량 데이터를 기반으로 브랜드들이 온라인 비즈니스를 운영하며 마주하는 다양한 문제를 풀고 있습니다. 고객사마다 전혀 다른 사용 패턴과 예측하기 어려운 트래픽, 주문·결제·재고처럼 실패가 곧 비즈니스 리스크로 이어지는 도메인을 다루며 시스템의 안정성과 확장성을 함께 만들어 갑니다.
Chapter 1. 아임웹 백엔드 엔지니어가 마주하는 진짜 문제들
Chapter 2. 완벽한 답보다 빠른 검증을 선택하는 방식
Chapter 3. 정답을 구현하는 사람보다 문제를 정의하는 사람
Chapter 4. 다음 성장을 함께 그릴 동료에게
단순 구현을 넘어, 비즈니스의 구조를 설계하는 사람들
보통 백엔드 엔지니어의 역할을 떠올리면 서비스가 안정적으로 동작하도록 시스템을 뒷받침하는 일을 생각하게 됩니다. 사용자에게 직접 보이진 않지만 서비스가 멈추지 않도록 지탱하는 역할이죠. 그래서 백엔드 엔지니어를 흔히 ‘기반을 다지는 조력자’라고 부르기도 합니다.
아임웹에서도 백엔드 엔지니어는 서비스의 기반을 만드는 일을 합니다. 다만 아임웹은 단일 서비스가 아니라, 수많은 브랜드가 각자의 방식으로 비즈니스를 설계하고 운영하는 브랜드 빌더 플랫폼이라는 점에서 문제의 성격이 다릅니다. 고객사마다 사용하는 기능 조합과 트래픽 패턴, 외부 연동 방식이 모두 달라 비슷한 기능이라도 전혀 다른 맥락에서 이슈가 발생하곤 해요.
이 환경에서는 기능이 정상적으로 동작하는지만으로는 충분하지 않습니다. 작은 변경 하나가 여러 브랜드의 운영에 영향을 미치기도 하고, 반복되는 수정 요청의 원인이 코드가 아니라 초기 설계와 선택의 기준에 있는 경우도 점점 늘어나죠. 그래서 문제는 점점 “어떻게 고칠 것인가”보다 “처음에 왜 이렇게 설계했는가”로 옮겨갑니다.
그래서 아임웹의 백엔드 엔지니어는 구현 단계에만 머무르지 않습니다. 기획 초기부터 논의에 참여해, 지금의 선택이 이후 운영과 확장에 어떤 영향을 남길지를 함께 고민합니다. 기능을 구현하는 역할을 넘어, 문제를 정의하고 구조를 설계하는 엔지니어로 성장하게 되는 이유이기도 합니다.
이번 인터뷰에서는 아임웹 안에서도 서로 다른 스쿼드와 팀에서 일하고 있는 세 명의 백엔드 엔지니어를 만나 이야기를 나눴습니다.
크리에이터와 브랜드가 연결되는 새로운 커머스 모델을 만들고 있는 Creator Commerce 스쿼드의 경연님
앱스토어, OpenAPI, 매출 상승 도구를 통해 브랜드의 실험과 성장을 기술로 연결하는 Integration 스쿼드의 주승님
여러 스쿼드가 안정적으로 빠르게 일할 수 있도록 MSA/MFE 플랫폼과 공통 인프라를 설계하는 Productivity 팀의 성국님
서로 다른 영역에서 일하고 있지만, 세 명의 백엔드 엔지니어가 마주하는 고민과 선택에는 공통점이 있습니다. 성장하는 플랫폼 안에서 어떤 문제를 어떻게 정의하고, 어떤 기준으로 구조를 만들어가고 있을지. 지금부터 이들의 이야기를 통해 아임웹에서 백엔드 엔지니어가 어떤 역할을 맡고 어떤 방식으로 성장하고 있는지를 살펴봅니다.
Chapter 1. 아임웹 백엔드 엔지니어가 마주하는 진짜 문제들
아임웹의 백엔드 엔지니어는 어떤 문제를 가장 자주 마주하나요?
아임웹의 백엔드 환경을 설명할 때 가장 자주 나오는 말은 “예측이 어렵다”는 표현이에요. 정해진 피크 타임이 있는 서비스와 달리, 고객사별 이벤트나 외부 마케팅, 써드파티 앱 배포 같은 변수 하나만으로도 특정 도메인에 요청이 갑자기 몰리는 일이 생깁니다. 주문·결제·재고처럼 동시성이 높은 영역에서는 짧은 시간 안에 동일한 요청이 집중되며 지연이 쌓이기도 하고요. 외부 솔루션과 연결된 구조에서는 하나의 업데이트가 수백 개 브랜드의 API 호출로 이어지는 경우도 있습니다.
중요한 건 이런 상황이 ‘가끔’이 아니라 언제든지 반복될 수 있는 일상에 가깝다는 점이죠. 그래서 아임웹의 백엔드 엔지니어는 평균적인 트래픽보다, 가장 안 좋은 순간에 어디서 문제가 생길 수 있을지를 먼저 떠올리며 시스템을 바라보게 됩니다. 실제 판단 기준도 평균 TPS(Transactions per Second)보다는 p95·p99 지연이나 병목 지점, 장애 전파 범위에 더 가깝고요.
이런 문제를 풀 때, 백엔드 엔지니어는 어디까지 책임지나요?
이런 환경에서는 서버를 늘리거나 캐시를 추가하는 것만으로 문제가 끝나지 않는 경우가 많습니다. 겉으로는 성능 이슈처럼 보이지만 실제로는 요청이 만들어지고 반복되는 구조 자체가 원인인 경우도 적지 않기 때문이에요. 실제로 브랜드 이벤트와 프로모션이 겹치며 인증 요청이 몰렸던 적이 있었습니다. 처음에는 빠르게 스케일아웃으로 장애를 막았지만, 이후 원인을 다시 들여다보니 클라이언트에서 동일한 인증 요청이 반복 생성되고 있다는 점이 드러났어요. 그 뒤에는 서버를 더 늘리는 대신 프론트엔드 SDK 구조를 조정해 요청 자체를 줄이는 방향으로 접근했습니다.
외부 연동도 비슷합니다. OpenAPI를 제공하는 일은 단순히 기능을 노출하는 게 아니라, 외부의 예측 불가능한 요청 패턴까지 감당할 수 있는 구조를 설계하는 일에 가깝습니다. 이 과정에서는 기술 구현뿐 아니라, 파트너사에 어떤 사용 가이드와 기본값을 제시할지까지 백엔드 엔지니어의 판단에 포함돼요. 그래서 아임웹의 백엔드 엔지니어는 ‘서버만 보는 역할’이라기보다, 문제가 만들어지는 흐름 전체를 함께 설계하는 역할에 가깝습니다.
지금 가장 중요하게 보고 있는 과제는 무엇인가요?
지금 백엔드 조직에서 가장 중요하게 보고 있는 과제는 트래픽과 고객이 계속 늘어나더라도 특정 순간의 부하가 전체 서비스와 개발 속도를 흔들지 않도록 만드는 것입니다. 주문·결제·재고처럼 핵심 도메인에서 병목이 한 지점에 쏠리지 않도록 경계를 나누고, 외부 API 장애나 특정 도메인의 문제가 다른 영역으로 번지지 않도록 점진적인 분리와 격리를 진행하고 있어요.
경연 "아임웹은 매우 빠르게 성장하고 있고, 이 과정에서 발생하는 기술 부채는 복리처럼 누적됩니다."
병목과 불안정이 쌓이면 팀 생산성은 자연스럽게 떨어지고, 엔지니어의 시간은 새로운 가치를 만드는 데 쓰이기보다 문제를 수습하는 데 더 많이 쓰이게 되죠. 그래서 지금은 운영 안정성 자체가 하나의 제품 경쟁력이 되는 단계라고 보고 있어요.
이와 함께 오랫동안 유지돼 온 모놀리식 구조를 마이크로서비스 아키텍처(MSA)로 옮겨가는 과정에서의 마찰을 어떻게 줄일지도 중요한 과제로 보고 있습니다. 한 번에 구조를 바꾸기보다, 인증·게이트웨이·공통 플랫폼처럼 여러 팀이 함께 사용하는 영역부터 차근차근 정리하며, 전환 과정에서도 개발 속도와 안정성이 흔들리지 않도록 하는 데 집중하고 있어요.
그 과제가 해결되면, 엔지니어링 조직과 제품에는 단기·장기적으로 어떤 변화가 생길까요?
단기적으로 가장 먼저 체감되는 변화는 불안정에 대응하느라 소모되던 에너지가 줄어든다는 점이에요. 특정 고객사의 이벤트나 트래픽 급증이 전체 서비스로 번지지 않고, 문제가 생겨도 영향 범위가 명확해지면서 장애 대응과 핫픽스에 쓰이던 시간이 크게 줄어듭니다. 그만큼 개발 일정이 운영 이슈로 흔들리는 일도 줄어들고요.
장기적으로는 성장이 더 이상 리스크가 아닌 전제가 되는 구조로 전환됩니다. 트래픽이 늘어나거나 대형 고객이 유입되더라도 ‘언제 터질지 모르는 위험 요소’가 아니라, 시스템이 자연스럽게 흡수할 수 있는 조건이 되는 거죠. 각 도메인은 보다 독립적으로 확장할 수 있고 비용과 성능 역시 예측 가능한 범위 안에서 관리할 수 있게 됩니다.
이런 변화는 팀이 일하는 방식에도 영향을 줍니다. 문제가 터진 뒤에 수습하는 조직이 아니라, 설계 단계에서 병목과 실패를 먼저 걷어내는 조직으로 전환하게 됩니다. 결국 이 모든 변화는 제품의 가치가 고객 브랜드에 더 빠르고 안정적으로 전달되는 상태로 이어진다고 보고 있어요.
Chapter 2. 완벽한 답보다 빠른 검증을 선택하는 방식
아임웹에서는 정답이 불분명한 문제를 어떤 방식으로 검증해 나가나요?
아임웹에서는 처음부터 완벽한 답을 만들기보다, 작은 시도를 먼저 해보는 선택을 더 자주 합니다. 고객 니즈가 분명하지 않거나 정답이 정해져 있지 않은 문제일수록 정교한 계획보다 되돌릴 수 있는 선택인지, 실패 비용이 낮은 구조인지를 먼저 따져봐요.
이 방식은 신규 제품 개발에만 국한되지 않습니다. 외부 연동이나 기존 구조를 확장할 때도 마찬가지에요. 한 번의 기술적 선택이 오랫동안 부담으로 남을 수 있는 환경이기 때문에 처음부터 모든 걸 결정하기보다 작게 만들고, 빠르게 확인하고, 필요하면 과감하게 방향을 바꾸는 것을 더 중요하게 보고 있어요.
경연 “초기 단계에서는 완성도보다, 얼마나 빨리 배우고 다음 선택으로 이어갈 수 있는지가 더 중요하다고 생각해요.”
실제로 그렇게 일했던 사례가 있다면요?
Creator Commerce 스쿼드에서 새로운 제품을 처음부터 만들어보던 경험이 있어요. 당시에는 타겟 고객과 사용 시나리오가 명확하지 않아, 정답을 먼저 정의하기보다 가설을 빠르게 검증하는 게 더 중요한 상황이었습니다. 그래서 모든 고객을 대상으로 한 기능을 만드는 대신, 일부 고객에게만 최소 기능을 제공하는 작은 실험부터 시작했어요. 이때 백엔드가 가장 먼저 고민한 건 확장성이 아니라, 실패했을 때 얼마나 빠르게 되돌릴 수 있는지, 그리고 실제 사용 여부를 판단할 수 있는 최소한의 신호를 확보할 수 있는지였습니다. 기획이 아직 열려 있는 상태였기 때문에 데이터 구조도 한 방향으로 고정하지 않았고, 이후 선택에 따라 쉽게 수정할 수 있도록 여지를 남겼어요. 그 결과 핵심이라고 생각했던 기능이 실제로는 거의 사용되지 않는다는 걸 비교적 빠르게 확인했고, 큰 리소스를 쓰기 전에 방향을 전환할 수 있었습니다.
비슷한 판단은 외부 연동에서도 반복됐습니다. OpenAPI나 앱스토어 영역에서는 한 번 정의한 스펙이 여러 써드파티에 영향을 주기 때문에, 완벽하게 준비한 뒤 런칭하는 게 안전해 보이기도 해요. 하지만 실제 수요가 불확실한 상황에서는 꼭 필요한 기능만 최소한으로 열고 실제 연동 문의와 VoC(Voice of Customer, 고객의 목소리)를 기준으로 우선순위를 다시 정리하는 방식이 더 효과적이었습니다.
이 방식은 레거시나 큰 구조를 다룰 때도 같았나요?
네, 오히려 구조가 크고 오래된 영역일수록 같은 원칙을 더 강하게 적용했습니다. 아임웹 랜딩페이지를 포함한 플랫폼 백엔드는 오랫동안 브랜드 사이트와 동일한 PHP 기반 모놀리식 구조 위에서 운영돼 왔고, 한 번에 구조를 바꾸기엔 리스크가 너무 컸어요. 그래서 이번에는 “한 번에 바꾸지 않는다”는 전제를 두고 접근했습니다.
기존 코드는 그대로 둔 채, 플랫폼 백엔드 영역만 독립적으로 운영할 수 있는지부터 작은 단위로 검증했고요. 가능성이 보인 이후에야 기능 단위로 이전을 시작했고, 트래픽도 한 번에 넘기지 않고 단계적으로 나눠 적용했습니다. 이 과정을 통해, 레거시를 다룰 때 꼭 언어나 프레임워크부터 바꿔야 하는 건 아니라는 점이 분명해졌어요. 코드를 새로 쓰기보다 먼저 경계를 나누고 독립성을 확보하는 방식이, 리스크를 통제하면서 구조를 바꾸는 데 훨씬 현실적인 선택이었습니다.
예상치 못한 문제가 생겼을 때, 문제를 어떻게 공유하고 풀어가나요?
아임웹에서 예상치 못한 문제가 생기면 문제를 혼자 끌어안지 않습니다. 기술적으로 어떻게 풀지 고민하기 전에 이 문제가 어떤 맥락에서 발생했고 어떤 영역과 맞닿아 있는지를 빠르게 공유하는 게 먼저예요.
성국 “기술적인 수준이나 방식보다, 협업 방식 자체가 문제 해결의 핵심이 되더라고요.”
통합 결제 플랫폼을 만들면서 여러 외부 PG사와 연동하던 과정에서도 예기치 못한 상황을 겪었습니다. 테스트 환경에서는 문제없이 동작하던 결제 흐름이 실제 주문 시스템에 연결되자, 일부 PG사에서 결제 요청을 거부하는 일이 발생했어요. 브라우저 보안 정책과 외부 PG사의 정책처럼 내부에서 직접 통제할 수 없는 조건들이 동시에 얽혀 있던 상황이었습니다.
이때 한쪽에서 우회 방법을 찾기보다, 바로 Productivity 팀과 프론트엔드 엔지니어들에게 상황을 공유하고 해결 방향을 다시 잡았습니다. 단순히 ‘어떻게든 통과시키는 방법’을 찾기보다, 외부 정책을 존중하면서도 서비스 전체 흐름에서 안전한 결제 경험을 만들 수 있는 구조가 무엇인지를 함께 고민했어요. 각자의 전문 영역을 바탕으로 선택지를 정리하고 보안·안정성·확장성 기준으로 하나씩 검토해 나갔습니다.
이 경험을 통해 분명해진 건, 백엔드 플랫폼 업무라고 해도 제품이 실제로 완성되기 위해서는 서로 다른 전문성을 가진 사람들이 같은 맥락 위에서 고민하는 과정이 필수적이라는 점이었어요. 기술적인 해법 만으로는 풀 수 없는 문제일수록 협업 방식 자체가 해결의 중요한 축이 됩니다.
여러 도메인이 동시에 얽힌 상황에서도 같은 방식이 유지됐나요?
맞아요. 대규모 트래픽 상황에서도 같은 선택이 반복됐습니다. 연말 행사와 여러 고객사의 이벤트가 겹치면서 주문 도메인에 트래픽이 급격히 몰린 적이 있었고, 주문·결제·재고가 동시에 맞물린 상황이라 단일 팀만으로는 대응하기 어려웠어요. 이때 아임웹에서는 문제를 특정 팀의 책임으로 한정하지 않고, 서비스 전체 흐름을 기준으로 대응 방식을 다시 정리했습니다.
주승 “도메인 경계를 넘는 문제일수록 각 팀이 자기 영역보다 ‘지금 가장 큰 문제’를 먼저 보는 게 중요하다고 느꼈어요”
여러 스쿼드의 백엔드 엔지니어들이 함께 모여, 어디에서 병목이 생기고 있는지를 서비스 전체 흐름 기준으로 다시 짚는 것부터 시작했어요. 각자의 담당 영역을 바탕으로 역할을 나누고 우선순위를 맞추며 대응한 결과, 트래픽이 집중되는 상황에서도 안정적으로 처리할 수 있는 구조를 만들 수 있었습니다. 이후에는 같은 유형의 이벤트에서도 문제가 반복되지 않도록 기반을 정리했고요. 이런 선택이 가능했던 건, 문제를 혼자서 끌어안기보다 맥락을 공유하고 함께 풀어가는 방식에 익숙한 동료들이 있었기 때문이기도 합니다.
Chapter 3. 정답을 구현하는 사람보다 문제를 정의하는 사람
아임웹 백엔드 엔지니어로 합류하기 위해 가장 필요한 역량이나 일하는 태도는 무엇일까요?
저희가 함께 일하면서 공통적으로 느끼는 건, 아임웹에서는 기술적인 기본기와 완성도를 전제로 그 위에서 문제를 어떻게 바라보느냐가 더 중요해진다는 점이에요. 정해진 답을 빠르게 구현하는 문제보다 이 상황을 어떻게 정의해야 하는지부터 함께 고민해야 하는 경우가 더 많거든요.
그래서 저희가 중요하게 보는 태도는 대략 이 세 가지로 모아져요.
① 정답이 없는 문제 앞에서 기술과 제품을 함께 고민하며 끝까지 이해하려는 태도
② 바로 구현하기보다, 이 문제가 무엇인지부터 정의하고 트레이드오프를 고민하는 습관
③ 내 담당 영역이 아니더라도 맥락을 이해하려는 자세
왜 지금 이 선택이 필요한지, 되돌릴 수 있는 선택과 그렇지 않은 선택은 무엇인지를 먼저 구분하려는 태도를 중요하게 봅니다. 완벽한 설계보다도 실패를 감당할 수 있는 판단과 그 다음 선택으로 이어갈 수 있는 감각이 더 중요하다고 생각해요.
그렇다면, 어떤 일하는 방식의 사람일수록 이 환경에 잘 몰입하나요?
이 환경에 잘 맞는 분들의 공통점을 보면 문제를 빨리 해결하는 데서 멈추지 않고, 왜 이런 문제가 생겼는지를 이해하고 정의하는 과정까지 함께 가져갑니다. 요구사항을 곧바로 만들기보다 그 뒤에 있는 맥락을 함께 정리하고 선택지를 좁혀가는 과정 자체를 일의 일부로 받아들이는 편이죠.
또 하나는 아임웹에서는 문제를 개인의 숙제로 가져가기보다 팀 안에서 맥락을 공유하며 함께 풀어가는 방식을 기본으로 둔다는 점이에요. 그래서 혼자 문제를 깔끔히 해결하는 능력보다 이해되지 않은 지점을 그대로 두지 않고 드러내며 함께 풀어가려는 태도를 더 중요하게 봐요.
주승 “결국 아임웹은 고객 브랜드의 성공을 기술로 돕는다는 방향에 공감하고 그 과정에서 불확실성과 변화를 자연스럽게 받아들일 수 있는 분에게 잘 맞는 환경이라고 생각해요.”
그래서 이곳에 잘 맞는 백엔드 엔지니어는 불확실한 상황에서도 문제를 정의하고 팀과 함께 선택을 만들어갈 수 있는 사람에 가깝다고 느껴요.
반대로 도전적으로 느껴질 수 있는 부분도 있을까요?
해야 할 일이 명확하게 정리돼 있고, 정답이 빠르게 주어지는 환경을 선호한다면 다소 답답하게 느껴질 수 있어요. 여기서는 ‘주어진 일을 정확히 처리하는 것’보다 아직 정리되지 않은 문제를 팀과 함께 구체화해 가는 시간이 더 자주 필요하거든요.
업무의 경계를 바라보는 방식에서도 차이가 있어요. 하나의 기술적 선택이 다른 팀이나 서비스의 기준으로 이어지는 경우가 많다 보니, 지금 맡은 작업만 깔끔하게 끝내기보다 이 선택이 이후에 어떤 영향을 남길지까지 함께 고민하는 상황이 자연스럽게 생깁니다. 이런 논의와 조율을 일의 일부로 받아들이면 비교적 편하게 적응할 수 있지만 역할과 성과가 또렷이 분리된 환경을 기대한다면 에너지가 더 들 수 있어요.
백엔드 엔지니어들이 공통으로 중요하게 지키는 기준이 있다면 무엇인가요?
판단의 출발점은 늘 같습니다. 이 선택이 고객에게 어떤 영향을 주는가예요. 장애나 실패를 완전히 없앨 수는 없다고 보기 때문에, 실패를 전제로 하되 고객 경험이 크게 흔들리지 않도록 만드는 구조를 기본값으로 둡니다. 문제가 생겼을 때 얼마나 빠르게 감지할 수 있는지, 그리고 되돌릴 수 있는 선택인지는 항상 함께 고려하고요.
또 하나 중요한 기준은 특정 개인의 주의나 숙련도에 기대지 않아도 되는 구조인지입니다. ‘아는 사람만 조심해서 써야 하는 시스템’보다는 실수가 발생하더라도 고객 피해로 바로 이어지지 않도록 막아주는 선택을 하려고 해요. OpenAPI나 내부 플랫폼을 설계할 때도, 내부적으로 얼마나 편한가보다 이 선택이 고객 브랜드의 운영을 방해하지 않는지를 먼저 봅니다.
백엔드 엔지니어로서, 아임웹에서만 얻을 수 있는 경험이 궁금해요.
아임웹에서의 백엔드 경험을 한 가지로 꼽자면 불확실한 상황에서 무엇을 기본값으로 둘지 스스로 판단하는 감각을 실제 환경에서 계속 단련하게 된다는 점이에요. 문제를 한 번 해결하는 데서 끝나는 게 아니라 같은 상황이 다시 와도 전체 서비스에 영향을 주지 않도록 선택을 바꾸고 구조를 설계하는 과정을 반복하게 됩니다.
이런 경험을 쌓다 보면 백엔드 엔지니어의 역할도 자연스럽게 넓어집니다. 기능을 구현하는 사람을 넘어, 이 선택이 고객에게 어떤 결과로 남을지까지 책임지는 사람에 가까워지죠. 아임웹에서는 이런 판단을 가정이나 문서 속이 아니라, 실제 고객 브랜드의 운영과 성과 안에서 계속 확인하게 됩니다. 기술적인 결정이 곧 고객의 성과나 리스크로 이어지는 상황을 직접 겪으며 성장할 수 있다는 점은 백엔드 엔지니어에게 쉽게 얻기 어려운 경험이라고 생각해요.
Chapter 4. 다음 성장을 함께 그릴 동료에게
새 동료와 함께 이루고 싶은 목표가 있다면요?
새 동료와 함께 이루고 싶은 목표는 아임웹의 성장이 더 이상 백엔드의 제약이나 부담으로 느껴지지 않는 단계까지 플랫폼을 끌어올리는 것입니다. 트래픽이 늘고 사용 패턴이 복잡해져도 특정 순간의 부하나 장애가 전체 서비스로 번지지 않는 구조를 만드는 데 집중하고 있어요. 그 과정에서 엔지니어의 시간이 문제 수습에 소모되기보다, 제품 개선과 실험에 쓰일 수 있는 환경을 만드는 것을 중요하게 보고 있습니다.
제품 경험 측면에서도 방향은 분명합니다. 대형 이벤트나 성수기 같은 까다로운 상황에서도 고객이 불안함을 느끼지 않는 플랫폼, 언제 사용해도 일관된 성능과 신뢰를 제공하는 기본값을 만드는 것. 이 안정성과 예측 가능성이 아임웹의 경쟁력이 되고 더 많은 시도와 확장을 가능하게 하는 기반이 되기를 기대하고 있어요.
마지막으로, 지원을 고민하는 분들께 한마디 부탁드려요
경연 이해되지 않는 부분을 그냥 넘기지 않고 끝까지 질문하고, 실패를 두려워하기보다 그 안에서 배우며 구조를 더 나아지게 만들고 싶은 분이라면 분명 많은 성장을 경험하실 수 있을 거예요. 완벽한 준비나 화려한 기술 스택보다, 문제를 대하는 태도가 훨씬 더 중요하다고 느껴요.
주승 “이걸 이렇게 만들어주세요”보다 “이 문제를 왜 풀어야 하는지”, “이 선택이 고객에게 정말 도움이 되는지”를 함께 고민하는 시간이 많아요. 정답 없는 문제를 풀어가는 과정 자체에서 재미를 느끼는 분이라면 의미 있는 경험이 될 거라고 생각합니다.
성국 지금 알고 있는 기술을 적용하는 데서 멈추기보다, 이해되지 않는 문제를 끝까지 파고들고 이 선택이 다음 단계에서도 맞는지 고민하는 과정이 반복돼요. 그런 고민을 팀과 나누며 성장하고 싶은 분이라면 굉장히 밀도 높은 경험을 하실 수 있을 거예요.
imweb Corp.
아임웹의 백엔드 엔지니어는 100만 개가 넘는 브랜드와 그 고객들로부터 발생하는 대용량 데이터를 기반으로 브랜드들이 온라인 비즈니스를 운영하며 마주하는 다양한 문제를 풀고 있습니다. 고객사마다 전혀 다른 사용 패턴과 예측하기 어려운 트래픽, 주문·결제·재고처럼 실패가 곧 비즈니스 리스크로 이어지는 도메인을 다루며 시스템의 안정성과 확장성을 함께 만들어 갑니다.
단순 구현을 넘어, 비즈니스의 구조를 설계하는 사람들
보통 백엔드 엔지니어의 역할을 떠올리면 서비스가 안정적으로 동작하도록 시스템을 뒷받침하는 일을 생각하게 됩니다. 사용자에게 직접 보이진 않지만 서비스가 멈추지 않도록 지탱하는 역할이죠. 그래서 백엔드 엔지니어를 흔히 ‘기반을 다지는 조력자’라고 부르기도 합니다.
아임웹에서도 백엔드 엔지니어는 서비스의 기반을 만드는 일을 합니다. 다만 아임웹은 단일 서비스가 아니라, 수많은 브랜드가 각자의 방식으로 비즈니스를 설계하고 운영하는 브랜드 빌더 플랫폼이라는 점에서 문제의 성격이 다릅니다. 고객사마다 사용하는 기능 조합과 트래픽 패턴, 외부 연동 방식이 모두 달라 비슷한 기능이라도 전혀 다른 맥락에서 이슈가 발생하곤 해요.
이 환경에서는 기능이 정상적으로 동작하는지만으로는 충분하지 않습니다. 작은 변경 하나가 여러 브랜드의 운영에 영향을 미치기도 하고, 반복되는 수정 요청의 원인이 코드가 아니라 초기 설계와 선택의 기준에 있는 경우도 점점 늘어나죠. 그래서 문제는 점점 “어떻게 고칠 것인가”보다 “처음에 왜 이렇게 설계했는가”로 옮겨갑니다.
그래서 아임웹의 백엔드 엔지니어는 구현 단계에만 머무르지 않습니다. 기획 초기부터 논의에 참여해, 지금의 선택이 이후 운영과 확장에 어떤 영향을 남길지를 함께 고민합니다. 기능을 구현하는 역할을 넘어, 문제를 정의하고 구조를 설계하는 엔지니어로 성장하게 되는 이유이기도 합니다.
이번 인터뷰에서는 아임웹 안에서도 서로 다른 스쿼드와 팀에서 일하고 있는 세 명의 백엔드 엔지니어를 만나 이야기를 나눴습니다.
크리에이터와 브랜드가 연결되는 새로운 커머스 모델을 만들고 있는 Creator Commerce 스쿼드의 경연님
앱스토어, OpenAPI, 매출 상승 도구를 통해 브랜드의 실험과 성장을 기술로 연결하는 Integration 스쿼드의 주승님
여러 스쿼드가 안정적으로 빠르게 일할 수 있도록 MSA/MFE 플랫폼과 공통 인프라를 설계하는 Productivity 팀의 성국님
서로 다른 영역에서 일하고 있지만, 세 명의 백엔드 엔지니어가 마주하는 고민과 선택에는 공통점이 있습니다. 성장하는 플랫폼 안에서 어떤 문제를 어떻게 정의하고, 어떤 기준으로 구조를 만들어가고 있을지. 지금부터 이들의 이야기를 통해 아임웹에서 백엔드 엔지니어가 어떤 역할을 맡고 어떤 방식으로 성장하고 있는지를 살펴봅니다.
Chapter 1. 아임웹 백엔드 엔지니어가 마주하는 진짜 문제들
아임웹의 백엔드 엔지니어는 어떤 문제를 가장 자주 마주하나요?
아임웹의 백엔드 환경을 설명할 때 가장 자주 나오는 말은 “예측이 어렵다”는 표현이에요. 정해진 피크 타임이 있는 서비스와 달리, 고객사별 이벤트나 외부 마케팅, 써드파티 앱 배포 같은 변수 하나만으로도 특정 도메인에 요청이 갑자기 몰리는 일이 생깁니다. 주문·결제·재고처럼 동시성이 높은 영역에서는 짧은 시간 안에 동일한 요청이 집중되며 지연이 쌓이기도 하고요. 외부 솔루션과 연결된 구조에서는 하나의 업데이트가 수백 개 브랜드의 API 호출로 이어지는 경우도 있습니다.
중요한 건 이런 상황이 ‘가끔’이 아니라 언제든지 반복될 수 있는 일상에 가깝다는 점이죠. 그래서 아임웹의 백엔드 엔지니어는 평균적인 트래픽보다, 가장 안 좋은 순간에 어디서 문제가 생길 수 있을지를 먼저 떠올리며 시스템을 바라보게 됩니다. 실제 판단 기준도 평균 TPS(Transactions per Second)보다는 p95·p99 지연이나 병목 지점, 장애 전파 범위에 더 가깝고요.
이런 문제를 풀 때, 백엔드 엔지니어는 어디까지 책임지나요?
이런 환경에서는 서버를 늘리거나 캐시를 추가하는 것만으로 문제가 끝나지 않는 경우가 많습니다. 겉으로는 성능 이슈처럼 보이지만 실제로는 요청이 만들어지고 반복되는 구조 자체가 원인인 경우도 적지 않기 때문이에요. 실제로 브랜드 이벤트와 프로모션이 겹치며 인증 요청이 몰렸던 적이 있었습니다. 처음에는 빠르게 스케일아웃으로 장애를 막았지만, 이후 원인을 다시 들여다보니 클라이언트에서 동일한 인증 요청이 반복 생성되고 있다는 점이 드러났어요. 그 뒤에는 서버를 더 늘리는 대신 프론트엔드 SDK 구조를 조정해 요청 자체를 줄이는 방향으로 접근했습니다.
외부 연동도 비슷합니다. OpenAPI를 제공하는 일은 단순히 기능을 노출하는 게 아니라, 외부의 예측 불가능한 요청 패턴까지 감당할 수 있는 구조를 설계하는 일에 가깝습니다. 이 과정에서는 기술 구현뿐 아니라, 파트너사에 어떤 사용 가이드와 기본값을 제시할지까지 백엔드 엔지니어의 판단에 포함돼요. 그래서 아임웹의 백엔드 엔지니어는 ‘서버만 보는 역할’이라기보다, 문제가 만들어지는 흐름 전체를 함께 설계하는 역할에 가깝습니다.
지금 가장 중요하게 보고 있는 과제는 무엇인가요?
지금 백엔드 조직에서 가장 중요하게 보고 있는 과제는 트래픽과 고객이 계속 늘어나더라도 특정 순간의 부하가 전체 서비스와 개발 속도를 흔들지 않도록 만드는 것입니다. 주문·결제·재고처럼 핵심 도메인에서 병목이 한 지점에 쏠리지 않도록 경계를 나누고, 외부 API 장애나 특정 도메인의 문제가 다른 영역으로 번지지 않도록 점진적인 분리와 격리를 진행하고 있어요.
병목과 불안정이 쌓이면 팀 생산성은 자연스럽게 떨어지고, 엔지니어의 시간은 새로운 가치를 만드는 데 쓰이기보다 문제를 수습하는 데 더 많이 쓰이게 되죠. 그래서 지금은 운영 안정성 자체가 하나의 제품 경쟁력이 되는 단계라고 보고 있어요.
이와 함께 오랫동안 유지돼 온 모놀리식 구조를 마이크로서비스 아키텍처(MSA)로 옮겨가는 과정에서의 마찰을 어떻게 줄일지도 중요한 과제로 보고 있습니다. 한 번에 구조를 바꾸기보다, 인증·게이트웨이·공통 플랫폼처럼 여러 팀이 함께 사용하는 영역부터 차근차근 정리하며, 전환 과정에서도 개발 속도와 안정성이 흔들리지 않도록 하는 데 집중하고 있어요.
그 과제가 해결되면, 엔지니어링 조직과 제품에는 단기·장기적으로 어떤 변화가 생길까요?
단기적으로 가장 먼저 체감되는 변화는 불안정에 대응하느라 소모되던 에너지가 줄어든다는 점이에요. 특정 고객사의 이벤트나 트래픽 급증이 전체 서비스로 번지지 않고, 문제가 생겨도 영향 범위가 명확해지면서 장애 대응과 핫픽스에 쓰이던 시간이 크게 줄어듭니다. 그만큼 개발 일정이 운영 이슈로 흔들리는 일도 줄어들고요.
장기적으로는 성장이 더 이상 리스크가 아닌 전제가 되는 구조로 전환됩니다. 트래픽이 늘어나거나 대형 고객이 유입되더라도 ‘언제 터질지 모르는 위험 요소’가 아니라, 시스템이 자연스럽게 흡수할 수 있는 조건이 되는 거죠. 각 도메인은 보다 독립적으로 확장할 수 있고 비용과 성능 역시 예측 가능한 범위 안에서 관리할 수 있게 됩니다.
이런 변화는 팀이 일하는 방식에도 영향을 줍니다. 문제가 터진 뒤에 수습하는 조직이 아니라, 설계 단계에서 병목과 실패를 먼저 걷어내는 조직으로 전환하게 됩니다. 결국 이 모든 변화는 제품의 가치가 고객 브랜드에 더 빠르고 안정적으로 전달되는 상태로 이어진다고 보고 있어요.
Chapter 2. 완벽한 답보다 빠른 검증을 선택하는 방식
아임웹에서는 정답이 불분명한 문제를 어떤 방식으로 검증해 나가나요?
아임웹에서는 처음부터 완벽한 답을 만들기보다, 작은 시도를 먼저 해보는 선택을 더 자주 합니다. 고객 니즈가 분명하지 않거나 정답이 정해져 있지 않은 문제일수록 정교한 계획보다 되돌릴 수 있는 선택인지, 실패 비용이 낮은 구조인지를 먼저 따져봐요.
이 방식은 신규 제품 개발에만 국한되지 않습니다. 외부 연동이나 기존 구조를 확장할 때도 마찬가지에요. 한 번의 기술적 선택이 오랫동안 부담으로 남을 수 있는 환경이기 때문에 처음부터 모든 걸 결정하기보다 작게 만들고, 빠르게 확인하고, 필요하면 과감하게 방향을 바꾸는 것을 더 중요하게 보고 있어요.
실제로 그렇게 일했던 사례가 있다면요?
Creator Commerce 스쿼드에서 새로운 제품을 처음부터 만들어보던 경험이 있어요. 당시에는 타겟 고객과 사용 시나리오가 명확하지 않아, 정답을 먼저 정의하기보다 가설을 빠르게 검증하는 게 더 중요한 상황이었습니다. 그래서 모든 고객을 대상으로 한 기능을 만드는 대신, 일부 고객에게만 최소 기능을 제공하는 작은 실험부터 시작했어요. 이때 백엔드가 가장 먼저 고민한 건 확장성이 아니라, 실패했을 때 얼마나 빠르게 되돌릴 수 있는지, 그리고 실제 사용 여부를 판단할 수 있는 최소한의 신호를 확보할 수 있는지였습니다. 기획이 아직 열려 있는 상태였기 때문에 데이터 구조도 한 방향으로 고정하지 않았고, 이후 선택에 따라 쉽게 수정할 수 있도록 여지를 남겼어요. 그 결과 핵심이라고 생각했던 기능이 실제로는 거의 사용되지 않는다는 걸 비교적 빠르게 확인했고, 큰 리소스를 쓰기 전에 방향을 전환할 수 있었습니다.
비슷한 판단은 외부 연동에서도 반복됐습니다. OpenAPI나 앱스토어 영역에서는 한 번 정의한 스펙이 여러 써드파티에 영향을 주기 때문에, 완벽하게 준비한 뒤 런칭하는 게 안전해 보이기도 해요. 하지만 실제 수요가 불확실한 상황에서는 꼭 필요한 기능만 최소한으로 열고 실제 연동 문의와 VoC(Voice of Customer, 고객의 목소리)를 기준으로 우선순위를 다시 정리하는 방식이 더 효과적이었습니다.
이 방식은 레거시나 큰 구조를 다룰 때도 같았나요?
네, 오히려 구조가 크고 오래된 영역일수록 같은 원칙을 더 강하게 적용했습니다. 아임웹 랜딩페이지를 포함한 플랫폼 백엔드는 오랫동안 브랜드 사이트와 동일한 PHP 기반 모놀리식 구조 위에서 운영돼 왔고, 한 번에 구조를 바꾸기엔 리스크가 너무 컸어요. 그래서 이번에는 “한 번에 바꾸지 않는다”는 전제를 두고 접근했습니다.
기존 코드는 그대로 둔 채, 플랫폼 백엔드 영역만 독립적으로 운영할 수 있는지부터 작은 단위로 검증했고요. 가능성이 보인 이후에야 기능 단위로 이전을 시작했고, 트래픽도 한 번에 넘기지 않고 단계적으로 나눠 적용했습니다. 이 과정을 통해, 레거시를 다룰 때 꼭 언어나 프레임워크부터 바꿔야 하는 건 아니라는 점이 분명해졌어요. 코드를 새로 쓰기보다 먼저 경계를 나누고 독립성을 확보하는 방식이, 리스크를 통제하면서 구조를 바꾸는 데 훨씬 현실적인 선택이었습니다.
예상치 못한 문제가 생겼을 때, 문제를 어떻게 공유하고 풀어가나요?
아임웹에서 예상치 못한 문제가 생기면 문제를 혼자 끌어안지 않습니다. 기술적으로 어떻게 풀지 고민하기 전에 이 문제가 어떤 맥락에서 발생했고 어떤 영역과 맞닿아 있는지를 빠르게 공유하는 게 먼저예요.
통합 결제 플랫폼을 만들면서 여러 외부 PG사와 연동하던 과정에서도 예기치 못한 상황을 겪었습니다. 테스트 환경에서는 문제없이 동작하던 결제 흐름이 실제 주문 시스템에 연결되자, 일부 PG사에서 결제 요청을 거부하는 일이 발생했어요. 브라우저 보안 정책과 외부 PG사의 정책처럼 내부에서 직접 통제할 수 없는 조건들이 동시에 얽혀 있던 상황이었습니다.
이때 한쪽에서 우회 방법을 찾기보다, 바로 Productivity 팀과 프론트엔드 엔지니어들에게 상황을 공유하고 해결 방향을 다시 잡았습니다. 단순히 ‘어떻게든 통과시키는 방법’을 찾기보다, 외부 정책을 존중하면서도 서비스 전체 흐름에서 안전한 결제 경험을 만들 수 있는 구조가 무엇인지를 함께 고민했어요. 각자의 전문 영역을 바탕으로 선택지를 정리하고 보안·안정성·확장성 기준으로 하나씩 검토해 나갔습니다.
이 경험을 통해 분명해진 건, 백엔드 플랫폼 업무라고 해도 제품이 실제로 완성되기 위해서는 서로 다른 전문성을 가진 사람들이 같은 맥락 위에서 고민하는 과정이 필수적이라는 점이었어요. 기술적인 해법 만으로는 풀 수 없는 문제일수록 협업 방식 자체가 해결의 중요한 축이 됩니다.
여러 도메인이 동시에 얽힌 상황에서도 같은 방식이 유지됐나요?
맞아요. 대규모 트래픽 상황에서도 같은 선택이 반복됐습니다. 연말 행사와 여러 고객사의 이벤트가 겹치면서 주문 도메인에 트래픽이 급격히 몰린 적이 있었고, 주문·결제·재고가 동시에 맞물린 상황이라 단일 팀만으로는 대응하기 어려웠어요. 이때 아임웹에서는 문제를 특정 팀의 책임으로 한정하지 않고, 서비스 전체 흐름을 기준으로 대응 방식을 다시 정리했습니다.
여러 스쿼드의 백엔드 엔지니어들이 함께 모여, 어디에서 병목이 생기고 있는지를 서비스 전체 흐름 기준으로 다시 짚는 것부터 시작했어요. 각자의 담당 영역을 바탕으로 역할을 나누고 우선순위를 맞추며 대응한 결과, 트래픽이 집중되는 상황에서도 안정적으로 처리할 수 있는 구조를 만들 수 있었습니다. 이후에는 같은 유형의 이벤트에서도 문제가 반복되지 않도록 기반을 정리했고요. 이런 선택이 가능했던 건, 문제를 혼자서 끌어안기보다 맥락을 공유하고 함께 풀어가는 방식에 익숙한 동료들이 있었기 때문이기도 합니다.
Chapter 3. 정답을 구현하는 사람보다 문제를 정의하는 사람
아임웹 백엔드 엔지니어로 합류하기 위해 가장 필요한 역량이나 일하는 태도는 무엇일까요?
저희가 함께 일하면서 공통적으로 느끼는 건, 아임웹에서는 기술적인 기본기와 완성도를 전제로 그 위에서 문제를 어떻게 바라보느냐가 더 중요해진다는 점이에요. 정해진 답을 빠르게 구현하는 문제보다 이 상황을 어떻게 정의해야 하는지부터 함께 고민해야 하는 경우가 더 많거든요.
그래서 저희가 중요하게 보는 태도는 대략 이 세 가지로 모아져요.
왜 지금 이 선택이 필요한지, 되돌릴 수 있는 선택과 그렇지 않은 선택은 무엇인지를 먼저 구분하려는 태도를 중요하게 봅니다. 완벽한 설계보다도 실패를 감당할 수 있는 판단과 그 다음 선택으로 이어갈 수 있는 감각이 더 중요하다고 생각해요.
그렇다면, 어떤 일하는 방식의 사람일수록 이 환경에 잘 몰입하나요?
이 환경에 잘 맞는 분들의 공통점을 보면 문제를 빨리 해결하는 데서 멈추지 않고, 왜 이런 문제가 생겼는지를 이해하고 정의하는 과정까지 함께 가져갑니다. 요구사항을 곧바로 만들기보다 그 뒤에 있는 맥락을 함께 정리하고 선택지를 좁혀가는 과정 자체를 일의 일부로 받아들이는 편이죠.
또 하나는 아임웹에서는 문제를 개인의 숙제로 가져가기보다 팀 안에서 맥락을 공유하며 함께 풀어가는 방식을 기본으로 둔다는 점이에요. 그래서 혼자 문제를 깔끔히 해결하는 능력보다 이해되지 않은 지점을 그대로 두지 않고 드러내며 함께 풀어가려는 태도를 더 중요하게 봐요.
그래서 이곳에 잘 맞는 백엔드 엔지니어는 불확실한 상황에서도 문제를 정의하고 팀과 함께 선택을 만들어갈 수 있는 사람에 가깝다고 느껴요.
반대로 도전적으로 느껴질 수 있는 부분도 있을까요?
해야 할 일이 명확하게 정리돼 있고, 정답이 빠르게 주어지는 환경을 선호한다면 다소 답답하게 느껴질 수 있어요. 여기서는 ‘주어진 일을 정확히 처리하는 것’보다 아직 정리되지 않은 문제를 팀과 함께 구체화해 가는 시간이 더 자주 필요하거든요.
업무의 경계를 바라보는 방식에서도 차이가 있어요. 하나의 기술적 선택이 다른 팀이나 서비스의 기준으로 이어지는 경우가 많다 보니, 지금 맡은 작업만 깔끔하게 끝내기보다 이 선택이 이후에 어떤 영향을 남길지까지 함께 고민하는 상황이 자연스럽게 생깁니다. 이런 논의와 조율을 일의 일부로 받아들이면 비교적 편하게 적응할 수 있지만 역할과 성과가 또렷이 분리된 환경을 기대한다면 에너지가 더 들 수 있어요.
백엔드 엔지니어들이 공통으로 중요하게 지키는 기준이 있다면 무엇인가요?
판단의 출발점은 늘 같습니다. 이 선택이 고객에게 어떤 영향을 주는가예요. 장애나 실패를 완전히 없앨 수는 없다고 보기 때문에, 실패를 전제로 하되 고객 경험이 크게 흔들리지 않도록 만드는 구조를 기본값으로 둡니다. 문제가 생겼을 때 얼마나 빠르게 감지할 수 있는지, 그리고 되돌릴 수 있는 선택인지는 항상 함께 고려하고요.
또 하나 중요한 기준은 특정 개인의 주의나 숙련도에 기대지 않아도 되는 구조인지입니다. ‘아는 사람만 조심해서 써야 하는 시스템’보다는 실수가 발생하더라도 고객 피해로 바로 이어지지 않도록 막아주는 선택을 하려고 해요. OpenAPI나 내부 플랫폼을 설계할 때도, 내부적으로 얼마나 편한가보다 이 선택이 고객 브랜드의 운영을 방해하지 않는지를 먼저 봅니다.
백엔드 엔지니어로서, 아임웹에서만 얻을 수 있는 경험이 궁금해요.
아임웹에서의 백엔드 경험을 한 가지로 꼽자면 불확실한 상황에서 무엇을 기본값으로 둘지 스스로 판단하는 감각을 실제 환경에서 계속 단련하게 된다는 점이에요. 문제를 한 번 해결하는 데서 끝나는 게 아니라 같은 상황이 다시 와도 전체 서비스에 영향을 주지 않도록 선택을 바꾸고 구조를 설계하는 과정을 반복하게 됩니다.
이런 경험을 쌓다 보면 백엔드 엔지니어의 역할도 자연스럽게 넓어집니다. 기능을 구현하는 사람을 넘어, 이 선택이 고객에게 어떤 결과로 남을지까지 책임지는 사람에 가까워지죠. 아임웹에서는 이런 판단을 가정이나 문서 속이 아니라, 실제 고객 브랜드의 운영과 성과 안에서 계속 확인하게 됩니다. 기술적인 결정이 곧 고객의 성과나 리스크로 이어지는 상황을 직접 겪으며 성장할 수 있다는 점은 백엔드 엔지니어에게 쉽게 얻기 어려운 경험이라고 생각해요.
Chapter 4. 다음 성장을 함께 그릴 동료에게
새 동료와 함께 이루고 싶은 목표가 있다면요?
새 동료와 함께 이루고 싶은 목표는 아임웹의 성장이 더 이상 백엔드의 제약이나 부담으로 느껴지지 않는 단계까지 플랫폼을 끌어올리는 것입니다. 트래픽이 늘고 사용 패턴이 복잡해져도 특정 순간의 부하나 장애가 전체 서비스로 번지지 않는 구조를 만드는 데 집중하고 있어요. 그 과정에서 엔지니어의 시간이 문제 수습에 소모되기보다, 제품 개선과 실험에 쓰일 수 있는 환경을 만드는 것을 중요하게 보고 있습니다.
제품 경험 측면에서도 방향은 분명합니다. 대형 이벤트나 성수기 같은 까다로운 상황에서도 고객이 불안함을 느끼지 않는 플랫폼, 언제 사용해도 일관된 성능과 신뢰를 제공하는 기본값을 만드는 것. 이 안정성과 예측 가능성이 아임웹의 경쟁력이 되고 더 많은 시도와 확장을 가능하게 하는 기반이 되기를 기대하고 있어요.
마지막으로, 지원을 고민하는 분들께 한마디 부탁드려요
경연 이해되지 않는 부분을 그냥 넘기지 않고 끝까지 질문하고, 실패를 두려워하기보다 그 안에서 배우며 구조를 더 나아지게 만들고 싶은 분이라면 분명 많은 성장을 경험하실 수 있을 거예요. 완벽한 준비나 화려한 기술 스택보다, 문제를 대하는 태도가 훨씬 더 중요하다고 느껴요.
주승 “이걸 이렇게 만들어주세요”보다 “이 문제를 왜 풀어야 하는지”, “이 선택이 고객에게 정말 도움이 되는지”를 함께 고민하는 시간이 많아요. 정답 없는 문제를 풀어가는 과정 자체에서 재미를 느끼는 분이라면 의미 있는 경험이 될 거라고 생각합니다.
성국 지금 알고 있는 기술을 적용하는 데서 멈추기보다, 이해되지 않는 문제를 끝까지 파고들고 이 선택이 다음 단계에서도 맞는지 고민하는 과정이 반복돼요. 그런 고민을 팀과 나누며 성장하고 싶은 분이라면 굉장히 밀도 높은 경험을 하실 수 있을 거예요.
아임웹 백엔드 엔지니어로 합류하여 문제 해결을 경험해보세요
🚀 브랜드의 '시작'과 '성장'을 책임지는
Back-end Engineer 채용 공고 바로가기
🧑💻 아임웹 팀의 기술력을 책임지는
Back-end Engineer (Platform) 채용 공고 바로가기