안녕하세요. 스튜디오 킹덤 클라이언트 개발자 이한나입니다. 이 글은 제가 신입으로 입사하여 3년 차인 지금까지 일하며 실수한 것들을 돌아보고 되새겨 보는 글입니다. 이 글이 저처럼 신입 또는 주니어 클라이언트 개발자분들께 작게나마 도움이 되기를 바라며 저의 경험을 나누고자 합니다.일하다 보면 종종 내가 이해한 것과 기획자가 의도하는 방향이 다른 경우가 생깁니다. 확신이 가지 않는 부분은 당연히 물어봐야 합니다. 설계를 하고 있을 때, 작업을 진행하고 있을 때, 작업을 완료 했을 때까지, 늦었다고 생각할 때가 가장 빠른 질문 타이밍입니다."10번 뽑기 기능"을 만드는 상황을 예시로 들어보겠습니다.여기서 질문을 하지 않는 개발자가 1번 뽑기를 10번 반복하는 것으로 이해하고 (음! 전부 이해했어!) 작업을 진행합니다.그리고 마감날이 되어 테스트를 돌려본 기획자가 물어봅니다.기획자 : 이거 뽑기 10번을 전부 보여주고 있네요? 뽑기는 1번만 보여주고 보상을 10개를 줘야 하는데 다르게 나오는 것 같아요. 확인 부탁드립니다.그동안의 시간과 노력을 지우고 다시 작업을 하는 상황이 되어버렸습니다. 눈물을 머금고 다시 작업을 하고 싶지 않다면 자신이 이해한 것 그리고 작업 방향이 기획자가 의도하는 방향과 맞는지 물어보고, 기록하고, 작업을 진행하도록 합시다.추가로 작업하면서 중간중간 결과물을 영상으로 찍거나 스크린샷으로 캡쳐해 공유합시다. 구현 방향을 공유하는 의미도 있고, 나중에 리팩터링하거나 기능이 추가될 때 원본 기능이 어땠는지 참고하기 좋아서 기록 차원에서라도 남겨두는 게 좋습니다. 그리고 귀여운 작업물을 만들었다면 자랑할 수 있다는 장점도 있습니다.다른 프로그래머의 코드를 수정할 때도 비슷합니다. 코드에는 의도와 맥락이 있습니다. 왜 이런 코드가 있는지 물어보고 의도에 맞는 방향으로 작업해 야 합니다. 그리고 수정 방향에 대해 얘기하다 보면 생각지 못한 더 좋은 코드가 떠오르거나 어딘가에 있는 동일한 코드를 가져다 쓸 수 있음을 알게 될 수 있어서, 어떤 코드에 대해 수정이 고민이 된다면 담당 프로그래머와 얘기해 보는 것이 좋습니다.데이터 수정은 기획자에게 요청하자"쿠키런: 킹덤"에서는 기획자가 퀘스트 내용이나 쿠키의 능력치 같은 게임 데이터를 작업합니다. 적은 양의 데이터 수정일지라도 어떤 데이터는 서로 연결되어 있어 규칙에 맞게 입력해야 하고, 또 그 데이터를 수정하고 번역 요청을 하는 등 관리가 필요합니다. 따라서 데이터 수정은 담당 기획자에게 요청하는 것이 가장 안전합니다. (담당자한테 물어보자는 위 문단의 내용과도 유사합니다.)네트워크 환경이 항상 최선의 상태가 아닐 수 있음을 고려하자예를 들어서, 클라이언트는 서버와 통신을 할 때, 클라이언트가 서버에 보내는 모든 요청이 실패할 수 있음을 고려해야 합니다. 유저의 네트워크 환경이 다양하기 때문입니다. 요청이 실패하면 경우에 따라 유저가 말을 걸어도 NPC 가 반응을 하지 않는 등 의도하지 않게 게임에 갇힐 수 있습니다. 그래서, 요청이 실패했을 때 화면이 어떻게 나와야 하는지, 다

