에이닷 웹서비스팀의 E2E 테스트 도입기에이닷은 SK텔레콤이 2022년 5월에 공개한 AI 에이전트 서비스입니다.에이닷 웹서비스개발팀은 adot.ai 웹사이트의 검색·노트 기능을 제공하고, 앱 내 웹뷰 개발까지 담당하며 다양한 웹 기술로 사용자 경험을 강화하고 있습니다.2025년, 저희 팀의 목표 중 하나는 테스트 코드 작성 및 운영 체계화였습니다.특히 QA 자동화를 위해 E2E(End-to-End) 테스트를 본격적으로 도입해본 경험을 공유해보려 합니다.테스트 코드는 크게 세 가지로 나눌 수 있습니다.• None 이 세 가지는 실행 환경, 시점, 복잡성 등에서 차이가 있으며, E2E 테스트는 특히 실제 사용자의 서비스 흐름 전체를 자동화해 검증한다는 점에서 가장 큰 차이점을 지니고 있습니다.• None “로그인 → 페이지 이동 → 버튼 클릭 → 결과 확인”처럼 실제 사용자 시나리오 전체를 확인 가능합니다• None Playwright, Cypress, Selenium으로 DOM 클릭·입력 등 실제 사용과 유사하게 동작을 검증할 수 있습니다• None 프론트엔드·백엔드 연결 상태와 주요 기능의 안정성 테스트 할 수 있습니다• None 실행 속도가 느리고, 작성·유지보수 비용이 높습니다• None 도입 시 초기 설정과 러닝커브 필요합니다테스트 도구 선정 전, 대표적인 세 가지 도구를 비교했습니다.• 사용자 친화적인 인터페이스로 프론트엔드 테스팅에 탁월• cypress studio로 코드 자동 생성 가능하나 아직 실험적 기능 Playwright도 강력한 디버깅 기능 제공. Cypress 수준의 상호작용성을 달성하려면 추가 설정 필요• None 포괄적인 크로스 브라우저 테스팅을 지원하고, 복잡하고 대규모 프로젝트를 위한 고급 병렬 처리가 가능하며 CI/CD 연동 용이성을 고려하여 Playwright를 선택하였습니다.설치와 실행 그리고 report를 보는 방법은 아래의 간단한 명령어로 가능합니다• None Playwright의 codegen 기능은 테스트 코드를 자동으로 초안화해주는 강력한 도구입니다• None local서버를 구동시켜두고 이를 타겟으로 codegen 실행하는 방법은 아래와 같습니다• None Codegen을 통해 테스트 초안을 작성하는 과정에서 DOM selector 탐지할 수 있습니다• None input 입력하는 코드를 자동화할 수 있습니다selector는 data-testid로 관리하는것이 합리적• None Codegen이 작성해준 E2E테스트 초안은 처음엔 무척 간편하다는 느낌을 안겨주었습니다. 하지만 서비스는 빠르게 변화하고 그에 따라 코드의 변경점이 늘어날 수록 Selector에 대한 고민이 늘어났는데요.• None 결과적으로 class, id, DOM 구조는 언제든 변경될 수 있다는 점에서 점차 data-testid 기반 selector를 사용하는 방식으로 정착하게 되었습니다.• None 초기에는 개발 Repo와 테스트 Repo를 분리해서 관리하는 것으로 시작하였습니다.• None 하지만 실제 경험상 하나의 Repo에서 개발 코드와 테스트 코드를 함께 관리하는 것이 훨씬 효율적이라는 결론을 얻었습니다. 이유는 다음과 같습니다:• None product 코드 변경시 → 테스트 코드도 즉시 반영 필요합니다.• None 같은 속성은 product 코드에 직접 추가해야 하는 점에서도 역시 하나의 Repo에서 관리가 필요했습니다.• None playwright는 UI모드로 테스트를 실행할 수 있습니다.• None UI모드에서는 테스트 전체 과정이 스크린녹화되어 기록되고 원하는 시점에 mouse hover하여 테스트 과정을 step by step으로 확인 가능합니다.• None 특정 테스트 watch mode 실행을 하면 코드를 수정하고 저장 시 테스트가 자동 재실행이 되어 유용합니다.• None 스크린 녹화와 watch mode는 특정 테스트를 디버깅하고 빠른 피드백을 받기에 큰 도움이 되었습니다.• None 로그인 플로우를 테스트 코드로 구현했을 때, 단순히 만 사용하면 너무 빠른 입력에 의해 로봇 탐지에 걸려 로그인에 실패합니다.• None 이를 해결하기 위해 랜덤 wait를 삽입하여 실제 사용자 입력과 유사하게 만들어 안정적으로 로그인을 시킬 수 있었습니다.• None QA팀에서 에이닷 노트라는 서비스를 타겟으로 작성하고 공유해주신 테스트 코드는 무려 248개나 되는 방대한 분량이었습니다.• None 모든 코드를 수작업으로 작성하기엔 비효율적이었고, Cursor를 활용하기 시작하였습니다.• None 방법은 간단했는데요 먼저 Cursor에 아래와 같이 QA팀에서 제공해주신 TC 를 스크린샷해서 첨부합니다.• None “이 스크린샷 기반으로 테스트 코드를 작성해줘. 티켓 넘버를 주석으로 달아줘.”라고 입력하면 자동으로 테스트 코드 생성됩니다'• None 여러 테스트를 추가하다보면 테스트가 실패하기도 하는데요 이때 “실패하는 테스트는 예외 처리 추가해줘.” 라고 입력하면 즉시 수정을 진행합니다• None Cursor를 도입하면서 자동 코드 생성과 즉시 수정을 반복하며 코드 작성 속도를 획기적으로 단축할 수 있었습니다.E2E Test는 어떤 목표를 잡고 진행하는게 좋을까?• None Unit Test의 경우 전체 Code coverage의 60% 이상 작성하기 같은 목표를 수립하곤 합니다. E2E 테스트는 어떨까요?• None E2E테스트는 테스트의 목적과 사용자의 사용성을 테스트 하는 것이기에 Code Coverage를 목표로 설정하는 것의 의미가 크지 않습니다.• None 팀에서 선정한 중요도 높은 TC들에 대해 테스트를 작성하는 것으로 목표를 수립하였고 QA팀이 제공해주신 TC의 50% 이상의 TC를 작성하는 것으로 목표를 수립하고 진행하고 있습니다.E2E 테스트는 빠른 실행·간단한 유지보수와는 거리가 멀지만, 서비스 전체 품질을 보장하는 핵심 역할을 합니다.에이닷 웹서비스팀은 Playwright와 Cursor를 도입해 방대한 QA 시나리오를 효율적으로 자동화하고, 이를 통해 개발자와 QA 모두의 생산성을 높일 수 있었습니다.앞으로도 저희는 사용자 경험

