ConfigMap 변경을 자동으로 반영하는 GitOps 구성을 하기 전까지, 우리 팀은 다음과 같은 방식으로 작업을 진행하고 있었습니다.개발자들이 ConfigMap에 추가하거나 수정해야 할 값이 생기면,제가 ArgoCD와 연결된 Git 저장소 내 ConfigMap 정의 파일을 직접 수정하고, 커밋한 뒤, 관련 파드를 수동으로 재시작(rollout restart)해주는 방식이었죠.이 작업은 표면적으로는 단순해 보이지만, 운영팀 전체 리소스의 반복적인 소모를 유발하고 있었고, 개발자 입장에서도 빈번한 요청을 전달하는 데 부담이 따를 수밖에 없었습니다.이러한 불편함을 줄이고, 더 나아가 자율적인 설정 관리가 가능하게 만들 수 없을까 고민하게 되었습니다.그래서 저는 다음과 같은 질문을 중심으로 접근을 시작했습니다:• None 우리가 이미 보유한 기술 스택으로 해결할 수 있는 문제인가?• None 개발자들이 직접 ConfigMap을 컨트롤할 수 있는 방식은 무엇인가?• None ConfigMap이 수정되었을 때, 자동으로 관련 파드를 재시작할 수 있는 툴이나 프로젝트가 존재하는가?여러 대안을 비교해본 결과, 우리 팀의 GitOps 구조에 가장 잘 맞는 해법은 Reloader + Argo CD 조합이었습니다.주요 이유는 별도의 커스텀 로직 없이도 단순하게 적용 가능하고, DevOps팀이 직접 개입하지 않아도 개발자들이 설정을 변경했을 때 곧바로 반영된다는 점이었습니다.Reloader를 간단히 설명드리자면, Reloader는 Kubernetes에서 ConfigMap이나 Secret 리소스에 변경이 감지되면,해당 리소스를 참조하고 있는 Deployment나 StatefulSet을 자동으로 재시작해주는 컨트롤러입니다.저희 팀은 이미 Kustomize + Argo CD 조합으로 GitOps 기반의 배포 환경을 운영하고 있었고,애플리케이션 리소스들과 함께 ConfigMap도 하나의 배포 단위로 포함되어 있었습니다.하지만 이 구조에서는 ConfigMap만 수정하려 해도 전체 애플리케이션 리소스를 함께 변경해야 했기 때문에, 설정 관리의 유연성이 떨어지고 커밋 단위도 무거워지는 문제가 있었습니다.그래서 저는 먼저 ConfigMap을 분리했고, ConfigMap만 별도로 관리할 수 있도록 GitOps 구조로 변경했습니다.변경 후 개발자분들은 직접 ConfigMap을 수정하면, Argo CD를 통해 해당 변경이 자동으로 동기화되고,Reloader가 이를 감지하여 관련 Deployment가 자동으로 재시작되는 것을 확인할 수 있었습니다.글로만 보면 다소 이해가 안될 수 있기 때문에, 그림을 보면서 다시 설명드리겠습니다.저희는 먼저 ConfigMap을 별도의 Git 저장소로 분리했고, Argo CD가 해당 저장소를 바라보도록 설정했습니다.그리고 Reloader가 클러스터 내 ConfigMap 리소스를 watch하도록 구성했으며, 이후에는 ConfigMap 값에 변경이 생기면,이를 참조하고 있는 리소스를 자동으로 rollout restart하도록 설정했습니다.example 네임스페이스에서 사용되는 ConfigMap들을 Kustomization으로 관리할 수 있도록 설정합니다.ConfigMap에 reloader.stakater.com/match: "true" 어노테이션을 추가하여, Stakater Reloader가 이 ConfigMap의 변경을 감지할 수 있도록 합니다.ArgoCD에서 ConfigMap 리소스를 관리할 수 있도록 kustomize 경로를 지정하여 자동 동기화가 가능하게 구성합니다.해당 Deployment가 참조 중인 ConfigMap 변경을 감지할 수 있도록 reloader.stakater.com/search: "true" 어노테이션을 추가합니다.이번 구조 개선을 통해 ConfigMap 변경 작업이 더 이상 번거로운 수작업이 아닌, GitOps 기반으로 자동화되었습니다.비록 작은 구조적 변화였지만, 개발자와 운영자 모두의 부담을 크게 줄일 수 있었고, GitOps의 진정한 장점을 팀원들과 함께 체감할 수 있는 계기가 되었습니다.앞으로도 이런 작지만 실용적인 개선을 꾸준히 이어가 보려 합니다.