Apache Airflow가 3.0 버전으로 올라가면서, 기존의 FAB(Flask App Builder) 기반 UI에서 React 기반 UI로 전면 개편되었습니다.이 과정에서 여러 흥미로운 기능들이 추가되었는데요,이번 글에서는 그 중 하나인 i18n 기능과, 한국어 번역 기여 가이드에 대해 소개해드리겠습니다.Airflow의 i18n(Internationalization) 프로젝트는 Airflow의 웹 UI를 다양한 언어로 번역할 수 있도록 국제화를 지원하는 작업입니다.이 프로젝트는 문자열을 모국어로 변경하는 것 이상으로, 다음과 같은 목표를 가지고 있습니다:• None 글로벌 커뮤니티 활성화: 다양한 언어권 기여자들의 참여 유도• None 번역 품질 유지: 일관된 용어와 구조를 유지해 지속 가능성 확보현재 Airflow는 영어를 기본 언어(default locale)로 사용하며, 각 언어별 JSON 파일을 통해 다양한 locale을 지원하고 있습니다.한국어도 공식적으로 지원되는 locale 중 하나이며, 지속적인 기여가 필요한 상황입니다.Airflow의 UI 번역에 기여하려면 로컬 환경에서 번역 파일을 수정하고, 실제 UI에서 어떻게 보이는지 테스트해볼 수 있어야 합니다.이를 위해 Airflow에서는 공식 개발 툴인 Breeze를 사용합니다.Breeze는 Docker Compose 기반으로 작동하므로, 사용 전에 Docker 환경이 실행 중이어야 합니다.• None 옵션을 통해 코드 수정을 핫 로드 가능하도록 합니다.※ 위 옵션들은 필요에 따라 수정 가능합니다.명령어를 실행하면 아래와 같이 나올 것입니다.그럼 으로 Airflow UI에 들어가서 , 으로 로그인 해줍니다.좌측 하단의 User > Select Language 를 통해 UI를 한국어로 변경할 수 있습니다.그럼 이제 번역 기여 방법에 대해서 알아봅시다.Airflow의 번역은 단순히 "PR을 열고 번역을 올린다"는 것만으로 끝나지 않습니다.공식 정책에 따라 책임자, 승인자, 검수 절차 등이 세분화되어 있어, 기여 전에 몇 가지 구조를 이해해두면 좋습니다.Airflow UI 한국어 번역 파일은 다음 경로에 위치합니다:여기에 각 UI 텍스트에 해당하는 key-value 형태의 JSON이 있으며, "value" 부분을 번역하는 것이 저희의 역할입니다.만약 새로운 UI 문자열이 추가되면, 한국어 번역 파일에도 해당 키가 추가 되며, 로 표시되어, 번역이 필요한 항목을 쉽게 찾을 수 있습니다:이러한 항목들을 찾아 번역하고 PR을 보내는 것이 가장 기본적인 기여 방법입니다.Airflow에 누락된 번역을 자동으로 검사하고, TODO 항목을 추가해주는 도구가 있습니다.이 명령어를 실행하면 아래와 같은 결과가 출력됩니다:각 파일별로 어떤 항목이 누락되었는지, 파일별 번역 진행률이 얼마인지도 확인할 수 있습니다.이 명령어를 통해 를 생성할 수 있으니, 새로운 UI 문자열이 추가되면 해당 명령어를 실행해주어야합니다.그리고 번역을 하면서 몇 가지 팁이 있자면:• None Breeze 환경에서 직접 UI를 띄워 번역이 어떻게 반영되는지 테스트해보세요.• None 영어를 직역하기보다는 자연스럽고 사용자 친화적인 표현이 중요합니다.• None 이나 등 형식 요소는 반드시 그대로 유지해주세요.• None 한 PR에서 너무 많은 항목을 다루기보다는, 관련한 항목끼리 묶어서 올리는 것이 좋습니다.• None 가능하면 기존에 번역보다 TODO: 로 표시된 항목을 번역하는 것이 우선입니다.• None PR 설명에는 어떤 항목들을 번역했는지 간략하게 명시하면 좋습니다.• None 번역시 일관된 용어 사용을 위해 기존 번역 예시를 참고해주세요.Airflow의 i18n 정책에 따르면, 모든 번역 PR은 다음 조건을 충족해야합니다.• None 해당 언어의 Translation Owner가 언어적 측면을 승인해야 합니다.• None Code Owner 또는 커미터가 기술적 측면(포맷, 린트 등)을 확인하고 병합합니다.따라서 PR을 하실 때, 아래와 같이 저희를 태그해서 진행해주시면 더욱 빠른 리뷰에 도움이 됩니다!번역은 기여를 시작하는 데 가장 부담이 적은 방법 중 하나입니다.하지만 단순한 작업 그 이상으로, Airflow의 기여 방식과 문화를 체험하는 가장 좋은 기회이기도 합니다.처음엔 작은 오타 하나, 하나의 문장을 자연스럽게 고치는 것부터 시작해보세요.혹시 기여를 하고 싶은데 어려움이 있다면,이 게시글 댓글을 통해 언제든지 편하게 질문해주세요!

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다.이 세션에서는 BERT기반 모델인 SPLADE모델의 대규모 실시간 서비스를 위한 최적화 방법에 대해서 이야기 합니다. 세상에서 가장 빠른 BertTokenizer 구현체인 FlashTokenizer 의 개발 배경과 성능에 대해 소개합니다.실시간 서빙을 위한 모델 추론 최적화가 필요하신 분들NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