안녕하세요. 서비스웹개발팀의 프론트엔드 개발자 헨비입니다.이번 고객센터 채팅 상담 프로젝트는 Web과 Mobile Web, 그리고 “여기어때” 앱 내의 WebView(Android/iOS) 환경에서 동시에 작동하는 서비스입니다.실시간 상호작용과 멀티 디바이스 환경에서 안정성을 보장하기 위해 단위 테스트와 E2E 테스트를 도입했습니다.특히 핵심 사용자 여정(접속→연결→메시지/파일→종료)은 수동 테스트만으로는 리스크를 충분히 검증하기 어렵다고 판단했습니다.이러한 이유로 테스트 코드의 필요성을 절실히 느꼈고, 그 과정과 선택을 이번 글에서 공유하고자 합니다.1. 왜 Playwright를 선택했는가GUI E2E Test Tool 중의 양대산맥인 Cypress와 Playwright 가 있습니다.각자의 장점과 단점을 알아보고 왜 Playwright를 선택하게 되었는지 같이 체크 해보겠습니다.Cypress 장점GUI 기반 Test Runner와 Time‑Travel 덕분에 개발자 경험(DX)이 뛰어납니다.방대한 생태계와 네트워크 스텁 기능, 그리고 친절한 문서가 초보자 진입 장벽을 낮춰줍니다.설정과 사용 흐름이 단순해서 빠르게 시작할 수 있습니다.결론적으로 테스트코드의 이해와 작성이 쉽고 UI가 이쁩니다.Cypress 단점브라우저 엔진과 탭, 도메인 제어에 제약이 있어, 복잡한 시나리오 테스트에는 부적합할 수 있습니다.Safari(WebKit)를 지원하지 않아 iOS Safari 호환성을 보장하기 어렵습니다.Playwright 장점Chromium, Firefox, WebKit까지 모두 공식 지원해 크로스 브라우징 커버리지가 넓습니다.멀티 탭, 권한 설정, 네트워크 제어, 디바이스 및 GPS 시뮬레이션 등 고급 브라우저 제어 기능이 훨씬 풍성합니다.자동 대기, 병렬 실행, Trace/비디오/스크린샷 캡처 같은 견고한 테스트 인프라가 기본 포함되어 있습니다.Playwright 단점Cypress의 UI Runner처럼 한눈에 보여지는 인터페이스와 같은 개발자 통합 경험은 아니어서, 일부에겐 다소 불편할 수 있습니다.선택 기준과 결론본 서비스는 고객센터 “실시간 채팅” 앱으로 iOS Safari(WebKit) 호환성과 모바일 뷰 재현성이 매우 중요합니다. 또한 파일 업로드/미디어 재생, 웹소켓 기반 메시징 등 브라우저 레벨 제어가 필요했습니다.멀티 브라우저(WebKit 포함)와 모바일 디바이스 프로필과 후에 포커싱/권한/다운로드까지 포괄하는 제어가 필요했기에 Playwright를 선택했습니다. 더군다나 Web과 Webview 모두에서 사용되는 앱이므로 많은 멀티 브라우저와 다양한 모바일 디바이스 프로필이 있다는 점이 매력적 이였습니다.Component Test, E2E가 모두 필요한 이유실시간 채팅은 “UI 상호작용의 촘촘함”과 “End-To-End 시나리오의 연속성”이 모두 중요합니다.컴포넌트 테스트(CT)로는 채팅에 접속해서 바로 만나는 다양한 컴포넌트들의 핵심 UI의 상태 전이(비활성/활성, 파일 선택, 미디어 렌더와 닫기)를 빠르고 결정적으로 검증했

