Meta에서 4월 5일 토요일에 Llama 4를 발표했습니다.이미 며칠 지나서 지금은 새로운 소식들에 묻힌 감이 있습니다만 요즘 AI가 하루하루가 다르기 때문이겠죠.메타에서 토요일에 부랴부랴 발표를 진행한 것도 더는 미룰 수 없었기 때문이라는 견해도 나오고 있습니다.라마2와 3은 구조상 차이가 크지는 않았는데, 라마4는 이전 모델들과 여러 가지 차이가 있습니다. 우선 모든 크기에서 멀티모달 모델이고, MoE 구조를 채택했습니다.긴 입력을 지원하기 위해서 새로운 임베딩 알고리즘을 도입했습니다. 데이터가 고갈되면서 다시 아키텍처가 중요한 시대가 되는 것 같습니다.자세한 기술은 technical report가 발표된 뒤에 확인하기로 하고, 이 글에서는 내용이 모두 공개되어 있는 토크나이저만 살펴 보겠습니다.라마4 토크나이저라마4 토크나이저에 대한 분석은 이미 나와 있습니다.Sionic AI에서 라마 4는 한국어에 가장 친화적인 오픈소스 모델입니다는 분석을 발표했습니다.라마4 토크나이저에 포함된 한국어 관련 토큰 비중이 크게 증가했다는 내용입니다.비록 라마4의 공식 지원 언어에 한국어가 명시되지는 않았지만, 다국어 데이터를 늘리면서 한국어 데이터도 많이 늘어난 것으로 보입니다.그렇다면 라마4 토크나이저의 한국어 효율이 얼마나 향상됐는지 확인해 보겠습니다.위 분석글에서 한국어 텍스트가 몇 토큰으로 처리되는지 분석하지는 않았으므로 직접 확인해 보겠습니다.예시로 Meta Llama 3 간단한 분석에서도 보았던 데보션 매니페스토를 측정해 보겠습니다. 데보션 매니페스토는 아래와 같습니다:문장부호와 빈 칸을 포함해서 171글자로 된 데보션 매니페스토를 라마2 토크나이저에 입력하면 246토큰이 됩니다.라마2에서는 한글 토큰 비율이 낮아서 한글 한 글자를 세 개의 토큰으로 나타내는 경우가 있기 때문입니다.이보다 개선된 라마3 토크나이저에서는 93토큰이 됩니다. 거의 2글자당 1토큰 정도로 효율이 꽤 높아졌습니다.그렇다면 라마 4는 어떨까요? 확인 결과,확실히 한국어 토큰이 늘어난 효과가 있습니다.다른 오픈소스와 비교해 보면, OpenAI의 o200k_base 토크나이저가 88토큰이니까 라마4 토크나이저가 훨씬 효율적입니다.이 정도면 엑사원과 비슷한 수준이고 다국어 모델 중에서 최고 수준입니다.한국어에 중점을 둔 SKT A.X 토크나이저보다는 30% 정도 토큰을 더 사용합니다만 그래도 충분히 효율적이라고 볼 수 있겠습니다.비슷한 규모의 모델끼리는 토크나이저 효율이 높으면 언어 이해 및 생성 성능도 상승하는 경향이 있습니다.아무래도 한국어 지원이 가장 중요한 부분이기 때문에 먼저 설명했습니다. 이제 라마4 토크나이저의 전반적인 특졍을 간단히 보겠습니다.라마3에서는 OpenAI의 cl100k_base에 다국어 토큰을 추가해서 만들어서 토큰의 80% 이상이 겹쳤는데 라마4는 Meta 독자적으로 토크나이저를 만들었습니다.토큰 수 (vocab size)는 정확하게 20만개를 맞추었습니다. 토크나이저 인코딩은 이전과 똑같이 BBPE이기 때문에 눈으로 개별 토큰이 무엇인지