AI 검색 엔진의 부상 (검색의 진화)다음은 "AI 검색이 기존의 검색과 어떻게 다른지 설명해줘"라는 질문를 구글과 Chat GPT에 각각 던졌을 때의 답변입니다.기존의 검색 (구글)과 AI 검색 (Chat GPT)이 어떻게 다른지를 보여주는 대표적인 예입니다."AI 검색이 기존 검색과 어떻게 달라" 라고 묻는다면, 아마 대부분의 사람들은 "정답을 바로 말해주는 것"을 꼽을 것입니다.원하는 정보를 찾기 위해, 링크를 하나하나 찾아 들어가 문서를 직접 읽고 정리해야 했던 기존의 검색과 달리,AI 검색은 관련 문서를 "AI 가" 모두 읽고, 사용자가 원하는 답을 "AI 가" 정리해 줍니다.답을 하기 까지 시간이 다소 소요되기도 하고,때로는 거짓 정보를 제공하거나 있지도 않은 정보를 만들어내기도 하지만,바로 답을 내어주는 AI 검색의 편의성은 이 모든 단점을 모두 감내하고도 남을만한 신기한 경험을 사용자에게 제공해 줍니다.문서를 대신 읽고 사용자 질문에 맞는 답을 해주는 AI 검색은 어쩌면 검색의 가장 본질적이면서도 동시에 (현재로서는) 가장 진화된 형태라 할 수 있을 것입니다.AI 검색 엔진의 내재화 필요성LLM 이 개발되면서 AI 검색 엔진 개발의 난이도가 다소 낮아진 것은 사실입니다.검색 엔진 개발에 있어서 가장 어려운 부분인 질의 분석과 문서 색인 그리고 답변 요약 기능이 모두 LLM과 RAG 등의 LLM 연관 기술로 어느 정도 해결이 가능해 졌기 때문입니다.Perplexity 가 AI 검색 엔진을 처음 선보이고 나서 유사한 기능의 AI 검색 엔진이 여럿 나올 수 있었던 배경에는 이러한 LLM 의 등장이 가장 컸습니다.고성능의 AI 검색 엔진이 존재함에도 불구하고 SKT 내부에서 AI 검색 엔진을 자체적으로 개발하게 된 배경은 다음과 같습니다.첫째로는 한국의 지역적 특성 때문입니다.성능이 좋다고 알려진 Perplexity 도 한국에서 일어난 이슈에 대해 실시간으로 대응을 제 때 해주지 못할 때가 있습니다.아래는 그 대표적인 예입니다.두 번째로는 AI 검색 엔진의 기술과 그들이 제공해주는 API 간의 성능 차이 입니다.AI 검색 엔진들은 사용자의 복잡하고 다양한 질문에 대응하기 위해 보다 많은 비용을 들여 높은 수준의 검색 기술을 개발하게 됩니다.그러나 그들이 제공하는 API 는 그들이 가진 고수준의 검색 결과 보다는 가성비가 가장 좋은 (다소 낮은) 수준의 검색 결과를 제공합니다.API를 제공받는 곳에서 높은 수준의 검색 결과를 기대하기 어려운 이유입니다.마지막으로 커스터마이징 이슈입니다.서비스에 필요한 특정 질의 군의 검색 결과가 맘에 들지 않아 개선하고 싶거나,서비스 개발을 위해 입력이나 출력의 포맷 변경이 필요한 경우 모두,전적으로 검색 엔진 개발 업체에 기대할 수 밖에 없습니다.이러한 이유로 AI 검색 엔진의 내재화가 필요하다 판단되었고,2024년 7월부터 AI 검색 엔진 개발 프로젝트가 시작되었습니다.AI 검색엔진 PAAS는 2024년 7월에 개발을 시작하여 2024년 9월 그 첫 번째 버전을 내부에 공개하였습니다.2024년 12월에는 시스템 안정성과 검색 성능 향상 그리고 검색 서비스 제공을 위한 API 를 구축하였습니다.그리고 2025년 1월, 외부 AI 검색 엔진과 비교하여 적은 비용으로 수준 높은 검색 품질을 제공한다는 성능 실험 결과를 인정받아 에이닷에 적용되었습니다.에이닷에서 최신 정보를 요구하는 질문을 하신다면 PAAS가 답할 확률이 높습니다.아래는 PAAS 답변의 예입니다.출처가 노출되었다면 PAAS 답변일 가능성이 높습니다.PAAS 는 Personal AI Assistant Search 의 약자입니다.개인 AI 비서 검색이라는 단순한 이름을 가지고 있지만, 사용자의 질문에 보다 정확하고 풍부한 답을 제 시간에 제공하기 위해 노력하고 있습니다.다음은 PAAS 의 내부 구조입니다.각 모듈이 담당하는 역할을 간단히 소개하면 다음과 같습니다.• None 사용자 대화 이력과 사용자 질의를 입력 받아 검색 필요 여부, 검색 유형, 검색 플랜, 유효 수집 기간 등을 분석하여 Query Processor 에 전달합니다.• None• None• None 원본 질의 만으로 문제 해결 가능• None• None 원본 질의와 확장 질의로 문제 해결 가능• None 예) "아이유 연기활동과 최근 출연작 알려줘"• None• None 질의를 분해하고 분해한 질의들을 모두 검색하고 종합해야 문제 해결 가능• None 예) "포토프린터 대표적인 거 몇 개 찾아서 이들의 장단점과 평가 그리고 가격을 정리해줘"• None• None PAAS는 문제를 풀기 위한 검색 플랜을 생성합니다. 다음은 그 예입니다.• None 아래 검색 플랜 예제에서는 모두 9개의 확장 질의가 만들어졌음을 확인할 수 있습니다.• None (확장) 질의를 입력받아 관련있는 문서들을 모두 찾아 Search Processor 에 전달합니다.• None 관련 문서의 수가 부족할 경우에는 크롤러에게 수집 요청을 하게 되고, 크롤러는 다방면으로 시드를 수소문하여 관련 문서를 수집합니다.• None 빠른 시간 내에 AI 검색 엔진을 만들 수 있었던 배경에는 저희 본부가 다음의 시스템/모듈들을 미리 구축 및 개발해 두었기 때문입니다.• None Index 로부터 얻어진 후보 문서들을 최신으로 업데이트 합니다.• None 후보 문서의 수집 시간이 Search Planner 에서 제공해 준 유효 수집 기간 내에 있다면 업데이트 하지 않습니다.• None 방문하는 사이트의 트래픽을 최소화하기 위해 (Crawler와 Scraper의 각 사이트) 방문 주기와 횟수는 Global TPS Controller 에 의해 엄격히 통제 및 관리됩니다.• None 웹 컬렉션 (컬렉션은 문서의 묶음입니다.) 외에 뉴스, 증권과 같은 다른 컬렉션이 존재한다면 컬렉션 랭킹을 먼저 수행합니다. (컬렉션 랭킹 또한 Search Planner 에서 제공해 준 정보를 이용합니다.)• None 다음으로 컬렉션 내 후보 문서들의 랭킹을 매깁니다. 만약 문서와 질의간의 유사도가 많이 낮다면 문서를 후보 셋에서 제거합니다.• None 사용자의 대화 이력과