3편에서는 lambda 설정에 대해서 알아보겠습니다.아직 갈 길이 멉니다!!전체 아키텍쳐는 1편을 참고해 주시길 바랍니다.• None S3에 동영상이 업로드 완료• None 해당 lambda에서 업로드 파일 트리거• None 업로드된 동영상 확인 및 media convert에 작업 의뢰기본 실행 역할 변경 → 기존 역할 사용 → 1편 IAM에서 만들었던 "{환경}-ifland-Role-LambdaVod" 선택아래 2개의 파일을 zip 파일로 압축.코드 → 에서 업로드 클릭 → .zip 파일 선택 후 위에서 압축한 zip 파일 업로드MediaConvertRole : 1편 IAM 에서 만들었던 {환경}-ifland-Role-MediaConvert 의 ARN버킷 : 2편 S3 에서 만든 버킷 선택• None event bridge에서 작업 완료 내용 트리거 및 lambda로 내용 전달• None lambda에서 작업 내역 확인 및 데이터 워싱• None CMS 시스템으로 결과 callback 이프랜드에서는 구축한 동영상 시스템을 Content Media Service(CMS) 라고 지칭함.기본 실행 역할 변경 → 기존 역할 사용 → 1편 IAM 에서 만들었던 "{환경}-ifland-Role-LambdaVod" 선택프로젝트 폴더 생성후 convert.py 와 requirements.txt 를 배치.필요 라이브러리 다운로드프로젝트 폴더 안에서 모든 파일을 zip 으로 압축• None 코드 → 에서 업로드 클릭 → .zip 파일 선택 후 위에서 압축한 zip 파일 업로드구성 → 환경 변수에 결과를 알려줄 API 입력CallbackUrl : 동영상 변환 결과를 받을수 있는 API URL 입력• None 결과를 받을수 있는 API 개발이 별도 필요한데요. 소스 포함해서 이 부분은 추후 블로그 작성시 공유 드릴 예정입니다.complete.py 의 내용은 eventbridge에서 받은 mediaconvert 결과값을 그대로 api 에 전달하지 않고, lambda에서 데이터를 가공해서 api 로 전달 한다.데이터 가공전(mediaconvert 결과값 원본)데이터 가공후(개발될 callback API 에서 받을 데이터)4편에서는 VPC 설정과 lambda에서 이 VPC를 연결하는 작업을 진행하도록 하겠습니다.유저 입장에서는 단순히 동영상 하나 보는것 뿐인데 실제 구축시에는 이렇게나 많이 설정이....아무튼 4편으로 다시 돌아오겠습니다!