우리는 다양한 상황에서 음성으로 AI와 대화하고 있습니다. 대부분의 음성 챗봇은 사용자의 입력이 끝나야 다음 단계가 진행되는 순차 처리 방식입니다.• None STT (Speech-to-Text): 사용자의 음성을 텍스트로 변환• None LLM (Large Language Model): 변환된 텍스트를 기반으로 AI 응답 생성• None TTS (Text-to-Speech): 생성된 텍스트 응답을 다시 음성으로 합성이 구조는 음성을 → 텍스트로 → 생각하고 → 다시 음성으로 바꾸는 방식으로 동작하고 있습니다.그런데 이 구조에는 두 가지 한계를 가지고 있습니다.• None 챗봇이 음성으로 응답하는 동안에는 사용자가 말을 시작할 수 없습니다.• None 즉, 사람이 대화 중 끼어들 듯 말하는 barge-in 기능이 지원되지 않아, 실제 대화처럼 자연스럽게 주고받는 흐름이 어렵습니다.• None 음성 입력 → 텍스트 변환(STT) → 응답 생성(LLM) → 음성 합성(TTS) 과정을 순차적으로 거치기 때문에, 각 단계의 처리 시간이 누적되며 전체 응답 속도에 영향을 줍니다.사람과의 자연스러운 대화처럼, 말이 겹치고 바로 반응하는 진짜 실시간 대화란 어떤 모습일지에 대해 고민해보게 되었습니다.여기서 말하는 ‘실시간’은 단순히 빠른 응답이 아니라, 사용자와 챗봇이 동시에 말하고, 끊고, 반응하는 자연스러운 상호작용을 의미합니다.이러한 경험이 가능할지 탐색하는 과정에서, 우리는 OpenAI의 Realtime API를 테스트해보며 그 가능성을 살펴보게 되었습니다.OpenAI Realtime API는 멀티모달 모델(GPT-4o 및 mini) 을 기반으로 한 초저지연(ultra low-latency) 양방향 인터페이스입니다.WebSocket 또는 WebRTC 연결로 텍스트와 오디오를 동시에 스트리밍하고, 실시간 음성 대화를 구현할 수 있게 만들어졌습니다. (Speech-to-Speech)OpenAI Realtime API는 다음 두가지 연결 방식을 지원합니다.우리는 기존의 백엔드 시스템에서 관리할 수 있도록 WebSocket을 활용하여 서버 - 서버 연동을 테스트해보았습니다.클라이언트에서 실시간으로 음성 데이터를 서버로 전송하면, 서버는 이를 OpenAI Realtime API에 전달하고, 응답 결과(음성 또는 텍스트)를 다시 실시간으로 클라이언트에 전달하는 구조입니다.서버는 이 과정에서 중계와 함께 DB에서 프롬프트 설정을 조회하거나, 로그를 저장하는 등 비즈니스 로직도 함께 처리할 수 있습니다.그리고 OpenAI Realtime API와는 WebSocket 연결을 유지한 채, 스트림 기반으로 상시 통신하고 있습니다.4. Go Channel과 Goroutine으로 WebSocket 양방향 스트림을 쉽게 다뤄보자우리가 목표로 했던 것은 WebSocket 기반 OpenAI Realtime API와의 실시간 양방향 통신을 안정적이고 명시적으로 다루는 것이었습니다.WebSocket을 사용하면 다음과 같은 이유로 구현이 복잡해질 수 있는데요.• None 하나의 스트림에서 동시에 송수신이 일어나야 합니다. (별도의 스레드, 비동기 핸들링 구조 필요)• None 연결 종료, 네트워크 오류, 타임아웃 등 다양한 실패 케이스가 송수신 양쪽에서 다르게 발생하므로 예외 처리가 분산될 수 있습니다.• None 연결 상태를 mocking하거나 제어하기 어렵습니다.이를 위해 Go에서 제공하는 채널(channel) 과 고루틴(goroutine) 을 활용했습니다.Go의 chan(채널)은 Goroutine 간 데이터를 주고받을 수 있는 안전한 통신 수단입니다.간단히 말하면, 두 개의 흐름 사이에 데이터를 흘려보내는 파이프 같은 개념입니다.goroutine Go의 초경량 스레드로, 함수 하나를 동시에 실행시키는 비동기 작업 단위입니다.수천 개를 띄워도 메모리 부담이 거의 없기 때문에, WebSocket처럼 동시에 여러 작업이 일어나는 환경에서 특히 유용합니다.그래서 우리는 Go의 chan과 goroutine 조합을 사용해 읽기와 쓰기, 에러 처리, 종료 흐름을 명확히 분리하고 구조화했습니다.그 결과, 내부 로직은• None 채널에서 꺼내는이처럼 데이터 흐름을 명확히 분리한 덕분에 WebSocket의 읽기/쓰기 처리뿐 아니라 에러 핸들링과 종료 처리까지도 직관적으로 구현할 수 있었고, 테스트 작성 역시 수월해졌습니다이후 서비스 로직에서는 session의 In과 Out 채널을 통해 메시지를 주고받기만 하면 되므로, WebSocket 처리에 직접 관여하지 않고도 실시간 흐름을 간결하고 편리하게 구현할 수 있습니다.이번 글에서는 OpenAI Realtime API가 무엇인지, 그리고 어떤 상황에서 활용할 수 있는지부터 이를 Go의 goroutine과 channel을 활용해 실시간으로 연결하는 구조까지 함께 살펴보았습니다.복잡할 수 있는 WebSocket 스트림도, Go의 채널을 활용하면 직관적인 흐름으로 추상화할 수 있다는 것을 확인할 수 있었고,이를 통해 실시간 음성 응답 흐름을 안정적이고 효율적으로 구현할 수 있었습니다.Realtime API는 현재 베타(Beta) 단계로, 지속적으로 발전 중인 기술입니다.실제 서비스에 안정적으로 적용하기 위해서는 프롬프트 설정, 보이스 옵션, 그외 여러 파라미터 등 다양한 기능들을 상황에 맞게 테스트하고, 최적의 조합을 찾아가는 과정이 필요했습니다.하지만 그만큼 앞으로 더 많은 기능이 추가되고, 더 나은 성능과 커스터마이징 옵션들이 제공될 것이라는 기대도 큽니다.Go의 channel과 goroutine은 이러한 실시간 스트리밍 구조에 매우 강력한 도구입니다.이번 예제를 바탕으로, 여러분의 프로젝트에서도 채널 기반의 구조를 다양하게 시도해 보시길 추천드립니다. 😄

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 발표 내용유저 세그먼트를 손쉽게 정의하고, 이를 다양한 액션 채널(Braze, IDS, GAM 등)과 자동 연동할 수 있는 네이버 웹툰의 Cohort System을 소개합니다. 조건 기반 필터링, ML 모델 연동 등 다양한 방식으로 세그먼트를 만들고, 중복 제거 로직과 함께 효율적으로 활용할 수 있습니다. 시스템 구조와 기술 스택, 실제 마케팅 활용 사례까지 함께 공유하며, 데이터에서 인사이트, 나아가 액션까지의 연결을 어떻게 자동화했는지를 설명합니다.강의 대상데이터 엔지니어 / 백엔드 엔지니어: 데이터 흐름 자동화, 시스템 구조에 관심 있는 분ML 엔지니어 / 데이터 사이언티스트: ML 결과를 실시간 타겟팅에 적용하고 싶은 분마케터 / PM: 타겟 유저 추출과 액션 전환까지의 전체 흐름을 이해하고 싶은 분목차Episode 1: 데이터 추출, 아직도 수작업으로 하시나요?반복과 오류, 그리고 비효율의 문제Episode 2: 웹툰의 코호트 시스템코호트 시스템의 구조와 흐름Episode 3 : Data 연결: 코호트에서 액션으로ML 모델IDSBrazeGAMEpisode 4 : Data 확장: 코호트에서 코호트로코호트 간 중복 제거 기능Episode 5: 캠페인 사례로 본 Cohort System의 효과코호트 시스템은 어떻게 쓰여질까? NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY 2025(5월)의 일부 세션을 공개합니다.

