AI 시대 개발자 생존 가이드

내 코드가 성과를 만들었다는 걸
어떻게 증명할까?

통제변인·조작변인에서 출발해 토스의 실험 설계, 가역/비가역 개념, AI의 한계, 그리고 프론트엔드 개발자의 커리어 전략까지 — 이 세션의 흐름을 쉽게 정리했습니다.

실험 설계 커리어 전략 AI 시대 2026.09.03
01

문제: "내 덕분"이라는 걸 어떻게 알아?

토스애즈가 200ms를 줄였더니 이탈률이 낮아졌다. 정말 성능 때문일까? 그 시점에 광고 콘텐츠가 더 잘 맞아진 것일 수도 있다.

쉬운 비유

오늘 기분이 좋다. 날씨가 맑아서일까, 아침을 먹어서일까?
날씨가 맑은 날에 아침도 먹었다면, 둘 중 무엇 때문인지 알 수 없다.
이게 통제변인이 없는 상태다.

성능 200ms 단축
→
이탈률 감소 📉
→
이것도 바뀜
광고 품질 ↑
⚠️
Before/After 비교만으로는 인과 증명 불가

배포 시점에 다른 것도 함께 바뀔 수 있다 — 계절성, 타겟팅 개선, 경쟁사 이슈 등. 이걸 분리하지 않으면 "내 덕분"이 아니라 "그 시기와 겹쳤을 뿐"이다.

핵심 정리

인과관계를 증명하려면 "다른 모든 것은 똑같고, 내가 바꾼 것만 달랐다"는 구조가 필요하다.

02

해결: A/B 테스트 — 무작위로 나눈다

같은 시점에 무작위로 두 그룹을 만든다. 외부 변수는 양쪽에 동등하게 작용하므로, 결과 차이 = 내 변경 덕분이라고 말할 수 있다.

쉬운 비유

반 학생 60명을 주사위로 무작위로 나눠 30명씩.
A반: 새 교과서 / B반: 기존 교과서
날씨, 선생님, 시험 날짜는 동일.
시험 점수 차이 = 교과서 차이라고 말할 수 있다.

Control 그룹

기존 방식 유지

외부 변수의 영향을 동등하게 받는 비교 기준점. "원래 어땠는지"를 동시에 측정한다.

Treatment 그룹

변경 사항 적용

내가 바꾼 것만 다르다. 두 그룹의 지표 차이가 곧 변경의 효과다.

🔑
무작위 배정이 핵심

랜덤하게 나눠야 "A 그룹엔 우연히 충성 고객이 더 많았다" 같은 편향이 없어진다. 무작위가 아니면 비교가 의미 없다.

03

토스는 어떻게 하나? — TUBA & ABC 테스트

토스는 단순 A/B가 아닌 ABC 테스트를 쓰고, 성공 지표와 가드레일 지표를 동시에 본다.

TUBA란?

Toss User Behavior Analyzer — 푸시 발송, 실험 세팅, 분석을 하나의 플랫폼에서. 전체 사용자의 6%를 무작위로 뽑아 실험에 배정한다.

🔵

Control

기존 방식 그대로. 비교 기준점.

🟡

Variant 1 (보수적)

작은 변화. 안전한 방향.

🟢

Variant 2 (진보적)

큰 변화. 과감한 방향.

실제 사례: 푸시 알림 "연속 무반응 N번이면 발송 중단" 기준을 조작변인으로. 두 N값을 동시에 2개월 실험 → 보수/진보 둘 다 CTR +4%p 개선, 발송량 감소에도 총 클릭 유지.

이중 지표 체계 — 핵심 통제 장치

지표 유형역할구성
✅ 성공 지표 조작변인의 효과 측정 실험마다 다름 (CTR, 전환율 등)
🛡️ 가드레일 지표 핵심 비즈니스 건전성 통제 앱 오픈 AU, 서비스별 AU, 매출
🚨
원칙: 성공 지표가 올라도 가드레일이 악화되면 채택하지 않는다

CTR이 높아졌어도 매출이 떨어지면 버린다. 이게 "광고 품질이 아닌 성능 때문"이라는 인과를 가능하게 하는 구조다.

04

A/B 테스트가 불가능할 때 — MTVi & DID

서비스 전체 가치처럼 실험 설계 자체가 어려운 경우, 토스는 인과추론 방법을 따로 쓴다.

