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

안녕하세요! 아주 오래 전 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 여러 이미지를 입력하고 시나리오 작성하기흥미롭게 읽으셨나요? 상상력을 발휘해서 다양한 분야에 활용해보시면 좋겠습니다.

LY Corporation(이하 LY)은 지난 6월 30일과 7월 1일 양일간 AI를 메인 테마로 한 기술 컨퍼런스 'Tech-Verse 2025'를 개최했습니다.행사는 이틀간 방문객 연인원 1,200명 이상, 웹사이트 방문자 연인원 7,000명 이상, 동영상 시청 수 6,000회 이상을 기록하며 성황리에 막을 내렸습니다.행사에서는 키노트를 시작으로 12개 카테고리에서 131개의 세션이 발표됐는데요. LY 그룹 각 사에서 개발 및 연구를 통해 쌓아온 성과와 지식, 최첨단 기술 등이 다양한 사례와 함께 공유됐습니다. 또한 현장은 'Change and Change'라는 테마로 오감으로 변화를 체험할 수 있도록 공간이 연출돼 참가자들에게 하루 종일 테마에 몰입할 수 있는 환경이 제공됐습니다.행사는 LY의 수석 집행 임원 겸 CTO(최고 기술 책임자) 박의빈 님이 Tech-Verse 2025의 개최 배경을 설명하고 키노트에서 전달할 주제(플랫폼 통합과 AI 전략)를 공유하는 것으로 시작했습니다.두 기업이 합병해 LY로 거듭나면서 필요해진 플랫폼 통합에 관해서는 집행 임원 겸 서비스 인프라 그룹장 토미카와 노부히로(Tomikawa Nobuhiro) 님이 설명했습니다.토미카와 노부히로 님은 '왜 자체 클라우드 플랫폼을 구축해야 할까요?'라고 질문을 던진 뒤 다음과 같이 답변했습니다.• 평균 약 4배에 달하는 압도적인 비용 절감 효과• LY의 엄청난 서비스 규모와 여러 서비스의 수평적 통합과 관련된 공통 니즈에 대응• 합병 후 역할이 중복되는 플랫폼 및 인프라 통합• 고객이 더욱 안심할 수 있는 보안을 제공하기 위한 정보 보안 강화 및 혁신 가속화토미카와 노부히로 님은 '이 플랫폼을 통해 우리는 더욱 안전하고, 빠르고, 대담하게 기술 혁신에 도전할 수 있으며, 이 도전이 궁극적으로 사용자 여러분의 삶을 더욱 풍요롭게 만들 미래를 가져올 것입니다"라고 세션을 마무리했습니다.이어서 다시 박의빈 님이 AI 기업을 지향하는 LY의 AI 전략을 크게 두 갈래로 나눠 소개했습니다.먼저 '모든 서비스의 AI 에이전트화'를 화두로 제시하며 아래와 같이 현재까지의 성과와 앞으로의 방향을 제시했습니다.• 이미 44개의 서비스에 생성형 AI 도입• 수천만 개의 에이전트 생성 가능• 이를 연계해 퍼스널 에이전트를 구현해서 사용자 한 명 한 명의 니즈를 지원이어서 '개발 환경 자체도 획기적으로 진화시켜야 한다'며 다음과 같은 내용을 전달했습니다.• 7월부터 모든 엔지니어에게 전면 도입되는 AI 개발 솔루션 제공• RAG(retrieval-augmented generation)에 축적된 사내 지식을 활용해 더 높은 품질 확보(다양한 지식 및 가이드라인 이해)• PoC(proof of concept) 결과 'Code Assist'의 정답률 96%, 'Auto Test'로 97%의 시간 단축 등의 성과 확인박의빈 님은 '환경을 획기적으로 개선해 엔지니어가 서비스 개선에 보다 집중할 수 있도록 만들어 더 우수한 서비스를 빠르게 제공할 수 있으며, 이를 통해 사용자에게 'WOW'한 라이프 스타일 플랫폼과 '!'(놀라움)가 있는 일상 경험을 제공하는 것이 우리의 최종 목표입니다'라고 마무리했습니다.키노트의 더욱 자세한 내용은 아래 슬라이드를 참고해 주세요.키노트 세션에 이어 진행된 글로벌 CTO 세션에서는 LY의 CTO 박의빈 님과 LINE Plus의 CTO 권순호(Kwon Snow) 님, LINE Taiwan Limited의 CTO Chen 님과 Hung-Chia(Chen Marco) 님, LINE Company(태국)의 CPO/CTO Kasetsin 님과 Weera(Ball)님이 함께 단상에 올랐습니다. 이들은 LINE Premium의 태국 현지화와 LINE OA 스토어, OA Plus, LINE 메신저 등의 글로벌 협업 사례들을 소개하며 LY 그룹의 글로벌 회사들이 어떻게 서로 연계해 각국에서 서비스를 전개하고 있는지 소개했습니다.박의빈 님은 '나라와 언어가 다른 엔지니어들이 시너지를 내는 것은 결코 쉬운 일이 아니며, 그 도전을 지금까지 계속해 온 우리 엔지니어들에게 진심으로 박수를 보내고 싶다'고 말하며 글로벌 CTO 세션을 마무리했습니다. 글로벌 CTO 세션의 더욱 자세한 내용은 아래 슬라이드를 참고해 주세요.이어서 AI, Security, Server Side, Private Cloud, Infrastructure, Data Platform, AI Use Cases, Frontend, App, Design, Product Management, Engineering Management 등의 카테고리에서 총 131개의 세션이 진행됐습니다. Tech-Verse 2025 (Speaker Deck)에서 각 세션의 슬라이드를 확인하실 수 있으니 관심 있으신 분들은 참고하시길 바랍니다.행사 현장에는 세션 발표 외에도 여러 가지 볼거리와 참여 이벤트가 풍성하게 준비돼 있었습니다.행사 현장에는 참가자들이 개발 팀과 직접 교류할 수 있도록 다양한 서비스를 소개하는 패널을 전시해 놓은 프로덕트 스트리트가 마련돼 있었습니다. 행사 기간 동안 많은 참가자들이 이 거리를 오가며 부스 담당자와 열정적으로 대화하는 모습을 볼 수 있었습니다.행사장의 또 다른 하이라이트첫날 열린 친목 모임에서는 유명 레스토랑 셰프를 초빙해 식사를 제공했고, 베스트 스피커상 수상자를 발표하는 시상식도 진행됐습니다. 또한 LINE 공식 계정을 통해 진행된 스탬프 모으기 활동이나 푸짐한 기념품이 제공되는 설문조사 등 참가자들을 설레게 하는 다양한 이벤트가 마련돼 있었습니다.추후 YouTube에 행사 관련 영상을 게시할 예정이며, 이 블로그로 기술 관련 기사도 올릴 예정입니다. 아래 계정을 팔로우하시면 언제든지 최신 콘텐츠 알림을 받으실 수 있으니 참고하시기 바랍니다.마지막으로 행사에 참가해 주신 모든 분들께 진심으로 감사를 드립니다. 여러분 덕분에 멋진 행사를 만들 수 있었고, 주최측으로서 매우 영광이었습니다. 앞으로 더욱 풍성한 행사를 만들기 위해 최선을 다하겠습니다. 많은 관심과 응원 부탁드립니다.