기술 문서는 늘 부족합니다. 특히 좋은 기술 문서가 부족하죠.테크니컬 라이터는 좋은 기술 문서를 쓸 수 있지만, 사내 프로젝트를 모두 담당하기에는 수가 턱없이 모자랍니다. '개발자 글쓰기 교육'으로 그 간극을 메워보려는 시도도 있지만, 과연 교육만 들으면 모든 개발자가 기술 문서를 잘 쓰게 될까요?글쎄요, 저는 회의적입니 다. '잘 쓰는 방법을 몰라서'는 개발자가 기술 문서를 쓰지 않는 원인 중 하나일 뿐, 전부가 아니니까요. '시간'이나 '관심' 같은 외부적 원인은 교육으로는 해결하지 못합니다.문서 엔지니어로서, 저는 이 문제를 '개발자 교육'보다 '엔지니어링'으로 풀어보려고 노력해 왔습니다. 프로세스를 통한 강제화, 도구를 이용한 자동화로요. 생성형 AI가 글 쓰는 직무를 대체할 것이라는 예측도 있지만, 이런 관점에서 볼 때 도큐먼트 엔지니어에게 AI가 반드시 경쟁자인 것만은 아니더군요. 오히려 기존의 한계를 극복하게 해주는 기회에 가깝죠. 비유하자면, 테크니컬 라이터가 한 땀 한 땀 공들여 문서를 만들어 내던 가내수공업 방식을 공장형 자동 생산으로 바꿀 기회랄까요.LINE Plus의 Document Engineering 팀은 이런 마음가짐으로 AI를 꾸준히 활용해 왔고, 덕분에 그 아이디어를 시험해 볼 기회를 얻었습니다.LY 그룹은 업무에 생성형 AI를 도입하는 데 적극적입니다. 그 일환으로 주요 개발 단계에서 생성형 AI를 활용하는 프로젝트를 진행 중인데요. 대상 작업 중 하나가 문서화입니다.저희 팀은 프로젝트를 시작하면서 문서화 생산성을 높이겠다는 목적 아래 개발 단계에서 가장 필요한 문서가 무엇일지 한참 고민했습니다(프로젝트 자체 요구 사항을 참고해서요). 몇 가지 아이디어가 있었고, 그중 소스 코드를 이용하면서 개발자나 사용 자에게 모두 영향을 미치는 API 레퍼런스 문서에 적용해 보기로 했습니다.소스 코드를 설명하는 기능은 GitHub Copilot 같은 코딩 어시스턴트가 이미 잘하고 있는데 '뭘 더 하려는 것일까?'하는 의문이 생기실 수도 있겠네요. 아쉽게도 코딩 어시스턴트로는 해결하지 못하는 문제가 몇 개 있습니다.더불어 프로젝트마다 API 문서 형식도 다르고 배포하는 곳도 달라서 참고하기 어렵다는 개발 팀 의견도 있었습니다. 코딩 어시스턴트는 이것도 해결하지 못하죠. 따라서 저희는 '사내 정보를 참고해서 사내 스타일에 맞는 API 주석을 작성하고, 이를 레퍼런스로 만들어 한곳에서 배포하기'를 목표로 삼아 프로젝트를 시작했습니다.저희 팀은 기술 문서를 검토하고 다국어화한 경험이 많습니다. 이미 몇몇 프로젝트에서는 문법, 표현, 스타일 일관성을 확인하는 용도로 프롬프트를 만들어 AI를 활용하고 있고요.사내 스타일 가이드에 맞춰 일관된 톤과 스타일을 유지하려면 꽤 긴 프롬프트가 필요합니다. 여기에 프로그래밍 언어별로 상세한 API 주석을 작성하는 방법과 용어 정보까지 더했더니 LLM이 몇몇 지시를 놓치기 시작했습니다(LLM도 지시가 많으면 기억력이 떨어지나 봅니다). 그러잖아도 사내 머신 러닝 팀 전문가의 도움을 받고 있었던 터라 개선 방안을 여쭸더니, 실행 단계를 나누고 단계별로 수행할 프롬프트를 분리하라고 하시더군요.처음에는 아래와 같이 세세하게 단계를 나눴습니다.