안녕하세요! 검색플랫폼팀의 Backend Engineer 하이(Hy)에요.당근에는 중고거래, 동네생활, 동네업체, 채팅 등 다양한 서비스가 있는데요. 검색플랫폼팀은 검색 서비스를 안정적으로 지원하는 플랫폼을 만들며, 다양한 서비스의 검색을 지원하고 있어요. 이를 위해서는 가장 먼저 각 서비스들의 데이터가 필요한데요. 이번 글에서는 각 서비스의 데이터를 검색 엔진에 전달하는 색인 파이프라인을 운영하면서, 어떤 문제가 있었고 어떻게 해결했는지 이야기하려고 해요.색인 파이프라인은 1) 실시간성을 보장하기 위한 Online 색인과 2) 사전 변경, 데이터 보정을 위해 하루에 한 번 전체 색인을 하는 Offline 색인을 해요. 이 두 가지를 진행할 때, 기존 파이프라인은 아래와 같은 문제점이 있었어요.생산성데이터를 가져오고 색인하는 로직의 패턴은 대부분 동일하지만, 서비스마다 로직이 따로 존재해서 관리 포인트가 많아져요.의존성당근의 서비스 DB에 직접적으로 붙어서 데이터를 가져오기 때문에, 각 서비스 DB에 강한 의존성을 가지게 됐어요.비용하루에 한 번 OnlineDB의 내용을 전체 Full Scan해야 하기 때문에 색인 파이프라인의 DB의 사이즈가 커야 했어요. 또한 서비스팀에서도 저희를 위한 ReplicaDB를 만들어주어야 해요.가시성어떤 필드가 어떻게 색인이 되는지, 필터링 로직 등 색인 로직이 어떻게 구성됐는지 등을 파악하려면, 늘 코드를 전부 일일이 확인해야 했어요.이전 색인 파이프라인에서 개발해야 하는 부분위의 4가지 문제를 해결하기 위해 다음과 같은 목표를 세웠어요.설정 기반의 인터페이스로 자동화하여, 누구나 기여할 수 있는 생산성이 높은 시스템을 만들어요.외부 서비스 DB에 대한 의존성을 낮춰서, 상태가 변경되어도 안전한 색인 파이프라인을 만들어요.하루에 한 번 풀색인(Full Indexing)의 부담을 낮추고 비용을 줄여요.이벤트가 쏟아져도 안전한 고가용성의 시스템을 만들어요.1) 설정 기반의 인터페이스로 자동화하여, 누구나 기여할 수 있는 생산성이 높은 시스템을 만들어요.위의 목표를 달성하기 위해서는 동작을 명시하는 설정 Interface가 잘 정의되어야 해요. 또한 아무리 자동화가 목적이라도 안전한 시스템을 갖추기 위해선, 먼저 안전한 스키마를 설계해야 해요. 그래서 아래와 같은 원칙을 세웠어요.해당 인터페이스에 명시된 동작만 이루어져야 하며, 이외에 다른 동작을 하는 마술은 부리지 않아야 함모든 데이터는 스키마를 가지고 안전하게 처리할 수 있도록 해야 함모든 in/out 사이에는 비즈니스로직을 자유롭게 넣을 수 있어야 함사용자가 몰라도 되는 core 로직은 데이터 처리 외에는 하지 않아야 함먼저 동작을 명시하는 Interface를 정의하기 위해 비교적 접근성이 쉬운 yaml을 사용하였어요. 아래는 데이터를 어떻게 가져오고, 적재하고, 관리할지를 보여주는 Datastore의 Interface 예시예요.version: 1name: {서비스이름}_datastorestorage: datastoresources: - table:

소프트웨어 서비스에 LLM이 도입되고 이제 AGI 시대로 접어든 이후 Tech서비스에는 AI의 활용이 점점 더 발전하고 있습니다.QA 테스트 자동화(Automation Test)에도 Chat기반 LLM Agent로 테스트 자동화를 빠르게 개발하고 도입할 수 있는 기술이 탄생했습니다.Chat기반 LLM Agent로 테스트 자동화를 진행하기 위해서는 Cursor IDE를 사용하고 있습니다.Cursor는 AI 코드 에디터이기 때문에 직접 테스트 프레임워크를 내장하고 있는 건 아니지만, 다양한 테스트 프레임워크와 잘 호환되도록 설계되어 있는데여러가지 테스트 프레임워크를 사용해봤지만 특히 Playwright 테스트 프레임워크와는 매우 강력한 호환성 시너지를 발휘합니다.Cursor는 Visual Studio Code(VS Code) 를 기반으로 만들어진 AI 코드 에디터입니다.GitHub Copilot이나 ChatGPT처럼 AI의 도움을 받아 코딩을 빠르고, 효율적으로 할 수 있도록 설계된 도구입니다.2024년 하반기 ChatGPT처럼 Chat 기반 Agent로 프롬프트 입력으로 개발 코드 작성을 지원해주는 업데이트를 지원합니다. (Chat 프리미엄 기능은 유료 - 참고)AI Model의 context User Roles 설정도 가능하며, OpenAI, Anthropic, Google, Azure API Key 연동도 가능합니다.Playwright는 Microsoft에서 개발한 Web 전용 End-to-End(E2E) 웹 애플리케이션 테스트 자동화 프레임워크입니다.Node.js를 통해 웹 브라우저를 실제 사용자가 조작하는 것처럼 자동화해서, UI 기능을 테스트하거나 웹 크롤링, 스크린샷, PDF 생성 등 다양한 작업을 할 수 있습니다.여러가지 테스트 프레임워크를 사용해 봤지만 Cursor는 다음과 같은 이유로 Playwright와 호환성 시너지가 가장 좋았습니다.• None AI가 시나리오 흐름을 잘 이해함: 예를 들어 “로그인 후 대시보드로 이동” 같은 흐름을 자연스럽게 코드로 생성• None 테스트 + 스크린샷 + mocking까지 프롬프트 기반으로 자동화 가능• None Headless 모드로 개발 이후 운영모드의 CI 확장성으로도 용의함QA에서는 테스트를 진행하기 위해서 TestCase를 작성 및 관리를 진행하고 있습니다.테스트 자동화의 가장 최적화 방법은 실제사용하고 있는 TestCase의 검증 동작을 테스트 자동화로 구현하는것을 목적으로 하고 TestCase 기반의 프롬프트를 샘플 코드로 작성합니다.[Web기반 에이닷 멀티LLM - 로그인 TestCase의 예시][TestCase] (아래 TC는 샘플코드를 위한 일부 생략된 예시 발췌 입니다.)샘플코드를 작성해보기 위해 몇개의 TestCase를 하나의 Prompt Step별 작성합니다.빠른 테스트 코드 작성을 위해서 일부 Button Control Element Locator를 미리 지정해두었고 (생략가능) PlayWrighr로 자동화 코드 생성을 요청하는 프롬프트를 만들었습니다.준비해둔

