AI 시대에, 나는 무엇을 상상하고, 어떻게 행동해야 하는가?AI 시대를 맞아, 스스로에게 다시 질문을 던지게 됩니다.“이 거대한 변화 앞에서 나는 무엇을 상상하고, 어떻게 행동해야 하는가?”2012년 마이리얼트립을 창업한 이후, 지난 13년간 여러 기술적 전환점을 마주해왔지만, 이번처럼 전면적이고 구조적인 전환은 처음입니다. 그 흐름 속에서 저는 창업자로서의 경험과 반성을 되짚어보고, 우리가 어떤 방향으로 나아가야 할지를 고민하게 되었습니다.모바일 시대의 후회: 상상력의 빈곤이 낳은 기회 손실정말 이런 앱에서 수백만원, 천만원 이상의 결제를 할까?마이리얼트립의 첫 앱은 창업 3년 뒤인 2015년에 출시됐습니다.그 전까지 저는 모바일이 수백만 원에 이르는 고관여 여행 상품을 구매하기엔 부적절하다고 판단했습니다. 작은 화면과 느린 반응 속도, 부족한 신뢰도 등 여러 이유로 우리는 PC 웹에 더 많은 자원을 투입했고, 실제 당시 데이터를 봐도 모바일에서의 구매는 10만 원 이하 소비에 집중되어 있었습니다.하지만 곧 상황은 급변했습니다. 우리는 모바일 중심의 변화에 뒤늦게 반응해야 했고, 그 경험은 제게 큰 교훈을 남겼습니다. 대표의 상상력이 부족하면 회사 전체가 중요한 흐름을 놓칠 수 있다는 것을, 뼈아프게 깨달았습니다. 그 이후부터 저는 다짐했습니다. 다음 변화가 온다면 가장 먼저 움직이고, 가장 넓게 상상하겠다. 그리고 지금, 그 ‘다음’이 눈앞에 와 있습니다. AI는 모바일보다 더 거대한 변화입니다.분업에서 통합으로: 조직 구조의 근본적인 전환AI의 본질은 기술이 아니라 구조의 변화에 있습니다.산업화 이후, 조직은 분업을 통해 복잡한 문제를 효율적으로 해결해왔습니다. 기획자는 기획을, 디자이너는 디자인을, 개발자는 개발을 담당하며 역할을 분리하는 것이 일반적이었습니다.그러나 기술이 비약적으로 발전할 때마다 이 구조는 도전을 받아왔습니다. 인터넷, PC, 모바일은 업무의 경계를 흐리게 했고, 이제 AI는 그 흐름을 근본적으로 가속화하고 있습니다. 실제로 많은 AI 기반 스타트업에서는 소수의 구성원이 다기능적으로 문제를 해결하는 구조가 빠르게 보편화되고 있습니다.분업이 무너질 때, 각 개인은 더 넓은 권한과 책임을 가지게 됩니다. 더 이상 팀 간의 조율에 의존하지 않고, 혼자서 문제를 정의하고 해결하는 구조가 만들어집니다. 이 흐름은 결국, 리더십의 ‘조율’ 기능이 축소되고, IC(Individual Contributor)의 시대를 여는 전환점이 될 것입니다.기능보다 문화가 먼저다: 리터러시가 변화의 시작점처음에는 AI 전담 조직을 만들어 특정 기능을 개발하고, 각 팀에서의뢰된 솔루션을 구현하는 방식으로 접근했습니다. 그러나 곧 병목이 발생했습니다. 요청 중심의 구조는 컨텍스트 이해에 많은 시간과 에너지를 소모했고, 팀 전체의 속도는 오히려 느려졌습니다.크몽과 비슷한 방식이라 생각해 ‘마리트크몽’ 이라는 귀여운 이름을 붙였습니다.그래서 우리는 전략을 바꾸었습니다. 특정 팀이 AI를 담당하기보다는, 모든 구성원이 AI를 이해하고 활용할 수

이번 포스팅은 현재 LLM Agent을 구현하기 위해서 가장 많이 쓰이는 Langchain과 Langgraph의함수의 차이점에 대해서 간략하게 알아봅니다.Agent는 보통은 특수한 영역 또는 기능에 특화된 일꾼 입니다.근데 여기에 이게 를 추가해서유저의 요청에 따라, 상황에 맞는 Tool를 사용해서 기존에 학습하지 못했던 기능을 가능케 합니다.이를위해서 ReAct(Reasoning and Action) Agent를 사용하게 됩니다.이때 기존 포스팅을 통해서, Scratch부터 Agent를 만들어 봤지만실제 Production에서는 Langchain이나 Langgraph를 사용하게 됩니다.Langchain에서는 함수를 통해서 Agent를 만들 수 있고prompt를 통해서 Agent가 어떤 Chain Of Thought 를 진행할지 기술하게 됩니다.그래서 사용자의 prompt작성 수준에 따라서 Agent의 Tools Call능력이나, Reasoning능력이 달라지게 됩니다.하지만 API문서에서 보면, 아래와 같은 문구를 확인할 수가 있습니다.Langchain Agent는 Production 용도에는 적합하지 않다는 내용이네요.Langchain의 경우 prompt를 이용해서 Agent가 Tool을 사용하게 유도합니다.이 덕분에 Tool Call이 학습되지 않은 모델에서도 Tool을 사용할 수 있다는 장점이 있습니다.Langgraph의 경우 동일한 이름의 함수를 제공합니다.대신 차이점을 보이는게Langgraph의 공식 문서에서는prompt입력에 대한 가이드 라던가, 복잡한 prompt를 입력하라고 안내해주지 않습니다.3. 둘이 뭔 차이에요?두 라이브러리의 실제 vLLM 또는 OpenAI로 보내지는 prompt를 확인하기 위해서 아래 코드를 사용합니다.이제 코드를 실행시키고, 디버깅 로그를 확인해봅니다.requests를 보내기 전에 이미 prompt부분이 Agent정의때 사용된 가 이미 포맷팅이 된 것을 확인할 수 있습니다.실제로 requests를 보내기 이전에 prompt 포맷팅이 진행되는 것음langchain의 create_react_agent 소스코드에서도 확인할 수가 있습니다.Langgraph는 prompt가 포맷팅 되지 않고 그대로 전달되게 됩니다.여기서 Langchain과의 큰 차이점은 requests의 parameter로 tools가 전달되게 됩니다.• None Langchain : Client Side에서 prompt를 처리함• None Langgraph : LLM Service Side에서 prompt를 처리함외부 환경에서 상용 서비스(ChatGPT, Gemini, Claude)를 이용할 경우langgraph로 tool call API를 이용할 수가 있습니다.그렇기 때문에 이런경우는 정상적으로 Tool을 사용하는 Agent를 구현할 수 있습니다.하지만 vLLM등을 이용하는 Private LLM환경에서는Tool Call이 허용되지 않는 모델이나, vLLM 설정에 따라 Tool Call이 불가능 할 수 있습니다.이런 경우에 Agent를 구현하기 위해서 Langchain을 사용한 Agent구현을 고려해 볼 수 있습니다.