안녕하세요, 테크블로그 구독자 여러분! 토스 콘텐츠 프로듀서 김태성입니다.혹시 유튜브 시리즈 〈언더커버 사일로〉를 보신 적 있나요? 토스 안팎에서 벌어진 실제 문제를 예능 포맷으로 풀어낸, 토스의 첫 도전이었습니다. 시작 전엔 “과연 통할까?” 하는 두려움이 컸지만, 다행히 많은 분이 토스가 진정성 있게 러닝 쉐어를 나누고 싶어 한다는 마음을 알아봐 주셨어요. 덕분에 “더 깊이 고민하고, 더 많이 실패하고, 결국 더 크게 성공해 보자”는 우리의 바람도 힘을 얻었습니다.〈언더커버 사일로〉는 토스 밖 여섯 명의 메이커가 ‘사일로원’이 되어, 토스가 실제로 직면했던 과제를 해결해 보는 두뇌 서바이벌 예능입니다. 기획 초반엔 팀원들을 설득하려고 “토스판 〈크라임씬〉을 만들겠다”고 선언하고 다녔는데, 그땐 진짜 아무것도 없는 상태였어요. 그래도 “직무와 상관없이 누구나 이 콘텐츠를 통해 토스의 일하는 방식을 고해상도로 들여다볼 수 있어야 한다”는 목표만은 확고했습니다.사실 토스는 그동안 컨퍼런스, 밋업, 그리고 바로 이 테크블로그를 통해 제품 개발 과정에서 얻은 러닝과 인사이트를 꾸준히 공개해 왔어요. 그런데도 “성공담만 내보내는 거 아니냐”, “실패는 숨기는 거 아니냐”, “토스니까 가능하지, 우리는 환경이 달라서 안 된다” 같은 반응이 종종 이어졌죠.제 생각은 달랐습니다. 치열한 논의와 문제 해결 의지만 있다면, 누구라도 토스 사일로처럼 일할 수 있다고 믿었어요. 그래서 외부 메이커들이 같은 조건에서 같은 문제를 풀어 보는 실험을 해 보고 싶었습니다. 먼저 비공개로 여러 소규모 스타트업 메이커분들을 모셔 사전 리허설을 진행했고, PO·개발자·창업자·디자이너·마케터 등 다양한 참여자들이 문제를 해결하는 과정에서 배워 가는 것을 보며 확신을 얻었습니다.바로 그 확신이 “토스 사일로에 외부 메이커가 잠입한다”는 콘셉트로 〈언더커버 사일로〉를 제작하게 된 배경입니다.도메인이 뭐든, 경력이 얼마든, 직무가 달라도 문제 해결에 열정만 있다면 누구나 토스가 겪었던 비즈니스 과제를 풀어낼 수 있다고 믿어요. 그래서 외부 메이커들이 흥미를 가질 만한 토스 프로덕트 다섯 개를 골랐습니다.언더커버 사일로에 출연한 챌린저스는 물론, 시청자 여러분도 이 다섯 가지 과제를 함께 고민하며 풀어 보길 바랍니다. 아직 시리즈를 못 보신 분이라면, 토스가 어떻게 고민하고 결정하며 실패와 성공을 반복하는지를 생생하게 체험하실 수 있을 거예요. 앞으로도 더 많은 러닝 쉐어를 통해, 여러분이 자신의 자리에서 새로운 도전을 이어 갈 용기를 얻어가셨으면 합니다.이번 글을 읽고 ‘언더커버 사일로’가 궁금해지셨다면, 지금 바로 본편을 확인해 보세요!그리고 테크블로그에서는 본편에서 다 전하지 못한 비하인드 스토리를 차례로 풀어갈 예정이니, 놓치지 않으려면 꼭 구독해 주세요.