Part 1 에서는 Knowledge distillation 이 어떤 것인지, 어떤 방법론들이 존재하는지 살펴봤다.Part 2 에서는 distillation 을 이용해 LLM 추론 속도를 높이는 speculative decoding과, 가장 최신의 knowledge distillation 방법론들에 대해서 알아본다.사실 Distillation 의 장점은 student 모델의 성능 개선에만 있는 것이 아니다!Transformers는 학습 병렬화를 통해 거대 모델의 학습이 가능하게 했지만, 추론 할 때 엄청 느리다.Input sequence 에 대한 logit 은 한번에 구할 수 있는데, token 을 생성할 때에는 sequential 하게 생성해야 하기 때문이다.그래서 나온 Speculative decoding은 큰 모델의 답변과 비슷하게 답변하는 작은 모델을 통해 큰 모델의 속도를 높이는 방법이다.• None 작은 모델은 빠르게 생성할 수 있으니까 일단 token 여러개를 생성한다• None 큰 모델로 token 여러개에 대한 logit 을 한번에 뽑아서, 잘못 생성된 token 을 찾는다.• None 잘못 생성된 token 부터 다시 작은 모델로 토큰을 생성한다 -> 반복이게 되려면 큰 모델과 작은 모델의 답변이 비슷해야 속도가 올라간다. 만약에 모든 토큰이 다 달라버리면, 괜히 작은모델을 태워서 리소스만 더 잡아먹는 것이다.그런데 같은 데이터셋으로 학습했다고 하더라도 작은 모델과 큰 모델의 답변이 비슷할거라는 보장이 없다. 따라서 Distillation 을 통해서 speculative decoding 성능을 극대화하는 방법이 제안되었다.Distillation을 하면 student model 의 답변들이 teacher 와 비슷해지면서 10~45% 추론 속도가 증가했다.이 방법론은 실제로 Google 검색 페이지에 적용되어 있다가장 최근에는 이 Speculative decoding을 응용한 하이브리드 방법론도 제안되었다.GKD 가 성능이 좋기는 하지만, Student 의 on-policy response 가 썩 좋지 않은 상태에서 GKD 를 하는 게 괜찮을까에 대한 의문이 있다.이런 상황에서는 off-policy 더라도 퀄리티 좋은 teacher 의 response 를 써서 Supervised KD 를 하는게 나을 수도 있다.이 두 방법론의 장점만을 취한 방법론이 SKD 다.우선 Student 의 on-policy response 를 뽑는다. 그리고 각 token이 teacher 의 top-K token 에 포함되어 있는지 확인한다.만약 모두 포함되어 있는 경우라면 on-policy 응답이 꽤 좋은 상황이므로 GKD를 수행한다.포함되지 않는 토큰이 있는 경우라면 해당 토큰을 Teacher 의 token 으로 교체하여 퀄리티를 높이고, 이를 이용해 Supervised KD를 수행한다.이 SDK 방법론을 적용했을 때 성능도 오르고 speculative decoding 속도도 올랐다고 한다.왜냐면 Student 의 성능 관점에서는 on-pol

