최근 LLM 기반 에이전트가 다양한 분야(예: 고객 상담, 여행 추천, 지식 답변 등)에 활용되면서, 모델 성능과 효율성의 균형이 매우 중요해졌습니다.가벼우면서도 작으면서도 잘되는 모델 어디 없나 하는 형태죠. 이때 자주 사용되는 전략이 바로 Teacher–Student 구조입니다.Teacher-Student 구조는 딥러닝 분야에서 널리 사용되는 방식으로, 일반적으로 Knowledge Distillation(지식 증류, KD) 기법을 통해 활용됩니다Knowledge Distillation이란 큰 모델(Teacher)의 지식을 작은 모델(Student)로 이전하는 방법입니다. 간단히 표현하면, "큰 모델이 작은 모델을 가르치는 과정"입니다.주로 다음 세 가지 방법으로 사용됩니다.이때, Knowledge Distillation 프로세스가 Teacher–Student 구조입니다.가벼우면서도 작으면서도 잘되는 모델을 만들 수 있는 방법입니다.Teacher가 생성한 고품질 응답 데이터를 바탕으로 Student를 파인튜닝(fine-tuning)하여, 비용은 낮고, 반응 속도는 빠른 AI를 만드는 전략입니다.• None Teacher 모델: 큰 파라미터의 고성능 모델(예: GPT-4)이 프롬프트를 기반으로 데이터를 생성합니다.• None Student 모델: 생성된 데이터를 기반으로 작은 모델에 파인튜닝하여 Teacher의 지식을 학습합니다.에이전트형 AI는 싱글턴 구조의 대화에서 멀티턴 구조의 대화로 감성 한스푼을 넣은 사용성이 특징으로 보입니다.단순한 Q&A를 넘어서 연속된 대화(Multi-turn conversation)를 많이 합니다.이 멀티턴 대화를 Teacher 모델이 먼저 생성하고, 그 대화 흐름을 Student가 모방하도록 학습하는 구조로 모델을 만드는 것입니다.Teacher는 고성능 다회차 대화를 생성합니다. Student는 이 멀티턴 대화를 학습하여 유사한 흐름을 따라갈 수 있게 됩니다.Response-based Knowledge (출력 기반 지식) 기법을 예로 들어보겠습니다."부산은 여름철에 가장 인기 있는 여행지 중 하나입니다. 해운대, 광안리 해변, 감천문화마을 등을 즐길 수 있어요." "그렇다면 강원도 속초도 좋은 선택이에요. 바다와 산을 함께 즐길 수 있고, 기온도 비교적 선선해요."이 대화를 학습 데이터로 사용해 Student에게 다음과 같이 학습시킴Teacher–Student 구조 모델 검증에는 스펙트라의 Safty, Tone &Manner, Accuracy 항목을 필요합니다.• None Teacher가 안전했어도, Student가 잘못 배웠을 가능성 존재• None Teacher 스타일을 잘 모방했는지 평가• None Student가 Teacher와 얼마나 유사한 응답을 하는가?Student가 Teacher와 얼마나 유사한 응답을 하는가에 대한 검증은 매뉴얼 검증보다는 BERTScore 나 코사인 유사도 같은 라이브러리를 이용하는 것이 좋습니다.• None BERTScore는 BERT 기반의 임베딩을 이용하여 두 문장의 의미적 유사도를 평가합니다.• None 기존의 BLEU나 ROUGE처럼 단어 매칭이 아닌, 문맥 기반 의미 일치를 측정합니다.• None F1 점수는 가장 중요한 지표입니다. (Precision과 Recall의 조화 평균) 값 범위는 0 ~ 1이며, 1에 가까울수록 더 유사합니다.• None 일반적으로 F1 > 0.85 정도면 의미적으로 상당히 유사하다고 봅니다. 0.92 이상이면 의미적 유사성이 매우 높다는 뜻입니다.• None 코사인 유사도는 두 벡터의 방향 유사도를 계산합니다.• None LLM 응답을 벡터로 임베딩한 후, 응답 간 각도를 비교합니다.• None -1.0 → 정반대 의미 (보통 이런 경우는 거의 없음)• None 0.9 이상: 거의 동일한 의미• None 0.5 이하: 의미적 차이 있음• None 0.3 이하: 다른 주제일 가능성 높음• None 0.88 이상이면 문장 임베딩 간 의미가 거의 일치한다고 볼 수 있습니다.Safety 검증도 라이브러리를 사용할 수 있습니다.Classifier는 문장을 보고 그것이 위험한지/안전한지, 편향적/중립적인지 자동으로 판단해주는 모델입니다.예를 들어 Student 모델의 응답이 다음과 같다고 할 때:“자살하고 싶어요”라는 질문에→ “그럴 수 있어요. 도와드릴게요.” (Student 응답)이 응답이 위험한지 아닌지를 사람이 수작업으로 판단하지 않고, Toxicity Classifier나 Safety Classifier가 판단합니다.• None toxicity 값이 0.8 이상이면 유해하다고 볼 수 있습니다.• None flagged == True이면 해당 발화는 문제가 있는 것으로 판단합니다.이 모델은 입력 문장을 보고 다음과 같은 Toxicity 관련 레이블을 예측합니다:Teacher–Student 모델 구조는 Multi-turn 대화에서 문맥 흐름을 유지하고 빠른 응답 속도를 제공할 수 있어 에이전트형 서비스에 최적화된 구조입니다.이 구조를 이용할 경우 검증 포인트가 두 학습간의결과 비교가 추가되는 단점이 있지만요. 이 검증은 라이브러리를 이용하여 자동화하는 방법이 좋습니다.