대형 언어 모델(LLM)은 방대한 데이터를 학습하여 인간과 유사한 문장을 생성할 수 있는 능력을 갖추었지만, 종종 실제 사실과 일치하지 않는 그럴듯한 출력을 만들어내기도 합니다. 이를 환각(hallucination)이라 하며, 사용자에게는 설득력 있어 보이지만 사실에 근거하지 않은 정보를 생성하는 현상입니다. 예를 들어, 약물의 부작용에 대해 잘못된 내용을 자신 있게 제시하거나, 존재하지 않는 법적 판례를 만들어내는 경우입니다. LLM은 확률적 예측 기반으로 작동하기 때문에, 생성된 내용의 진위를 스스로 판단하거나 검증하지 못합니다. 이러한 환각 현상은 LLM의 신뢰성(reliability)을 심각하게 저해하는 문제로, 임상·법률·금융 등 정밀한 정보가 요구되는 분야에서 특히 위험할 수 있습니다.LLM 환각의 원인은 다양하지만, 크게 다음의 세 가지로 요약할 수 있습니다.• 모델이 학습한 데이터에 부정확하거나 편향된 정보가 포함된 경우, 그 오류가 그대로 재생산될 수 있습니다. 부정확한 인터넷 자료나 오래된 정보가 데이터에 섞여 있다면, 모델은 이를 사실로 학습하여 잘못된 정보를 생성하게 됩니다.• LLM은 자신이 알고 있는 것과 모르는 것을 구분하지 못하고 무조건 답변을 제공하려는 경향이 있습니다. 모델의 출력은 ‘가장 그럴듯한 다음 단어’를 예측하는 방식이기 때문에, 자신의 지식 한계나 불확실성을 고려하지 않고 높은 확률의 결과를 제시합니다. 이로 인해 틀린 정보도 매우 확신에 찬 어조로 전달되어 마치 사실처럼 보이게 됩니다.• LLM은 학습한 데이터 외에는 외부 정보 확인 능력이 없습니다. 생성된 내용이 사실인지 확인하는 내부 시스템이나 외부 데이터 연동 기능이 없기 때문에, 오류를 걸러낼 수 없습니다. 즉, 모델 스스로 사실 여부를 확인하거나 수정할 수 없기 때문에, 잘못된 정보를 ‘검증 없이’ 그대로 출력하게 됩니다.이 외에도 모델 크기 증가로 인해 기억 능력은 향상되었지만, 미지의 지식(knowledge boundary)에 대한 인식은 오히려 부족해지는 현상도 나타납니다. 모델이 자신이 알지 못하는 질문에 대해서도 무작정 답변을 시도하기 때문에, 정답이 존재하지 않는 질문에 대해서도 그럴듯한 답변을 만들어내는 것입니다.환각 문제를 완전히 제거하기는 어렵지만, 다양한 기법을 통해 발생 빈도를 줄일 수 있습니다. 주요 접근 방식은 다음과 같습니다.• 고품질 데이터로 미세조정(Fine-Tuning)• 학습 데이터의 품질을 높이면 모델의 출력을 더 정확하게 만들 수 있습니다. 검증된 신뢰할 만한 자료를 선별하여 모델을 미세조정하면, 잘못된 정보를 학습할 가능성이 줄어들어 환각 현상을 감소시킬 수 있습니다. 예를 들어, 의료 문헌이나 공식 기록 등 정확한 데이터를 사용해 추가 학습을 진행하면, 모델이 오류 있는 정보에 노출될 확률을 줄일 수 있습니다.• 인간 평가자가 모델의 출력을 평가하고 피드백을 제공하여, 이를 강화 학습 과정에 반영하는 방법입니다. RLHF에서는 평가자가 모델의 응답을 점수화하여 부정확한 답변에는 페널티를 부여하고, 올바른 답변에는 보상을 제공합니다. 이를 통해 모델이 점차 유용한 답변을 학습하게 되며, 부정확한 출력을 줄일 수 있습니다. GPT-4도 RLHF를 통해 반복 학습을 거치며 출력 품질을 향상시킨 것으로 알려져 있습니다.• 모델이 자신의 기억에만 의존하지 않고 외부 데이터베이스나 문서를 참조하도록 하는 기법입니다. RAG를 적용하면, 모델이 사용자 질문에 답할 때 신뢰할 수 있는 외부 소스(예: 위키피디아, 논문 등)에서 관련 정보를 검색하여 활용하게 됩니다. 이를 통해 모델의 지식 한계를 보완하고, 생성된 문장을 사실 기반으로 교정할 수 있습니다. 단점으로는 대규모 검색 처리가 필요해 계산 비용이 많이 든다는 점이 있습니다.• 모델 출력을 직접 검증하는 단계로, 규칙 기반 필터나 추가적인 점수화 과정을 활용합니다. 예를 들어, 생성된 여러 후보 답변을 문장 유사도나 사실 검증 알고리즘으로 재평가하여 가장 신뢰할 수 있는 답변을 선택하거나, 비현실적이거나 근거 없는 답변을 제거합니다. 또한, 모델의 신뢰도 보정(calibration) 기법도 적용됩니다. 모델이 각 답변에 자신감 점수를 부여하도록 학습시키거나, 온도 파라미터(Temperature Parameter)를 조정하여 출력을 덜 무작위적으로 만들면, 낮은 확률의 답변이 줄어들어 허위 응답 가능성이 감소합니다.이처럼 고품질 데이터 미세조정, RLHF, RAG, 검증 시스템 등의 다양한 방법이 환각을 줄이는 데 활용되고 있습니다. 다만, 이들 방식은 계산 비용 증가, 모델 유연성 저하 등의 한계도 존재합니다. 예를 들어 RAG는 외부 지식 조회에 많은 연산이 필요하고, RLHF는 다수의 인간 평가 작업이 필요하여 비용이 많이 듭니다. 그럼에도 의료, 금융, 법률처럼 높은 정밀도가 요구되는 분야에서는 이러한 기법들이 필수적으로 사용되고 있습니다.강화 학습 파인튜닝(Reinforcement Finetuning, RFT)이 모델의 추론 능력을 높이는 대신, 의도치 않은 부작용을 유발할 수 있다는 연구 결과가 발표되었습니다. 연구진은 표준 RFT를 적용한 모델들이 답이 불분명하거나 정보가 부족한 질문에 대해 “모르겠다”라고 답하는 대신, 허구의 답변을 자신 있게 제공하는 “환각 세금(hallucination tax)” 현상을 발견하였습니다. 구체적으로, RFT 학습을 거친 모델은 답이 없는 문항에 대해 거절률(refusal rate)이 80% 이상 감소하였으며, 환각성 답변율은 오히려 증가하였습니다.이 문제를 해결하기 위해 연구진은 Synthetic Unanswerable Math (SUM)라는 합성 수학 문제 데이터를 사용하였습니다. SUM은 일부 정보가 의도적으로 누락되어 풀 수 없는 수학 문제들로 구성되어 있으며, 모델이 “답할 수 없다”라고 판단하고 거부 응답을 할 수 있도록 훈련됩니다. 훈련 데이터에 SUM 문제를 10% 포함해 학습한 모델은 답이 없는 문항에서 적절히 “모르겠다”라고 응답하는 비율이 높아졌고, 환각성 답변은 줄어들었습니다. 이와 같은 학습 방식은 모델의 성능 저하