LTV의 한계

기존 방식

  • 3~5년 장기 전제 필요
  • 투자 회수 주기와 안 맞음
  • 어느 서비스 덕분인지 구분 불가
MTVi — 토스 자체 개발

새 방식

  • "향후 1년간 인과적 증분 재무가치"
  • 직접 이용 가치 + 크로스 액티베이션
  • CAC 초과 불가 원칙의 정량 기준
DID (Difference-in-Difference) 란?

신규 유저 그룹 vs 미사용자 그룹(통제군)을 연령대·활동 규모로 매칭해 특성 차이를 보정한다. "이 서비스를 경험하지 않았다면 어땠을지"와 비교해서 순수 기여분을 추출한다.

광고: Incrementality 분석

광고 노출 / 비노출 / 클릭 3그룹을 동시에 비교하고, 퍼스트파티 결제 데이터로 혼동변수를 통제한다.
→ ETF 캠페인 실제 결과: 클릭 유저군 보유량 77.1% 증가를 인과적으로 입증.

05

고부하 vs 저부하 — 언제 무엇에 집중하나?

환경에 따라 개발자가 집중해야 할 것이 달라진다. 이게 "기술적 판단력"의 핵심이다.

쉬운 비유

식당이 손님으로 꽉 찼을 때: 주방 속도·테이블 회전이 매출을 결정한다. 인테리어 바꿀 시간이 없다.
식당이 한산할 때: 메뉴를 자주 바꾸고 실험해봐야 한다. 속도보다 아이디어가 중요하다.

🔴 고부하 환경

성능이 비즈니스 리스크

기기 파편화, 메인스레드 차단, 메모리 부족이 실제 이탈·매출 손실로 이어진다.

→ 렌더링 성능 최적화 자체가 성과

🟢 저부하 환경

속도보다 실험이 중요

성능 병목이 없다. 오버엔지니어링은 낭비. 빠른 A/B 테스트를 지원하는 구조가 진짜 성과다.

→ 실험 지원 아키텍처가 성과

저부하 환경의 실험 지원 패턴

🧩

Headless 컴포넌트

UI와 비즈니스 로직을 분리. 실험 대상 로직만 교체 가능.

📦

디자인 시스템

UI를 독립 패키지로 분리해 출시 속도를 높인다.

🎯

선언적 퍼널

다단계 흐름을 코드 수정 없이 설정으로 변경.

🚩

Feature Flag

실험군/대조군 로직을 런타임에 분기하고 쉽게 병합.

💡
"부하"는 진짜 축이 아니라 프록시다

더 정확한 두 축: ① 실패의 가역성(되돌릴 수 있나?) + ② 병목의 위치(성능인가, 실험 속도인가?). 부하가 낮아도 B2B·규제 산업이면 다른 선택이 맞다.

백엔드도 저부하면 같은 방향인가?

방향은 같고, 구현이 다르다.
FE 실험 = 분기 + 독립 배포
BE 실험 = 분기 + 독립 배포 + 영속 상태 관리 + 롤백 경로
🗄️
BE 실험 설계 시 반드시 먼저 답할 질문

"이 실험이 DB에 무엇을 쓰는가? 롤백하면 그 데이터를 어떻게 처리할 것인가?"
FE는 롤백하면 끝이지만, BE는 DB에 쓴 데이터가 남는다.

06

가역성 — 되돌릴 수 있나?

"되돌릴 수 있나"가 아키텍처와 커리어 선택을 모두 설명하는 핵심 개념이다.

✏️ 가역적

실수해도 되돌릴 수 있음

  • UI 버그 배포 → 롤백으로 끝
  • Feature Flag 잘못 켬 → 다시 끄면 끝
  • 실험 중단 → 기존 경로로 복귀
🖊️ 비가역적

한 번 발생하면 못 되돌림

  • 결제 중복 → 환불해도 신뢰 손상 남음
  • DB 컬럼 삭제 → 데이터 복구 불가
  • 이메일 오발송 → 수신된 메일 회수 불가

FE vs BE 비가역 요소 비교

영역비가역성의 형태발현 속도실제 예시
FE 지각·신뢰 손상, 외부 의존성 즉각적 개인정보 노출, 앱스토어 평점 하락, 공개 API 설계 변경 불가
BE 데이터 손실, 금전, 법적 책임 지연됨 (조용히 누적) DB 삭제, 암호화 키 유출, 결제 중복, 이메일 오발송
💡
BE 비가역의 특징: 조용하고 늦게 터진다