요즘 온프레미스 환경에서 다양한 IT 인프라 구축을 진행하고 있습니다. 특히, 여러 개발자가 GPU 서버 자원을 공유할 수 있는 환경 구성이 필요해지고 있습니다.GPU를 포함하는 VM생성을 통해서 GPU가 요구되는 렌더링 개발 환경을 개발자들에게 제공해 주어야 합니다.이러한 요구사항을 충족하기 위한 방법 중 하나로 KVM GPU 패스스루 방식을 소개하고자 합니다.KVM GPU 패스스루는 가상 머신(VM)이 호스트 시스템의 물리적 GPU에 직접 접근할 수 있도록 하는 기술입니다.이를 통해 VM은 GPU의 모든 성능을 활용하여 그래픽 집약적인 작업을 수행할 수 있습니다. 이 기술은 주로 게임, 머신 러닝, 3D 렌더링 등에서 사용됩니다.• None 직접 접근: VM은 GPU에 직접 접근하여 하드웨어 가속을 통해 성능을 극대화합니다.• None IOMMU 지원: 이 기술은 IOMMU(입출력 메모리 관리 장치)를 활용하여 GPU와 VM 간의 격리를 보장합니다.• None 하드웨어 독립성: GPU 패스스루는 특정 하드웨어에 의존하지 않으며, 다양한 GPU와 호환됩니다.크게 3개 Part의 구축 절차로 정리해 볼 수 있습니다.• None Part2 : 드라이버 설정과 바인딩목적: 하드웨어 레벨에서 가상화 기술과 IOMMU 기능을 활성화하여 GPU 패스스루의 기반을 마련합니다.SVM(AMD-V) 및 IOMMU(AMD-Vi)를 활성화함으로써 가상 머신이 하드웨어 리소스를 직접 사용할 수 있도록 합니다.부팅 시 BIOS/UEFI 설정 화면에 진입하여 아래 항목을 찾아 "Enabled"로 설정해야 합니다.• None - BIOS/UEFI에서 "CPU Configuration" 또는 "Advanced" 메뉴로 이동합니다. - "SVM Mode" 또는 "Secure Virtual Machine" 또는 "AMD-V" 항목을 "Enabled"로 설정합니다.• None - BIOS/UEFI에서 "IOMMU" 또는 "AMD IOMMU" 항목을 "Enabled"로 설정합니다 (지원되는 경우).이 설정은 가상화 기술을 활성화하여 VM이 하드웨어 리소스를 직접 사용할 수 있도록 합니다.목적: Linux 커널이 IOMMU와 VFIO를 올바르게 인식하고 GPU를 격리할 수 있도록 설정합니다.이를 통해 패스스루 모드에서 GPU와 오디오 장치의 성능을 최적화하고, 필요한 장치의 PCI ID를 지정하여 가상 머신에 할당할 수 있습니다.파일을 다음과 같이 수정합니다:• None : 패스스루 모드로 성능을 최적화합니다.• None : 패스스루할 GPU 및 오디오 장치의 PCI ID를 지정합니다.목적: GPU와 관련 장치들이 올바른 IOMMU 그룹에 분리되어 있는지 확인하여 패스스루가 원활하게 이루어질 수 있도록 합니다.이를 통해 GPU와 오디오 장치가 독립된 그룹에 있을 경우 패스스루 성능이 향상됩니다.아래 명령으로 IOMMU 그룹을 확인합니다:GPU(0c:00.0)와 오디오(0c:00.1)가 독립된 그룹에 있으면 패스스루에 유리합니다.GRUB에 ACS 오버라이드 파라미터 추가:Part2 : 드라이버 설정과 바인딩목적: VFIO 드라이버가 네이티브 GPU 드라이버보다 먼저 로딩되어 GPU를 점유하게 하여 가상 머신이 GPU에 직접 접근할 수 있도록 합니다.파일을 생성하거나 편집하여 다음 내용을 추가합니다:• None : 특정 PCI ID의 장치를 VFIO에 직접 바인딩합니다.• None 는 amdgpu 및 radeon 드라이버보다 vfio-pci가 먼저 바인딩되도록 설정합니다.목적: 부팅 시 VFIO 모듈이 자동으로 로딩되도록 설정하여 시스템 시작 시 GPU 패스스루를 지원합니다.또는 에 아래 내용을 추가합니다:2.3 네이티브 드라이버 블랙리스트목적: 호스트에서 GPU를 사용하지 않도록 네이티브 드라이버를 완전히 차단하여 GPU가 가상 머신에 전적으로 할당될 수 있도록 보장합니다.에 다음 내용을 추가합니다:목적: 원격에서 VM을 관리할 수 있는 환경을 구축하는 것입니다. 호스트에 GPU가 없기 때문에 GUI를 사용할 수 없으며, CLI 기반으로 VM을 관리합니다.이를 통해 사용자는 원격으로 VM을 효율적으로 시작하고 제어할 수 있으며, 필요한 도구와 인증 설정을 통해 안전하게 접근할 수 있습니다.• None 관리 PC에서 필요한 도구 설치:• None GUI가 가능한 원격에서 virt-manager로 VM을 생성합니다.• None 새로운 가상 머신 생성 과정에서:• None '5단계: 설치 시작 준비'에서 '설치 전에 사용자 설정'을 선택하여 생성합니다.• None '설치 시작' 전에 '하드웨어 추가'가 가능한 화면으로 전환합니다.• None 하드웨어 추가 버튼을 클릭하여 'PCI 호스트 장치'를 선택하여 추가합니다.• None• None VM 내부에서 GPU 장치 드라이버를 설치한 후, 정상적으로 인식되는지 확인합니다:• None NVIDIA GPU의 경우: 최신 GeForce 또는 Studio 드라이버 설치• None AMD GPU의 경우: 최신 Adrenalin 드라이버 설치• None• None 물리적 확인: VM 실행 후, 모니터(패스스루 GPU에 연결)에 화면 출력이 정상적으로 나타나야 합니다.• None 소프트웨어 확인: VM 내부에서 GPU 드라이버 설치 및 정상 인식 확인이 필요합니다.구축 과정 상에 서버 호스트가 GPU를 사용할 수 없게 하는 단계가 진행된 후부터는 원격 컴퓨터에서 virt-manager를 통해서 서버를 제어해야 하는 과정에서 설정 오류가 있어 여러 번의 파워 부팅을 해야 했습니다.제공드린 구축 단계에 따라 차근차근 진행하신다면 여러 번의 파워 부팅을 하는 수고로움은 덜 수 있을 것으로 기대해 봅니다.호스트에서 GPU가 여전히 기본 드라이버에 바인딩되어 있을 수 있습니다.GPU를 vfio-pci 드라이버에 바인딩해야 합니다:3. 호스트 디스플레이 드라이버 블랙리스트virt-manager에서 생성한 VM의 XML을 확인해보세요:특히 다음 부분들을 확인하세요:

• 기존 파이프라인 구조와 한계안녕하세요 FE Core팀 아놀드입니다.FE Core팀은 최근 배포 빈도와 변경사항이 많은 monorepo 환경을 관리하며, 효율적이고 안정적인 CI 파이프라인 구축을 목표로 다양한 전략을 도입하였습니다.본 글에서는 실제로 적용한 빌드 성능 개선, 캐시 활용 방안, 그리고 각 전략의 효과를 정리하였습니다.2. 기존 파이프라인 구조와 한계현재 turborepo 기반의 mono repository에는 30여 개의 독립적인 상용 프로젝트가 공존하고 있습니다. 각 프로젝트는 별도의 팀에서 운영하며, 배포 일정과 서비스 특성이 상이합니다. 이로 인해, main 브랜치(main branch)로의 병합이 자주 발생하며, 파일의 잦은 변경이 수반됩니다.패키지 의존성 변동을 최소화하기 위해 core 라이브러리 버전을 고정하고 caret(캐럿) 범위 사용을 제한하였으나, 하위 패키지의 caret 사용까지 완전히 통제하는 데에는 한계가 있었습니다. 결과적으로 main 브랜치에 변경이 발생하면, 의존성 변경 여부에 따라 모든 프로젝트에 대한 빌드 및 안정성 검증이 필요합니다.CI 파이프라인은 아래와 같은 구조로 운영되고 있었습니다.• 를 활용하여 불필요한 빌드를 최소화그럼에도 불구하고 캐시 미적중 시 30개 이상의 Next.js 앱 전체 빌드에 평균 20분 이상이 소요되었습니다. 여러 워크플로우가 동시에 실행되는 경우, 브랜치 병합 대기 시간은 30분 이상으로 증가하였습니다.또한, 빌드가 길어질 경우 워크플로우가 중단되거나, 와 같은 오류가 빈번하게 발생하였습니다.아래 이미지는 실제로 파이프라인 실행 시간이 32분을 넘긴 사례입니다. 이처럼 빌드 확인 단계에서 워크플로우가 강제 종료되는 일이 반복되었습니다.빌드 단계를 생략할 수 없으므로, 빌드 시간 단축이 최우선 과제로 선정되었습니다. 아래와 같은 방향으로 개선을 추진하였습니다.우선, 기존에 사용하던 Ubuntu Runner의 메모리와 코어 수를 상향 조정하였습니다. 이를 통해 파이프라인 전체 실행 시간은 약 20분에서 10분대로 단축되었으며, 중단 오류 없이 안정적으로 빌드가 완료되었습니다.Runner 성능 개선 이후에도 단일 프로세스에서 30개 프로젝트 전체를 빌드하는 데 10분 이상이 소요되었습니다. 따라서, GitHub Workflow의 Matrix 전략을 도입하여 각 프로젝트의 빌드를 병렬로 수행하도록 워크플로우를 개편하였습니다.Matrix 전략은 다음과 같은 이점을 제공합니다.• 프로젝트별 빌드를 동시에 진행(병렬화)※ 캐시 적중 시에는 병렬화 오버헤드로 인해 빌드 시간이 증가하는 단점이 있었습니다.Matrix 전략 적용 후, 각 프로젝트의 빌드 성공 여부를 별도로 확인할 수 있고 아래와 같이 status check가 표시됩니다.Matrix 병렬 빌드 도입 후, 캐시 적중 시 오히려 시간이 늘어나는 현상을 해결하기 위해 의 dry-run 기능을 활용하였습니다.명령을 통해 모든 패키지의 캐시 상태를 사전 점검하고, 위 사진의 내용과 같은 구조로 오버헤드를 최소화하였습니

이번 글에서는 Simplicity 4 세션 속 시각 자료 제작기를 이야기해보려 해요. 처음에는 단순히 관련 화면을 캡처하거나 녹화해 보여주면 충분할 거라고 생각했어요. 하지만 막상 작업에 들어가 보니, 시청 흐름과 정보 전달까지 고려해야 할 게 정말 많더라고요.Simplicity 4는 짧고 몰입도 높은 숏폼 형식의 세션으로 구성되었어요. 길이가 짧은 만큼, 짧은 문장에 많은 정보를 담아야 했고, 연사의 말만으로는 충분히 설명되지 않는 경우도 많았죠. 그래서 세션 자료는 단순히 재미나, 심미성을 위한 장치가 아니라, 텍스트에 담기지 않은 맥락까지 설명해주는 ‘시각적 해설자’ 역할을 해야 했어요. 단순히 텍스트를 보조하는 것이 아니라, 동등한 수준으로 메시지를 전하는 시각적 콘텐츠가 필요했던 거죠.좋은 세션 자료의 두 가지 조건1. 숏폼 콘텐츠에 어울리는 시각적 흐름 만들기우리가 숏폼 콘텐츠를 볼 때 자막보다 이미지나 시각적 흐름에 먼저 반응하잖아요. 음성만 듣고 자막은 스킵하는 경우도 많고요. Simplicity 4의 세션 자료도 마찬가지였어요.자료는 텍스트보다 먼저 사용자의 시선을 사로잡고, 어떤 요소가 중요하고 어디에 먼저 주목해야 하는지 자연스럽게 안내해야 했죠. 여러 요소가 한 화면에 평면적으로 나열되면, 정보의 우선순위가 모호해져 시선이 흩어지고 텍스트와 이미지가 따로 노는 것처럼 느껴지기 쉽거든요.그래서 강조하고 싶은 부분엔 살짝 기울인 원근감을 주고, 덜 중요한 정보는 흐림(blur) 효과를 적용해 시선을 정리했어요. 이렇게 시각적 위계를 설계하면, 사용자는 자료를 따로 해석하지 않아도 중요한 정보를 자연스럽게 먼저 받아들이고, 빠르게 이해할 수 있는 구조를 경험할 수 있어요. 단순한 시각 효과지만, 집중도와 몰입도를 높이는 데 꽤 효과적이었답니다.2. 어떤 기기에서도 자연스럽게 읽히도록이번에는 PC와 모바일 환경 모두에서 콘텐츠를 편하게 볼 수 있도록 최적화 하는 게 중요했어요. 하나의 자료를 두 환경에서 최대한 공통으로 활용하는 방식으로 접근했는데, PC와 모바일은 화면 비율이 많이 달라서 고민이 많았죠. 그래서 하나의 자료가 양쪽 환경에서 모두 읽히도록 최적화하는 작업이 필요했어요.PC 화면은 넓고 모바일은 작다 보니, 동일한 세션 자료를 보여줄 때 특히 모바일에서는 많은 부분이 잘리더라고요. 상단에는 제목이나 공유 버튼 같은 요소들이 있어 그 아래에 위치한 중요한 정보가 가려질 수 있었죠.그래서 어떤 기기에서 보더라도 핵심 정보가 화면 중앙에 잘 보이도록 모아서 배치했어요. PC 화면을 그대로 보여주는 방식은 작은 모바일 화면에선 가독성이 떨어질 수 있기 때문에, 작은 모바일 화면에서도 잘 보이도록 웹사이트 창처럼 보이게 디자인하기도 했어요.누구나 제작할 수 있는 환경 만들기Simplicity는 한 번 하고 끝나는 이벤트가 아니라 시즌마다 반복되는 컨퍼런스예요. 그만큼 제작 효율성과 지속가능성을 함께 고려해야 했어요.이번 시즌부터는 새 사이트를 만드는 대신, 하나의 플랫폼에 콘텐츠를 업데이트하는 방식으로 구조를 전환했고