접근성 지원을 한다고 하면, 사람들은 뭘 더 해야 한다고 생각합니다. 뭘 더 하는 만큼 개발기간도 더 늘어난다고 생각합니다. 하지만 이런 생각은, 보안성을 챙기면 개발기간이 늘어난다 는 주장만큼이나 틀린 말입니다. 보안성을 고려하며 개발하는 것이지, 개발 다 끝내놓고 그 다음에 보안성을 따로 높이는 사람이 어디있나요? 접근성을 고려하는 일은, 사실 우리가 더 좋은 제품을 만들기 위해 늘 하는 고민들의 다른 측면일 뿐입니다.하지만 평소에 접근성을 높이는 일에 관심이 없던 사람 입장에선, 이런 얘기도 뜬구름 잡는 얘기처럼 들립니다. 접근성 지원이 어떻게 우리가 늘 하는 고민 의 다른 측면일 수 있을까요? 나는 그런 고민을 한 적이 없는데 말이죠.관점을 바꿔, 이렇게 여쭤보겠습니다. 당신은 프로그래머로써 일반 텍스트(plain text)의 힘을 충분히 활용하고 있습니까?『실용주의 프로그래머』는 일반텍스트(plain text)의 힘을 다음과 같이 강조합니다.…우리는 지식을 다루기 가장 좋은 형식이 일반 텍스트라고 믿습니다. 일반 텍스트를 사용하면, 우리는 손으로든 프로그램으로든 거의 모든 도구를 사용해 지식을 조작할 수 있는 능력을 얻게 됩니다. 대부분의 바이너리 형식의 문제는, 데이터를 이해하는 데 필요한 문맥이 데이터 자체와 분리되어 있다는 점입니다. …(중략) 애플리케이션 없이 해석할 수 없다면, 그 데이터는 암호화된 것이나 다름없으며 전혀 의미를 지니지 못합니다. 사람이 읽을 수 있는 형태의 데이터, 그리고 자기 기술적(self-describing) 데이터는 그 데이터를 생성한 애플리케이션이나 그 외 모든 형식의 데이터를 뛰어넘어 더 오래 살아남을 것입니다. 단언컨대 그렇습니다. 데이터만 살아남는다면, 그것을 사용할 기회는 여전히 존재합니다 — 비록 그 데이터를 작성한 원래의 애플리케이션이 사라진 이후라도 말입니다.접근성 높은 제품을 만든다는 것은, 더 다양한 환경에서 동작하는 제품을 만든다는 것과 정확히 같은 뜻입니다. 손이 없는 유저가 음성이나 눈으로 접근할 수 있는 환경, 눈이 없는 유저가 시각적 요소 없이 정보에 접근해야 하는 환경, 손과 눈이 모두 없는 컴퓨터가 어떻게든 정보에 접근해 단위테스트를 실행시켜야하는 환경에서 모두 동작하는 제품이 접근성 높은 제품입니다. 이 때 다양한 환경이 같은 출력물을 일관되게 해석할 수 있게 하기 위해선, 그 출력물은 반드시 텍스트여야 합니다. 오직 텍스트만이 특정 환경에 의존하지 않고 그 자체적으로 해석될 수 있기 때문입니다.그래서 유능한 프로그래머는 언제나 ‘입력과 출력을 어떻게 텍스트로 다룰 수 있을까’를 고민합니다. 텍스트로만 만든다면, 그것이 무엇이든 분석하고 조작할 수 있기 때문입니다. 우리가 API와 CLI로 개발하는 이유, 가장 강력한 AI가 대형언어모델의 형태인 이유에는, 모두 같은 배경이 있는 것입니다.접근성을 지원할 때, 우리가 하는 대부분의 일이 UI에 텍스트 형태의 정보를 추가하는 일인 것도, 결코 우연이 아닌 방금 말한 배경에서 나온 의도적 디자인입니다. 실제로,