안녕하세요 현대자동차 자율주행 기반기술팀 조재훈 책임연구원입니다. 이번 포스팅은 'AI 학습 데이터'에 대한 현업에서의 고민을 정리해 보았으며 1) AI시대의 데이터, 2) 자율주행 도메인(domain)에서의 데이터, 3) 결론 3파트로 구성하였습니다.AI시대의 데이터최근 어딜가나 'AI'라는 키워드가 빠지지 않는데요, 좋은 성능을 갖는 AI를 개발하기 위해서 중요한 요소는 어떤것들이 있을까요?AI 모델? AI모델을 학습하기 위한 전용 GPU? AI를 학습하기 위한 데이터?모두 중요 하지만, AI 성능에 직접적이면서 결정적인 역할을 하는 것은 '데이터'라고 생각합니다. 그렇기에 많은 회사들이 데이터 센터 구축 및 활용 방안에 집중하고 있으며, 국가적인 차원에서도 국제적인 R&D 기술력 확보를 위해 정책적으로도 많은 고민을 하고 있는 것을 확인할 수 있습니다.그러면 여기서 이런 궁금증이 드는데요 ' 어떤 데이터가 좋은 데이터일까요?'좋은 데이터란 단순히 많은 양을 확보하는 것이 아니라, 모델이 학습할 수 있도록 구조적이고 체계적인 방식으로 정제된 데이터를 의미합니다. 특히, AI 모델이 일반화(generalization) 능력을 갖추려면, 다양한 상황과 환경을 반영한 데이터가 필요합니다. 그러나 현실적으로 모든 케이스의 데이터를 수집하는 것은 시간과 비용, 그리고 윤리적인 문제 등 여러 가지 한계가 존재합니다.실제(real) 데이터의 한계실제 데이터는 AI 모델 학습에 있어 가장 이상적인 데이터 소스이지만, 몇 가지 문제점이 존재합니다.데이터 수집의 어려움: 특정 도메인(예: 자율주행, 의료)에서는 데이터를 얻는 것이 쉽지 않으며, 개인정보 보호법 등의 규제에 의해 사용이 제한될 수 있음비용 문제: 대규모 데이터셋을 확보하고 라벨링하는 데는 많은 비용과 시간이 소요됨희귀한 사례 부족: 특정 상황(예: 드문 사고 상황, 극단적인 날씨 조건 등)의 데이터는 충분히 확보하기 어려워 모델이 특정 환경에서만 잘 작동하는 문제(편향, bias)가 생길 수 있음이러한 한계를 극복하기 위한 방법 중 하나가 합성(synthetic) 데이터입니다.합성(synthetic) 데이터란?합성 데이터는 실제 환경을 기반으로 컴퓨터가 생성한 가상의 데이터입니다. 3D 시뮬레이션, Generative 모델을 활용한 데이터 생성 (generated data 또는 pseudo label), 데이터 증강 기법(data augmentation) 등을 이용하여 기존 데이터를 변형하거나 완전히 새로운 데이터를 만들어낼 수 있습니다.합성 데이터가 유용한 이유는 다음과 같습니다.다양한 환경 및 변수 조절 가능: 현실에서 수집하기 어려운 다양한 조건(예: 다양한 조명 조건, 다양한 장애물 상황 등)을 자유롭게 생성할 수 있음비용 절감: 실제 데이터를 수집하는 것보다 훨씬 낮은 비용으로 대량의 데이터를 생성할 수 있음개인정보 보호 문제 해결: 의료 데이터, 금융 데이터 등 민감한 정보를 포함한 데이터셋의 경우, 합성 데이터를 활용하면 프라이버시 문제를 해결하면서도 모델 학습이 가능함합성 데이터는 비용 효율적이고 확장 가능한 AI 모델 학습 솔루션을 제공하지만, 이를 단독으로 사용할 경우 실제 환경에서 모델을 바로 적용하는데 문제가 발생할 수 있습니다. 가장 큰 문제는 '도메인 갭 (domain gap)'으로, 합성 데이터와 실제 데이터 간의 질감, 조명, 객체의 형태 및 환경 조건의 차이로 인해 발생합니다. 합성 데이터로만 학습한 모델은 '일반화(generalization)'가 어려워 실제 환경에서 예측 정확도가 저하될 확률이 높습니다. 아래의 Fig. 1은 합성데이터와 실제 데이터에 대한 예시를 보여주는데요, 아무리 정밀하게 실제 데이터처럼 합성데이터를 생성한다 하더라도, domain gap 문제는 발생할 수 밖에 없습니다. 우리가 봤을 때 차이가 느껴지는 것 처럼, AI 모델 또한 다르게 인식을 하는 것이죠.Fig 1. (좌) 합성 KITTI 데이터, (우) 실제 KITTI 데이터자율주행 도메인에서의 데이터Fig 2. Data-Driven Development Loop (DDDL)자율주행에서는 데이터를 어떻게 구축/활용하고 있을까요? Fig 2. 는 자율주행 개발 프로세스를 간단히 표현한 그림입니다. 딥러닝 네트워크 관점에서의 개발 파이프라인을 DDDL (Data-Driven Development Loop) 이라고 표현을 하였으며, 4가지 단계를 포함합니다:데이터 수집 (Data construction)네트워크 학습 (Training)성능 평가 및 검증 수행 (Evaluation & Validation)최종 네트워크 배포 및 피드백 (Release)Fig 3.은 각 단계별 소모되는 Man power (인력), 시간 (Time), 비용(Cost)를 시각화 하여 비교한 결과를 보여줍니다.Fig 3. 자율주행 개발 시 발생하는 비용 비교 정리Man power (y축): 각 단계를 수행하기 위해 투입되는 인력에 대한 정량 분석 결과Cost (x축): 각 단계를 수행할때 필요한 총 가격에 대한 정량 분석 결과 (데이터 구축/활용/검증/배포 비용, GPU 등)Space of circle: 각 단계를 수행할 때 소모되는 시간(Time)에 대한 정량 분석 결과* 해당 내용은 정량 평가를 시각화 하기위해 나타낸 그림입니다. Waymo, Tesla, Nvidia의 technical report등에 명시된 자료들을 기반으로 구성하였지만 오차가 있을 수 있습니다. (Waymo: 1,000만 마일 이상의 실 도로 주행데이터 수집 2년이상 투자/ Tesla: FSD (Full Self-Driving) 학습 및 검증에 매주 1백만 마일의 도로 주행 데이터 수집 및 처리/ NVIDIA autonomous driving platform: NVIDIA GPU resource 사용량은 1~ 3주 학습 기간 산정함/ Cruise (GM 자율주행 부문): 실제 차량 배포까지 2주 ~ 1개월의 시간을 필요로함)해당 분석으로 부터, 다음의 3가지 결론을 내렸습니다.자율주행 개발 프로세스에서 데이터 구축은 가장 많은 시간과 비용 인력을 필요로하는 것으로 보