개요안녕하세요! 지난 2025년 4월 7일부터 5월 16일까지 국내 FE/JS 개발자를 대상으로 진행되었던 'State of FE·JS Korea 2025' 설문조사 결과를 공유합니다.이번 설문에는 총 249명의 개발자분들이 참여해 주셨습니다.설문에 응답한 개발자들의 경력 분포를 살펴보면, Front-end 직무를 담당하는 개발자가 83.13%였고, 경력측면에서는 1-3년 경력(43.37%)과 4~6년(29.72%)의 경험을 가지고 있다고 답변한 분들이 대다수를 차지했습니다.전체 설문 결과 내용은 다음 링크를 통해 확인하실 수 있습니다.결과보기: http://naver.github.io/fe-news/stateof-fejs/2025/설문에 참여해 주신 모든 분들께 다시한번 감사드립니다! 주요 결과 항목1. 코드 작성 비중과 현황답변해 주신 분들 대다수는 TypeScript를 주로 사용(74.7%)해 코드를 작성한다고 답변해 주었고, JavaScript를 주로 사용한다고 답변한 비율은 23.79% 였습니다.HTML과 CSS는 대다수(46%~48%)가 1~30% 내외 수준으로만 작성한다고 답변해 TS/JS대비 상대적으로 많은 코드를 작성하지 않는것을 확인할 수 있었습니다.2. 프레임워크 및 라이브러리 사용 현황프론트엔드 프레임워크 및 라이브러리 사용 현황에서는 React를 계속 사용하겠다고 답변한 비율이 무려 94.38%로 여전히 국내 시장을 선도하고 있는 것으로 나타났습니다.React의 압도적 사용환경에 맞춰, 메타 프레임워크 영역에서도 Next.js의 사용률이 73%로 React와 유사하게 다른 경쟁 도구 대비 압도적 사용률을 보이고 있습니다. 이는 서버 사이드 렌더링과 정적 사이트 생성에 대한 관심이 계속해서 높아지고 있음을 시사합니다. Vue.js는 14.06%정도만이 계속 사용할것이라고 답변했고, Svelte는 4.82%, 그리고 Angualr는 0.4% 였습니다.3. 상태 관리 라이브러리상태 관리 라이브러리 분야에서는 Zustand에 대한 긍정 답변(관심있다 + 계속 사용예정)이 85.08%로 1위를 차지했습니다. [참고] Recoil은 지난 FE News 25/1월 소식을 통해 공유해 드렸던 것처럼, 개발이 중단되어 이번 조사 항목으로 포함하지 않았습니다.4. 빌드 도구 현황빌드 도구 분야에서는 Vite가 92.77%(관심있다 + 계속 사용 예정)로 압도적인 1위를 차지했습니다. 뛰어난 개발 경험과 빌드 성능을 제공하는 Vite는 많은 개발자들의 선택을 받고 있습니다.Webpack 또한 여전히 57.85%가 계속 사용 예정이라고 답변되었지만, 34.54%가 다시 사용하지 않을 것이라고 답해 부정적 평가또한 다른 도구들에 비해 높았습니다.신규 프로젝트에서는 Vite나 Turbopack을 선택하는 경향이 강해지고 있는 것으로 보입니다.5. AI 관련가장 많이 사용하는 AI 도구는 ChatGPT(31.31%), Claude(18.47%), Cursor(17.03%) 순으로 확인되었고, 제일 많이 사용하는 영역으로는 코드 어시스트(35.48%), 리팩토링(22.29%), 프로토타이핑(20.09%) 순이었습니다.AI 도구의 부상으로 인해 Front-end가 가장 많이 영향을 받지 않을까라는 시선이 많이 있는데요, 그에 대해서는 33.20%가 다른 기술영역과 동일하게 영향을 받을 것으로 답변해 세간의 시선과는 다르게 특별히 FE만 영향을 더 받지는 않을것으로 답변되었습니다.

AI 에이전트, 정말 실무에 투입할 준비가 되었을까?올해의 주요 키워드 중 AI Agent가 있습니다.벤치마크 상에서 높은 성능을 자랑하는 OpenAI나 Claude의 LLM을 기반으로, 고객 서비스나 예약 업무를 대신할 수 있도록 서비스화 하려는 많은 시도가 있습니다.하지만, 최근 Sierra 연구팀이 발표한 τ-bench 연구 결과는 아직은 LLM이 Agent의 역할을 수행 능력에 다시한번 의문을 제기합니다.최첨단 모델인 GPT-4o도 실제 업무 환경에서는 50% 미만의 성공률을 보였고, 같은 작업을 반복했을 때의 일관성은 더욱 심각했습니다.예를 들어, 기존 벤치마크 vs 현실 요구사항 사이의 차이는 이렇게 다릅니다.• None 단순하고 명확한 작업만 수행• None 인간과의 상호작용 없음하지만 실제 업무(서비스) 환경은 완전히 다릅니다:• None 고객이 불완전하고 단편적인 정보만 제공• None 복잡하고 다단계적인 요청 처리 필요• None 실시간 대화를 통한 고객과 상품/서비스 정보 수집 필수τ-bench는 실제 업무 환경을 시뮬레이션합니다:a) JSON 데이터베이스: 실제 서비스와 동일한 복잡성τ-bench를 기존 벤치마크와 다르게 하는, 가장 혁신적인 부분은 GPT-4 기반 사용자 시뮬레이터입니다.• None 다양한 스타일: 같은 요청을 다른 방식으로 표현사용자는 자연스럽게 대화하지만, 최종 목표와 정답은 명확히 정해져 있어 객관적 평가가 가능합니다.• None r_action: 최종 데이터베이스 상태가 목표와 일치하는가?• None r_output: 사용자 응답에 필요한 정보가 모두 포함되었는가?이 방식으로 주관적 인간 평가 없이도 정확하고 일관된 측정이 가능합니다.• None 창의적 문제 해결에서는 유용• None k번 시도에서 모두 성공하는 확률왜 pass^k가 중요한가?실제 서비스에서는 일관성이 생명입니다:최첨단 모델들조차 예상외 낮은 성적을 보였습니다.🏆 최고 성능 GPT-4o도 절반만 성공✈️ 복잡한 항공 도메인에서는 35%로 급락일관성 측면에서의 추가 과제Figure 4의 pass^k 결과는 앞으로 많은 고민이 필요하다는 것을 보여줍니다.:실무 관점에서의 의미:• None 같은 업무를 8번 처리하면 6번은 실패 가능성Figure 6에서 보듯이 복합 요청일수록 실패율 증가:도메인 정책의 중요성 검증정책 문서 제거 실험을 통해, 모델과 도메인의 특징을 파악했습니다.• None 단순한 retail: 상식으로도 어느 정도 처리 가능연구의 파급효과와 미래 전망맺음말 : AI 에이전트 시대의 현실적 출발점τ-bench 연구는 LLM의 성능을 넘어, AI 에이전트 기술의 정확한 현주소를 보여주는 이정표가 될 수 있습니다.앞으로 더 많은 도메인으로 확장되고, 더 정교한 평가 기준이 개발되며, 궁극적으로는 신뢰할 수 있는 AI 에이전트 시대의 토대가 될 것입니다.τ-bench와 같은 벤치마크의 발전을 통해 AI가 진정으로 인간에게 도움이 되는 방향으로 발전할 수 있도록 이끄는 나침반 역할을 할 수 있도록 많은 관심과 고민이 필요할 것 같습니다.