AI 기술의 발전으로 누구나 쉽게 도구를 활용해 복잡한 문제를 해결할 수 있는 시대가 열렸습니다. 아이디어가 있다면 AI 도구로 개발을 바로 실행해 볼 수 있습니다.이번 글에서는 교육 분야의 개인 맞춤형 학습 앱(가칭 GRE Mind) 개발을 예시로 들어 AI 도구 활용의 잠재력에 대해 공유하고자 합니다.LLM을 활용한 기확과 클로드와 파일시스템 MCP를 활용한 기획안의 구현을 통해 초기 결과물을 신속하게 얻어 낼 수 있습니다.아이디어 기획과 LLM의 역할에빙하우스 망각곡선 이론을 기반으로 한 GRE 학습 앱 개발 사례를 통해 AI 도구의 잠재력을 탐구합니다.GRE Mind의 기획은 LLM(Large Language Model)을 활용해 시작해 볼 수 있습니다."GRE 공부", "망각곡선" 과 같은 키워드를 입력해 초기 아이디어를 제시하면 이를 바탕으로 상세 기획안을 도출해 줍니다.핵심적인 아이디어만 있다면 복잡하지 않은 프롬프트로도 효과성이 있다는 걸 확인해 볼 수 있습니다.LLM은 수험생의 주요 Pain Point(단어 암기, 복습 관리, 취약점 분석)를 분석해 앱의 핵심 컨셉—스마트 망각곡선 단어장 & 문제은행—을 제안했습니다.생각하고 있던 아이디어 대비 크게 나쁘지 않아 그대로 진행해 볼 수 있습니다.이 과정에서 LLM은 시장 조사, 사용자 니즈 분석, 기능 제안을 단 몇 분 만에 수행하며 기획 속도를 획기적으로 단축했습니다.GRE Mind의 코딩은 프롬프트 기반으로 진행하였습니다.코딩 구성에 직접적으로 영향을 주는 프롬프트는 첫 줄에 표현해서 전체 구성에 대한 요구사항을 전달할 수 있습니다.• None 핵심사항 : 코딩 언어 구성(html, js, css), 데이터 처리(sqlite, json), 모듈화(200라인 넘지 않도록 정의: 일반적인 LLM은 200라인을 넘으면 넘어서는 코드를 하지 못하고 반복적인 재 작성을 하는 빈번한 실수를 사전에 차단), 파일 시스템 MCP 활용, 로컬에 프로젝트 구조를 직접 만들어서 파일을 생성해 가면서 개발을 진행하도록 지시그 다음 줄에 기획안을 포함하여 기능별 요구사항(대시보드, 단어장, 퀴즈, 통계)을 명확히 제공해서 시행착오를 줄이고, 즉시 구현에 집중할 수 있도록 했습니다.이는 전통적인 개발 방식 대비 시간을 대폭 단축시켜 줄 뿐만 아니라 자동화 수준을 높일 수 있었습니다.AI 도구(Claude)는 MCP(Model Context Protocol) 파일 시스템을 활용해 프로젝트 구조를 자동 생성했습니다.GRE Mind의 경우, index.html, css/main.css, js/dashboard.js 등 필수 파일을 체계적으로 구성하고, LLM이 각 파일의 초기 코드를 생성했습니다.이를 통해 로컬 환경에서 프로젝트 초기 설정이 단 몇 분 만에 완료되었으며, 개발자 입장에서는 즉시 코딩 결과를 검토하고, 의사결정을 진행하는 단계로 바로 돌입할 수 있었습니다.GRE Mind의 index.html은 대시보드, 단어 학습, 복습 퀴즈, 통계 페이지를 포함한 완전한 웹앱 구조를 제공합니다.AI는 HTML과 JavaScript 코드를 생성하며, 망각곡선 알고리즘을 적용한 복습 시스템과 UI를 구현했습니다.테스트 단계에서는 AI가 생성한 더미 데이터를 활용해 단어 퀴즈, 학습 진행률 표시, 통계 시각화를 검증했습니다.예를 들어, 대시보드의 "오늘의 학습" 카드는 새로운 단어, 스마트 복습, 취약점 극복을 표시하며, 사용자가 클릭 시 즉시 학습 또는 퀴즈로 전환됩니다.몇 분 만에 동작하는 웹앱GRE Mind는 AI 도구를 활용해 단 몇 분 만에 동작 가능한 프로토타입으로 완성되었습니다.index.html은 네비게이션, 대시보드, 단어 학습, 퀴즈, 통계 페이지를 포함하며, 각 페이지 간 전환은 js/navigation.js로 부드럽게 처리됩니다.개발자는 입장에서는 AI가 생성한 코드를 검토하고, UI 스타일(css/main.css)이나 학습 데이터와 같은 세부 사항만 보정하면 완성도 높은 앱을 얻을 수 있었습니다.LLM은 GRE Mind에 필요한 GRE 단어(초기: 5개 단어), 예문, 퀴즈 데이터를 생성해 앱에 통합했습니다.예를 들어, 단어 "abate"에 대해 뜻, 어원, 예문, 동의어/반의어를 생성하고, 이를 플래시카드와 퀴즈 형식으로 제공했습니다.또한, 사용자의 학습 데이터를 기반으로 망각곡선에 따라 복습 주기를 계산하는 JavaScript 로직(js/forgetting-curve.js)도 AI가 제안해 빠르게 구현했습니다.추가로 100개의 데이터를 더 생성해 달라고 다음과 같이 손쉽게 LLM에게 요구할 수 있습니다.생성된 데이터를 코드에 통합하면 100개의 데이터를 기반으로 학습할 수 있는 앱으로 확장을 할 수 있게 되었습니다.앱 완성 후, 사용자의 피드백을 반영해 추가 기능을 구현할 수 있습니다. 예를 들어, "나만의 단어장" 기능을 추가해 사용자가 "학습중" 또는 "마스터"로 단어를 분류할 수 있도록 할 수 있습니다.지금 부터는 다양한 새로운 아이디어와 함께 요구사항을 분석하고, 의사결정에 집중해서 지속적인 개선과 혁신을 통해 완성도를 높여 갈 수 있습니다.결론: AI 시대의 새로운 개발 패러다임GRE Mind 개발 사례는 AI 도구가 아이디어 기획, 코드 생성, 데이터 통합, 테스트까지 전 과정을 가속화할 수 있음을 보여줍니다.LLM과 MCP 파일 시스템을 활용하면 몇 분만에 동작하는 앱을 만들고, 사용자의 요구에 맞춰 지속적으로 개선할 수 있습니다.AI 시대의 개발 자체는 더 이상 전문가만의 영역이 아닙니다. 누구나 아이디어를 빠르게 현실로 구현할 수 있는 이 패러다임은 다양한 분야에서 혁신을 가속화할 것입니다.앞으로 개발자 또는 엔지니어의 역할은 무엇일까요?어쩔 수 없이 진행해야 했던 프로젝트 기본 구조를 생성하고, 다른 프로젝트이지만 동일한 모듈을 작성해야 했던 반복적인 구현 작업에서 벗어나거나 해방 시켜줘서 의사결정이 필요한 영역에서 역할을 더 할 수 있을 것으로 예상해 볼 수 있습니다.이번 글에서 소개시켜 드린 파일시스템MCP 활용의 강력함은 높은 코드 생산성을 체감할 수 있게 해 주었습니다.최근 우연히 본