목차인트로첫 번째 Solution: All-in-One 오픈소스 데이터 디스커버리 플랫폼, DataHub- Step 1: DataHub 구축- Step 2: 지속적인 메타 데이터 관리 시스템 구축두 번째 Solution: 당근 DataWiki- 핵심 고민들- Step 1: DataWiki의 탄생- Step 2: 메타 데이터 SSOT현재와 미래: 잔존 과제들과 다음 스텝인트로안녕하세요, 당근 데이터 가치화 팀의 Software Engineer 다니엘레예요. 가설 검증을 위해선 어떤 데이터를 봐야 할까? , 해당 데이터를 어디서 찾아볼 수 있을까? 데이터 기반의 의사결정을 시작하려면, 이런 질문들을 늘 마주하게 되죠. 기민한 의사결정을 위해서는 필요한 데이터를 쉽고 빠르게 찾을 수 있어야 해요. 데이터는 충분히 쌓고 있지만 정작 어떤 데이터가 존재하는지, 이 데이터가 정확히 무엇을 의미하는지, 누가 관리하며 언제 마지막으로 업데이트한 건지 등을 알기 어려운 경우가 종종 있어요. 바로 아래와 같은 상황처럼 말이죠.아무리 좋은 데이터가 있어도 찾을 수 없다면 무용지물이에요. 찾아도 데이터의 의미를 정확히 파악하지 못한다면 잘못된 의사결정으로 이어질 수도 있죠. 이런 상황들이 반복될수록 분석 업무의 효율성이 떨어질 뿐 아니라, 데이터에 대한 신뢰마저 흔들리게 돼요. 따라서 조직 내에서 구성원들이 데이터를 쉽게 찾고, 이해하고, 신뢰할 수 있도록 지원하는 과정인 데이터 디스커버리는 매우 중요해요.데이터 가치화 팀이 정의한 데이터 디스커버리를 확보하는 데 필요한 기능은 크게 다음 세 가지예요.메타 데이터 정보의 수집이 쉽고 지속적으로 최신 상태를 유지할 수 있어야 한다.입력된 메타 데이터 정보의 저장 및 관리가 잘 돼야 한다.저장된 메타 데이터 정보를 잘 탐색할 수 있어야 한다.첫 번째 Solution: All-in-One 오픈소스 데이터 디스커버리 플랫폼, DataHub위에서 언급한 필요 기능들을 가장 적은 자원으로 충족시킬 방법은 오픈소스로 제공되는 DataHub를 사내 데이터 디스커버리 플랫폼으로 도입하는 거였어요. DataHub는 다양한 데이터와 메타 데이터를 하나의 중앙 플랫폼에서 검색, 탐색, 관리할 수 있도록 지원하는 메타데이터 관리 플랫폼이에요.DataHub는 다양한 외부 시스템과의 연동을 손쉽게 지원하고, Kafka 기반의 실시간 스트리밍 방식을 통해 자동화된 데이터 수집을 지원해요. 덕분에 수동 관리에 따른 부담을 최소화하고 일관된 유지보수가 가능해요. 수집된 데이터는 데이터베이스에 저장되어 웹 UI를 통해 사용자의 높은 접근성과 관리 용이성을 제공하고요. 또한 Elasticsearch를 이용한 빠르고 정확한 검색 기능과 함께, 그래프 데이터베이스를 통한 연관 관계 탐색 기능을 지원해요. 이를 통해 사용자는 필요한 메타 데이터를 빠르게 탐색할 수 있어요.이처럼 DataHub는 메타데이터의 수집과 유지, 효율적 관리 및 저장, 빠른 탐색이 가능하도록 설계되었기 때문에, 문제점들을 보완하기 위한 가장 적합한 솔루션으로 선택하게 되었어요.Step 1: DataHub 구축먼저, DataHub의 구조를 살펴보면 다음과 같아요.출처: https://docs.datahub.com/docs/architecture/architecture간단하게 메타 데이터의 처리 과정을 따라가며 DataHub의 아키텍처를 설명해 볼게요. DataHub는 1) Kafka를 통한 실시간 스트리밍 방식으로 메타데이터를 수집하고, 2) Metadata Service 서버에서 이를 처리하여 MySQL에 저장하며, 3) Elasticsearch를 통해 검색할 수 있게 만들고, 4) 그래프 DB를 이용해 관계를 표현하며, 5) Frontend 서버로 사용자에게 서비스를 제공하는 구조로 이루어져 있어요.App Tier의 리소스들은 Helm 차트로 배포(MetadataChangeEvent 제외)하였고, 나머지 Persistence Tier의 리소스들은 관리의 안정성과 운영 효율성을 위해 AWS에서 리소스들(RDS, OpenSearch, MSK)을 생성 및 결합하여 구축하였어요.Step 2: 지속적인 메타 데이터 관리 시스템 구축DataHub 구축만으로 앞서 정의한 기능을 모두 충족하기는 어려웠어요. 메타 데이터를 수집하여 저장, 관리, 탐색할 수 있는 플랫폼이 구성되었을 뿐, 데이터를 어떻게 유지력 있게 수집할지는 별도의 고민이 필요했죠. 여기서 유지력이라 하면 크게 두 가지 관점으로 생각해 볼 수 있었어요.데이터 신선도추가적인 메타 데이터 (데이터 맥락, 데이터 히스토리 등)데이터셋 메타 데이터의 변경 사항이 반영되도록 데이터 신선도를 어떻게 유지할지, 또 단순 자동화로는 수집하기 어려운 데이터 맥락 및 히스토리를 어떻게 수집할지 추가적인 고민이 필요했어요.이를 해결하기 위해 업데이트된 메타 데이터와 원천 데이터와의 지속적인 싱크를 통해 데이터 신선도를 확보했어요. 또 구성원들이 참여해 추가적인 메타 데이터를 수집할 수 있도록 4가지 작업을 진행하였어요.Step 2 1: 데이터 파이프라인을 통한 메타 데이터 업데이트 자동화데이터 가치화 팀은 Airflow의 DataHub Provider를 활용해 관리 중인 데이터 파이프라인(e.g. DB 데이터, 사용자 로그, dbt, Karrotmetrics 지표)의 끝단에 메타데이터 업데이트 태스크를 추가했어요. 이를 통해 각 파이프라인과 연결된 메타데이터가 주기적으로 자동 업데이트돼요.Airflow DAG task graphs for updating DataHub또한파이프라인에서 직접 관리되지 않는 데이터셋의 메타데이터도 별도의 파이프라인을 통해 주기적으로 수집하고 있어요. 이를 통해 메타데이터 관리의 사각지대를 최소화했어요.Airflow task graph for BigQuery-to-DataHub metadata ingestionStep 2 2: 데이터 신선도 모니터링 파이프라인을 통한 신선도 확보데이터의 신선도를 정확히 모니터링하기 위해 명확한 판단 기준이 필요했어요. DataHub를 업데이트하는 모든 데이터 파이프라인은 최대 daily(매일) 주기로 동작하기 때문