신용대출 찾기 서비스는 다양한 제휴사의 대출 상품을 연동하여, 고객이 보다 편리하게 대출 상품을 탐색하고 신청할 수 있도록 돕는 서비스입니다.이번 글에서는 신규 제휴사 연동 이후 제휴사의 테스트 서버가 유효한 응답을 주지 않거나, 특정 케이스를 테스트하기 어려운 상황을 어떻게 해결했는지, 그리고 이를 위해 설계한 mock 서버를 소개하고자 해요.신규 제휴사 연동 이후 다음과 같은 문제들이 반복적으로 발생했어요.• None 특정 퍼널 또는 고객 조건에 맞는 테스트 데이터 확보의 어려움• None 테스트 과정에서 실제 제휴사 서버로부터 유효한 응답을 받기 어려운 상황이러한 문제들은 QA 및 신규 기능 개발 효율을 떨어뜨릴 뿐 아니라, 서비스 출시 일정에도 영향을 주었습니다. 이를 해결하기 위해 사용자, 제휴사, 퍼널 단위로 정밀하게 동작을 제어할 수 있는 mock 서버를 설계했어요.본격적인 설명에 앞서, 대출 도메인과 관련된 주요 용어를 간략히 정리할게요.• None : 은행, 저축은행, 보험사 등 대출 상품을 제공하는 금융기관• None : 고객 정보를 활용해 대출 금리, 한도 등을 간단히 확인하는 행위• None : 가심사 결과를 바탕으로 고객이 특정 상품에 대해 대출을 신청하는 행위• None : 제휴사가 고객 정보를 활용해 대출을 실행하고 자금을 입금하는 행위기능적 / 비기능적 요구사항은 아래와 같았어요.mock 서버는 다음과 같은 구성요소로 설계되었습니다.신용대출 찾기 서비스는 mock 동작 여부나 mock 데이터 생성 시 필요한 유저 정보를 클라이언트 요청의 헤더를 통해 주입받습니다. 이렇게 하면 비즈니스 로직에는 전혀 영향을 주지 않고, 테스트를 유연하게 제어할 수 있어요.• None RestTemplate에는 인터셉터를 통해 요청마다 헤더를 추가할 수 있어요. 아래는 유저 ID와 원장 ID를 주입하는 예시입니다.• None 에 등록하면, 모든 제휴사 요청에 자동으로 헤더가 포함됩니다.• None WebClient에서는 을 활용해 헤더를 주입해요. 아래는 동일한 목적의 필터 예시입니다.• None 와 같이 등록해주면 돼요.모든 설정값은 DB 테이블에서 관리하여 유연성을 확보했어요.• None• None 콜백 을 N 초 후에 받을 것인지• None 특정 퍼널 에 대해 어떤 mock 응답을 받을 것인지 등정의된 정보를 사용해 mock 응답 을 생성합니다.mock 서버에서는 실제 제휴사처럼 콜백 응답을 지연하여 전송하는 기능이 필요합니다. 이를 통해 비동기 응답을 테스트할 수 있도록 지원하며, 실제 서비스 환경을 더 현실감 있게 시뮬레이션할 수 있어요.예약은 다음과 같이 두 단계로 구성됩니다.• None 가심사 조회나 대출 신청 API 호출 시점에,• None 각 요청에 대해 몇 초 후 콜백을 호출할 지 결정되며, 이 설정은 유저 설정( )에 정의된 값을 사용합니다.• None 필드에 실행 시점을 기록합니다.• None mock 서버에서는• None 를 사용해 콜백 API 요청을 실제로 전송합니다.mock 응답은 실제 제휴사 응답과

안녕하세요. 여기어때컴퍼니 iOS개발팀 샐리입니다.지난 5월 14일 AWS Summit Seoul 2025 — Industry Day에 참석했습니다.예상대로 올해 행사에서는 생성형 AI가 가장 화두였습니다. 다양한 세션들을 듣고 Expo도 둘러보았는데요. 생성형 AI가 산업 전반에 얼마나 빠르게 적용되고 있는지 체감하고 인사이트도 얻을 수 있었습니다.코엑스에 도착하니 벌써 많은 분들이 부스 체험을 하고 계셨습니다. 저도 얼른 참가자 등록을 하러 갑니다.행사 입장을 위해 네임택을 수령하러 왔습니다. 세련된 공간 연출과 조명 덕분에 마치 콘서트에 온 듯 했네요. 규모에서부터 압도되는 느낌이었고 어떤 프로그램들이 기다리고 있을지 기대감이 커졌습니다.AWS Summit Seoul 행사는 세션과 Expo로 이루어져있습니다. 모두 다 해보려니 시간이 약간 부족하기도 했지만 세션과 Expo를 모두 즐기고 알차게 보내고 왔습니다.세션1. 여행 goes AI! AWS 생성형 AI 없이는 살아남을 수 없어!여기어때가 여행/숙박 앱이다보니 자연스레 관심이 가는 주제였습니다.RAG 기반의 업무용 생성형 AI 챗봇인 Amazon Q에 대해서 알게 되었는데요. Amazon Q로 사내에 도움이 되는 챗봇을 만들어보면 재밌을것 같다는 생각이 들었습니다.AI is not going to replace humans, but humans with AI are going to replace humans with AI. — Karim Lakhani말 그대로 직역해보자면 AI는 사람을 대체할 수는 없지만 AI를 사용하는 사람이 AI를 사용하지 않는 사람을 대체할 것이다.AI가 오래 전부터 연구되어 온 기술이긴 하지만 AI기술이 보편화되는 것은 살짝 먼 이야기라고 느껴졌었는데요. Chat-GPT의 등장으로 판도가 완전히 바뀌었죠. 이제는 누구나 AI를 사용하고 활용할 수 있게 되었. Chat-GPT가 등장한게 지금으로부터 불과 몇년 전이지만 현재는 AI가 없는 일상이나 업무는 거의 상상할 수 없을 정도니까요. 단순한 정보 검색을 넘어서 문서와 코드 작성, 아이디어 구상 등 실질적인 생산성 도구가 되어 우리의 삶을 더 편리하게 해주고 있습니다.저도 AI가 인간의 모든 능력을 완전히 대체할 수는 없다고 생각합니다. 하지만 이제는 AI 없이 일하는 게 비효율이 되어버린 시대로 바뀌었다는 생각이 들었습니다. 앞으로는 AI를 어떻게 잘 효율적으로 활용하느냐가 큰 관건이 될 것 같습니다.2. Amazon Bedrock을 이용한 이미지 검색서비스의 혁신저는 작년 사내 해커톤에서 GenAI를 활용한 챗봇을 주제로 참가했었는데요. 간단하게 설명드리면 Google Vision API로 숙소 이미지 메타데이터를 태깅하고 색인 DB를 구축하여 이미지 기반 숙소 검색 기능을 제공하는 챗봇이었습니다. 해커톤에서 만든 것과 실제 비즈니스 방식이 어떻게 어떻게 다를지 궁금했습니다.게티이미지코리아에서는 키워드 기반의 검색을 자연어 검색이 가능한 기능을 구현했다고 합니다. 사용자가 이미지를 업로드하면 Amaz