은 시각 정보(Vision)와 언어(Language)를 결합한 멀티모달 모델로, 다량의 이미지-텍스트 데이터를 학습해 시각과 언어 정보를 동시에 처리할 수 있습니다. 이미지와 텍스트를 함께 입력받아, 둘 사이의 관계를 학습함으로써 이미지를 보고 설명하거나 질문에 답변할 수 있습니다.최근 거대 언어 모델(LLM)의 성공으로 텍스트 기반 AI가 빠르게 발전했지만, 현실의 문제는 단순한 텍스트 이해를 넘어 이미지, 음성, 영상 등 다양한 데이터를 동시에 해석해야 하는 경우가 많습니다.특히 문서 인식 (Document Understanding) 분야에서는 문서 내 복잡한 글자, 서식, 표, 그림 등을 이해하기 위해 멀티모달 AI에 대한 요구가 커지고 있습니다.이 리포트에서는 LLM에서 VLM 모델로의 전환 배경과 필요성을 시작으로, VLM의 개념 및 기술 트렌드, 서비스 적용 사례, 기술적 확장 방법, 그리고 개발 과정에서 마주하는 한계와 향후 방향까지 살펴보겠습니다.LLM에서 멀티모달 모델로의 전환 : 배경과 필요성LLM은 방대한 텍스트 말뭉치를 학습해 사람 수준의 언어 이해와 생성 능력을 보여주었지만, 이미지나 영상 등 비언어적 정보는 처리하지 못하는 한계가 있습니다.사람이 문서를 읽을 때 레이아웃이나 그림을 함께 살펴보며 텍스트를 해석하듯, AI도 텍스트 외의 시각 정보를 함께 이해할 수 있어야 합니다. 하지만 이러한 요구는 텍스트 기반의 LLM만으로는 충족하기 어렵습니다. 이에 따라 언어 모델에 ‘눈’과 ‘귀’를 달아주는 멀티모달 확장이 주목받고 있습니다.AI 연구계는 “언어만으로는 충분하지 않다(Language Is Not All You Need)”는 관점에서, 다양한 지각 능력을 언어 모델에 결합해야 진정한 지능에 가까워질 수 있다고 보고 있습니다.멀티모달 모델은 단일 정보에 의존하는 기존 모델보다 더 정밀한 예측과 풍부한 이해를 제공합니다. 이러한 이유로, 문서 AI 분야에서도 멀티모달로의 전환은 더 이상 선택이 아니라 필수로 자리 잡아가고 있습니다.VLM은 “이미지를 이해하고 말하거나, 반대로 말로부터 이미지를 다루는” 핵심 역량을 갖춘 멀티모달 모델로, 활용 범위가 매우 넓습니다.특히 기존에 여러 가지 특화된 일을 하던 모델들을 개별적으로 사용하는 것이 아니라, 하나의 큰 모델로 여러 업무를 통합 처리할 수 있는 점이 강점입니다. VLM의 대표적인 활용 분야는 다음과 같습니다.이외에도 VLM의 활용 분야는 매우 다양하며, 이미지와 텍스트를 다루는 많은 일을 할 수 있습니다.최신 VLM 모델은 OCR 기능도 수행할 수 있으며, OpenAI GPT-4 계열 모델과 Anthropic Claude 등 대규모 멀티모달 모델은 OCR 분야에서도 높은 수준의 정확도를 보여주고 있습니다. 최근의 VLM은 비교적 복잡한 자연 이미지 속의 텍스트까지도 인식할 수 있으며, 전통적인 OCR 모델을 능가하는 성능을 보이기도 합니다.그러나 추론 속도 측면에서는 한계가 있습니다. 대규모 모델은 API 통신 및 거대한 파라미터로 인해 지연이 길어지고, 오픈소스 기반의 VLM 모델도 일반적인 OCR 모델과 비교하면 매우 큰 편이라 연산량이 많습니다.다음 표는 VLM으로 이미지 처리 작업 시 장단점입니다.VLM은 대규모 데이터셋에 대해 사전학습되었기 때문에 사전학습 데이터에 포함된 도메인에 대해서는 소량의 데이터셋으로 fine-tuning 하여 성능을 낼 수 있지만, 사전학습이 힘든 특수한 분야에 대해서는 일반적인 vision 모델과 비교하면 성능이 낮고, 추가 학습에 필요한 공수도 많이 듭니다.최근 거대 멀티모달 모델들이 잇따라 출시되며 기술 경쟁이 가속화되고 있습니다.OpenAI의 GPT-4 with Vision(GPT-4V) 출시를 시작으로, Google DeepMind의 Gemini, Anthropic의 Claude 3, Meta의 Llama 2 기반 멀티모달 모델, Microsoft의 Kosmos 시리즈 등 각 기관이 앞다투어 VLM을 선보이고 있습니다.최신 VLM들의 기술 아키텍처를 비교해 보면, 대체로 ‘Vision Encoder + Language Model‘ 구조를 따르면서도 정보 결합(Fusion) 방식에서 차이가 있습니다.일부 모델은 크로스 어텐션 계층을 통해 이미지 특징을 언어 모델에 주입하는 방식을 택합니다. DeepMind의 Flamingo가 대표적으로 CLIP 비전 인코더와 거대한 LLM 사이에 게이트형 크로스 어텐션 층을 두어 두 모달리티를 연결합니다.반면 GPT-4V나 Gemini처럼 통합 아키텍처를 가진 경우, 학습 과정에서 처음부터 멀티모달 입력에 대응하도록 Transformer 내부에 시각-언어 토큰을 함께 처리합니다. 또한 resampler 모듈 등을 사용해 가변 길이의 이미지 특징을 고정 길이 토큰으로 변환하여 언어 모델에 결합하는 기법도 제안되었습니다.요약하면, 어떻게 두 모달리티를 융합하여 추론에 활용할 것인가가 VLM 아키텍처 설계의 핵심이며, 모델마다 혁신적인 방법들이 시도되고 있습니다.Fine-tuning 전략도 주요 기술 동향 중 하나입니다. 대규모 이미지-텍스트 데이터로 사전학습(pre-training)을 한 후, 특정 작업에 적합하도록 Instruction 튜닝이나 LoRA 기반 미세조정을 적용하는 사례가 늘고 있습니다.예를 들어 LLaVA는 GPT-4로 생성한 Q&A 데이터를 활용한 시각적 Instruction 튜닝으로 성능을 끌어올렸고, Meta는 Llama 2를 기반으로 한 다양한 멀티모달 실험(음성 결합, 이미지 캡션 등)에 LoRA 기법을 활용하고 있습니다.또한 지식 증류(Knowledge Distillation)를 통해 거대 모델의 능력을 경량 모델에 전이하여 실용성을 높이려는 연구도 진행 중입니다.이처럼 성능 개선을 위한 다양한 시도가 이어지고 있지만, 현재 VLM의 한계점도 분명합니다.멀티모달 모델은 거대 언어 모델에 비전 인코더까지 합쳐지면서 메모리와 계산량이 기하급수적으로 늘어나 배포 비용이 매우 비쌉니다.예를 들어 해상도가 매우 높거나 텍스트가 빽빽한 문서 이미지의 경우 인식 오류가 생길 수 있습니다. 또 환각(hall

안녕하세요! 강남언니에서 퍼포먼스 마케팅을 담당하고 있는 제임스입니다.iOS ATT 정책 도입 이후, 많은 마케터분들이 iOS 캠페인의 성과 측정에 어려움을 겪고 계실 거라 생각합니다. iOS 사용자에 대한 정확한 성과 측정과 타겟팅이 제한되면서, 저 역시 예산을 가장 많이 투입 했던 iOS 캠페인이 하루아침에 ‘성과가 가장 안 좋은 캠페인’으로 전락해 큰 상실감을 느꼈던 기억이 있네요.퍼포먼스 마케터의 역할은 예산을 효율적으로 사용하여 최적의 성과를 내는 것인데, 정확한 지표 없이 iOS 캠페인 예산을 유지하는 것은 쉽지 않은 일이었어요. 그 결과, iOS 예산을 줄이거나 오가닉 지표를 참고해 조정하는 등 여러 가지 대응을 했던 기억이 납니다. 또한 ATT 동의율을 높이기 위한 다양한 테스트도 진행했었어요. ✅ ATT로 하루아침에 성과가 달라졌다고 예산을 줄이는건 당연히 합리적인 판단이 아니고✅ 오가닉 지표만으로 캠페인 성과를 측정하는 것은 한계가 있으며✅ ATT 동의율을 높이는 노력은 효과가 크지 않았습니다. 많은 퍼포먼스 마케터분들이 저와 같은 고민을 하고 계실 거라 생각합니다. 데이터 측정을 최대한 정확하게 하는 것. 이것이 가장 중요한 첫 번째 단계라고 생각합니다. 퍼포먼스 마케팅의 핵심은 비즈니스 목표에 맞춰 외부 유저를 효율적으로 유입시키는 것이므로, 성과를 정확히 분석하고 판단하는 일은 가장 기본적이면서 중요한 과제입니다.특히, 강남언니와 같이 20~30대 여성 유저가 주요 타겟인 플랫폼에서는 iOS 유저가 상당한 비율을 차지하기 때문에 더욱 신경을 써야 하는 부분입니다. 강남언니에서는 iOS 캠페인의 성과를 어떻게 측정하고 있을까?다들 아시다시피, iOS 환경에서는 SKAN(SKAdNetwork)을 활용하는 것이 필수적입니다. 강남언니도 SKAN 데이터를 활용해 iOS 캠페인을 분석하고 있지만, SKAN만으로 모든 문제가 해결되지는 않습니다.SKAN을 사용하는 데에는 명확한 한계가 존재하기 때문에, 강남언니는 이 한계를 보완하여 최대한 정확하게 데이터를 분석하고 있습니다. SKAN 한계를 극복하는 보정 및 최적화 전략을 강남언니에서는 어떻게 하고 있는지 소개해 드릴게요. SKAN의 한계를 아래 관점으로 분석 후 보정 했어요.✅ 짧은 어트리뷰션 윈도우는 채널 별 기여 패턴 분석을 통한 보정✅ 데이터 집계 지연은 채널 별 데이터 집계 지연을 파악하여 보정✅ 광고 소재 단위의 성과는 다양한 소스 데이터를 활용한 입체적인 분석을 통해 보정 ✅ SKAN 3.0은 앱 설치 완료 후 24시간 이내의 Conversion Value 업데이트를 기준으로 포스트백이 전송됩니다.✅ 그 결과, 구매 주기가 긴 앱은 전환이 포착되지 않아 성과가 저평가될 수 있어요. 각 채널별로 인스톨 이후 이벤트(가입, 구매 등)가 언제 기여되는지를 분석하여 성과를 보정하는 방식입니다. 설치 이후 3일 차에 구매가 채널에 기여 되는지, 혹은 7일 차에 기여 되는지를 파악하는 것이죠.우리 서비스의 평균 구매 전환 주기가 7일이라고 가정해봅시다. 이 경우 SKAN

wade.hong AI 시대, ‘밥그릇’ 걱정 대신 직접 뛰어들어 채용 AI도구를 만든것이 인상 깊었습니다. 또한 아키텍처 설계와 어려웠던점도 같이 공유되어서 좋은 가이드가 되었습니다.river.pool 채용이라는 익숙한 주제를 AI 도구로 풀어가는 여정이 인상 깊고 재미있게 다가왔습니다. 막연하게 느껴졌던 AI 기술의 실제 활용 방식을 엿볼 수 있어 많은 참고가 되었습니다.안녕하세요, 저희는 인프라플랫폼실의 잔, SE팀의 이곤, 빌리, 퐁, API플랫폼팀의 이안입니다. 하얗게 불태운 2025년 카카오페이 X AWS 해커톤(이하 카페톤) 참여 경험을 소개하고자 합니다.지난 카페톤은 평소에 했던 채용 관련 고민을 AI로 풀어낼 수 있는 좋은 기회였습니다. AI 완전 초보자들이 모여 채용 AI 도우미 AIVA를 개발하며 무려 4위라는 유의미한 결과를 낳기까지 정말 쉽지 않은 과정이었는데요. 수상까지 해서 감사하지만, 무엇보다 해커톤을 진행하면서 AI 시대에 개발자는 어떤 자세로 접근해야 할지 고민해 볼 수 있어 더욱 뜻깊었습니다.그럼 지금부터 해커톤에 참가한 계기, 왜 하필 채용을 주제로 했는지, 아키텍처까지 차근차근 말씀드리겠습니다.요즘의 AI는 빠르게 우리에게 다가오고 있습니다. 과거 특정 시기에 기술적으로 광풍은 불었지만 유의미한 형태로 현실 세계에 나오지 못했던 기술들과는 사뭇 다릅니다. 개발자로서 하루가 다르게 새로운 뉴스가 나오는 AI기술을 바라볼 때마다 한편으로는 신기하고 편리하면서도 이 기술이 내 밥그릇을 뺏는 것은 아닐까라는 걱정을 가지고 바라보고 있었습니다.그러던 중 카페톤 공지가 발표되자마자 “그래 이 기술이 내 밥그릇을 뺏어갈지, 아니면 이번 기회에 나도 올라탈 수 있는지 확인하자”라는 생각으로 참가하게 되었습니다.( 물론 우승상품이 마음을 먹는 데에 큰 도움을 주었습니다 )왜 채용을 주제로 했는가?여느 기업들이 다 그렇겠지만, 카카오페이에서는 채용을 정말 중요하게 여겨 아주 많은 인원들이 긴 시간을 들여 채용 프로세스를 진행합니다. 하지만 매일 본래 자신의 업무를 하면서 지원자분들의 수많은 이력서를 하나하나 자세히 보는 것은 물리적으로 쉽지는 않습니다. 또한 객관성을 위해 타 팀의 채용 프로세스에 참여하게 되기도 하는데요, 이때에는 해당 팀의 업무도 파악하고 기술에 대해서 조사가 필요하기도 합니다.심지어 상대적으로 간단한 이력서 평가와는 다르게 개발자 채용 시 기술과제 평가의 경우, 지원자의 역량과 채용을 진행하는 팀에서의 역량 요구 수준을 고려하여 다각도에서 분석이 이루어지고, 한 지원자의 과제를 평가하는 데만도 1시간 이상 걸리는 경우도 많습니다. 이 또한 여러 명이 개별적으로 평가해야 하므로, 많은 자원이 투입됩니다.이 과정에서 저희는 한 가지 고민을 떠올리게 되었습니다. ‘지원자들이 들인 노력에 비해, 과연 그 정성이 충분히 전달될까?’많은 지원자분들 역시 본업 혹은 준비 중인 상황 속에서 시간과 에너지를 들여 기술과제를 작성하셨을 텐데요, 평가자의 입장에서 체력적·시간적 한계 때문에 정성껏 작성된 과제를 그

비밀번호는 그간 수많은 보안 사고의 원인이 되어 왔습니다.전세계 데이터 유출사고의 약 80% 이상 취약한 패스워드로 인해 발생했다는 결과가 있을만큼이죠. 취약한 패스워드의 70%는 단 1초만에 해킹이 가능하다고도 해요.이런 문제로 비밀번호를 없애는 새로운 기술 패스키(Passkey)가 등장합니다.패스키는 비밀번호를 대체하는 새로운 기술로 사용자의 기기와 이용하는 서비스 양 쪽에 생성된 암호화 키 쌍으로 동작하는 차세대 인증 기술이에요.패스키의 등장과 그 역사를 논하자면 더 많은 설명이 필요하지만 이번 포스트는 Apple의 WWDC25 세션 중 가장 인상깊었던 “What’s New in Passkeys” 를 요약해 설명드리고자 해요.이 세션을 통해 Apple은 생태계 전반 (iOS, iPad OS, macOS, visionOS)에 걸쳐 회원가입 단계부터 패스키 관리 이전까지의 전체 흐름을 아우르는 한층 진화된 패스키 인증 프레임워크를 보여주었는데요,패스키 기술의 진화 발전은 궁극적으로 피싱(phishing)을 방지하는 보안 수준으로의 성숙도를 향해 가고 있다는 점과 실제 시장에서 의미있는 적용 결과들이 속속들이 발표되었습니다.특히 이번 세션에서는 서비스 기획자 및 개발자 관점에서 적용할 수 있는 사용자 시나리오 그리고 개선된 API를 통해 서비스 혁신에 효과적인 핵심 포인트를 총 5개의 Chapter로 구성하였어요.그럼 각 항목의 핵심 내용 위주로 살펴보도록 하겠습니다.가장 먼저 아이디와 패스워드 설정없이 패스키 기반의 회원가입이 가능해졌음을 알렸습니다.기존의 비밀번호 기반의 회원가입도 자동 완성 (Auto-fill) 그리고 강력한 비밀번호 제안 등의 기능 지원으로 사용자 경험이 개선되었지만, 여전히 모든 설정 화면을 거쳐 정보를 입력해야 합니다.또한, 비밀번호라는 피싱 요소 (phishable factor)가 존재해요.하지만 Account Creation API를 통해 회원가입부터 Credential Manager (iOS Keychain 등 암호 관리자)에서 이미 검증된 이메일과 회원정보(예. 이름)을 그대로 사용해패스키 기반의 회원가입(Sign-up with a passkey)을 적용하면 사용자 경험과 보안 수준 모두 향상할 수 있게 됩니다.사용자는 한 번의 클릭으로 회원가입이 가능하게 됩니다.서비스의 계정 정보(이메일, 이름 등)의 최신 변경 사항이 사용자의 Credential Manager에 자동으로 반영되어 정보 갱신을 위한 별도의 사용자 행위가 불필요해 집니다.이를 위해 개발자는 Account 정보 변경 시, Signal API를 호출하는 기능을 구현하면 됩니다.패스키 지원 이전의 서비스에서 비밀번호를 사용하고 있던 기존 사용자들에게 백그라운드에서 자동으로 패스키를 생성해 제공할 수 있습니다.사용자는 기존 방식의 로그인 이후 패스키 업그레이드 알림을 받게되고, 그 다음 인증시부터 별도의 등록절차 없이 패스키 로그인이 가능해집니다.이를 통해 사용자의 패스키 인증방식 전환과 사용자 경험의 개선이 보다 자연스럽게 이루어질 수 있습니다./credential-management 와 같은 REST 기반 Endpoint를 통해 서비스별 패스키를 Credential Manager에서 조회 · 폐기 · 업데이트 할 수 있게 했습니다.즉, Credential Manager 화면에서 서비스별 패스키를 직접 추가할 수 있는 경로를 제공하여 서비스 밖에서도 사용자 패스키 경험을 확대할 수 있습니다.크로스 플랫폼 사용자 편의성 향상을 위해 서로 다른 Credential Manager 또는 다른 기기로 더 안전하고 쉽게 이전할 수 있도록 지원합니다.사용자는 기존 관리자 혹은 기기에서 Face ID 등 인증 방식을 통해 권한을 검증하고 간편하게 패스키를 이전하여 연속적으로 관리할 수 있습니다.이제 패스키는 단순한 로그인 수단을 넘어, 계정 생성 > 상태 동기화 > 자동 전환(생성) > 마이그레이션까지 커버하는 통합 인증 기술을 의미하는 개념이 되었습니다.서비스 제공자는 기존 가입 및 로그인에서 작은 수정만으로도 보안을 강화하고 서비스의 진입의 허들을 대폭 낮추어 서비스 본질에 집중할 수 있습니다.• None 패스키: 인증 기술의 미래, 비밀번호 없는 세상으로의 발걸음

안녕하세요, 여기어때 iOS개발팀 두부입니다.여기어때 iOS 앱은 1년 전인 2024년 5월 Tuist 도입을 통한 모듈화를 진행했고, 현재는 Micro Feature Architecture 기반의 유연한 Feature 개발을 통해 빠르게 성장해 나가고 있습니다.최근에는 SwiftUI와 MVI Pattern을 결합한 UI 로직과 상태 관리가 명확히 분리되는 아키텍처를 채택하며 팀 내부 기술 스택은 한층 견고해졌습니다. 이 덕분에 공통 컴포넌트 재사용은 물론, 기능 개발 시 일관된 규칙 적용이 자연스럽게 뒤따르고 있죠.Photo by Jack Sloop on Unsplash여기어때 iOS 앱에서는 SwiftUI 화면을 개발할 때 아래 5가지 파일로 책임을 분리하고 있습니다.CoordinatorHostingViewControllerReducerView (View)ObservableReducerReducer이렇게 분리된 레이어 덕분에 명확하게 상태를 관리할 수 있지만, 매번 수작업으로 5개의 파일을 생성하고 기본 코드를 채우는 과정은 매우 번거롭습니다. 하지만 이러한 ‘Boilerplate Code’를 자동으로 생성할 수 있다면, 앞에서 언급한 기본 코드를 반복적으로 채우는 업무 패턴을 역으로 이용해 생산성을 높이는 구조를 만들 수 있지 않을까요?바로 이 지점에서 Tuist Scaffold와 Makefile을 활용한 자동화가 빛을 발합니다.Scaffold?Scaffold는 건설, 건축 등 산업현장에서 쓰이는 임시로 설치한 가시설물 등을 뜻하는데요. 프로그래밍에서의 Scaffolding은 기본 구조를 빠르게 생성하는 자동화된 코드 생성 기술을 의미합니다.소프트웨어를 개발하다 보면, 기존 아키텍처가 있는 프로젝트에서 개발자가 프로젝트와 일관성 있는 새로운 컴포넌트나 기능을 부트스트랩하고 싶을 때가 생깁니다. Tuist는 이러한 Scaffolding 기술을 Template으로 관리할 수 있게 제공하고 있습니다. Template은 Tuist에서 기본으로 제공해 주는 템플릿을 사용할 수도 있고, 직접 만들어 사용할 수도 있습니다.이번 글에서는 화면 개발 시 흔히 겪는 불편을 해소하기 위해, 생성된 모듈에 Boilerplate Code를 자동으로 생성하는 Tuist Template을 만드는 방법을 다뤄보겠습니다.Template을 톺아봅시다Template 생성먼저, Template을 생성하는 법에 대해서 알아보겠습니다.디렉터리 이름과 동일한 .swift파일을 생성합니다. (Manifest file)이때 주의할 점은, 파일 및 폴더명을 아래 형식에 맞게 설정해주어야 한다는 것 입니다....└─ Tuist └── Templates └── SwiftUIScreen ✅ └── SwiftUIScreen.swift ✅✅ Templates 하위 폴더 이름과 그 폴더 안에 있는 .swift 파일 이름이 동일해야 합니다.Template 정의Tuist Template의 핵심은 Manifest라 불리는 .swift 파일입니다. 이 파일에

안녕하세요, 여기어때컴퍼니(이하 여기어때) Android개발팀 테드입니다.YDS 컴포넌트 중 YDSImage의 Compose Preview가 렌더링되지 않는 문제를 발견했고, 이를 어떻게 개선했는지 공유드리고자 합니다.본격적인 내용에 들어가기 전에, YDS와 YDSImage가 무엇인지 간단히 짚고 넘어가겠습니다.※ YDS가 낯선 분들은 아래 설명을 읽어보시면 전체 내용을 이해하는데 도움이 됩니다.YDS(Yeogi Design System)?여기어때는 UI 일관성을 매우 중요하게 생각합니다. 그래서 사내 디자인 시스템인 YDS(Yeogi Design System)를 활용하여 텍스트, 색상, 여백, 컴포넌트 규격은 물론, 상태 처리 방식까지 체계적으로 정의하고 있습니다. 이를 바탕으로 Android개발팀과 iOS개발팀이 모두 동일한 기준으로 화면을 구성하고 있습니다. 제가 속한 Android개발팀 역시 YDS의 가이드라인을 기반으로 컴포넌트를 작성하고 있고, 실제 앱 화면에서도 이를 적극 활용하고 있습니다. 덕분에 화면 간 일관성을 자연스럽게 유지할 수 있고, 코드 재사용성이 높아 유지보수와 기능 확장이 쉬운 구조를 갖추고 있습니다.저는 아직 인턴으로 합류한 지 3개월밖에 되지 않았지만, YDS의 장점을 크게 체감하고 있습니다. 디자이너 분들께서 Figma 내에서 YDS에 정의된 규격을 기반으로 화면을 일관성 있게 설계해 주신 덕분에, 제가 디자인 의도를 파악하는 데 혼란이 없었습니다. 코드 역시 컴포넌트 단위로 잘 추상화되어 있어, UI 구현 과정이 매우 수월했습니다.그 결과 UI 구현 과정에서 드는 시간과 시행착오가 눈에 띄게 줄었고, 동일한 피쳐를 개발하는 iOS개발팀과의 싱크를 맞추기 위한 별도의 시간이나 비용이 거의 들지 않아서 개발 효율 면에서도 크게 만족하고 있습니다 :)YDSImage 컴포넌트?YDSImage는 YDS의 여러 컴포넌트에서 공통적으로 사용하는 네트워크 기반 이미지 렌더링 컴포넌트입니다.@Composablefun YDSImage( modifier: Modifier = Modifier, url: String?, customDefaultImage: @Composable (() -> Unit)? = null, ...) { var imageLoadState: State by remember { mutableStateOf(State.Empty) } val imageRequest = remember(url) { defaultImageRequest(context = LocalContext.current, data = url) } Box(modifier = modifier) { when (imageLoadState) { is State.Loading -> Skeleton() is State.Error -> customDefaultImage?.invoke() ?: DefaultImage() else ->

안녕하세요! 여기어때 BFF개발팀 미카엘입니다. 오늘은 여기어때에서 BFF가 어떤 역할을 하는지, 왜 필요한지, 그리고 실제로 어떻게 활용되고 있는지에 대해 이야기해보려고 해요. 기술적인 개념이지만 최대한 쉽게 풀어볼 테니 편하게 읽어주세요!BFF(Backend for Frontend)란?BFF(Backend for Frontend)는 각각의 프론트엔드(Web, iOS, Android 등)에 맞춰진 최적화된 백엔드 계층(Layer)을 의미해요. 말 그대로 “프론트엔드를 위한 백엔드”라는 뜻이죠.예를 들어, iOS와 Android 앱에서 같은 데이터를 받아야 하지만, 각 클라이언트의 특성이 다르다면 어떻게 해야 할까요? BFF 없이 백엔드에서 직접 데이터를 주면, 프론트엔드에서 불필요한 데이터를 걸러내거나 가공해야 해서 비효율적일 수 있어요. 반면, BFF가 있으면 클라이언트의 특성에 맞춰 데이터 가공을 한 후 전달하므로, 프론트엔드 개발이 훨씬 쉬워지고 성능도 최적화될 수 있는 것이죠.여기어때에서는 왜 BFF가 필요할까요?여기어때는 숙박뿐만 아니라 항공권, 레저 티켓, 여행 패키지 등 다양한 서비스를 운영하고 있어요. 게다가 이 서비스는 B2B 웹페이지, B2C 웹페이지, Android 및 iOS 앱 등 다양한 클라이언트를 통해 제공됩니다.모든 클라이언트가 같은 백엔드를 호출하면 어떻게 될까요?불필요한 데이터까지 모두 받아야 해서 네트워크 비용 증가하고, 프론트엔드에서 데이터를 변환해야 해서 처리 속도가 저하하고, 새로운 기능 추가할땐 각 클라이언트의 코드 변경 부담이 증가하겠죠.이런 문제를 해결하기 위해서는 BFF를 활용하면 됩니다!여기어때에서는 각 클라이언트별 맞춤형 API를 제공하는 BFF 구조를 통해서 성능을 최적화하고 있습니다.BFF가 여기어때에서 하는 일1. 클라이언트별 맞춤형 API 제공각 클라이언트(Web, Android, iOS)는 사용 방식과 요구사항이 다릅니다.모바일 앱(Android, iOS)은 네트워크 트래픽을 최소화하고 배터리 사용량을 절감하기 위해 가벼운 데이터를 요청해야 하고 B2B 웹페이지는 대량의 데이터를 조회하고 분석하는 기능이 필요하고 B2C 웹페이지는 사용자 경험을 극대화하기 위해 풍부한 데이터를 제공해야 할 수 있지요.BFF는 이러한 차이를 반영하여 각 클라이언트에 적합한 데이터 형태로 응답을 줍니다.덕분에 불필요한 데이터 전송을 줄이고, 최적화된 성능을 제공할 수 있죠.2. 성능 최적화여기어때의 서비스에서는 실시간 예약, 빠른 검색, 대량 데이터 조회가 아주 중요한 요소입니다.특히 모바일 환경에서는 네트워크 비용과 응답 시간이 중요한데, BFF를 통해 이를 최적화할 수 있습니다.네트워크 트래픽 감소: 모바일에서는 꼭 필요한 데이터만 전송하여 트래픽 비용을 줄일 수 있습니다.캐싱 활용: 자주 요청되는 데이터는 캐싱하여 백엔드 부하를 줄이고 응답 속도를 빠르게 만들어줍니다.데이터 가공: 프론트엔드에서 데이터를 가공할 필요 없이, BFF에서 필요한 형태로 변환하여 전송합니다.3. 보안 및 인증 처리B2