주니어 개발자의 성장을 목표로 진행한 에러 디버깅 스터디 과정을 소개합니다.• [이론 스터디] 1. 에러 알림 대응 프로세스• 2. '현상'이 아닌 '원인'을 해결해야 하는 이유• [이론 스터디] 2. ‘디버깅 마인드셋: 디버깅의 고통을 절반으로 줄여주는 고수들의 행동패턴 따라하기' 영상 시청• 1. 디버깅 고수는 원인파악에 많은 시간과 노력을 투자한다.• 2. 디버깅 고수가 되기 위한 5단계 가이드• 스터디를 통해 배운 디버깅 팁 소개• 1. 검증되지 않은 가설을 믿지 않기 (고산하, 김경록, 최지수)• 2. 디버깅의 시작점은 단서를 수집하는 것 (최지수)• 4. 에러가 발생한 API의 특성을 이해하기 (김경록)• 5. 디버깅 과정을 쓰레드로 공유하기 (최지수)• 7. 중요한 문제 해결 후 회고하기 (고산하)• 스터디 이후, 어떻게 달라졌을까?• 마지막으로, 스터디 후기를 들려주세요.안녕하세요. 딜리버리 프로덕트 개발팀에서 일하고 있는 한경훈입니다.개발자라면 프로덕션에 배포 후 예상치 못한 에러가 발생하거나, 한밤중에 긴급한 장애 알람을 받는 상황을 종종 겪습니다. 이러한 에러는 때로는 서비스의 안정성과 직결되는 중요한 문제가 되기도 합니다.이러한 상황에서 중요한 것은 에러의 현상을 단순히 파악하는 데 그치지 않고, 시급도를 판단하고 근본적인 원인을 찾아 해결하는 것입니다. 문제를 깊이 있게 분석하고 해결하는 과정은 단순히 버그를 고치는 것을 넘어, 개발자로서의 실력을 쌓는 중요한 기회가 됩니다.다양한 에러 상황에 체계적으로 대처하는 능력은 주니어 개발자가 성장하기 위해 반드시 갖추어야 할 핵심 역량이기도 합니다. 이에 저희 팀은 "주니어 개발자를 위한 에러 디버깅 스터디"를 기획하게 되었고, 약 10주간 스터디를 진행하였습니다. 이번 글에서는 스터디의 진행 과정과 그 과정에서 배운 값진 경험들을 공유하고자 합니다.스터디는 총 10주간 “이론 스터디”와 “실전 디버깅 스터디” 두 파트로 나누어 진행되었습니다.• 에러 알림 대응 프로세스: 모니터링 시스템에서 에러 알림이 울렸을 때, 상황을 파악하고 대응하는 워크플로우 교육을 진행하였습니다.• 때마침 인프콘에서 디버깅을 주제로한 발표가 있었고, 실제 고수들의 행동패턴을 함께 학습했습니다.(럭키비키!)• 디버깅 마인드셋: 디버깅의 고통을 절반으로 줄이는 고수들의 행동패턴 따라하기• 실제 문제를 디버깅해보는 단계로, 매주 1시간씩 다음과 같은 타임 테이블로 진행되었습니다.• 주제 선정: 실제 발생했던 미처리 에러 중 하나를 선택하고 상황 설명[이론 스터디] 1. 에러 알림 대응 프로세스이론 스터디의 첫 번째 세션에서는 에러 알림 발생 시 효과적인 대응 방법에 대해 두 가지 내용을 중점적으로 다루었습니다.현상 분석: 무엇이 발생했는가? 에러를 마주쳤을 때 가장 먼저 해야 할 일은 현상을 정확히 파악하는 것입니다. 이는 다음 단계의 모든 의사결정의 기초가 됩니다. 현상 분석을 통해 장애 상황인지, 빠른 조치가 필요한 이슈인지, 혹은 마이너한 이슈인지와 같은 시급도와 영향범위를 파악할 수 있습니다