흔한 IntellIJ 사용자의 Cursor를 쓰고싶다는 욕망요즘 Cursor와 같은 IDE 와 LLM 을 통합한 제품들이 정말정말 인기가 많습니다.주변 개발자 중 안쓰는 사람이 없을 정도입니다.써보니까 너-무 좋기는 한데 골수 Jetbrains 빠인 저에게는VS Code 기반의 IDE 인 Cursor 넘어가는 것이 굉장히 부담스러웠습니다.좋은 것은 알겠는데, 10년간 써온 IDE를 바꾸는 것은 쉽게 결정할 수가 없었습니다.그래도 이런 툴을 안 쓰기에는 아쉬워서코딩은 IntelliJ 로 AI와의 대화는 Cursor로 하는 어정쩡한 방식을 한동안 사용했습니다.그래도 젯브레인인데, 유사한 기능이 금방 나오겠거니 하고 기다렸더니IntelliJ 안에서 쓸 수 있는 툴이 나오기 시작했습니다.일단 좋아하는 회사에서 만든거라 굉장한 편견을 가지고 사랑을 보내며 사용했는데,시간만 가고 해결이 안되는 현상을 수없이 겪고나서 사용을 포기하게 되었습니다.• None 가격: $10 / 월 (또는 IntelliJ All Products Pack 을 쓰면 무료)동료 개발자에게 들은 새로운 툴인 Augment Code는 조금 느리긴 하지만Cursor 에 거의 필적하는 코드작성 능력과 속도를 보여줬습니다.성능만 본다면 쓸만한데,$50 의 월간 구독료는 견디기가 힘들어 무료 사용기간이 끝나고 포기하게 되었습니다.• None 코드 작성능력: 커서보다 아주조금 떨어짐• None 괜찮은 성능에 괜찮지 못한 가격.gif마지막으로 찾은 툴은 Claude + IntelliJ 였고, 효과는 놀라웠습니다.IntelliJ IDEA 의 코드를 Cursor와 동일한 품질로 이해하고 답변을 작성해줬습니다.게다가 Google 드라이브 + 메일 + 일정 등의 외부 생태계와도 연결을 할 수 있어 확장성이 매우 뛰어났습니다.그래서 저는 정기결제를 추가하고 당분간은 여기에 정착하기로 했습니다.• None 방식: 별도 App 을 설치하여 IntelliJ와 연결• None 좋은 성능에 합리적인 가격.gif둘을 연결하려면 MCP (Model Context Protocol) 를 활용하여 연결해야 합니다.MCP 는 LLM에게 Context (이 글에서는 내 프로젝트 코드) 를 제공하는 프로토콜입니다.MCP 에 대한 자세한 설명은 아래 블로그를 참고해주세요!우리는 아래 2개를 설정하여 사용할 것입니다.먼저 IntelliJ 에는 Server로 작동하게끔 하는 플러그인을 설치해줍니다.IntelliJ 설정에서 Plugins 로 들어가서 MCP Server 를 검색하고 설치만 하면 됩니다.다음으로는 Cluade Desktop 에 Intellij Server 정보를 등록해줍니다.Claude Desktop 이 없다면 다음의 링크에서 다운로드 받고 설치합니다.설치를 마치고 Claude를 열고 설정에 들어갑니다.Claude 설정을 열고 (맥 기준 Cmd + , ) 개발자 탭으로 들어갑니다.여기서 설정 편집 버튼을 누르고 claude_desktop_config.json 파일을 엽니다.그럼 거의 비어있는 json 파일이 열리는데요.그곳에 아래 내용을 넣고 저장합니다.그리고 Claude Desktop을 다시 켜서 설정으로 들어가보면아래 그림처럼 jetbrains 가 추가되어 running 상태로 나옵니다.이제 모든 준비가 완료되었습니다.이제 내 코드를 기반으로 Claude와 대화해보세요!Claude + Github, Google 등 다른 툴과의 연계방법이것으로 끝나면 Cursor와 똑같다고 느끼실 수 있는데 MCP 방식으로 연동하면 더 큰 장점이 있습니다.바로 MCP를 준수하는 세상의 모든 툴과 연계를 할 수 있다는건데요.$20으로 Claude 유료결제만 하면 연계기능을 제공하는 모든 툴들과 연계를 해서 사용할 수 있습니다.Google 의 드라이브 + 메일 + 일정은 연결버튼만 누르면 바로 연결이 됩니다.먼저 설정으로 다시 들어가서 일반 탭에서 Claude 설정 바로가기 버튼을 누릅니다.들어오면 이렇게 연결 버튼만 누르면 바로 컨텍스트로 제공할 수 있는 앱들이 있고, 계속 추가될 전망입니다.여기까지 Cluade 와 다른 툴들을 연계하는 방법이었구요!매번 AI 기술의 발달이 놀랍게만 느껴집니다.

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 발표 내용14년 된 네이버 캘린더 안드로이드/iOS 네이티브 앱에 코틀린 멀티플랫폼(KMP), 컴포즈 멀티플랫폼(Compose-Multiplatform) 모듈을 적용하며 얻은 경험을 공유강의 대상멀티플랫폼(KMP), 컴포즈 멀티플랫폼(Compose-Multiplatform)에 관심 있는 개발자크로스 플랫폼에 관심 있는 개발자목차KMP, Compose-Multiplatform 소개 KMP, Compose-Multiplatform 모듈 도입 배경 모듈 연동 방법 공통 플랫폼 설정 Android 개발 iOS 개발 NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY 2025(5월)의 일부 세션을 공개합니다.