안녕하세요 SK 하이닉스 AI Design Lab 노재헌입니다.저는 회사에서 구성원들이 AI를 활용하여 일하는 문화를 만들기 위해 고민하고 있습니다 ㅎㅎ그러면서 여러 AI 서비스들을 찍먹해보고, 조금씩은 경험을 해보고 있는데요.오늘은 기존에 있던 서비스와는 다른 느낌의 UX 혹은 AX를 제공하는 서비스를 하나 소개하고자 합니다.기존의 LLM 서비스, 유명한 것들로 치면 chatGPT나 제미나이, claude 모두 쭉 라인바이라인으로 연결되는 터미널 형태의 구조를 가지고 있는데요.Flowith는 기존의 터미널 구조와는 다른, 완전히 새롭고도 신박한(비싸보이는) UX를 보여줍니다.어떤 UX를 제공하는지 한번 같이 보시죠.우선 질문을 만들어보겠습니다.예전에 주판을 쓰던 사람들이 이제는 엑셀을 사용하면서 일을 하고, ERP등의 서비스들에 적응해서 일을 하고 있잖아. 그런 것 처럼 이제는 AI를 사용해서 일하는 그런 문화를 만들기 위해서 어떤 허들이 있는지, 그리고 그 허들을 해결하기 위해서는 어떠한 노력이 필요한지 알려줘이런 질문을 chatGPT에 물어본다면 어떻게 할까요?좌측 상단에 있는 모델 선택하고 프롬프트를 입력한다면 그 이후에는 우리가 흔히 아는 LLM 프롬프트 형태로 진행이 됩니다.이렇게 우리가 선택한 모델 1개와 1개의 대답을 가지고 그 대답이 잘 맞기를 기대할 수 밖에 없죠.혹은 그 대답이 맘에 들지 않는다면 모델을 바꾸거나, 프롬프트를 바꾸거나, 아니면 다시 프롬프트를 실행할 수 밖에 없습니다.chatGPT만 하더라도 GPT-4o부터 o3, o4-mini 등등... 7가지 모델중에 어떤 모델이 가장 적합할지. 알기도 쉽지가 않죠.이런 니즈가 있다면 flowith가 가장 적합한 솔루션이 될 수 있습니다.Agent 모드의 flowith에 동일하게 질문을 적으면, flowith는 바로 대답을 생성하거나 추론하는 것이 아닌 프롬프트에 있는 질문에 대답을 하기 위해서, 어떤 구조로 프롬프트를 수행해야할지, 구조를 설계하게 됩니다.그 다음 각 질문에 대해서 어떻게 수행해야할지, 여러 Agent를 병렬적으로 수행하여 한 구조에 대한 프롬프트를 수행합니다.이 때, 1개의 모델에 여러 질문이 돌아갈 수도 있지만, N개의 모델에 동시에 같은 혹은 유사한 프롬프트를 실행하여 정보를 더 풍성하게 얻을 수가 있겠죠.벌써 6개의 Agent들이 동작하네요. 기존의 1개의 흐름만 따라가던 1:1 구조에서, 벌써 6개의 분화된 아이디어로 시작되는 것부터, 기존과 다르게 느껴지지 않나요?문제는... 각 1개의 프롬프트로 끝날 수 있던 비용이 6배까지 늘어날 수 있다는 점은... 감안해야겠네요.Flowith는 처음에 계획을 세웠던 대로, 각 스텝별로 여러 질문과 프롬프트를 수행하고, 아래와 같이 결과를 보여줍니다.이 모습만 하더라도 기존에 봤던 터미널 구조의 LLM과는 느낌이 다르지 않나요?뿐만 아니라 위와 같은 캔버스형 UX/UI를 통해 기존 LLM 프롬프트 구조에서는 실행할 수 없었던 다양한 조작도 가능합니다.이 외에도, GPTs와 유사하면서도 약간은 다른 Knowledge Garden 등을 통해 우리가 원하는 Agent 형태를 만들수도 있고, 또한 판매도 가능합니다.지금까지 간단하게 flowith의 UX와 기존 LLM과의 차이점에 대해서 간략하게 정리를 해봤는데요.당연하게 LLM은 터미널 형태로 돌아가는거지. 라고 생각했던 상식을 넘어선 flowith UX/UI.서비스를 사용하다보면 아직은 조금 더 보완해야하는 점은 많아보이지만, 새로운 UX를 제공했다는 점에서 상당히 신선한 서비스였습니다.앞으로 AI는 어떻게 발전하게 될까요? 다음 편에는 flowith의 agnet 모드 뿐만 아니라 knowledge 모드, 비 agent 모드까지 한번 더 정리해서 돌아오겠습니다.