모두가 AI 로켓에 올라타도록, 당근 운영실이 AI로 일하는 법 — 당근 AI Show & Tell #2당근은 매주 ‘AI Show & Tell’을 통해 각 팀의 AI 실험을 전사적으로 공유해요. AI를 업무에 어떻게 적용하고 있는지, 그 과정에서 어떤 시행착오와 인사이트가 있었는지를 가감 없이 나누죠. 당근은 완벽한 정답을 찾기보다 먼저 과감하게 실행하며, AI 전환에 빠르게 몰입하고 있어요. AI로 만드는 생생한 도전의 순간들, 지금 만나보세요.✍️ 이 콘텐츠는 생성형 AI를 활용해 제작한 콘텐츠입니다.서비스 운영실 팀 내부 세션 ‘Nextstep for Service Operation’ 발표 자료단순히 팀에 AI를 도입한다고 해서 곧바로 혁신을 만들어낼 수 있을까요? 기술은 어디까지나 수단일 뿐이에요. 새로운 기술을 ‘무엇을 위해’, ‘어떻게’ 활용할지에 대한 체계가 뒷받침되지 않으면, 변화는 새로운 기술을 한두 번 시도해 보는 수준에서 그칠 수 있어요. AI로 유의미한 성과를 지속적으로 만들기 위해선 문제 해결 방식과 협업 구조까지 조직 전체가 AI에 맞게 바뀌어야 해요.최근 당근 AI Show & Tell 세션에서 서비스 운영실 리더 Brent와 운영실 ML Engineer 리더 Aio는 “운영실이 AI로 일하는 방식”을 공유했어요. 운영실은 사용자 접점의 최전선에서 사용자 문제 해결에 집요하게 몰입하는 팀이에요. 그렇기 때문에 AI를 도입할 때도 어떻게 해야 더 빠르고 정확하게 사용자 문제를 해결할 수 있을지 고민하며, 팀의 실행과 학습 속도를 극대화할 수 있도록 조직 구조와 일하는 방식을 재설계했어요.이 글에서는 당근 운영실이 AI 전환을 위해 어떻게 실행 문화를 세우고, 조직 구조를 실험적으로 바꿔 나갔는지, 그리고 어떻게 직군의 경계를 넘어 팀 모두가 함께 몰입할 수 있었는지 그 과정을 전하려고 해요.Part 1. 기반을 다지다 — 방향과 실행 문화의 세팅운영실의 AI 전환은 팀의 비전을 함께 점검하며 목표를 명확히 설정하는 데서 시작됐어요. “사용자 문제를 해결해 사용자 만족으로 연결하겠다”라는 운영실의 목표는 예나 지금이나 같고, AI 시대에도 변하지 않을 거란 점을 다시 확인했는데요. 다만 AI라는 강력한 수단을 잘 활용하면, 이전과는 비교할 수 없을 만큼 빠르게 목표를 성취할 수 있다는 데 모두가 공감했어요. 그렇게 팀 전체가 AI로 과감하게 시도하며 그 구체적인 방법을 찾아가 보자는 데 뜻을 모았죠.특히 운영실 리더들은 한 달 동안, 많게는 하루에 한 번씩, 최소 일주일에 한 번은 모여 실행 전략을 구체화했어요. AI 프로젝트의 방향과 분기별 OKR, 북미 대상 제품 전략까지 논의하며, 운영실의 다양한 프로덕트 중 어떤 영역을 AI로 혁신할 수 있을지 리스트업하고 우선순위를 재정비했죠. 이 치열한 정렬 과정 덕분에 팀원들은 방향을 잃지 않고, 함께 한 방향을 바라볼 수 있게 됐어요.이후 구성원들이 그 방향으로 힘 있게 나아갈 수 있도록, 구성원들에게 심리적 안정감을 주려 했어요. AI는 빠르게 실험하며 최적화하는