안녕하세요! <언더커버 사일로>의 치열한 두뇌 싸움, 모두 즐겁게 보고 계신가요?본편만큼이나 많은 분들이 기다리셨을 '비하인드 토크'를 드디어 들고 왔어요. 에피소드를 보며 "왜 저런 문제를 냈을까?", "나라면 어떻게 풀었을까?" 하고 궁금해왔던 모든 것들, 그 숨겨진 이야기와 출제자의 진짜 의도를 모두 여기에 담았습니다.이제 이 Q&A 코멘터리를 통해, <언더커버 사일로>의 인사이트를 더욱 깊고 풍성하게, 꼭꼭 씹어 즐겨주시길 바라요.언더커버 사일로 비하인드 토크 MC 범근님은 토스의 iOS 개발자예요. 스스로를 ‘말하는 걸 좋아하는, 보기 드문 개발자’라고 소개하셨죠. 기자 출신답게 말솜씨랑 핵심을 똑 짚어내는 질문 실력은 이미 검증 완료! 사실 기획 초기엔 토스 직원들이 문제를 푸는 포맷이라 범근님도 출연자로 점찍혀 있었는데, 외부 메이커를 불러서 더 크게 가보자—는 방향이 잡히면서 자연스럽게 진행자 자리를 꿰차게 됐답니다.실제 출제위원 등장: AI 아니고 진짜 PO입니다토스 챌린저스 팬이라면 “문제 진짜 PO들이 직접 냈대?” 하고 한 번쯤 궁금했을 거예요. 댓글엔 “혹시 AI로 만든 거 아닌가요?” 같은 질문도 있었고요.그래서 준비했습니다, 짜잔! 실제 출제위원인 두 분의 PO가 비하인드 토크에 직접 출동했어요. 주인공은 인플로우 사일로의 조성은 PO와 모네타이제이션 사일로의 박세진 PO입니다.다들 잘 아시겠지만, ‘언더커버 사일로’의 첫 주자는 인플로우 사일로였어요. 콘텐츠에서는 인플로우 사일로를 “토스에 새 유저를 끌어오는 팀” 정도로만 소개하지만, 사실 그 뒤에는 훨씬 더 흥미로운 비하인드 스토리가 숨어 있답니다.지금부터, 당신은 인플로우 사일로원이 됩니다.여러분 근데 그거 아시나요? 조성은 PO는 당시 입사 2년 차로, 승건님의 뒤를 이어 인플로우 사일로를 맡게 되었어요. 처음엔 워낙 다양한 방향성에 막막했지만, ‘토스는 원래 바이럴 맛집이었잖아’라는 생각으로 폭발적인 바이럴에 초점을 맞추기로 했죠.성은님이 레퍼런스로 삼았던 토스의 대표 히트작은 2023년 만우절에 터뜨린 〈바보티콘〉 이벤트예요. 브랜드콘을 무료로 뿌리면서 ‘의외성’과 ‘기대감’을 제대로 저격해 대박을 냈다고 분석했어요.인플로우 사일로의 미션: 유저 그로스그렇다면 인플로우 사일로가 하는 일은 뭘까요? 한마디로, 모든 서비스의 메인 목표로 꼽히는 유저 그로스 입니다. 토스 사용자 수를 키우려면인플로우 사일로는 전자에 집중해요. 즉, 신규·부활 유저를 데려오는 것이 사일로의 목표죠. 문제는 이 사람들이 앱을 안 쓰니 직접 말 걸 방법이 없다는 것. 그래서 두 가지 길을 택했죠.인플로우 사일로는 둘 중 후자가 더 강력하다고 판단했고, “바이럴 제품을 쉴 새 없이 만들자!”는 목표를 세웠습니다. 핵심 지표는 공유율 같은 한 가지로 딱 정하고, 나머진 과감히 생략. 바이럴 제품은 생명력이 하루이틀로 짧아서 성공·실패가 즉시 갈리거든요. 덕분에 팀은 매일 새로운 아이디어를 실험하고, 그 자리에서 배우고, 곧장 다음 판을 준비합니다—빠른 실행과 학습이 비결인 셈이죠