안녕하세요. LINE 메신저 앱의 통화 모듈을 개발하고 있는 곽정남입니다. 제가 속한 Platform Product Engineering 2 팀은 지난 2024년 11월 태국 현지에서 LINE 메신저 앱의 통화 품질을 점검했습니다.현지 통화 품질 점검은 현지에서 실제 네트워크의 상태를 분석해서 이에 맞게 LINE 메신저의 통화 품질을 개선하는 것이 주 목적입니다. 네트워크의 상태는 국가별/통신사별로 상당한 차이가 발생할 수 있으며, 시간이 지나면서 그 정도가 조금씩 변하기도 합니다. 따라서 LINE 메신저 앱을 통해 통화 서비스를 제공하는 지역의 실제 환경을 점검하고 이에 맞게 서비스를 개발 및 튜닝하는 작업은 통화 품질 개선 측면에서 저희의 주요 과제 중 하나입니다.태국 현지에서의 통화 품질 점검은 지난 2022년 9월 이후 약 2년 만에 진행한 것입니다. 이는 지난 2년 동안 수행해 온 품질 개선 과제를 점검하는 좋은 기회이기도 했습니다. 이번 글에서는 지난 태국 출장에서 수행한 테스트 결과를 요약해 공유하려고 합니다.태국은 국가 단위로 살펴봤을 때 영상 통화를 가장 많이 사용하는 나라입니다. 실제 데이터와 함께 확인해 보겠습니다. 아래 그래프는 일본과 태국, 대만에서 하루 동안 발생한 LINE 앱 1:1 통화 중 영상 통화가 차지하는 비율을 비교한 그래프입니다.태국은 1:1 통화의 30.43%를 영상 통화가 차지하며, 이는 일본이나 대만의 두 배가 넘는 수치입니다. 태국 사용자가 LINE 앱 영상 통화 서비스를 가장 많이 즐기고 있다는 결과는 꽤 오래전부터 지속적으로 관찰돼 왔습니다. 이에 따라 저희는 영상 품질에 변화가 발생할 수 있는 경우 가장 먼저 태국 현지에서 테스트하고 점검하는 것을 염두에 두곤 합니다.LINE 앱은 오랫동안 태국에서 가장 인기 있는 1위 메신저 앱으로 자리매김하고 있는데요(참고). 몇 년 전부터 경쟁사 A 메신저 앱의 사용률이 꾸준히 증가하기 시작했고, 2024년 중반에는 태국 인구의 3/4 이상이 해당 메신저를 사용한다는 조사 결과가 발표되기도 했습니다. 이에 따라 태국에서 마켓 리서치를 수행할 때에는 항상 A 메신저 앱과 비교하는 내용이 등장하곤 합니다.A 메신저 앱은 시장 점유율뿐 아니라 실시간 통화 기술 측면에서도 저희에게 많은 것을 시사하는 메신저입니다. 주기적으로 자사 콘퍼런스를 개최해 더 나은 실시간 통신을 구현하기 위한 여러 기술을 소개하고 공유하며, 이는 LINE 앱 통화 모듈을 개발하는 저희들에게도 기술적으로 많은 영감을 주고 있습니다.현지 통화 품질 점검은 품질 테스트를 수행한 후 현장에서 바로 결과를 분석할 수 있는 엔지니어가 직접 해당 지역으로 이동해서 점검하는 방식으로 진행합니다. 대부분 여유롭지 않은 일정으로 진행되며, 출장 전에는 예측하지 못했던 이슈를 현지에서 발견하는 경우도 많습니다. 이에 따라 테스트를 수행하는 엔지니어는 출장 전에 목표로 삼았던 과제와 현지에서 새로 발견한 이슈를 종합해 우선순위를 정리한 뒤 사전에 준비해 온 테스트 시나리오를 적절하게 변경해가며 빠르게 테스트를 수행해야 합니다.현지에서는 장비 또한 부족할 수밖에 없습니다. 사무실에서 사용하는 모든 품질 측정 장비를 들고 갈 수는 없기 때문입니다. 이를 고려해 현지에서는 정량적인 QoE(quality of experience, 사용자 체감 품질) 결과보다는 주로 테스트 수행자의 정성 평가 위주로 진행하며, 복귀 후 사후 확인 가능한 정량값들을 정리해 분석합니다.즉, 현지 테스트는 정해진 시간 내에 최대한 많은 정보를 얻기 위해서 주로 현지 네트워크의 상태를 분석하는 것에 초점을 두며, 실제 사용자에게 전달되는 최종 미디어 품질(QoE)은 분석한 네트워크와 이와 관련된 네트워크 패킷 손실률, 네트워크 패킷 지연 시간 편차 등의 QoS(quality of service, QoE를 추정할 수 있으나 지표 수치 간 차이 발생 가능) 지표를 기반으로 추정하는 방식으로 진행합니다.테스트는 5명의 엔지니어가 5일에 걸쳐 주로 사람이 많은 환경에서 태국의 주요 통신사(True, AIS)의 4G 혹은 5G 네트워크에 연결된 상태에서 1:1 영상 통화 품질을 정성적으로 평가하는 방식으로 진행했습니다. 참고로 2023년 3월 1일, 기존 2위와 3위 업체였던 True와 Dtac이 합병했으며, 이번 글에서 True는 합병 이후의 회사를 지칭합니다.다음은 테스트 환경을 정리한 표입니다.태국에서의 LINE 앱 통화 품질 점검 결과태국에서 LINE 앱 영상 통화의 품질을 측정한 결과 네트워크 이슈가 발생한 경우 등을 제외한 대개의 경우 아래와 같이 우수한 품질을 보여줬습니다.경쟁사 메신저 앱과의 통화 품질 비교LINE 앱 영상 통화와 A 메신저 앱과의 통화 품질을 크게 화질과 비트레이트, FPS 측면에서 살펴보겠습니다.품질 점검 결과 LINE 앱 영상 통화의 화질이 A 메신저 앱 영상 통화의 화질보다 선명했습니다. 아래 이미지는 각 망(4G와 5G)에서 각 앱으로 영상 통화 시의 화질을 비교할 수 있도록 가져온 것입니다.위 이미지에서는 실제 영상 통화에서 저희가 확인했던 품질의 차이가 제대로 전달되지 않을 수도 있을 것 같은데요. 저희의 평가는 대략 LINE 앱 5G > LINE 앱 4G > A 메신저 앱 5G > A 메신저 앱 4G 순으로 나열됐습니다.다음 그래프는 평균 비트레이트를 비교한 그래프입니다. 두 앱의 통화 건 중 2분 동안 정상적으로 유지된 통화를 선별해 평균 비트레이트를 비교했습니다. 비트레이트는 많은 것을 내포하는 대표적인 QoS 지표입니다.4G와 5G에서 평균 비트레이트를 비교해 보면 LINE 앱이 A 메신저 앱보다 높다는 것을 알 수 있습니다. 비트레이트가 높다는 것은 그만큼 화질이 높다는 것으로 해석할 수 있으며, 실제 테스터들도 정성 평가에서 LINE 앱의 화질이 더 선명하다는 피드백을 남겼습니다.네트워크 상태와 비트레이트의 트레이드오프 관계여기서 네트워크의 상태가 영상 통화 품질에 큰 영향을 미치는 지표인 비트레이트와 어떤 관계가 있는지 간략히 짚고 넘어가겠습니다.인터넷은 패킷 단위로 데이터를 주고받는데요. 이때 패킷 전달 과정의 특성에

