Android Compose를 사용할 때 안정성(Stability) 은 결코 가볍게 넘길 수 없는 핵심 주제입니다. 안정성이 지켜져야만 Compose가 불필요한 재구성을 건너뛰고 성능을 유지할 수 있기 때문입니다. 이를 위해 개발자가 따라야 할 몇 가지 규칙이 존재하지만, 문서나 예제만으로는 모든 함정을 미리 알기 어렵습니다.이 글에서는 안정성 개념을 이미 기본적으로 이해하고 있는 개발자를 대상으로 합니다. 단순 개념 설명이 아니라, 직접 겪을 수 있는 베드 케이스(잘못 사용 한 사례) 를 통해 우리가 놓치기 쉬운 부분과 Compose 내부가 어떤 메커니즘으로 반응하는지 살펴보겠습니다.베드 케이스 실험recomposition이 발생했을 때, 일반 class, data class, @Stable, @Immutable 을 각각 적용했을 때 어떤 결과가 나타나는지 비교했습니다.Test version : kotlin 2.2.10, compose bom 2025.08.00테스트는 recomposition을 강제로 발생시키는 버튼을 포함한 TestScreen으로 구성하였습니다. 버튼을 누를 때마다 count 값이 증가하여 Column 내부가 recomposition 대상이 되도록 하여 어떤 경우에 recomposition skip 되는지 알아보겠습니다.@Composablefun TestScreen() { var count by remember { mutableIntStateOf(0) } Column { Button( onClick = { count++ }, // count 를 증가 시켜 recomposition 발생 ) { Text("count: $count") } // recomposition 대상 코드 TestClassContent(TestClass("$count TestClass Text")) }}class + var 프로퍼티 조합일반 class 와 가변 형태에서 테스트 결과 입니다. 테스트를 진행하는 Content 내부에는 Row 로 감싸진 Text Component 를 사용하며, TestClass 의 String를 통해 text 를 그리게 되어있습니다.class TestClass( var text: String,)@Composablefun TestClassContent(content: TestClass) { Row(modifier = Modifier.padding(10.dp)) { Text(text = content.text) }}val testClass by remember { mutableStateOf(TestClass("TestClass Text")) }TestClassContent(testClass)TestClassContent(TestClass("New TestClass Text"))TestClassContent(TestClass("$count TestClass Text"))rememb

데이터 자동 생성으로 생산성 향상 : Playwright로 3분 걸리던 계약 생성을 30초로!안녕하세요 여기어때컴퍼니 QA2팀 스칼렛입니다.오늘은 제가 Playwright를 활용하여 검증 과정에서 겪었던 비효율을 해소하고, 생산성을 극대화했던 경험을 공유하고자 합니다. 특히, 반복적인 수동 작업에 지쳐있던 분들이라면 이 글이 도움이 될 것이라고 생각합니다.기능 구현의 배경: ‘입점 계약’ 도입과 번거로움제가 참여했던 프로젝트는 파트너의 입점 계약 절차를 개선하는 내용이었습니다.기존에는 ‘내부 관리자 도구의 제휴점 정보’에서 직접 입력할 수 있었지만, 이제는 ‘입점 계약 플랫폼’을 통해서만 입력이 가능해졌습니다. 이 ‘입점 계약’은 수동으로 생성하거나, 이싸인온(eSignon, 전자계약)을 통해서만 생성할 수 있는데요.문제는 검증을 위해 필요한 계약 데이터를 수동으로 생성하는 데 있었습니다.숙소 카테고리 별로 계약 서식도 다르고 계약 내 입력 할 항목들도 많아 계약 한 건을 만드는 데 약 2~3분 정도가 소요되었고, 이는 단순 반복 작업의 연속이었습니다.이번에는 혼자서 프로젝트를 진행하여 제한된 시간을 효율적으로 활용하는 것이 매우 중요했기 때문에, 이러한 단순 작업을 줄이고 핵심적인 검증 작업에 더 집중하기 위해 데이터 자동 생성에 대해서 고려하게 되었습니다.왜 Playwright를 통한 자동화였나?Playwright는 웹 테스트 자동화 도구로 널리 알려져 있지만, 저는 데이터 자동 생성이라는 목표를 위해 이 도구를 선택했습니다. 테스트 자동화와 데이터 생성이라는 목적은 다르지만, Playwright의 강력한 기능들은 데이터 생성 작업에 특히 유용합니다. 제가 Playwright를 선택하게 된 이유는 다음과 같습니다.UI 레코딩 및 코드 생성: Playwright는 코드를 직접 레코딩하고 생성해주는 기능을 지원합니다. 이는 초기 개발 시간을 단축하고, UI 변경에 따른 유지보수를 더욱 쉽게 만듭니다. 로봇 프레임워크의 키워드 기반 방식은 유연하지만, Playwright의 코드 생성 방식은 직관적인 개발 경험을 제공합니다.빠른 실행 속도: Playwright는 브라우저와 직접 통신하여 Selenium보다 훨씬 빠르고 안정적으로 동작합니다. 특히 UI 레코딩 기반으로 자동화를 구축했을 때, 빠른 실행 속도는 대량의 데이터를 효율적으로 생성하는 데 필수적입니다.자동 대기(Auto-waiting): Playwright는 요소가 나타나거나 사라지는 것을 자동으로 기다려주므로, 타이밍 문제로 인한 불필요한 오류 발생 가능성이 현저히 낮아집니다. 로봇 프레임워크에서 수동으로 기다리는 명령을 추가하는 것보다 훨씬 편리하고 견고합니다.웹 테스트 자동화 도구인 Selenium 과의 비교Playwright 이전에는 웹 테스트 자동화 툴로 Selenium을 많이 사용했었는데요.표로 비교해보았습니다.→ 저는 테스트 자동화툴과 익숙하지 않았기때문에 초보자가 접근하기 쉬워야했고 codegen 기능을 통한 UI 레코딩 및 코드 생성과 빠른 실행 속도, 높은 안정성이

오늘은 우리 삶의 필수템, 스마트폰 통신이 어떻게 더 촘촘하고 안정적으로 진화하고 있는지, 그 비밀스러운 내부 이야기를 살짝 공개하려고 합니다.'트럭이 전봇대를 박았는데 왜 내 폰이 안 터지지?' 같은 아찔한 상상, 한 번쯤 해보셨죠?바로 그 문제를 해결하기 위한 저희의 눈물겨운(?) 노력과 그 결과물,'Real Impact 커버리지맵(가칭)' 탄생 스토리를 지금 바로 시작합니다!😩 "우린 한 팀인데… 왜 따로 놀았을까?" 유선팀 vs 무선팀의 동상이몽통신사의 Lastmile 구간을 담당하는 대표적인 두 개의 조직이 있습니다.하나는 전국 방방곡곡에 중계기를 설치하고 최적의 통신 커버리지를 만드는 무선 조직!이들은 마치 명당 자리를 찾는 스나이퍼처럼, 중계기 위치와 안테나 각도에 영혼을 갈아 넣죠.무선팀: "여기 언덕에 중계기 뙇! 안테나 각도 30도 틀어서 저쪽 아파트 단지까지 신호 쏴줘야지! 빵빵 터져라!"* 끊김 없는 서비스를 위해 촘촘히 박혀 있는 무선 중계기다른 하나는 이 중계기들을 거미줄처럼 엮어주는 광케이블과 유선 장비를 관리하는 유선 조직!보이지 않는 땅속, 전봇대 위에서 안정적인 데이터 길을 만드는 도로 설계자 같은 존재랍니다.유선팀: "A중계기랑 B중계기는 이쪽 라인으로 묶고, C중계기는 만약을 위해 저쪽으로 돌려서 생존 루트 확보! 절대 끊기면 안 돼!"*모세혈관과 같이 전국 방방곡곡을 연결하는 유선망(선로 인프라+장비)문제는 이 두 전문가 집단이 각자의 미션에 너무 충실했다는 것!무선팀은 전파의 도달 범위에, 유선팀은 선로의 안정적인 연결에만 집중하다 보니,정작 '하나의 광케이블이 끊어졌을 때, 실제로 어떤 지역의 고객들이 얼마나 불편을 겪을까?' 에 대한 통합적인 답을 내리기 어려웠죠. 😱💡 "만약 이 선이 끊긴다면?" 발상의 전환이 만든 혁신강남역 한복판의 통신을 책임지는 중계기 10개가 하필이면 단 하나의 광케이블에 모두 연결되어 있다면?어느 날 갑자기 포크레인이 그 케이블을 '푹' 찍는 순간… 강남역 일대는 순식간에 통신 암흑지대가 되는.... 끔찍하죠? 😱하지만 만약 그중 3개의 중계기가 다른 길(광케이블)로 연결되어 있다면 어떨까요? 속도가 조금 느려질 순 있어도 카톡이나 검색 같은 최소한의 서비스는 유지될 수 있겠죠.이것이 바로 저희가 주목한 '생존 커버리지' 의 개념입니다.저희는 이 아이디어를 현실로 만들기 위해 두 가지 핵심 데이터를 융합하였습니다.ㅇ 프론트홀 토폴로지 (Fronthaul Topology): 어떤 중계기가 어떤 유선 장비와 광케이블에 연결되어 있는지 보여주는 '족보' 데이터! 📜ㅇ Atlas 맵: T맵 데이터를 포함, 수많은 모바일 기기가 실제로 어디서, 얼마나 원활하게 서비스를 이용하고 있는지 보여주는 '실시간 민심' 데이터! 🗺️*여기서 보여주는 색깔로 해당 지역에서 서비스 받은 from. 중계기를 구분합니다.이제 마법을 부릴 시간입니다! 유선망의 '족보'와 실시간 '민심' 데이터를 지도 위에서 합치고, 한단계, 한단계 분석해보았습니다.• None Logic : 서비스 out기준 Threshold : 60% 이하 (BIN 이내 서비스 out 40% 까지는 감내하겠음)위 분석 체계를 통해서 광케이블 하나를 지도 위에서 'OFF' 시켰을 때, 실제로 통신 서비스가 단절되는 '진짜' 영향 범위를 알 수 있게 되었습니다.기존에는 지도 위에 중계기 점들만 보고 '음, 이 지역은 중계기가 많으니 괜찮겠군' 하고 막연히 추측했다면,이제는 '아니, 이 케이블 하나 끊기면 여기 아파트 단지랑 저기 쇼핑몰 전체가 서비스 불능이네!' 하고 직관적으로 리스크를 파악할 수 있게 된 거죠.*특정선로에 연계된 커버리지 현황 및 서비스 아웃 분석 화면이 'Real Impact 커버리지맵'은 단순히 위험을 보는 것에서 그치지 않습니다.(To-Be)👨‍💻 똑똑한 망 설계: 새로운 광케이블을 어디에 깔아야 가장 효율적으로 위험을 분산시킬 수 있을지, 데이터 기반의 최적의 루트를 찾습니다. (삽질 방지!)🚨 선제적 위기관리(RM): 태풍이나 화재 등 재난 상황 발생 시, 가장 취약한 지역을 미리 파악하고 자원을 집중 투입해 골든타임을 확보할 수 있습니다.👍 고객 경험 레벨업: 고객들은 이제 '운 나쁘게' 통신이 끊기는 경험을 훨씬 덜하게 될 겁니다. 보이지 않는 곳에서 저희의 데이터가 여러분의 연결을 지킬테니!!🚀 연결의 미래, 데이터가 그 길을 밝힌다이제 저희는 더 이상 유선과 무선이라는 틀에 갇혀 세상을 보지 않습니다.고객이 느끼는 '실질적인 서비스 품질'이라는 단 하나의 목표를 향해, 데이터라는 강력한 무기를 손에 쥐었죠.'Real Impact 커버리지맵'은 그 위대한 여정의 첫걸음입니다.앞으로 AI와 머신러닝을 더해 미래의 장애를 예측하고, 스스로 네트워크를 최적화하는 단계까지 나아가는 것이 저희의 최종 목표랍니다.여러분의 손안에서 펼쳐지는 끊김 없는 세상, 기대되시죠? 😉

진화한 에이닷 4.0의 개편에이닷 3.0은 MainAgent, MusicAgent, StockAgent, MediaAgent, MovieAgent의 5개의 Agnet가 각각의 대화방으로 구성으로 개별성을 가지고 있었지만에이닷은 4.0으로 개편이 진행되었고 에이닷 3.0의 여러 Agent 대화방을 하나로 통합하는 OneAgnet로 진화하였습니다.여러 Agent를 하나로 통합되었기 때문에 검증에 대한 방법도 달리 진행이 필요했고 SPeCTRA도 2.0으로 변화를 준비하게 되었습니다.시작하며: SPeCTRA 1.0의 성과와 새로운 과제• None 효과적인 LLM 품질 평가 : 도구, 기준, 그리고 적용기 톺아보기(SPeCTRA)작년에 소개해드린 SPeCTRA 1.0은 기존의 수동적이고 주관적일 수 있는 LLM 답변 품질 평가를 자동화된 'LLM-as-a-judge' 방식으로 전환한 혁신적인 시도였습니다.로컬 PC 환경에서 클라이언트 로그를 직접 파싱하고, Java 기반의 배포 툴을 통해 QA/TE는 물론 유관부서 모두가 LLM 품질 테스트를 수행할 수 있게 함으로써 테스트 리소스의 효율을 극대화했습니다.하지만 여기서 멈추지 않았습니다.에이닷 4.0이 OneAgent로 개편됨에 따라 대규모 테스트의 연속성을 확보하고, 여러 팀 간의 협업을 더욱 원활하게 하며, 물리적 디바이스 연결의 한계를 극복하기 위한 새로운 과제가 주어졌습니다.더 높은 확장성, 향상된 협업, 그리고 안정적인 테스트 환경을 위해 SPeCTRA는 2.0으로의 진화를 시작했습니다.SPeCTRA 2.0의 핵심 변화: 무엇이 달라졌는가?SPeCTRA 2.0은 1.0을 계승하되, 데이터 흐름을 API 중심으로 완전히 재편하고 Web에서 구동되도록 개편되었습니다. 주요 변화는 다음과 같습니다.1. API 기반 테스트로의 전환가장 큰 변화는 테스트 실행 방식입니다.SPeCTRA 1.0이 로컬 PC에 연결된 모바일 클라이언트를 Appium, Logcat으로 제어하는 방식이었다면, SPeCTRA 2.0은 대화방의 API를 직접 호출하는 방식으로 전환되었습니다.이는 더 이상 테스트를 위해 물리적인 디바이스나 클라이언트 앱 실행 환경이 필요 없다는 것을 의미합니다.덕분에 테스트 환경 구축이 단순해졌고, CI/CD 파이프라인과의 연동이 더욱 유연해졌으며, API 기반의 동시 다발적인 테스트 수행으로 속도와 확장성 면에서 비약적인 발전을 이루었습니다.로컬 PC의 Excel 파일로 관리되던 테스트 시나리오와 결과 데이터는 이제 Google Sheets로 통합되었습니다.Google Sheets를 도입함으로써 얻는 이점은 명확합니다.• None 실시간 협업: QE팀이 동일한 테스트 시트 위에서 실시간으로 시나리오를 추가/수정하고, 평가 결과를 즉시 확인할 수 있습니다.• None 버전 관리 및 이력 추적: TestCase 모든 변경 사항이 기록되어 데이터의 정합성을 유지하기 용이합니다.• None 유연한 연동: Google Cloud 환경의 다른 서비스나 스크립트와 쉽게 연동하여 데이터 처리의 실시간 동기화 가능해졌습니다.3. 신뢰성 있는 로그 데이터 활용SPeCTRA 1.0에서는 실시간 클라이언트 로그를 파싱하여 LLM의 응답을 추출했습니다.이는 간편하지만, 로그 포맷이 변경되거나 유실될 경우 테스트의 안정성이 떨어질 수 있는 단점이 있었습니다.SPeCTRA 2.0에서는 중앙 로그 관리 시스템인 내부 시스템 로그의 결과 데이터를 활용합니다.정제되고 구조화된 로그 데이터를 API를 통해 가져옴으로써, LLM의 요청(request)과 응답(response)을 누락 없이 정확하게 확보할 수 있게 되어 테스트의 신뢰도를 크게 높였습니다.더군다나 LLM답변 추출에 그치지 않고 새롭게 도입된 Rewrite, Routing의 데이터도 함께 추출하여 실시간 동기화성을 더욱 극대화 했습니다.새로운 에이닷 4.0에는 사용자 기억 지양점인 Memory가 도입됨에 따라 SPeCTRA도 진화가 필요했습니다.기존의 1.0의 Judge Prompt는 그대로 사용하되 Memory 기능확인을 위한 추가 Prompt를 도입함하여 차별화를 두었습니다.SPeCTRA 2.0의 심장부: 자동화된 평가 아키텍처이 영역의 핵심은 'QA Judge Model'입니다.이 모델은 단순히 사용자의 질문과 LLM의 최종 답변만 보고 정답을 맞혔는지 평가하는 것을 넘어, 답변이 생성되기까지의 '과정'을 검증합니다.즉, LLM 에이전트의 '생각'의 흐름을 추적하여 평가하는 것입니다.SPeCTRA 2.0은 다양한 내부 API와 연동하여 에이전트의 동작을 다각도로 분석합니다.• None Reactive API: Access_Token을 기반으로 한 API 호출을 통해, 사용자 정보나 페르소나에 따른 개인화된 응답(Reactive) 결과가 올바르게 생성되었는지 확인합니다.• None Memory API: 대화에 적재된 기억(Memory)을 LLM 에이전트가 올바르게 조회하고 활용했는지 검증합니다.• None Rewrite & Routing API : 중앙 로그 시스템인 내부 시스템 로그를 통해 대화의 맥락을 어떻게 재구성(Rewrite)했는지, 그리고 Agent가 어떤 기능 Routing을 호출하려고 계획했는지까지 추적하여 평가의 정확도를 높입니다.이렇게 각 API를 통해 수집된 '과정' 데이터는 기존 SPeCTRA 1.0의 Safety, Performance, Tone & Manner, Accuracy를 포함하여SPeCTRA의 다차원적인 평가 기준(Prompt)과 결합되어 최종 평가 점수를 도출합니다.새로워진 SPeCTRA 2.0의 워크플로우SPeCTRA 2.0의 단순히 Data 추출를 API로 이전한 것에 그치지 않습니다. 아래 아키텍처 다이어그램의이 보여주듯, 평가의 '깊이'가 달라졌습니다.이러한 구조적 변화를 통해 SPeCTRA 2.0의 자동화된 품질 평가 워크플로우는 다음과 같이 더욱 견고하고 효율적으로 개선되었습니다.• None (Input) QA Google Sheets에 검증 시나리오를 작성합니다.• None (Process) 자동화 스크립트가 시나리오를 읽어 대화방 API를 이

부사수도 없는 작은 팀에서 일해본 경험이 있나요? 그렇다면 이런 상황은 한번쯤 겪어보셨을 거예요. 팀원이 휴가를 가면 그 사람의 업무가 멈춰버리거나, 휴가중에도 업무를 해야하는… 결국 아무도 마음 편히 쉴 수 없는 상황 말이에요. 특히 시스템 관리나 데이터베이스 운영 같은 전문 업무는 더욱 그렇죠.오늘 소개할 사례는 바로 그런 현실적인 문제를 AI로 해결한 마이리얼트립 코어플랫폼팀의 이야기입니다. 코어플랫폼팀은 SRE, DBA, DevOps 등의 업무를 단 3명의 인원으로 처리하고 있기 때문에 그 누구보다도 AI 도입에 적극적이었어요. 처음에는 팀원을 보조하는 “AI 인턴”의 컨셉으로 시작해, 사내 개발자들이 직접 이용할 수 있는 AI 에이전트 시스템으로 발전시켰는데요, 오늘은 이 AI 에이전트 시스템을 개발한 천필수, 박성민님의 이야기를 소개하려고 합니다.소규모 팀의 큰 책임[108개 데이터베이스, 1명의 관리자]이 팀의 천필수님이 직면한 상황을 구체적으로 살펴보면 정말 현실적인 문제였어요.“현재 클러스터 기준으로만 해도 50여 대가 넘고, 인스턴스 기준으로 하면 총 108개 정도 되는 데이터베이스를 운영하는 DBA(Database Administrator)는 현재 저 한 명인 상황이에요.”이 숫자들을 보면 상황의 심각성이 느껴지죠. 한 사람이 108개의 데이터베이스를 관리한다는 것은 단순히 업무량이 많다는 차원을 넘어서, 시스템 전체의 안정성이 한 사람에게 의존하고 있다는 뜻이에요.[단일점 장애의 위험성]“DBA가 퇴근을 했거나 휴가를 가면, 그 108대에 대한 모든 DBA 요청이 블로킹되고 지연된다는 문제의식을 평상시에 갖고 있었습니다.”이런 상황을 IT 업계에서는 ‘단일점 장애(Single Point of Failure)’라고 부르는데, 마치 중요한 다리에 기둥이 하나밖에 없는 것과 같아요. 그 기둥에 문제가 생기면 전체 교통이 마비되는 것처럼, 한 명의 전문가에게만 의존하는 시스템은 매우 취약할 수밖에 없죠.호기심에서 시작된 AI 실험[계획된 혁신이 아닌 자연스러운 시작]흥미로운 점은 이 팀의 AI 도입이 거창한 디지털 트랜스포메이션 계획에서 시작된 게 아니라는 거예요.“처음부터 AI를 통해서 이런 문제를 해결하겠다는 건 아니었고요. 회사 내에서 AI를 활용해서 업무를 개선하는 많은 케이스들이 나오다 보니, 저도 단순히 우선 공부부터 해보겠다는 차원에서 시작했어요.”이런 접근 방식이 오히려 성공의 열쇠였을지도 몰라요. 부담 없는 실험으로 시작했기 때문에 실패에 대한 두려움 없이 다양한 시도를 할 수 있었거든요.[작은 실험에서 큰 발견]“처음에는 간단한 DB를 조회하는 MCP 도구를 구현해서 클로드 데스크톱에 붙여봤고, 테스트를 해보니 생각보다 범용 LLM 모델들이 데이터베이스를 굉장히 잘 알고 있다는 것을 확인할 수 있었습니다.”이 순간이 중요한 전환점이었어요. AI가 단순히 챗봇 수준이 아니라, 실제로 전문적인 데이터베이스 업무를 수행할 수 있다는 가능성을 발견한 거죠. 팀에서는 새로운 인턴 사원이 내 옆에서 업무를 보조해주는

챌린저스 여러분, 언더커버 사일로의 마지막 여정, ‘계좌 사일로’ 편에 오신 것을 환영합니다.이전의 네 가지 사일로가 모든 서비스가 겪는 보편적인 성장통에 대한 이야기였다면, 이번 편은 ‘토스는 금융 앱이다’라는 본질적인 질문에서 출발합니다. 수많은 규제와 제약 속에서, 토스마저 아직 정답을 찾지 못한 문제를 함께 풀어보는 시간이 될 텐데요. 토스의 가장 근본적인 고민이 담긴 마지막 과제, 그 비하인드 스토리를 지금부터 시작합니다.가장 토스다운 문제, 가장 어려웠던 출제언더커버사일로의 마지막 화는 ‘계좌 사일로’였습니다. 기획 단계부터 토스는 금융 앱이니까, 금융의 본질을 다루는 사일로 하나는 꼭 넣어야겠다고 생각했어요.그런데 문제가 있었습니다. 금융 기능은 관련된 사전 지식이 너무 많이 필요했어요. 첫 화였던 인플로우 사일로는 ‘신규 유저 확보’라는 보편적인 과제였고, 만보기는 ‘비용과 지속가능성’, 페이스페이는 ‘UX와 사용성’, 고양이는 ‘리텐션’에 집중했죠. 이 네 가지를 합치면 사실상 프로덕트의 전 과정을 훑는, 모든 메이커가 공감할 만한 문제들이었습니다.하지만 송금, 카드, 결제 같은 금융 도메인으로 들어가려고만 하면, 수많은 규제와 절차의 벽에 부딪혀 문제 출제가 번번이 막혔습니다. 챌린저들이 문제 하나를 제대로 풀기 위해, 몇 시간씩 사전 지식을 공부해야만 하는 상황을 만들고 싶지는 않았어요. 토스가 이미 찾은 정답을 그들에게 기대하는 것 자체가 불공평했죠. 그건 저희가 가진 모든 배경지식을 그들도 똑같이 가지고 있어야 한다는 뜻이니까요.‘토스도 정답을 모르는 문제’를 내기로 하다그래서 저희는 생각을 완전히 뒤집기로 했습니다. 만약 토스도 아직 답을 찾지 못한 문제를 내면 어떨까?그러면 챌린저들이 저희의 선택과 일치하는 정답을 내야 할 필요가 없어져요. 문제를 풀기 위한 최소한의 사전 지식만 드리고, 토스의 방식을 모르는 외부 메이커들의 날카로운 시선으로 최고의 해결책을 찾아보게 하는 거죠.이런 고민 끝에, 계좌 사일로가 가진 수많은 성공 경험을 과감히 제쳐두었습니다. 대신 규제 속에서도 신규 계좌 개설 인플로우와 전환율을 동시에 잡을 수 있는 전략을 짜는 것, 바로 이 오픈 퀘스천이 언더커버사일로의 마지막 과제가 되었습니다.마지막 과제: 당신도 챌린저입니다이제 여러분도 언더커버 사일로에 참여한 챌린저와 동등한 상황에서 문제를 풀어보실 수 있도록, 지금부터 저희가 마주한 두 가지 현실적인 제약을 먼저 공유해 드리겠습니다.첫째, 계좌 사업의 본질상 리텐션은 의미가 없습니다. 여러분도 아시다시피, 단기간에 여러 개의 계좌를 만드는 것은 제한되어 있죠. 사실상 한 명의 사용자는 평생 단 하나의 계좌만 만든다고 가정해야 합니다. 그렇기 때문에 이탈한 사용자를 다시 불러오는 리텐션 지표보다는, 일단 들어온 사용자가 실제로 계좌를 개설했는지를 보여주는 전환율이 가장 중요한 지표가 됩니다.둘째, 그런데 그 전환율이 너무나도 낮습니다. 토스는 이미 대한민국 국민의 절반이 쓰고 있고, 앱의 가장 좋은 자리인 홈 화면과 계좌 탭에 ‘계좌 만