MySQL 접근에 대한 안정성을 높이기 위해 MySQL Ver. 5.7.23부터 MySQL 계정의 비밀번호 인증을 위한 알고리즘 플러그인으로 caching_sha2_password가 도입되었습니다. 도입 시에는 기본 인증 플러그인이 아니었기 때문에 원하는 사람만 선택하여 사용할 수 있었습니다. 하지만, MySQL Ver. 8.0.x 버전부터 기본 인증 플러그인 값이 caching_sha2_password로 변경되었고, MySQL Ver. 9.0 부터는 mysql_native_password가 지원되지 않는 것으로 결정되었습니다. 이에 따라 기존에 mysql_native_password를 사용하는 경우 caching_sha2_password로 변경해야 하며, MySQL 운영 시 어떤 부분들이 영향을 미칠지에 대한 고민도 필요해 졌습니다. 여기에서는 caching_sha2_password 플러그인 도입을 위해 필요한 사전 지식을 소개하고, 변경 및 운영 시 어떤 내용들을 반영해야 하는지를 정리해 보려고 합니다.caching_sha2_password 플러그인은 SHA-256 알고리즘을 기반으로 작성된 인증 플러그인입니다. 그래서 먼저 여기서는 간단하게 Hash 알고리즘에 대해 정리해 보려고 합니다. SHA_256 알고리즘은 Hash 알고리즘 중 하나입니다. Hash 알고리즘은 단방향 알고리즘으로 속도가 빠르지만, 복호화는 불가능합니다. Hash 알고리즘은 변환/계산할 때 쓰이는 MD5, SHA1, SHA256, SHA384, SHA512 등의 알고리즘이 있습니다. 이 중 몇 개만 간단히 짚어 보고 가겠습니다.MD5는 Message-Digest Algorithm5의 약자로 임의의 길이의 데이터를 고정된 비트 128비트를 기반으로 Hash로 변환하는 단방향 해시 함수입니다. 메시지 축약 알고리즘으로 많이 사용되며, 프로그램이나 파일이 원본 그대로 인지를 확인하는 무결성 검사 등에 많이 사용됩니다. 간단히 다음과 같은 특징을 가지고 있습니다.• 입력 데이터를 해시값으로 변환할 수는 있지만, 해시값만으로는 원래의 데이터를 복원할 수는 없습니다.• 어떤 데이터를 입력하든 항상 128비트의 해시값을 생성합니다.• 입력 데이터의 아주 작은 변화만 있어도 아주 다른 해시값을 만들어 냅니다.• 충돌 공격(Collision Attack)에 약해 더 이상 안전하지 않다고 판명되어, 이제는 잘 쓰이지 않습니다.MySQL에서는 다음과 같이 간단히 암호화 할 수 있습니다.SHA 알고리즘은 미국 국가표준기술연구소(NIST)에서 발행한 암호학적 해시 함수군으로 다음과 같은 특징을 가지고 있습니다.• 입력된 데이터를 고정된 길이의 해시값으로 변환합니다.• 입력 데이터의 크기와 상관없이 항상 동일한 길이의 해시값을 생성합니다.• 만들어진 해시값을 가지고 원본 데이터를 복원할 수 없습니다.• 미세한 값의 변화에도 전혀 다른 해시값이 만들어집니다.• 동일한 입력에 대해서는 항상 동일한 해시값을 생성합니다.위와 같은 특징을 가진 SHA는 시간이 지남에 따라 보안 취약점이 발견되면서 여러 버전으로 발전했고, SHA-1부터 현재 SHA-3까지 발전했지만, SHA-1은 현재 사용이 권장되지 않아, 이제 사용하지 않는다고 봐도 무방합니다. 현재는 SHA-2가 널리 사용되고 있고, SHA-2, SHA-3을 사용하는 것을 권장합니다.3개의 알고리즘을 비교하면 다음과 같이 간단히 정리해 볼 수 있습니다.현재 MySQL에서 사용하는 caching_sha2_password 인증 플러그인은 SHA-2 기반으로 만들어진 알고리즘을 사용하여 개발되었습니다. 여기에서는 MySQL 비밀번호 암호화에 사용하는 SHA-2만 간단히 살펴보겠습니다.SHA-1의 보안 취약점을 보완한 알고리즘으로 다음과 같은 내용이 보강되었습니다.• Merkle-Damgard(Davies-Meyer) 기반으로 내부 알고리즘이 개선되었고, 더 많은 계산 횟수를 사용하여 보안성을 강화했습니다.• 단일 알고리즘이 아니라 변형된 알고리즘을 사용하게 설계되었습니다.• 사용되는 해시 길이 값이 다양합니다.• 동일한 입력 데이터에 대해서는 항상 동일한 해시값을 생성합니다.• 입력 데이터에 아주 사소한 변화만 있어도 결과 해시값이 완전히 다르게 생성되는 쇄도 효과(Avalanche Effect)를 보여줍니다.SHA-2는 앞서 이야기 한대로 현재 가장 일반적으로 사용되고 많이 사용되는 암호화 알고리즘으로 다양한 디지털 보안 애플리케이션에서 핵심적인 역할을 수행합니다.SHA-2는 생성되는 해시값의 길이 및 변형 기술에 따라 SHA-224, SHA-256, SHA-384, SHA-512 제품군을 가지고 있습니다. 이 중 SHA-256, SHA-512를 가장 많이 사용합니다. MySQL에서는 SHA-256을 기반으로 인증 플러그인을 만들어서 제공합니다.MySQL은 버전에 따라 다양한 인증 플러그인을 제공했습니다. 여기에서는 간단히 버전에 따라 어떤 플러그인이 사용되었는지 정리하겠습니다.MySQL은 default_authentication_plugin 시스템 변수를 통해 기본 사용 가능한 플러그인을 설정해 사용할 수 있습니다. 버전에 따른 기본 인증 플러그인은 다음과 같습니다.MySQL에서 제공한 인증 플러그인 중 주요한 플러그인 몇개만 간단히 살펴보도록 하겠습니다.mysql_old_password 인증 플러그인은 다른 암호화 기술을 사용하지 않고, 자체적으로 해시 알고리즘을 만들어서 제공한 인증 플러그인입니다. 비밀번호 문자열을 기반으로 특정 비트 연산과 같은 간단한 변환을 여러번 수행하는 상대적으로 단순한 알고리즘으로 구현되었습니다. 또한, 생성되는 해시값은 16자리 16진수 문자열(8바이트)로 변환됩니다.SHA-1알고리즘을 사용하여 구현한 인증 플러그인입니다. 입력된 비밀번호를 SHA-1 알고리즘으로 2번 해싱해 최종 저장될 해시값을 생성합니다. 이 값을 40자리 16진수 문자열로 변환하고, 앞에 * 문자를 추가하여 총 41자로 해시값을 저장합니다. 변환된 비밀번호의 해시값은 mysql.user 테이블의 authentication_string 컬럼에 저장하고, 클라이언트 접근 시