Terraform과 Ansible를 들어보신 적 있으신가요? 클러스터를 구성하다보면 자주 마주치게 되는 이름들입니다.IaC(Infrastructure As Code)의 대표적인 도구들로 서버, 네트워크, 스토리지 등 IT 인프라를 사람이 직접 클릭 하거나 명령어를 입력해 수동으로 설정하는 대신,코드로 정의하고 자동화된 방식으로 관리/프로비저닝하는 도구입니다.현재 On-Prem 환경에서 Kubernetes 인프라를 프로비저닝하는 작업을 진행하고 있는 현재에 IaC는 매우 편리하고 일관성을 가지는 도구입니다.그렇다면 On-Prem의 K8S 환경을 제공하는 입장에서 더 필요한 내용은 무엇이 있을까요?구성된 클러스터를 IaC 코드를 모르는 사용자들에게도 알기 쉽게 전달할 수 있어야 합니다.여러 방법이 있을 수 있겠지만 개인적으로 가장 선호하는 방식은 그래프를 통해 나타내는 것입니다.다음은 직접 경험해본 툴들을 비교한 내용입니다. 결국 손에 잘 익은 도구가 좋습니다.사용법도 큰 차이가 없어서 디자인적인 선호도가 중요할 것 같습니다.본론으로 들어와 이 툴들 중에서도 제가 리뷰 할 도구는 Mermaid Chart 입니다.Mermaid Chart의 가장 큰 장점은 Code로 표현된다는 점입니다.조금 의아하실 수 도 있겠지만 Graph를 Code로 나타내는 것이 더 어렵지 않을까? 생각 할 수도 있습니다.네, 물론 어렵습니다. 그럼에도 이를 가장 큰 장점으로 뽑은 이유는 이 어려운 일을 저희가 하지 않을 수 있기 때문입니다.LLM을 활용한다면 이 Code를 쉽게 작성 할 수 있습니다.개인적으로 저는 Cursor AI를 사용할 예정입니다.예제는 KubeSpray를 사용해볼 예정입니다.kubernetes는 기본 클러스터 구성외에도 정말 많은 Third Party를 가지고 있습니다.여러 Third Party를 활용하여 Sample 클러스터 구성을 준비했습니다.현재 클러스터 현황을 Cursor AI에게 Mermaid Chart Code로 만들어달라는 요청을 받은 결과 값입니다.해당 결과를 코드로 복사하여 Mermaid Chart 홈페이지에서 편집해보겠습니다.1. 먼저 Meremaid Chart 홈페이지를 이동하고 구글 계정으로 로그인합니다.• None Free Trial의 경우 3개 정도의 chart를 저장 할 수 있습니다.2. 편집기에 코드를 복사합니다.3. 현재는 다이어그램이 보기 쉽지 않습니다.- 디자인 컨셉을 변경하여 diagram을 변경 할 수 있습니다.4. 스타일을 편집하고 Adaptive 모드로 배치를 변경했습니다.이제 SVG 혹은 PNG 형식으로 Export까지 진행하면 발표 자료 혹은 시스템을 전달 할 수 있는 최종본 추출이 가능해집니다.이제 머리속에 있는 아키텍쳐를 IaC 코드를 기반으로 만든 Mermaid Chart 코드를 통해 편하게 편집하고 보여주시기 바랍니다.

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 발표 내용AI/ML 분산 처리 프레임워크인 Ray를 활용하여 GPU Util 100%를 달성한 배치처리 기법과 확장 가능한 모델 서빙 아키텍처를 소개합니다.발표 대상배치 파이프라인 설계와 모델 서빙 자동화를 담당하는 분Ray 기반 인프라 운영 및 GPU 클러스터 관리 업무를 수행하는 분Ray Serve를 활용해 고성능 모델 서빙 API를 설계·배포·운영하는 분Ray LLM(vLLM) 기반 LLM 추론 파이프라인을 구성·확장하고, 내부 모델 레지스트리를 연동하는 분목차Introduction to Ray Ray에 대한 소개 및 Core Architecture에 대한 이해Ray Data: GPU Util 100% Bach Inference를 위한 수난기 기존 구조와 도입된 구조 비교TroubleShooting 4건PipelineStep 추상 클래스 소개Ray Serve: 배치 + 서빙, 두 마리 토끼를 잡다 Offline Serving UseCaseGPU 자원 효율성 실험ModelInference, BaseDeployment 인터페이스 소개Ray LLM: ServeManager를 활용한 LLM 배포 (with vLLM) ServeManager 구조 소개TroubleShooting 4건Conclusion NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