안녕하세요, 저는 Comm Client 팀 이준영입니다. 저희 팀은 에이닷 앱 전화, 에이닷 전화(구. T전화) iOS 클라이언트 개발을 담당하고 있습니다.iOS 앱을 개발하다 보면, 다양한 리소스 파일들을 다루게 됩니다. 이 중에서도 버튼, 아이콘처럼 여러 해상도와 테마에 대응해야 하는 이미지 리소스 관리는 매우 번거롭습니다.그래서 오늘은 저희 팀이 이미지 리소스를 어떻게 관리하고 있는지에 대한 이야기를 공유해 드리려 합니다.Xcode가 이미지 리소스를 다루는 법Xcode는 라는 Asset Catalog를 통해 각종 리소스를 관리합니다.이 구조 덕분에 해상도(2배율, 3배율 대응)나 테마 모드(Dark, Light)등에 따라 여러 종류의 이미지를 제공하더라도, 코드에서는 아래와 같이 이름 하나만으로 이미지를 참조할 수 있습니다.만약 여러분이 , 라는 이미지를 Xcode에 으로 추가하면 내부적으로는 아래와 같은 폴더 구조가 생성됩니다.여기서 폴더는 하나의 "논리적 이미지" 단위를 나타내며, 실제 사용될 이미지 파일들과 파일로 구성됩니다.각 폴더 안에는 이라는 파일이 항상 존재합니다.이 파일은 해당 이미지 세트에 어떤 이미지 파일이 들어 있는지, 어떤 해상도와 테마에 대응하는지를 정의하는 메타 데이터를 담고 있습니다.쉽게 말해, Xcode가 어떤 상황에서 어떤 이미지를 선택해야 하는지를 알려주는 역할을 합니다.위 의 예시를 보여드리겠습니다.이 구조를 구성하는 주요 요소들을 하나씩 살펴보면 다음과 같습니다.• None : 실제로 연결될 이미지 파일들의 집합입니다. 각 항목은 하나의 PNG 파일에 해당합니다.• None• None 해당 이미지가 몇 배 해상도용인지 나타냅니다. (예: 1x, 2x, 3x)• None• None 어떤 플랫폼에서 사용할 수 있는지를 나타내며, 보통은 입니다.• None• None 해당 이미지가 어느 테마 모드에서 사용될지를 나타냅니다.• None 예를 들어, 다크모드일 경우 처럼 명시됩니다.• None : 이 파일 자체의 메타데이터입니다.• None• None 보통 로 고정됩니다.• None• None 현재 버전은 이며, Xcode 버전에 따라 내부 사용될 수 있는 값입니다.결과적으로 위 예시는 라이트 모드에서는 , 다크 모드에서는 를 자동으로 적용하도록 설정한 구조입니다.이처럼 에는, 각 이미지가 어떤 조건에서 어떻게 사용할지 정의되어 있다는 것을 알 수 있습니다.실제 프로젝트에서의 문제점에이닷 내 전화의 경우, 아래와 같이 이미지 리소스를 구성하고 있습니다.보시다시피, 하나의 이미지 리소스가 총 4개의 이미지 파일로 구성되어 있습니다.따라서 하나의 이미지 리소스를 변경하려면, 4개의 PNG 파일을 바꿔줘야 합니다.25개의 리소스만 변경하려고 해도, 실제로는 100개의 이미지 파일을 교체해야 하는 것이죠.이걸 사람이 하나하나 확인해 가면서 직접 옮기는 것은 너무 힘든 일입니다.그래서 저희 팀은, 이미지 리소스 관리 자동화를 도입했습니다.위에서 보셨듯이, 저희는 이미지 리소스를 일정한 규칙에 따라 관리하고 있습니다.모든 파일 이름은 해상도와 테마 모드를 기준으로 이름 짓고 있으며, 아래와 같은 규칙을 따르고 있습니다.따라서, 위 규칙만 따른다면 아래와 같이 정보를 추출할 수 있습니다.• None• None 이미지의 논리적인 이름그래서 다음과 같이 자동화 목표를 잡았습니다.• None 파일명에서 이미지 정보 추출• None 같은 을 가진 이미지 파일들을 그룹화이제 단계별로 실제 스크립트를 작성해 보겠습니다.1. 파일명에서 이미지 정보 추출하기제일 먼저, 이미지 파일 이름으로부터 이미지 정보를 알아내야 합니다.예를 들어 라는 파일명이 주어지면 다음과 같은 정보를 알아낼 수 있습니다.이 정보를 추출하는 코드는 아래와과 같습니다.2. 같은 base_name을 가진 PNG 파일 그룹화이제 함수를 통해 각 파일의 정보를 얻을 수 있게 되었으니, 본격적으로 같은 리소스 이름( )을 가진 이미지 파일들을 그룹으로 묶는 작업을 해보겠습니다.여기에서 목적은 같은 을 가진 PNG 파일들(ex. , ) 같은 파일들을 하나의 으로 묶기 위한 준비 작업입니다.아래는 디렉터리 전체를 재귀적으로 순회하면서 PNG 파일들을 그룹화하는 함수입니다.이제 이 그룹을 기반으로 .imageset 폴더를 만들고, 각각의 이미지 파일을 복사한 뒤, 그에 맞는 Contents.json 파일을 생성하는 단계만 남았습니다.앞서 설명해 드렸듯이, Xcode는 .imageset 폴더 내부에 있는 Contents.json 파일을 기준으로 어떤 이미지를 어떤 상황에서 사용할지 판단합니다.이 파일에는 이미지의 해상도( ), 테마 모드( ), 파일 이름( ) 등의 메타 정보가 담깁니다.예를 들어, 파일에 대한 항목은 다음과 같이 구성되어야 합니다.이 내용을 생성하는 코드는 아래와 같습니다.이제 PNG 파일을 분석해서 이미지 이름( )을 기준으로 묶었고, 각 파일에 대해 메타 정보도 생성할 수 있습니다.이제 남은 작업은, 각 그룹을 폴더로 변환하고, 해당 폴더에 이미지 파일을 복사한 뒤, 그에 맞는 파일을 생성하는 것입니다.이걸 코드로 작성하면 아래와 같습니다.이 함수를 실행하면, 아래에 Xcode에서 바로 사용할 수 있는 폴더 구조로 자동으로 생성됩니다.수많은 PNG 리소스를 개발자가 손댈 필요 없이 에 바로 집어넣을 수 있는 상태로 만드는 것입니다.자, 이제 png 파일들을 변환하는 데 필요한 코드는 모두 작성했습니다.이제 실제로 자동화 스크립트를 실행해 보겠습니다.안의 PNG 파일들을 전부 순회하면서 이미지 이름( )을 기준으로 그룹화하고,에는 Xcode가 바로 사용할 수 있는 구조가 자동으로 생성됩니다.이제 이 결과물을 Xcode 프로젝트의 디렉터리에 그대로 복사해 넣으면, 아래와 같이 이미지가 자동으로 적용됩니다.이 스크립트를 도입한 이후, 이미지 리소스를 관리하는 방식이 완전히 달라졌습니다.기존에는 디자이너로부터 수십, 때로는 수백 개에 달하는 PNG 파일을 받을 때마다 일일이 파일을 Drag&Drop해야 했습니다. 그 과정에서 실수도 종종 발생했고요.하지만 이제는 몇 초 만에 모든 리소스를 자