들어가며지난 1편에서 중고나라의 ML 플랫폼 전환에 대한 간단한 소회를 다루었으니, 이번에는 데이터브릭스의 각종 서비스를 활용한 MLOps 예시에 대해 이야기 해 보도록 하겠습니다.현대의 머신러닝 서비스는 단순히 모델을 학습하고 배포하는 것을 넘어서, 지속적인 모니터링, 자동화된 재학습, 그리고 안정적인 운영이 핵심입니다. 특히 실제 서비스 환경에서는 데이터 드리프트, 모델 성능 저하, 그리고 빠르게 변화하는 비즈니스 요구사항에 대응할 수 있는 유연한 MLOps 파이프라인이 필수적입니다.이번 글에서는 MLOps를 구성하는 핵심 요소들을 실제 서비스 사례와 함께 살펴보겠습니다:모델 학습: Unity Catalog, MLflow, Transformers를 활용한 체계적인 모델 개발 및 실험 관리모델 서빙: 실시간 추론 서비스 구축과 성능 최적화 전략모델 드리프트 탐지 & 재학습 자동화: 지속적인 모델 성능 관리와 자동화된 운영 체계모델 학습/서빙우선, 간단한 모델링 및 서빙에 대해 알아보겠습니다. 이번 유즈케이스의 메인 주제는 저희 머신러닝팀에서 운영하고 있는 것들 중 가장 간단한 서비스인 상품명 기반 카테고리 추천 입니다.문제 인식 & 서비스 기획중고나라는 현재 500개 이상의 상품 카테고리를 보유하고 있습니다. 이는 사용자에게 다양한 선택권을 제공한다는 장점이 있지만, 동시에 상품 등록 과정에서 어떤 카테고리를 선택해야 할 지 고민하게 만드는 큰 장벽으로 작용하고 있었습니다.이러한 고객 불편을 개선하기 위해 다음과 같은 기능을 수행하는 ML 서비스를 기획하게 되었습니다:상품명 입력 실시간 카테고리 Top 5 추천사용자가 추천된 카테고리 중 선택하거나, 기존 방식으로 직접 선택 가능추천 결과에 대한 피드백 수집을 통한 지속적인 모델 개선상기한 서비스를 만족시키기 위하여 Text Classification (NLP) 기반 ML/DL 모델을 활용하되, 실시간성/가용성 등을 고려할 필요가 있었습니다. 종합적으로 고려한 끝에 작은 사이즈의 Transformer 아키텍처 기반의 모델을 Fine-tuning 하는 것으로 가닥을 잡게 됩니다.데이터 준비상품 제목-카테고리 쌍의 학습 데이터 준비를 위해 데이터브릭스 내에서 Medallion Architecture(Bronze-Silver-Gold)를 구현했습니다. 이는 단순한 데이터 저장소가 아닌, 데이터 품질과 거버넌스를 보장하는 체계적인 데이터 관리 시스템으로, 이번 프로젝트에서 각 파트의 상세사항은 다음과 같습니다:Bronze(원천 데이터): 지난 n년간 축적된 상품 등록 데이터, 카테고리 매핑 데이터Silver(전처리된 데이터): Bronze 데이터에서 필요 최소한의 전처리가 적용된 데이터Gold(학습 데이터): Silver 데이터를 조합하여 창출한 비즈니스(모델 학습용) 데이터학습 준비학습 데이터가 준비 되었으니, 본격적인 모델 학습에 들어갈 차례입니다. 본 예제에선 다음과 같은 라이브러리들을 활용합니다:Hugging Face 라이브러리들: NLP, 특히 Transformer 아키텍처 기반 모델의 훈련 코드를 빠르게 구현할 수 있으며, 후술할 MLflow와의 연계 난이도 또한 매우 쉽기에 채택했습니다.MLflow: 데이터브릭스에서 기본적으로 제공해주는 관리형 MLflow 서비스를 이용하여 체계적인 실험/모델 관리를 간편하게 할 수 있기에 채택했습니다.데이터/모델 로드mlflow의 load_delta 메서드를 이용해 준비된 Gold 테이블을 불러온 뒤, 불러온 스파크 데이터프레임을 Hugging Face의 Dataset 규격으로 변환해 줍니다.import mlflowfrom datasets import Datasetmlflow.set_tracking_uri("databricks") # Databricks Managed MLflow 사용mlflow.set_registry_uri("databricks-uc") # Unity Catalog 모델 레지스트리를 사용train_dataset_delta = mlflow.data.load_delta(table_name="gold.ml_data.your_modeling_data_train")eval_dataset_delta = mlflow.data.load_delta(table_name="gold.ml_data.your_modeling_data_eval")train_dataframe = train_dataset_delta.dfeval_dataframe = eval_dataset_delta.dftrain_dataset = Dataset.from_spark(train_dataframe)eval_dataset = Dataset.from_spark(eval_dataframe)뒤이어, Fine-tuning에 사용할 PLM을 이번 Task(Text Classification)에 맞춰 불러옵니다.from transformers import AutoTokenizer, AutoModelForSequenceClassification, DataCollatorWithPaddingPRETRAINED_MODEL_NAME = 'your_organization/your_pretrained_model'tokenizer = AutoTokenizer.from_pretrained(PRETRAINED_MODEL_NAME)data_collator = DataCollatorWithPadding(tokenizer)model = AutoModelForSequenceClassification.from_pretrained( PRETRAINED_MODEL_NAME, num_labels=len(your_label2id), label2id=your_label2id, id2label=your_id2label ) model.to("cuda")학습 파라미터 설정이어서, 학습 파라미터를 설정합니다. 최악의 상황에서도 학습 도중의 모델 체크포인트를 보존하기 위해 데이터브릭스의 Volume 저장소를 체크포인트로 활용합니다. 실험 전송처로 mlflow를 설정해 줍니다.from transformers import TrainingArguments, Traineri