LY Corporation은 높은 개발 생산성을 유지하기 위해 코드 품질 및 개발 문화 개선에 힘쓰고 있습니다. 이를 위해 다양한 노력을 하고 있는데요. 그중 하나가 Review Committee 활동입니다.Review Committee에서는 머지된 코드를 다시 리뷰해 리뷰어와 작성자에게 피드백을 주고, 리뷰하면서 얻은 지식과 인사이트를 Weekly Report라는 이름으로 매주 공유하고 있습니다. 이 Weekly Report 중 일반적으로 널리 적용할 수 있는 주제를 골라 블로그에 코드 품질 개선 기법 시리즈를 연재하고 있습니다.이번에 블로그로 공유할 Weekly Report의 제목은 '차일드 록(child lock)'입니다.메시지의 데이터 모델로 라는 추상 클래스가 있다고 가정해 봅시다. 메시지에는 여러 유형이 있으며, 각 유형은 의 자식 클래스를 정의하는 방식으로 표현합니다.여기서 의 자식 클래스 의 목록 를 화면에 표시하기 위해 다음과 같이 추상 클래스 를 정의했다고 가정하겠습니다. 단, 메시지 표시 로직은 메시지 유형에 따라 달라지므로 에는 목록 표시 로직을 구현하지 않았습니다. 부모 클래스의 에서는 헤더와 푸터(footer)만 표시하고, 목록 표시는 자식 클래스에서 오버라이딩해서 구현할 것으로 기대한 코드입니다(Kotlin에서 은 오버라이딩이 가능하다는 의미의 수정자입니다).다음 는 를 구현한 예시입니다. 를 타입 파라미터로 지정하고, 해당 클래스 고유의 목록 표시 로직을 에 정의했습니다.이 코드에 문제가 있을까요?자식 클래스가 장난을 못 치도록 하기를 명시적으로 호출해야 한다는 것은 대부분 오버라이딩 가능한 함수의 범위가 너무 넓다는 것을 의미합니다(예외에 대해서는 뒤에서 설명하겠습니다). 위 코드는 오버라이딩할 수 있는 함수의 범위가 너무 넓기 때문에 다음과 같은 구현 실수가 발생하기 쉽습니다.• 호출 누락: 모든 자식 클래스는 헤더와 푸터를 업데이트하려면 를 호출해야 합니다. 만약 호출을 누락한 경우 헤더와 푸터가 업데이트되지 않는 버그가 발생하며, 이때 특별히 에러 가 발생하지 않기 때문에 버그를 간과하기 쉽습니다.• 오버라이딩 누락: 상속 시 오버라이딩이 필요하다는 제약 조건이 인라인 주석으로만 설명돼 있습니다. 따라서 오버라이딩해야 할 다른 함수가 있는 상황에서는 오버라이딩을 누락하는 버그가 발생하기 쉽습니다. 오버라이딩을 강제하기 위해 수정자를 사용하려고 해도 헤더나 푸터 업데이트 로직이 섞여 있다면 쉽지 않습니다.• 기대하지 않은 구현: 인라인 주석에 적혀 있는 대로 오버라이딩된 에서는 메시지 목록 표시만 구현되기를 기대하겠지만, 실제로 를 호출하면 헤더와 푸터도 표시됩니다. 즉, 오버라이딩의 책임 범위와 함수의 책임 범위가 일치하지 않습니다. 이로 인해 오버라이딩의 책임 범위를 오해하기 쉬우며, 결과적으로 책임 범위를 벗어난 코드가 자식 클래스에 구현될 수 있습니다.이 문제를 해결하기 위해서는 함수를 으로 만들지 말고 목록을 업데이트하는 함수인 를 분리해 추상 메서드(또는 순수 가상 함수)로 만드는 것이 좋습니다.자식 클래스는 다음과 같습니다.이렇게 하면 '헤더 및 푸터와 메시지 목록을 업데이트한다'는 의 흐름은 변경할 수 없게 만들면서 자식 클래스마다 메시지 목록을 다르게 구현할 수 있습니다. 이처럼 자식 클래스가 변경할 수 있는 범위를 제한하면 코드를 더욱 견고하게 만들 수 있습니다.비슷한 문제를 피하려면 다음과 같은 상황을 피하는 것이 좋습니다.• 오버라이딩된 부모 클래스의 함수를 호출하는 경우(명시적으로 를 사용하는 경우)• 다만 라이프사이클과 관련된 함수(생성자, 소멸자 등)와 플랫폼이나 라이브러리의 제약 조건 때문에 필요한 경우(Android의 등)는 예외.• 자식 클래스에서 공통으로 사용되는 함수의 흐름을 각 자식 클래스에서 구현하는 경우이와 같은 상황에 해당한다면 오버라이딩 가능한 범위를 제한하는 것이 좋습니다.C++에서는 함수를 정의할 수 있습니다. 이 함수는 부모 클래스에서만 호출할 수 있지만, 호출은 동적으로 디스패치됩니다. 함수를 사용하면 전체 흐름( )을 변경하지 않고 각 자식 클래스의 로직( )을 변경할 수 있습니다.

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