안녕하세요. LINE+ Contents Service Engineering 조직에서 백엔드 개발 및 프런트엔드 개발을 담당하고 있는 문범우, 안현모입니다.저희 조직에서는 그룹 구성원의 기술 성장을 돕고 향상된 능력을 적재적소에 활용할 수 있도록 'Tech Group'이라는 조직 내 스터디 그룹을 운영하고 있습니다. Tech Group에서는 여러 주제를 선정해 주제별로 소그룹을 나눠 함께 딥 다이브하는 시간을 보내는데요. 저희 그룹은 쿠버네티스(Kubernetes)를 주제로 다양한 내용을 함께 공부하고 토론하며, 필요한 사례를 연구하고 테스트한 뒤 프로젝트에 적용하고 있습니다.이 글에서는 저희가 다뤘던 다양한 주제 중 '쿠버네티스의 CPU 리소스'를 주제로 논의했던 내용을 공유드리려고 합니다. 먼저 쿠버네티스에서 CPU 리소스를 관리하는 방법을 소개하고, 더 나아가 애플리케이션의 성능을 개선하기 위해 CPU 상한( ) 설정을 이용해 CPU 리소스를 더욱 효율적으로 사용하기 위한 방법을 고민하고 테스트해 본 내용을 공유하겠습니다.이 주제와 관련해서 특히 재미난 점은 CPU 상한 설정을 유지 혹은 제거하는 것에 대해 각 프로젝트에서 서로 다른 결정을 내렸다는 점입니다. 미리 결론을 말씀드리자면, 벡엔드 서버 팀에서는 제거하는 것으로, 프런트엔드 서버 팀에서는 제거하지 않는 것으로 결정했습니다. 저희가 함께 테스트하고 토론했음에도 왜 이렇게 다른 결정을 내리게 됐는지 글을 읽으면서 함께 고민해 보신다면 여러분의 프로젝트를 개선하기 위한 좋은 아이디어를 얻으실 수 있을 것이라고 생각합니다.그럼 본격적으로 함께 살펴보겠습니다.먼저 쿠버네티스에서 CPU 리소스를 관리하는 방법을 살펴보면서 저희가 왜 CPU 상한 설정 제거를 고려하게 됐는지 말씀드리겠습니다.가장 먼저 살펴볼 내용은 쿠버네티스의 CPU 요청량( )과 CPU 상한( ) 설정입니다. 설명하기 위해 간단한 파드 매니페스트(pod manifest)를 가져왔습니다.위 내용 중 저희가 살펴볼 사항은 12번째 줄에 설정된 값과 15번째 줄에 설정된 값입니다.먼저 CPU 요청량( ) 설정을 살펴보겠습니다. CPU 요청량은 파드가 사용을 '보장받는' 최소 CPU 리소스의 값입니다. 이렇게만 생각하면 간단해 보일 수 있지만 간혹 '보장받는'이라는 개념을 '예약'과 혼동하시는 경우가 있습니다.예시를 들어볼까요? 아래와 같이 2 코어 CPU를 가진 노드에 를 1 코어로, 는 1.5 코어로 설정한 파드 두 개가 있다고 가정해 보겠습니다(편의를 위해 메모리 리소스 설정은 생략했습니다).위와 같은 상황에서 다음과 같이 부하가 많이 발생하지 않는 평소에는 각 파드가 모두 0.1 코어씩만 사용한다고 가정해 보겠습니다. 그렇다면 현재 노드에서 사용 가능한 여유 코어는 총 1.8 코어가 됩니다.이때 A 파드의 트래픽이 증가해 CPU 사용량이 많아지면 어떻게 될까요?바로 이런 상황에서 설정값이 '보장'의 개념인지 '예약'의 개념인지에 따라 다르게 작동할 수 있습니다.만약 '예약'의 개념이라면, A 파드의 트래픽이 증가하더

안녕하세요, 카카오페이손해보험 플랫폼기술팀의 리즈입니다.여러분은 데이터베이스 엔진을 몇 가지나 알고 계시는가요? 최초의 데이터베이스인 IDS가 1960년대에 설계1된 이후, 2025년인 지금까지 MySQL, Oracle, MongoDB, Redis, PostgreSQL 등 다양한 데이터베이스가 개발되어 사용되고 있습니다.그렇기 때문에 우리가 서비스를 구축할 때는 단순히 데이터를 저장하는 목적을 넘어, 각 데이터베이스의 특징과 장단점을 비교하며 서비스에 가장 적합한 데이터베이스를 선택하는 것이 중요합니다.이번 글에서는 검색 기능을 갖춘 데이터베이스이자 검색 엔진인 OpenSearch를 소개하고, 카카오페이손해보험의 플랫폼기술팀에서 어떻게 OpenSearch를 활용하고 있는지 함께 살펴보겠습니다.OpenSearch와 Analyzer를 알아보자OpenSearch는 검색 기능을 갖춘 NoSQL 데이터베이스이자 검색 엔진입니다.먼저, OpenSearch의 역사부터 간략히 알아보겠습니다. OpenSearch는 처음부터 새롭게 개발된 데이터베이스가 아니라 Elasticsearch에서 파생된 데이터베이스입니다. Elasticsearch는 Elastic 사에서 2010년에 출시된 검색 엔진2으로, 2021년에 Elastic사가 오픈소스였던 라이선스를 부분적으로 유료화3하면서, AWS가 Elasticsearch의 마지막 오픈소스 버전을 포크하여 독자적으로 개발한 프로젝트가 OpenSearch4입니다. 이 때문에 Elasticsearch와 OpenSearch는 핵심 기능과 구조가 매우 유사하며, 기존에 Elasticsearch를 사용해 본 경험이 있다면 OpenSearch도 쉽게 사용할 수 있습니다.다음으로, OpenSearch의 주요 특징을 살펴보겠습니다. 가장 큰 특징은 Apache Lucene을 검색 엔진으로 사용하여 뛰어난 검색 기능을 제공한다는 것입니다. Apache Lucene은 강력한 문서 전체 검색 및 인덱싱 기능을 제공하는 Java 기반의 검색 라이브러리로, 대량의 데이터를 효율적으로 인덱싱하고 빠르고 정교한 검색 결과를 제공합니다. 따라서 검색 서비스가 필요한 시스템을 구축할 때 OpenSearch는 매우 유용한 선택지가 될 수 있습니다.또한 OpenSearch는 JSON 기반의 문서(Document)를 저장하고 관리하기 때문에 반정형 데이터를 효율적으로 다룰 수 있습니다. 그리고 동적 스키마와 매핑 설정을 통해 데이터의 필드 타입을 유연하게 정의할 수 있어, 데이터 구조의 변경에도 유연하게 대응할 수 있는 장점이 있습니다.마지막으로, OpenSearch의 구성 요소는 RDBMS에서 사용하는 용어와 다소 차이가 있습니다.아래 표를 통해 간략하게 비교해 보겠습니다.OpenSearch에서 Index는 Table과 유사합니다. Document는 Index에 저장되는 데이터 Row를 의미하며, Document에 저장하는 각 Field는 데이터 타입을 관리합니다. Mapping은 테이블의 Schema와 유사하며 적재할 Document의 Field,

