애드테크 리더 마켓탭 CTO 서성호 인터뷰
퍼스트파티 데이터 시대, 애드테크 경험을 바탕으로 CRM 마케팅 솔루션을 설계하는 마켓탭 CTO와의 인터뷰
Dec 26, 2025
Contents
Q1. 간단히 자기소개 부탁드립니다.Q2. 개발자로서의 첫 커리어는 어떻게 시작했나요?Q3. 다음으로는 어떤 문제를 풀고 싶으셨나요?Q4. 마켓탭에 합류하게 된 계기는 무엇이었나요?Q5. 마켓탭 개발팀은 어떤 방식으로 일하나요?Q6. 제품을 만들 때 중요하게 보는 또 다른 기준은 무엇인가요?Q7. “이건 마켓탭만 할 수 있다”고 생각하는 기술적 차별점은 무엇인가요?Q8. 이런 구조를 설계하게 된 배경은 무엇이었나요?Q9. 마켓탭 제품은 어떤 방향으로 발전하고 있나요?Q10. 개발팀이 추구하는 엔지니어링 방향은 무엇인가요?Q11. 앞으로 1~2년 안에 가장 도전적인 목표는 무엇인가요?Q12. 개발팀은 어떤 동료와 함께하고 싶으신가요?Q1. 간단히 자기소개 부탁드립니다.
안녕하세요, 마켓탭에서 제품 개발을 맡고 있는 서성호입니다.
현재는 개발을 중심으로 제품 기획과 기술 방향 설정, 그리고 개발 조직 운영까지 함께 맡고 있어요.
마케터가 데이터를 더 잘 이해하고, 실제 마케팅으로 옮길 수 있도록 제품 구조를 설계하는 데 관심이 많습니다.
겉으로 보이는 기능보다도, 안정성과 확장성 같은 기본기가 제품의 신뢰를 만든다고 생각하며 개발하고 있습니다.
Q2. 개발자로서의 첫 커리어는 어떻게 시작했나요?
저는 서울대학교 컴퓨터공학부 재학 중이던 3학년 때 산업기능요원으로 처음 회사 생활을 시작했어요.
첫 회사는 Ad-Tech 분야에서 MMP, SSP, DSP, CDP, CRM 같은 다양한 솔루션을 운영하던 IGAWorks였습니다.
처음 Ad-Tech 도메인을 접했을 때는 솔직히 쉽지 않았어요.
어트리뷰션, 룩백 윈도우, 포스트백 같은 개념들이 머리로는 이해되는데, “이게 실제로 어떤 가치를 만드는 거지?”라는 질문이 계속 들더라고요.
그런데 일을 하다 보니 점점 체감이 됐어요.
하루에도 수천만 건씩 들어오는 광고 이벤트 하나하나가 광고비 정산으로 이어지고,
그 결과에 따라 마케팅 전략이 바뀌고, 그게 다시 비즈니스 성과로 연결되는 구조더라고요.
입사 후 3년 정도는 MMP 솔루션인 애드브릭스의 차세대 버전, ‘애드브릭스 리마스터’를 개발했어요.
광고 트래픽을 처리하고, 어트리뷰션을 계산하고, 포스트백을 통해 리타겟팅 광고가 정확하게 나가도록 만드는 일을 했죠.
이때 느꼈던 건, “이 시스템이 잠깐만 잘못돼도 누군가는 실제로 돈을 더 쓰게 된다”는 부담감이었어요.
그래서 자연스럽게 안정성이나 성능에 굉장히 집착하게 됐고, 지금까지도 그 기준은 제 안에 꽤 강하게 남아 있어요.
Q3. 다음으로는 어떤 문제를 풀고 싶으셨나요?
이후에는 CDP 솔루션인 ‘디파이너리’를 초기 기획 단계부터 개발했습니다.
이때는 이전과는 조금 다른 고민을 많이 했던 것 같아요.
단순히 데이터를 더 많이 쌓는 게 아니라, 흩어져 있는 고객 데이터를 어떻게 하나로 통합해야
마케팅에서 의미 있는 액션이 시작될 수 있을까에 대한 고민이었어요.
실제로 많은 기업들이 데이터를 이미 충분히 가지고 있었거든요.
문제는 그 데이터가 채널별, 시스템별로 나뉘어 있어서 사람이 한눈에 이해하기도 어렵고,
결국 액션으로 이어지지 못한다는 점이었어요.
그래서 디파이너리를 만들면서는 “이 고객을 한 명의 사람으로 이해할 수 있는 뷰를 만드는 것”에 집중했습니다.
그렇게 정리된 데이터를 처음 본 고객사 담당자분들이 “아, 이제 데이터가 무슨 말 하는지 알겠다”라고 말씀해주실 때, 마케팅에서 진짜 가치는 여기 있구나 싶었던 기억이 납니다.
Q4. 마켓탭에 합류하게 된 계기는 무엇이었나요?
Ad-Tech 쪽에서 오래 일하다 보니까, 어느 순간부터는 계속 비슷한 질문을 스스로에게 하게 되더라고요.
“광고 예산은 계속 커지는데, 왜 마케팅 의사결정은 여전히 감에 의존하는 경우가 많을까?”
특히 국내 시장에서는 데이터는 분명히 쌓이고 있는데, 막상 그걸 제대로 활용하지 못하는 구조가 반복된다고 느꼈어요.
게다가 3rd party 데이터 규제가 점점 강화되면서 결국 브랜드가 직접 모은 1st party 데이터가 중심이 될 수밖에 없겠다는 생각이 들었고요.
이 문제를 기술적으로, 그리고 제품으로 풀어보고 싶다는 생각을 하던 중에 지금의 성훈님, 창희님을 만나게 됐어요.
두 분이 광고·마케팅 현장에서 직접 겪은 문제 이야기들을 듣는데, 제가 기술적으로 느끼고 있던 문제랑 너무 잘 맞더라고요.
“툴을 하나 더 만드는 게 아니라, 마케터가 데이터를 바라보는 방식을 바꿔보자”
이 방향에 공감하면서 마켓탭을 함께 만들게 됐습니다.
Q5. 마켓탭 개발팀은 어떤 방식으로 일하나요?
마켓탭 개발팀은 완성도보다 방향성을 먼저 맞추는 팀이에요.
처음부터 완벽한 기획서를 만들기보다는, “이게 진짜 쓰일까?”를 최대한 빨리 확인하려고 해요.
예를 들면, 오디언스 생성 기능을 처음 만들 때도 처음부터 복잡한 조건 빌더를 만들지 않았어요.
대신 실제 마케터 분들이 어떤 조건을 제일 많이 쓰는지 로그부터 봤고, 가장 많이 반복되는 몇 가지 패턴만 먼저 기능으로 만들었습니다.
막상 운영을 시작해보면 “이건 생각보다 안 쓰네요” “이건 매번 수동으로 하니까 너무 번거로워요” 같은 피드백들이 바로 나와요.
그때부터가 진짜 개발 시작이라고 생각해요. 고객이 실제로 쓰면서 불편해하는 지점을 기준으로 기능을 다듬어갑니다.
Q6. 제품을 만들 때 중요하게 보는 또 다른 기준은 무엇인가요?
네, 또 하나 중요한 기준은, 항상 “이걸 나중에 AI로 바꿀 수 있을까?”를 생각하면서 만든다는 점이에요.
처음에는 사람이 직접 설정하도록 두되, 그 과정 자체를 데이터로 남기고 이후 자연어 기반 설정이나 자동 추천으로 확장할 수 있도록 구조를 잡아둡니다.
예를 들어 CRM 솔루션에 익숙하지 않은 마케터 분들은 ‘오디언스’라는 개념 자체가 처음인 경우가 많아요.
실제로 사용 방법이 궁금해 문의를 주시는 경우도 꽤 있었고요.
이런 상황을 보면서 “사용법을 문서로 설명하는 것보다, 제품 안에서 바로 이해할 수 있게 도와주는 게 맞겠다”라고 판단했어요.
그래서 오디언스 AI 모듈이 조건 설정 방법을 설명해주고, 원하는 대상만 자연어로 입력하면 복잡한 조건을 자동으로 구성해주는 기능을 구현했습니다.
이후에는 마케터 분들이 가이드를 하나하나 찾아보는 공수도 줄었고, 저희 쪽 문의 대응이나 CS도 눈에 띄게 줄었어요.
이 과정 역시 고객분들이 실제로 사용하는 흐름을 보고, 피드백을 들으면서 “어디를 도와주면 좋을지”를 고민한 끝에 나온 결과였습니다.
Q7. “이건 마켓탭만 할 수 있다”고 생각하는 기술적 차별점은 무엇인가요?
고객사분들을 만나면 거의 빠지지 않고 나오는 질문이 있어요.
“수십만, 수백만 건을 보내도 진짜 문제 없나요?” “중복 발송되거나 누락되지는 않나요?” 같은 질문이요.
이 질문을 들을 때마다, 이전에 분명히 안 좋은 경험을 하셨구나 싶어요.
마켓탭은 처음부터 수십만, 수백만 건의 메시지 발송이 동시에 발생하는 상황을 가정하고 백엔드와 인프라 구조를 설계했어요.
대량 발송 시 특정 지점에 트래픽이 몰리지 않도록 오디언스 계산, 발송 트리거, 실제 전송 단계를 분리했고,
실시간 처리가 필요한 영역과 비동기로 충분한 영역을 명확하게 나눠 한 단계의 지연이나 장애가 전체 발송에 영향을 주지 않도록 했습니다.
Q8. 이런 구조를 설계하게 된 배경은 무엇이었나요?
이런 구조를 선택한 데에는 이전 Ad-Tech 솔루션을 개발하면서 겪었던 경험도 크게 작용했어요.
실시간 처리에 집착하다 보니 비용은 계속 커지고, 조금만 트래픽이 몰려도 안정성이 흔들리는 구조를 여러 번 봤거든요.
그래서 마켓탭에서는 모든 걸 실시간으로 처리하지 않아도 되는 영역은 과감하게 분리하자는 판단을 했고, 그에 맞는 아키텍처를 처음부터 설계했습니다.
AWS 기반의 서버리스 아키텍처를 선택한 것도 같은 이유예요.
트래픽이 없을 때는 비용을 최소화하고, 대량 발송이 필요한 순간에는 자연스럽게 확장될 수 있는 구조를 만들고 싶었어요. 대규모 배치 작업은 Airflow 기반 스케줄링으로 안정적으로 처리하고 있고요.
그리고 기능을 추가할 때마다 로드 테스트와 회귀 테스트를 기본으로 진행합니다.
이 과정을 통과하지 못하면 아무리 좋은 기능이어도 배포하지 않아요.
개발 속도를 조금 늦추더라도, 장기적으로는 제품에 대한 신뢰를 지키는 게 더 중요하다고 생각합니다.
Q9. 마켓탭 제품은 어떤 방향으로 발전하고 있나요?
같은 데이터를 보더라도 마케터마다 해석은 정말 다르더라고요.
그래서 마켓탭은 “정답을 알려주는 제품”보다는 각자의 상황에 맞는 의사결정을 도와주는 제품이 되고 싶어요.
초기에 CRM을 도입하시는 많은 기업들이 커머스 산업군을 기준으로 만들어진 정형화된 기능과 지표에 맞춰서 자신들의 문제를 억지로 끼워 맞추는 경우를 많이 봤거든요.
그러다 보니 정작 중요한 고민은 남아 있는데, 제품이 제공하는 틀 안에서만 사고하게 되는 경우도 많았고요.
그래서 마켓탭에서는 특정 산업군의 정답을 먼저 정해두기보다는, 각 고객사가 어떤 비즈니스 구조를 가지고 있고 어떤 지점에서 마케팅 문제가 발생하고 있는지를 먼저 이해하려고 합니다.
그에 맞게 데이터 구조와 텍소노미를 설계하고, 필요하다면 컨설팅부터 기능 지원까지 함께 풀어가는 방식을 선택했어요. 이런 방향성을 바탕으로 여러 도메인에서 공통적으로 활용할 수 있는 형태로 Data Lake를 설계했고,커머스 외 산업군에서도 무리 없이 확장할 수 있는 구조를 만들었습니다.
제품을 만들다 보면 마케터 분들이 반복해서 막히는 지점들이 보이는데요. 마켓탭은 그 고민을 줄이는 쪽으로 기능을 계속 보완하고 있습니다.
마케터가 “왜 안 되지?”를 고민하는 시간은 줄이고, “다음엔 뭘 해볼까?”에 더 많은 시간을 쓸 수 있게 만드는 것, 그게 마켓탭이 지향하는 방향입니다.
Q10. 개발팀이 추구하는 엔지니어링 방향은 무엇인가요?
저희는 기술 자체보다 기술이 만들어내는 결과를 더 중요하게 생각해요.
어떤 기술이든 문제 해결에 분명한 도움이 된다고 판단되면 그게 최신 기술이든, 익숙한 기술이든 가리지 않습니다. 충분히 검증한 뒤에는 오히려 빠르게 도입하는 쪽에 가깝고요. 다만 “새롭다”는 이유만으로 선택하지는 않아요.
이 기술이 지금의 문제를 얼마나 잘 풀어주는지, 그리고 1~2년 뒤에도 유지·확장 가능한 구조인지까지 함께 봅니다. 확장성과 안정성을 기본값으로 두되, 비즈니스와 직접 연결되는 기술이라면 과감하게 실험하고 빠르게 제품에 녹여내는 것,
그게 저희 개발팀이 추구하는 엔지니어링 방향입니다.
Q11. 앞으로 1~2년 안에 가장 도전적인 목표는 무엇인가요?
AI가 발전할수록, 오히려 정제된 1st party 데이터의 중요성은 더 커진다고 생각해요.
AI가 아무리 똑똑해져도, 그 판단의 출발점이 되는 데이터가 정리되어 있지 않으면 결국 의미 있는 액션으로 이어지기 어렵더라고요.
마켓탭이 처음에 CRM 메시지 솔루션으로 시작한 것도 같은 이유였어요.
고객과 직접 연결되는 접점에서 1st party 데이터를 가장 명확하게 쌓고, 그 데이터를 실제 액션으로 연결할 수 있는 영역이었기 때문입니다.
다만 마케터 분들의 고민은 메시지 발송 하나로 끝나지 않는 경우가 훨씬 많았어요. “이 고객을 다시 불러오려면 어떤 채널이 좋을까?” “CRM에서 반응이 좋았던 타겟을 광고에서도 활용할 수는 없을까?” 같은 질문들이 자연스럽게 이어졌고요.
그래서 마켓탭은 메시지 채널에만 머무르기보다는, 카카오톡, 문자메시지, 앱푸시 같은 CRM 채널과 메타, 그리고 앞으로는 구글 DA 광고까지 하나의 1st party 데이터 흐름 안에서 함께 활용할 수 있도록 확장하고 있습니다.
궁극적으로는 산업군이나 브랜드별로 반복되는 마케팅 고민을 AI Agent가 일정 수준까지 대신 풀어주는 구조를 만들고 싶어요. 한 명의 컨설턴트가 직접 고민하고 제안하던 일을, AI가 수십, 수백 개 브랜드에 동시에 제공할 수 있다면 마케팅 방식 자체가 달라질 수 있다고 믿고 있습니다.
Q12. 개발팀은 어떤 동료와 함께하고 싶으신가요?
빠르게 만들고, 시장에 던지고, 고객 반응을 보면서 다시 배우는 과정을 즐길 수 있는 분이면 좋겠어요.
정해진 역할만 수행하기보다는, “이건 이렇게 바꾸면 더 좋아질 것 같은데요?”라고 자연스럽게 이야기할 수 있는 분이요.
마켓탭에서는 제품의 성장과 개인의 성장이 꽤 높은 확률로 함께 가요.
그 과정을 즐길 수 있는 분들과 오래 일하고 싶습니다.
Share article