정답 없는 AI 시대, 당근이 새로운 경험을 만드는 방식   당근 AI Show & Tell #6당근은 매주 AI Show & Tell 을 통해 각 팀의 AI 실험을 전사적으로 공유하며, 새로운 시대의 문제 해결 방식을 빠르게 찾아가고 있어요. 당근이 AI로 만드는 생생한 도전의 순간들, 지금 만나보세요. ️ 이 콘텐츠는 생성형 AI를 활용해 제작한 콘텐츠입니다.해당 이미지는 OpenAI의 이미지 생성 모델 DALL·E를 활용하여 GPT-4o에서 생성한 이미지입니다.AI 기술은 믿기 어려울 만큼 빠르게 진화하고 있고, 사용자 반응은 그만큼 예측하기 어려워졌어요. 어떤 기능이 구현 가능할지, 또 실제로 어떻게 받아들여질지는 점점 더 알기 어려운 시대죠. 그래서 중고거래실은 빠르게 실험하고 사용자 반응에 맞춰 다시 설계하는 방식을 택했어요. 그렇게 만들어진 새로운 기능은 반복적인 개선을 거치며, 사용자에게 자연스러운 경험 으로 자리 잡고 있어요. 지금 소개할 두 프로젝트는 모두 예측할 수 없는 반응 속에서 사용자 경험 중심으로 발전해 온 사례들이에요. 그 안에 담긴 고민과 설계 과정을 함께 살펴보시죠.Project 1. 물품이 보낸 편지   내가 판 물건이 편지를 써준다면?첫 번째 실험. 사용자의 호기심을 끌어내다중고거래실은 거래 경험을 개선해 이웃 간의 연결을 자연스럽게 늘릴 방법을 늘 고민하고 있어요. 최근엔 생성형 AI의 가능성을 빠르게 탐색하던 중, 중고거래실 PM인 Suzy는 이런 상상을 하게 됐죠. 내가 거래한 물건이 나에게 편지를 써준다면? 방금 판 물건이 그동안 감사했다는 인사를 전하며 후기를 써달라고 요청한다면, 사용자의 호기심과 감성을 자극해 자연스럽게 거래 후기 작성으로 이어지지 않을까 기대했어요.중고거래실은 빠르게 실행에 들어갔어요. 우선 LLM이 편지 스타일 응답을 생성하게끔 프롬프트를 설계했죠. 물품이 사용자 닉네임을 부르며 인사를 건네고, 함께 해서 행복했다 와 같은 여운 있는 문장을 일관되게 포함하도록 프롬프트를 다듬었어요. 동시에 Stark, Bada, Philip은 Claude와 Cursor를 활용해 편지가 담길 화면의 목업을 만들었어요. 그렇게 일사천리로 편지를 자동 생성하는 시스템을 구현해 냈고, 곧바로 A/B 테스트에 돌입했어요.실험군에 속한 사용자들은 거래 후기를 남겨주세요 라는 익숙한 알림 대신, 물품이 편지를 보냈어요! 라는 새로운 메시지를 받았어요. 알림을 클릭하면 웹뷰 페이지로 이동해, LLM이 생성한 거래한 물품의 작별 인사를 확인할 수 있죠. 편지 마지막 부분엔 저 대신 새로운 주인에게도 고마운 마음을 전해주실 수 있을까요? 같은 문구로 자연스럽게 후기를 작성하도록 유도했어요.테스트 결과 알림 오픈율은 기존 대비 두 배 이상 상승했지만, 정작 후기 작성률은 유의미한 변화가 없었어요. 알림을 클릭한 사용자의 다수는 후기 작성 경험이 없는 신규 사용자였죠. 평소 후기를 작성하지 않는 사용자들의 호기심은 유발했지만, 행동 전환까지는 이어지지 않았던 거예요. 기대한 성과에 도달하지 못했지만, 중고거래실은 여기서 멈추지 않았어요. 콘텐츠가 사용자의 관심을 끌어냈다는 점에 주목하고 곧바로 다음 실험을 이어갔습니다.두 번째 실험. 사용자의 관심을 행동으로중고거래실은 앞선 실패에서 중요한 인사이트를 도출했어요. 사용자가 특정 행동을 왜 해야 하는지 명확한 동기를 제공하지 못하면, 콘텐츠가 아무리 새롭고 흥미로워도 사용자 반응은 호기심에서 그칠 수 있다는 점이에요. 중고거래실은 후기까지 작성해야 할 이유를 어떻게 만들어낼지 고민한 끝에, 간단하지만 명확한 보상 구조를 설계했어요. 후기를 작성해야만 구체적인 편지 내용을 볼 수 있도록 한 거예요. 편지를 열어보고 싶다는 호기심 그 자체를 행동의 동기로 활용해 보기로 한 거죠.2차 실험을 빠르게 이어가기 위해 수정은 최소화했어요. 기존 알림 문구는 그대로 유지하되, 알림을 클릭하면 블러 처리된 편지지 위로 후기를 먼저 작성하라는 화면이 나타나도록 했죠. 기능 구조는 최대한 기존 상태를 그대로 유지하고, 사용자의 행동 순서와 조건만 변경한 셈이죠결과는 놀라웠어요. 알림 오픈율은 여전히 기존의 2배 이상을 유지하면서, 후기 작성률은 기대 이상으로 증가했어요. 게다가 SNS와 커뮤니티에서 가서 행복하게 잘 살아야 해 , 뭉클하고 귀여웠어요 같은 사용자 반응이 이어졌어요. 후기 작성 수를 높였을 뿐만 아니라, 사용자에게 따뜻한 경험을 선사했다는 점에서도 의미가 있었죠. 이후 이 기능은 국내뿐 아니라 북미와 일본 시장에도 정식으로 배포됐어요. 물품이 보낸 편지 는 실패 속에서도 유의미한 반응을 발견하고 개선한 덕분에 탄생할 수 있었어요.Project 2. AI 물품 추천   어떤 물건을 사야 할지 추천해 드려요!이어서 중고거래실은 AI를 활용해 새로운 탐색 경험을 만들어보기로 했어요. 당근은 ML 기반으로 사용자가 좋아할 만한 물건을 피드에 보여주고 있는데요. 비슷한 추천이 반복되면 새롭고 다양한 물건을 발견할 기회는 줄어든다는 한계가 있었어요. 중고거래실은 이 문제를 해결할 방법을 고민하다가, GPT 등장 이후 사람들이 AI에게 자연스럽게 질문하는 방식에 익숙해지고 있다는 점에 주목했어요. 구체적인 목적 없이도 AI와 대화하듯 새로운 물건을 탐색하는 기능을 만들어 보기로 한 거죠.이 기능은 LLM과 임베딩 기술을 조합해 구현했어요. 예를 들어 내일 장모님 생신 선물 뭐가 좋을까? 라고 입력하면, LLM이 문장을 분석해 감성 있는 티 세트 , 관절에 좋은 건강용품 , 소형 마사지기 같은 주제를 생성해요. 이 결과를 벡터화한 뒤, 중고거래 게시글의 텍스트 임베딩과 비교해 유사도가 높은 게시글을 추천하죠. 사용자가 어떤 질문을 입력해야 할지 막막해 하지 않도록, 초보 엄마아빠인데 육아 꿀템 뭐부터 준비해야 해? 와 같은 유즈 케이스들도 입력창 하단에 함께 제공했어요.물론 구현 과정이 순탄치만은 않았어요. 초기에 영어 전용 임베딩을 사용했을 땐 정확도가 낮아 어려움을 겪었지만, 이후 다국어 모델로 전환하면서 추천 품질을 개선할 수 있었어요. 또 민감한 표현이나 엉뚱한 질문에도 AI가 자연스럽게 반응하도록 다