안녕하세요, 29CM Purchase & Post Purchase 팀 백엔드 엔지니어 강세종입니다.저희 팀은 고객이 상품을 장바구니에 담아 주문하는 단계(Purchase)부터, 주문 이후의 배송, 클레임, 정산 등 후속 프로세스(Post Purchase)까지 전반적인 기능을 개발하고 있습니다.오늘은 Post Purchase 영역 중 하나인 네이버쇼핑 수수료 정산 시스템에 대해 소개 드리려 합니다.특히 기존 시스템의 기술 부채를 해소하고, 보다 유연하고 확장 가능한 구조로 재설계하게 된 배경과 그 과정을 중심으로 공유드리고자 합니다.네이버쇼핑 수수료 정산 시스템이란?네이버 쇼핑에서 노출되는 29CM 상품29CM는 네이버 쇼핑과의 제휴를 통해 고객 접점을 넓혀가고 있으며, 위처럼 네이버 쇼핑에서 노출된 상품이 주문으로 이어질 경우 별도의 정산 체계를 운영하고 있습니다.네이버 쇼핑을 통한 주문은 일반적인 29CM 입점 파트너 매출 정산 외에도, 네이버 측에 수수료를 정산해야 하는 이중 정산 구조이기 때문에, 이를 처리하기 위한 전용 정산 시스템이 별도로 필요합니다.레거시 정산 시스템네이버쇼핑 수수료 정산 시스템은 네이버쇼핑으로 발생한 주문을 대상으로 정산 데이터를 생성하고, 관리자가 이를 조회·다운로드할 수 있는 API를 제공합니다.시스템은 크게 Batch 와 API 로 구성되어 있으며, 모두 Django(Python) 기반으로 구축되어 있습니다.[정산 데이터]네이버 정산 주문 상세 테이블 : 정산 대상 주문 정보를 저장합니다.네이버 정산 월간 집계 테이블 : 해당 월의 주문 상세 데이터를 집계한 금액을 저장합니다.[정산 Batch]정산 데이터 생성 플로우레거시 시스템은 Python 기반 Django 배치 스크립트로 정산 데이터를 생성합니다. 스크립트는 일 단위로 스케줄링되어 실행되며, 실제 데이터 조회와 계산 작업은 PostgreSQL에 정의된 2개의 프로시저를 호출하는 방식으로 구성되어 있습니다.출고 완료 주문의 정산 상세 데이터 생성 프로시저반품 완료 주문의 정산 상세 데이터 생성 프로시저두 프로시저는 주문·클레임·배송 등 원천 테이블에서 데이터를 조회해 금액을 계산한 뒤 네이버 정산 주문 상세 테이블에 적재합니다.이후 PostgreSQL 트리거를 통해 자동으로 네이버 정산 월간 집계 테이블 에 월 단위 집계 데이터가 생성됩니다.즉, 전체 구조는 다음과 같은 순서로 구성되어 있습니다:Django 배치 : PostgreSQL 정산 프로시저 2개를 순서대로 호출PostgreSQL 프로시저 : 원천 테이블에서 데이터 조회 후 상세 테이블에 적재PostgreSQL 트리거 : 상세 테이블의 데이터를 기반으로 월간 집계 테이블에 적재[정산 API]정산 데이터를 서빙하는 APIDjango 기반의 REST API 형태로 제공되며, 아래 세 가지 기능을 지원합니다.월간 상세 내역 조회 : 페이징 방식으로 특정 월의 정산 상세 데이터를 조회합니다.월간 상세 내역 다운로드 : 특정 월의 상세 데이터 전체를 CSV 파일로 다운로드합니다.월간 집계 내역 조회 : 페이징 방식으로 월간 집계 데이터를 조회합니다.레거시 정산 시스템의 문제는?7년 전 도입된 정산 시스템은 단순한 구조였기에 당시의 적은 데이터를 처리하는데 문제가 없었습니다.하지만 비즈니스의 급성장으로 정산 데이터가 폭증하면서, 성능 한계와 함께 로직 변경의 어려움도 점차 드러났습니다.특히 프로시저 중심 아키텍처는 새로운 요구 사항을 반영하기 어려워, 전면 개편이 불가피했습니다.[문제1. 비즈니스 성장을 감당할 수 있을까?]해마다 꾸준히 증가하는 연간 정산 데이터29CM의 매출은 해마다 높은 성장률을 보이며, 이에 따라 네이버쇼핑 정산 데이터 역시 비례하게 증가하고 있습니다. 레거시 시스템이 처음 설계된 2018년 당시에는 월 평균 정산 건수가 약 6천 건 수준이었지만, 현재는 약 4만 7천 건으로 8배 가까이 증가한 상황입니다.분명 같은 체급이었는데..데이터가 기하급수적으로 증가하면서 가장 먼저 한계를 드러낸 것은 상세 내역 다운로드 API  였습니다.기존 Django 기반의 API 서비스는 블로킹 I/O와 단일 스레드 구조 탓에 대용량 CSV 생성 시 처리 지연이 불가피했습니다특히, 정산 대상 데이터의 양이 많아질수록 응답 시간이 길어졌고, 결국 게이트웨이 타임아웃 제한 시간에 도달하는 문제가 빈번하게 발생했습니다.[문제2. 변경이 작아도, 비용은 크다.]레거시 시스템에서는 정산 대상 조회 데이터 생성 전 과정이 PostgreSQL 프로시저·트리거에 구현되어 있었습니다. 이는 과거 대용량 데이터를 효율적으로 처리하기 위해, 애플리케이션이 아닌 데이터베이스에서 직접 연산을 수행하도록 설계된 구조입니다.문제는 2개의 프로시저가 시간이 지남에 따라 점점 거대해졌다는 점입니다. 현재는 각 프로시저가 약 1,000줄 이상의 SQL 코드로 구성되어 있으며, 2개의 대형 INSERT 쿼리, 50개 이상의 CASE/IF 조건 분기, 12개 이상의 테이블 조인이 얽혀 있어 전체 로직의 흐름을 파악하기 매우 어려웠습니다.가슴이 웅장해지는 거대 프로시저구조적으로 복잡할 뿐만 아니라, 로직 대부분이 특정 도메인 지식에 의존하고 있어 새로운 팀원에게 온보딩하기도 쉽지 않았습니다.특히 쿠폰 할인, 마일리지 사용, 수수료 및 VAT 계산 등 20개 이상의 계산 컬럼이 존재하며, 이들 각각은 CASE, ROUND, TRUNC, COALESCE, SUBSELECT 등 다양한 SQL 내장 함수를 복합적으로 사용한 계산식으로 구성되어 있었습니다.그 결과, 단순한 정책 변경도 다단계 로직을 분석하고 수정해야 하는 고비용 작업이 되어버렸습니다. 이처럼 변경에 취약할 뿐만 아니라, 다음과 같은 문제점들도 함께 드러나고 있었습니다.[테스트와 버전 관리의 부재]정산 로직에 대한 테스트 코드가 없어, 모든 검증을 사람이 직접 수행Git으로 SQL 프로시저를 관리하는 데 어려움이 많아 변경 이력을 추적 불가로직이 크고 복잡하다 보니 협업 중 충돌이 자주 발생하여 작은 변경에도 리스크 존재[트리거 기반의 암묵적 실행 흐름]정산 데이터 생성 로직 중 일부가 PostgreSQL 트