Data Ontology 구축을 위한 기획 및 개발 진행 중이며 Engineering 관점에서 초기 데이터 구성 방법에 대해 공유하려고 합니다.Mart 데이터를 대상으로 했으며 여러 방법 중 Data Lineage 생성에 대해 말씀드리겠습니다.Data Ontology의 정의는 "특정 도메인(분야)에 존재하는 개체들, 그 개체들이 속한 개념(클래스), 속성, 그리고 개념 간의 관계들을 형식적이고 명시적으로 정의한 지식 표현 구조"입니다.정의를 정리해보면 도메인을 설명할 수 있는 모든 메타 데이터의 세계로 이해할 수 있습니다.데이터 메타화의 기준은 아래와 같이 표현할 수 있습니다.• None• None ex) '강민우'는 사람이라는 클래스의 인스턴스• None• None ex) A는 B의 자식이다, C는 D의 부분이다• None• None ex) 모든 고양이는 포유류다ETL 과정을 거치는 Mart Data 속성을 반영하여 Data Ontology를 생성을 위해 Data Description, Relationship, Lineage가 필요하다고 판단했으며해당 메타를 조합하여 도메인에 대한 새로운 속성을 생성과 insight를 발굴할 수 있을 것으로 보입니다.Data Lineage의 정의는 "데이터를 생성한 시점부터 소비되는 시점까지의 전체 흐름과 변화를 추적하는 정보"입니다.데이터 계보라고도 하며 정리하면 데이터의 출처, 변환 및 가공 과정, 목적지를 보여주는 데이터 흐름의 이력 추적 체계로 이해할 수 있습니다.Mart 데이터는 사용자가 요청을 위해 수많은 ETL 과정을 거칩니다.이때, 명확한 사용자 요청, ETL 쿼리가 존재한다면 Data Ontology의 속성 및 관계 생성 가능성이 높아집니다.Mart 데이터가 생성되는 과정을 간단한 예시로 표현한 것이며Mart 데이터 결과 값 (명확한 사용자 요청) "고객 서비스 내 주문량", "고객 서비스 접근 경로", ETL 과정에 대한 Data Lineage 만 주어진 상황입니다.• None 1번과 2번 과정을 서로 다른 Mart 데이터 생성 과정이며 결과적으로 서로 고객, 서비스 테이블을 이용한다는 것을 확인할 수 있습니다.• None 공통적으로 Table B, C를 이용한다면 B와 C는 고객과 서비스 중 하나이며 고객, 서비스가 연관되는 Mart 데이터를 생성해야하는 경우 B, C를 이용할 확률이 높다는 것을 알 수 있습니다.• None Table B, C는 1번과 2번 과정에 모두 사용되었기 때문에 주로 함께 사용될 확률이 높다고 할 수 있습니다.• None 1번 과정의 ETL 노드들은 "주문량" 관계로 볼 수 있습니다.• None 2번 과정에서 Table D를 사용했으며 결과에 "접근 경로"가 있는 것으로 보아 D에는 경로에 대한 데이터가 포함되어 있을 확률이 존재하며 D의 속성이 "이용 내역"이 아닌 "사용자 이력"이 될 수도 있습니다.본 데이터를 활용하여 ETL 최적화, 업무 속도, 마케팅 및 AI 사업 향상을 기대할 수 있을 것으로 예상합니다.Data Lineage는 Table, Column 레벨로 나누어집니다.• None 본 블로그에서는 Table Lineage 추출 방법에 대해 다루겠습니다.Data Lineage 생성 도구들 중 JsqlParser, Open Lineage, Apache Atlas 에 대해 설명 드리겠습니다.• None 수 많은 쿼리가 이미 존재• None 누락 없어야하며 Job 재실행 시 영향도 큼• None 활용 방향성에 따라 Data Lineage 추출 및 변환 사항 변경 가능• None 쿼리 수정 후 Lineage 추출을 위해 연관된 모든 Job 실행하는 경우 없어야함위 사항을 고려하여 JsqlParser 사용하는 것으로 결정했으며 Big Data 파싱 가능하도록 추가 로직 생성했습니다.LLM을 활용하여 예시 쿼리를 준비했으며 해당 코드는 Table Level Lineage 추출을 위한 Spark의 Insert Overwrite Table 샘플 코드입니다.해당 코드는 Java 21을 사용했습니다.• None JsqlParser은 쿼리를 AST로 변경하며 쿼리의 세부사항을 모두 담고 있습니다.• None insertStatement에 디버깅했으며 위 이미지는 Insert Overwrite 하위 Select 문에 대한 AST입니다.• None JsqlParser 이용 시 sql을 지원하는 형식으로 변환해야 합니다(MySQL, Oracle, Big Query, Redshift, Snowflake 등).• None Spark 쿼리 파싱 경우 (java 로직 개발로 해결해야 합니다)• None SELECT문보다 FROM문이 먼저 나온 경우 -> WITH문이나 SELECT문 이후로 변경• None ".숫자" 명을 가진 테이블 및 컬럼 경우 -> backtick 추가• None ParseStatement 클래스에서 INSERT문의 target 테이블, InsertStatementParser 클래스에서 WITH문의 target 테이블과 FROM문의 source 테이블을 추출합니다.• None Result는 결과 DTO를 출력한 것이며 쿼리 내 source, target 테이블 리스트입니다.이상으로 Ontology 생성 과정 중 Table Level Lineage 생성 과정에 대해 알아보았습니다.해당 결과를 여러 방향으로 활용할 수 있을 것을 기대합니다.