FE 버그는 사용자가 바로 본다. BE 데이터 정합성 문제는 수개월 뒤 감사에서 발견되기도 한다. 폭발 반경이 더 크다.

07

AI가 못하는 영역 — 비가역적 판단

AI의 한계는 "가역적이냐 비가역적이냐"가 아니다. 진짜 경계는 "책임을 질 수 있나"다.

쉬운 비유

네비게이션은 최적 경로를 알려준다. 하지만
"이 도로가 지금 안전한가, 이 길로 가도 될까"는 운전자가 판단한다.
AI는 네비게이션이다. 결정은 운전자 몫.

AI가 잘함AI가 못함
가역적 코드 생성, 테스트, 롤백 자동화 팀 역학 판단, "이 롤백이 정치적으로 옳은가"
비가역적 리스크 분석, 패턴 감지, 체크리스트 최종 결정, 책임 수용, 이해관계자 설득
🎯
AI는 비가역적 결정을 "준비"하는 데 탁월하다

리스크 분석, 옵션 나열, 체크리스트 — 여기까진 AI가 잘한다. 하지만 결정 자체와 결과를 떠안는 것은 인간의 영역이다. ① 책임 귀속 불가, ② 도메인 암묵지 부재.

08

커리어 결론 — 백엔드로 전향해야 할까?

프론트엔드에 가역 요소가 많으니 AI에 취약하고, 백엔드가 더 안정적이지 않을까? 데이터로 검증했다.

❌
"BE가 더 안정적"이라는 전제가 데이터로 뒷받침되지 않는다

AI 대체 위험도 실측치: 프론트엔드 35% = 백엔드 35%. 동일하다. FE 채용이 24% 줄고 BE가 14% 줄어 격차는 있지만, 이건 레벨 문제이지 직군 문제가 아니다.

전향이 나쁜 이유

BE로 가는 것의 실제 비용

  • 이커머스 도메인 지식 1~2년 리셋
  • AI가 대체하는 건 스택이 아닌 "코딩 역할"
  • 대기업 IT 연봉은 연차 기반, 스택 무관
  • BE 단순 CRUD도 레드오션
FE가 유리한 이유

이커머스 FE의 실제 포지션

  • 전환율 0.1% = 연간 수십억 매출 차이
  • AI 개인화·동적 UI 가장 빠른 도입 영역
  • 플랫폼 다양화로 신규 실험 계속 증가
  • 비즈니스 임팩트를 수치로 말할 수 있는 자리

레이어별 AI 위협도

레이어FE 예시BE 예시AI 위협
Boilerplate 조립마케팅 페이지, 단순 UI표준 CRUD API🔴 높음
패턴 적용컴포넌트 생성API 통합🟡 중간
복잡한 엔지니어링접근성, 상태 관리, 성능분산 시스템, 보안🟢 낮음
판단 레이어비즈니스 지표 설계, 실험아키텍처 결정🟢 매우 낮음
결론

지금 해야 할 것: 전향이 아닌 레이어 업

기술 스택을 바꾸는 게 아니라, 같은 자리에서 더 높은 판단 레이어로 올라가는 것이 답이다.

백엔드 전향은 레드오션에서
다른 레드오션으로 이동하는 것

이커머스 FE 전문성은 지금 쌓고 있는 가장 희소한 자산이다. 버리지 말고 판단 레이어로 올라가자.

1
지금~1년: 임팩트 수치화 내 작업이 전환율·이탈률에 미친 영향을 수치로 기록. A/B 테스트 설계에 직접 참여.
2
1~3년: 전향이 아닌 확장 BE 기초(API 설계, DB 쿼리, SSR)를 FE 위에 쌓는다. API부터 UI까지 소유하는 사람이 된다.
3
3년~: 도메인 + 기술 브릿지 이커머스 비즈니스 맥락과 기술 트레이드오프를 동시에 소유. AI가 대체할 수 없는 포지션.
이 세션의 핵심 통찰

AI 시대 개발자의 진짜 자산은 "코드 작성"이 아니라 비즈니스 맥락 속에서 비가역적 판단을 내리고 책임지는 능력이다. 그 판단력을 쌓는 데는 FE든 BE든 관계없다.