인간 VS AI 카피라이팅 대결 : 에이닷으로 카피 잘 쓰는 법"AI 카피라이팅"은 이제 일상 속에 있다. 카피를 써주는 AI카피라이팅 도구는 국내외를 통틀어 대략 200여개가 있다고 한다.한국방송광고진흥공사(KOBACO)의 플랫폼 아이작(AiSAC)은 기존의 215만 건 이상의 광고 자료를 학습해서 카피를 만들 수 있다.[ 한국방송광고진흥공사(KOBACO)의 플랫폼 아이작(AiSAC) 소개 자료 ]마케터 입장에서 사람보다 더 나은 결과를 낸다면 AI를 쓰지 않을 이유가 없다.특히 액션이 바로 숫자로 증명이 되는 마케터에게는 AI는 선택이 아닌 필수다.에이닷 마케팅팀에 일하면서 App push, MMS 등 대 고객 커뮤니케이션 할 일이 많기 때문에"에이닷"으로 카피라이팅 도움을 받을 때가 많다다만 "AI만" 쓴다면 조금은 평범하고 엣지 없는 결과물이 나오기가 쉽다에이닷 마케팅팀에서 에이닷으로 카피를 작성하는 팁을 공유해 본다.똑똑한 신입사원에게 일을 시키는 법쇼팽 콩쿠르 우승자가 처음 야구공을 던진다면? 슈퍼맨에게 레시피 없이 크로아상을 굽게 한다면?AI는 똑똑하지만 맥락과 배경 지식 없이는 평균적인 결과밖에 내놓지 못한다.특히 카피의 경우는 AI만 활용했을 때 문화적 뉘앙스와 최근의 이슈나 맥락을 담아내기에 살짝 부족하다.초반에 조금 품이 들지만 기초적인 프롬프팅을 해놓고 인풋을 충분히 주는 것이 좋다.형식 없이 시작하긴 어려우니 Why-How-What 과 같이 특정 프레임을 이용하여 시작한다.푸시 알림의 목적과 사용자에게 제공하는 가치를 설명사용자의 동기를 자극하고 공감예시: "고객님의 안전한 쇼핑을 위해"목적을 달성하는 방법이나 과정을 설명사용자가 취해야 할 행동을 명확구체적인 제안이나 혜택을 제시사용자가 얻을 수 있는 실질적인 결과를 강조.추가로 목적,타겟,제약,컨텍스트 등 실제 내가 메세지를 기획할 때 생각하는 요소들을먼저 주입시켜야 한다. 아래는 내가 생각한(AI와 같이 논의한..) 메세지 기획 필수 체크 리스트이다.이런 충분한 맥락을 고려하여 인풋을 작성하면서 AI와 대화를 시작할 때 더 나은 결과를 기대할 수 있다.인간의 초안, AI의 퇴고이미 많이 알고들 있지만 대화를 하면 할수록 AI는 강해진다 (챗지피티=채찍피티)다만 경험적으로 시작부터 AI를 쓰기보다는 인간이 충분히 고민한 결과물을AI와 개선해 나갈 때 더 좋은 결과를 얻을 수 있다.예를 들어 내가 만든 초안에 대해 AI가 여러 관점을 반영해 대안들을 제시하게 한다소구 포인트와 차별점을 바꿔가면 어떤 카피가 좋을 지를 비교하는 것 외에도마케팅에 행동경제학적, 심리적 이론들을 이용하는 것이다.긴급성/희소성 관련 심리를 사용한 FOMO (Fear Of Missing Out) 라든지,손실회피 편향 (Loss Aversion, 지금 안 하면 놓치는 특별 혜택) 과 같은잠재적 손실에 대한 두려움 자극하는 이론들을 활용하는 것이다.기존에 작성된 카피를 이론에 따라 여러가지를 조합해보고 검증하고 강화한다.그리고 아래 결과물을 무조건 믿는 것 보다 다시 인간이 조금씩 수정하는 것