**Processing-In-Memory(PIM)**은 메모리 내부에 연산 기능(프로세싱 기능)을 탑재하여, 데이터를 이동시키지 않고 메모리 안에서 직접 처리하는 기술입니다.즉, CPU나 GPU가 아닌 메모리 자체가 연산을 수행함으로써, 데이터 이동을 줄이고 처리 속도를 극대화하는 혁신적인 반도체 아키텍처입니다.여기서 먼저 알아야 할 내용이 바로지금까지 대부분의 컴퓨터는 폰 노이만 구조라는 구조를 사용해 왔습니다.이 구조는 프로세서(CPU)와 메모리(DRAM)가 분리되어 있고, 데이터는 메모리에서 CPU로 오가며 처리되는 구조입니다.이런 구조에서는 데이터가 증가할 때 큰 세가지 문제가 발생 할 수 있습니다.• None 병목 현상: 데이터를 메모리에서 CPU로 가져오는 데 시간이 증가• None 전력 소모: 데이터 이동에 많은 전력 소모• None 속도 제한: 연산보다 데이터 전송 속도 저하로 전체 시스템 속도 제약위와 같은 폰 노이만 구조는 요즘 같은 인공지능, 빅데이터 분석, 머신러닝 등 데이터를 실시간으로 많이 처리 해야하는 상황에서 심각한 성능 저하와 전력 소모가 발생하게 됩니다.이러한 문제를 해결하기 위해 PIM 반도체가 등장합니다.PIM은 말 그대로 메모리 내부에서 연산을 수행한다(Processing In Memory)는 개념입니다.기존에는 기존에는 메모리는 데이터를 저장하는 역할만 하고, 연산은 CPU가 담당했습니다.하지만 PIM은 메모리 칩 내부에 연산 기능을 통합하여, 데이터를 CPU로 보내지 않고도 메모리 자체에서 직접 계산을 수행할 수 있도록 작동하는 반도체입니다.PIM은 구현 방식은 크게 두 가지 방식으로 나눌 수 있습니다.• None 기존 메모리 칩 내부에 간단한 연산 유닛(ALU: Arithmetic Logic Unit)을 추가하는 방식입니다. DRAM과 같은 범용 메모리 칩에 작은 프로세서를 넣어 데이터를 읽고 쓰는 과정에서 간단한 연산을 수행합니다.*ALU(산술 논리 연산 장치, Arithmetic Logic Unit)는 컴퓨터나 반도체 시스템에서 덧셈, 뺄셈 같은 산술 연산과 AND, OR 같은 논리 연산을 수행하는 부품연산 로직을 메모리 셀 자체에 통합(In-Memory Computing):• None 더 나아가 메모리 셀 자체의 물리적 특성을 활용하여 연산을 수행하는 방식입니다. 예를 들어, 저항성 메모리(ReRAM)나 상변화 메모리(PRAM)와 같은 차세대 비휘발성 메모리(NVM)는 데이터를 저장하는 동시에 논리 연산을 수행할 수 있는 잠재력을 가지고 있습니다. 이 기술이 최종 PIM의 지향점이라고 할 수 있습니다.삼성전자, SK하이닉스와 같은 기업들도 HBM-PIM, GDDR6-AIM 등 독자적인 PIM 솔루션을 선보이며 기술을 선도하고 있습니다.또한 PIM은 메모리나 프로세서의 성능 개선과 컴퓨터 아키텍처의 근본적인 변화를 가져올 수 있습니다.