안녕하세요! 아주 오래 전 2021년에 올린 글('AWS의 IaC Framework CDK 소개')에서 AWS CDK의 기본 개념과 장점에 대해 소개드렸는데요.오랜시간이 지났지만 ^^;; 글 후반부에 이야기 드렸었던 만큼 실제 프로젝트에서 CDK를 활용한 경험을 공유하고자 합니다.이 글을 통해 지금은 조금 아웃데이트되었지만 Vision AI모델을 AWS상에서 서빙하는 API 서비스를 AWS CDK로 구축하는데 필요한 사례와 노하우를 공유하려고 합니다.저희가 구축한 Vision AI API 서비스는 다음과 같은 아키텍처로 구성되어 있습니다:처음에는 모든 리소스를 하나의 스택에 넣었다가, 관리의 어려움을 겪고 다음과 같이 분리했습니다:개발, 스테이징, 프로덕션 환경을 효율적으로 관리하기 위해 설정 파일을 분리했습니다:Vision AI 모델의 의존성이 크기 때문에 Lambda Layer를 적극 활용했습니다:S3 라이프사이클 규칙CloudWatch 대시보드와 알람을 코드로 정의하여 일관성을 유지했습니다:GitHub Actions를 활용한 CI/CD 파이프라인을 구성했습니다:Vision AI 모델 로딩으로 인한 콜드 스타트가 심각했습니다. 다음과 같이 해결했습니다:스택 간 리소스 참조 시 순환 의존성 문제가 발생했습니다:• None 장애 대응 속도 향상: 코드 기반 롤백으로 5분 내 복구 가능• None 작게 시작하기: 처음부터 완벽한 구조를 만들려 하지 말고 점진적으로 개선• None 테스트 작성의 중요성: CDK 테스트로 배포 전 문제 발견• None 문서화: 팀원들을 위한 CDK 패턴과 가이드라인 문서 작성 필수이후에 좀 더 고도화된 시스템을 위해 다음과 같은 개선사항을 생각해볼 수 있습니다:• None CDK Pipelines 도입으로 더 정교한 CI/CD 구현• None FinOps 도구 통합으로 비용 최적화 자동화AWS CDK는 단순히 CloudFormation의 대체재가 아닌, 인프라를 소프트웨어처럼 다룰 수 있게 해주는 강력한 도구입니다.초기 학습 곡선은 있지만, 한번 익숙해지면 인프라 관리의 효율성이 크게 향상됩니다.다음 포스트에서는 CDK Custom Constructs를 활용한 재사용 가능한 컴포넌트 개발에 대해 다루어보겠습니다.질문이나 공유하고 싶은 경험이 있으시다면 댓글로 남겨주세요!

이번 모델의 특징 중 하나는 멀티모달에 대한 부분입니다.텍스트, 이미지 뿐만 아니라 오디오도 입력받을 수 있게 되었습니다.이미 이미지나 오디오를 입력 받아서 처리하는 모델은 많지 않냐고요?중요한건 Gemma 3n은 On-device 모델이라는 겁니다.인터넷에 연결되어 있지 않아도, 민감한 정보를 서버에 올리지 않아도, 서버 운영에 대한 추가비용 없이도 사용할 수 있습니다.다른 특징으로는 파라미터 최적화와 성능향상을 들 수 있습니다.LMArena의 Elo Score(상대적인 비교평가 지수)에서도 다른 거대모델들과 비교해서도 상당히 높다는 것을 확인할 수 있습니다.Gemma 3n은 E2B 모델과 E4B 모델이 존재하는데 각각 5B, 8B 파라미터를 2B, 4B 모델과 유사한 메모리 사용량으로 실행 가능합니다.그 밖에도 아래와 같은 특징들을 가지고 있습니다.• None 마트료시카(Matryoshika) 인형처럼 큰 모델 안에 완전한 작은 모델을 갖추고 있음. E4B 모델 학습 과정에서 E2B 모델이 동시에 최적화됨. 일부 레이어를 선택적으로 건너뛰어 최적의 모델 크기를 도출할 수 있음• None 파라미터의 상당 부분은 CPU에서 로드되고 핵심 트랜스포머 가중치만 GPU/TPU에 로드됨• None KV(Key-Value) 캐시 공유 기능을 도입하여 긴 시퀀스 입력을 이전보다 더 빠르게 처리함참고로 아래 코드는 Macbook Pro M3에서 jupyter notebook을 통해 실행되었습니다.사전 준비 작업으로 pytorch, transformers와 pytorch image models 라이브러리를 최신버전으로 설치해주셔야 합니다.전처리기와 모델을 불러옵니다.이제 오디오를 입력으로 받아서 처리해 보겠습니다.아래는 출력 결과입니다. 예제는 영어로된 음성을 입력했는데 한국어 음성을 넣어도 결과가 잘 나옵니다. 하지만 영어보다는 인식하는 성능이 쫌 떨어지는 것 같아요.다음은 이미지를 입력해보겠습니다.이미지도 오디오 입력과 거의 동일하고 messages 정의 부분만 수정해주시면 됩니다.입력된 이미지와 결과입니다. 다양한 스타일로 제목을 달아주었는데요. 어떠신가요?max_new_tokens 값을 수정하여 출력 길이를 조정할 수 있습니다.오디오와 이미지를 입력으로 받을 수 있게 되면서 더욱 다양한 방식으로 활용될 수 있을겁니다.구글에 있는 예제들을 보면 아래와 같은 것들도 가능하죠.• None 두 개의 이미지를 비교하기• None 이미지에 있는 물체들 인식하기• None 비디오 분석하기 (이미지 리스트와 오디오를 입력)• None 여러 이미지를 입력하고 시나리오 작성하기흥미롭게 읽으셨나요? 상상력을 발휘해서 다양한 분야에 활용해보시면 좋겠습니다.