안녕하세요. Security R&D 팀에서 FIDO2 클라이언트 개발을 담당하고 있는 김도연, 김영현입니다.공개 키 암호화를 기반으로 한 FIDO는 패스워드나 SMS OTP 인증과 비교했을 때 사용자 관점에서는 사용하기 쉽고 안전하며 서비스 관점에서는 배포 및 유지 보수하기 쉬운 인증 표준입니다. FIDO 관련 자격 증명은 사용자의 기기를 벗어나지 않고 서버에도 저장되지 않기 때문에 피싱(phishing)이나 모든 형태의 패스워드 도용 및 재전송 공격의 위험에서 벗 어날 수 있습니다.저희 회사는 2017년 FIDO 얼라이언스 이사진에 가입한 것을 시작으로 FIDO 서버의 상호 운용성 테스트 행사에 참여하는 등 FIDO와 관련한 여러 가지 이벤트에 참여했습니다. 그리고 2021년에는 서비스 제공 업체로서 전 세계 최초로 FIDO Universal Server 인증을 획득한 FIDO2 서버를 오픈소스로 공개했습니다. 이전에 패스워드 없는 세상으로의 첫 발걸음과 FIDO2 서버를 오픈 소스로 공개했습니다라는 글로 이와 관련된 내용을 소개했는데요. 이번 글에서는 새롭게 오픈소스로 공개하는, WebAuthn 표준을 따르는 FIDO2 클라이언트 SDK를 소개하려고 합니다. 클라이언트 측에서 FIDO2 인증을 구현할 때 이 SDK를 사용하면 더욱 쉽게 FIDO2 인증을 구현할 수 있습니다.패스워드 등의 지식 기반 인증(knowledge-based authentication)을 사용하는 기존 인증 기술을 대체하기 위한 새로운 인증 표준인 FIDO(Fast Identity Online)는 소유 기반 인증(possession-based authentication)을 활용한 인증 방식을 제안합니다.전통적인 인증 방식인 지식 기반 인증은 사용자와 서버가 사전에 설정해 공유한 지식을 기반으로 하는 인증 방식입니다. 사용자 입장에서는 패스워드와 같은 지식을 외우고 있어야 한다는 불편함이 있으며, 공격자가 사용자의 패스워드를 유추하거나 서버에 저장된 패스워드가 유출될 가능성이 있어 보안 사고에 매우 취약합니다.소유 기반 인증은 사용자가 소유하고 있는 기기를 기반으로 인증을 수행하는 방식입니다. FIDO의 인증 기술은 사용자의 기기를 인증기(authenticator)로 활용합니다. 사용자의 인증 정보(예: 생체 정보)는 기기에만 저장되고 서버에는 전달되지 않기 때문에 서버 입장에서는 보안을 한층 더 강화할 수 있습니다. 사용자는 패스워드를 기억할 필요가 없으며, 사용자만이 가지고 있는 정보를 통해 안전하고 쉽게 인증할 수 있습니다.FIDO1과 FIDO2의 차이는 다음과 같습니다.• FIDO1: FIDO1은 UAF(Universal Authentication Framework)와 U2F(Universal 2nd Factor)라는 두 가지 프로토콜을 포함합니다. UAF는 패스워드 없는 인증을 제공하는 프로토콜이고, U2F는 기존 패스워드 기반 인증에 보안 요소를 추가한 프로토콜입니다.• FIDO2: FIDO2는 FIDO1이 확장된 버전으로, WebAuthn(Web Au

안녕하세요. 여기어때컴퍼니 DevOps팀 루카스입니다. 저희 팀은 여기어때컴퍼니 Tech 조직내 개발자들의 업무 몰입을 위한 개발 환경과 체계를 만들어가는 조직으로 조직별로 상이한 개발 환경을 통합하고 운영하고 있습니다.Photo by Pankaj Patel on Unsplash이번에 다룰 주제는 팀에 합류하고 나서 첫 번째 작업이었던 GitLab 버전 업그레이드 과정입니다. GitLab은 소프트웨어 개발자에게 강력한 기능을 제공하는 형상 관리 플랫폼입니다. 하지만 최신 기능을 활용하고 보안 업데이트를 적용하기 위해서는 정기적으로 업그레이드를 해야 합니다. 우리 조직내 개발자들이 더욱 안전한 환경에서 신규 기능을 활용 할 수 있도록 저희팀은 GitLab을 업그레이드 하기로 결정하였습니다.1. 사전 준비1–1. Upgrade Path 확인GitLab의 현재 설치된 버전과 호환성을 확인합니다. 이런 경우에는 GitLab의 공식 문서에서 지원되는 업그레이드 경로를 확인하는 것이 좋습니다. https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/ 이 URL에서 현재 사용 버전, OS, 업그레이드 대상 버전 등을 선택하면 어떤 버전의 순서로 업그레이드를 해야하는지 알려 줍니다. 버전 변경에 대한 큰 변동사항에 대해서도 미리 경고해 줍니다.여기어때에서는 GitLab 15.1.6을 사용하고 있었으며, 16.9.4 버전으로 업그레이드를 진행하였습니다.15.1.6에서 16.9.4로 Upgrade Path는 다음과 같습니다.15.1.6 → 15.4.6 → 15.11.13 → 16.1.6 → 16.3.7 → 16.7.7 → 16.9.1Upgrade Path의 경고 마지막 부분에 Expiring Access Token 부분이 있었습니다. Gitlab PAT 관련 문서를 통해 추가로 확인해 보았습니다. https://docs.gitlab.com/ee/user/profile/personal_access_tokens.htmlNever Expire로 발급된 Personal Access Token은 모두 GitLab 16.0으로 업그레이드한 날짜로부터 1년 후에 만료 되도록 강제로 변경 됩니다. CI/CD Pipeline 자동화를 위해서 사용되는 토큰인 경우, 만료시 장애를 일으킬 수 있는 원인이 되기 때문에 사전 작업을 진행합니다.1) 기존 버전의 Personal Access Token의 만료일이 Never인 Token을 리스트업합니다.$ curl -s --header "PRIVATE-TOKEN: ${your_access_token}" "https://${gitlab url}/api/v4/personal_access_tokens" | jq '.[] | {id, expires_at}'결과 샘플은 다음과 같습니다.{ "id": 154, "name": "GITLAB-PAT", "expires_at": "2025-06-25"}your_access_token 은 admin 권한을 갖는 계정의 Personal Access

안녕하세요. 여기어때컴퍼니 SRE팀에서 클라우드 엔지니어링 업무를 하고 있는 제이슨입니다. 저는 오늘 조금은 특이했던 경험을 공유드리려고 하는데요, Docker를 이용해서 서비스하는 인스턴스의 CodeDeploy 배포 실패를 Troubleshooting하는 과정에서 겪은 일입니다.회사마다 다르긴 하지만 일반적으로 AWS 환경에서 배포할 때는 아래와 같은 방법으로 하게 됩니다.AWS 환경에서의 일반적인 배포 프로세스1. 사건의 시작평화로웠던 어느 오전… 갑자기 TargetGroup의 인스턴스가 unhealthy 상태로 되었다고 슬랙 모니터링 채널에 알림이 올라왔습니다. 이제 어떤 문제가 있는지 인스턴스를 확인해 봐야겠네요.2. 문제 해결을 위한 체크 리스트 확인인스턴스 확인우선 인스턴스가 On-Demand 혹은 Auto Scaling으로 구성되었는지를 확인 합니다. 문제의 인스턴스는 Auto Scaling으로 구성되어 있었고 TargetGroup의 Health Check 실패로 인해 Auto Scaling 정책에 따라 인스턴스 교체가 반복되는 상황이었습니다.2. CodeDeploy 상태 확인1번 확인으로 CodeDeploy에서 이력을 확인해보니 배포 실패가 반복되고 있었습니다.CodeDeploy의 배포 과정 중 어떤 부분에서 문제가 있었는지 자세히 확인해 보니 ValidateService 단계에서 TimeOut으로 실패했네요.CodeDeploy의 ValidateService 단계에서 발생한 문제를 확인하기 위해서는 CodeDeploy 배포 프로세스를 알아야 할 필요가 있습니다.담당 개발자에게 문의할 수도 있지만 Jenkins에서 Build 후 업로드된 xxxx.tar.gz 파일을 S3 버킷에서 다운로드하여 압축을 풀게되면 아래 그림에서 보는 것처럼 CodeDeploy 배포 프로세스를 정의하는 appspec.yml 파일을 확인할 수 있습니다.CodeDeploy 배포 프로세스CodeDeploy에서 확인한 것과 같이 AfterInstall 단계까지 정상적으로 수행 되었지만 ValidateService 단계에서 문제가 발생한 것으로 보입니다. 그렇다면 이전 단계에서 문제가 발생했을 가능성이 큽니다. AfterInstall 단계를 점검해 보니 Docker를 사용해서 Application을 서비스한다는 것이 확인되네요.[root@ip-xx-x-xx-xxx ~]# cat appspec.ymlversion: 0.0os: linuxfiles: - source: / destination: /home/xxxx/deploy/xxxxxx-api/temppermissions: - object: /home/xxxx owner: xxxx group: xxxx mode: 775hooks: BeforeInstall: - location: BeforeInstall.sh timeout: 60 AfterInstall: - location: AfterInstall.sh timeout: 60 ApplicationStart

오픈소스 AI Platform인 Kubeflow를 도입 후 Pipeline 쪽 기능을 주로 사용하면서 얻은 경험, 느낀점을 적어 보려고 합니다.Kubeflow는 Kubernetes 상에서 머신러닝(ML) 워크플로우를 구축하고 배포하기 위한 오픈소스 플랫폼입니다.이름에서 알 수 있듯이, Kubeflow는 'Kubernetes'와 'TensorFlow'를 결합하여 탄생했으며,원래는 Google이 Kubernetes에서 TensorFlow 작업을 원활하게 수행할 수 있도록 개발했습니다.현재는 다양한 머신러닝 프레임워크를 지원하며, Kubeflow는 ML 모델의 개발, 훈련, 배포 및 관리에 필요한 모든 요소를 통합하여 제공합니다.Kubernetes의 이점을 머신러닝에 통합Kubeflow는 Kubernetes의 확장성, 가용성, 관리 용이성을 활용하여 ML 워크플로우를 지원합니다.Kubernetes의 컨테이너 오케스트레이션 기능을 통해 ML 작업을 효율적으로 배포하고 관리할 수 있습니다.데이터 준비, 모델 training, 하이퍼파라미터 튜닝, 모델 serving 등 머신러닝의 전체 라이프사이클을 관리하는 통합 환경을 제공합니다.이를 통해 데이터 사이언티스트, 머신러닝 엔지니어, 데이터 엔지니어들이 협력하여 효율적으로 작업할 수 있습니다.모든 환경에서 일관된 운영Kubeflow는 클라우드, 온프레미스, 하이브리드 환경에서 모두 동일하게 동작하도록 설계되었습니다.이를 통해 특정 환경에 구애받지 않고, 동일한 ML 워크플로우를 구축하고 실행할 수 있습니다.다양한 머신러닝 프레임워크와 도구를 지원하여 사용자가 원하는 구성 요소를 선택하고 확장할 수 있도록 합니다.Kubeflow의 주요 구성 요소복잡한 머신러닝 워크플로우를 정의하고 자동화하기 위한 도구입니다.파이프라인을 구성하여 데이터 전처리, 모델 훈련, 검증 및 배포 등 일련의 작업을 순서대로 실행할 수 있습니다.파이프라인은 코드로 정의되며, 다양한 컴포넌트를 재사용할 수 있어 관리와 유지 보수가 용이합니다.학습된 모델을 Kubernetes 클러스터에서 실시간으로 서빙할 수 있는 기능을 제공합니다.이는 모델을 API 엔드포인트로 노출시켜 애플리케이션에서 쉽게 사용할 수 있도록 합니다.KFServing은 스케일링, 롤백, 모니터링 등의 기능을 통해 모델 서빙을 안정적으로 관리합니다.하이퍼파라미터 튜닝 및 자동 머신러닝(AutoML)을 위한 도구입니다.Katib을 사용하면 다양한 하이퍼파라미터 조합을 자동으로 탐색하여 최적의 모델 성능을 찾을 수 있습니다.TensorFlow 및 PyTorch와 같은 특정 머신러닝 프레임워크를 Kubernetes에서 실행할 수 있도록 지원합니다.이를 통해 대규모 분산 학습이 가능해지며, 클러스터 리소스를 효율적으로 사용할 수 있습니다.Jupyter Notebooks 환경을 Kubernetes에서 호스팅하여 데이터 사이언티스트가 브라우저를 통해 데이터를 탐색하고, 모델을 개발할 수 있도록 합니다.이러한 노트북 환경은 쉽게 확장 가능하며, Kubeflow의 다른 구성 요소

LLM-as-a-Judge는 생성된 데이터셋과 실제 데이터셋을 비교하여 평가하고, 이를 통해 모델의 응답 품질을 지속적으로 개선하는 평가방식입니다.LLM-as-a-judge로 Chatbot Arena를 MT-bench 방식으로 LLM 평가 결과논문에 따르면 MT-bench의 전문가 투표와 Chatbot Arena에서 수집된 크라우드 투표 결과를 비교했을 때GPT-4 judge와 사람의 선호의 일치도가 80% 이상으로, 사람간의 평가와 유사한 성능을 보여 관심을 갖게 되었습니다.(https://arxiv.org/abs/2306.05685)LLM-as-a-Judge는 대형 언어 모델(LLM)을 평가하고 개선하기 위한 방법으로, 사람이 평가하는 것처럼 LLM이 다른 모델의 출력을 평가하는 방식입니다.이 접근법은 다음과 같은 장점을 가지고 있습니다:• None 스케일러빌리티: 사람이 직접 평가하는 데 드는 시간과 비용을 절감할 수 있습니다. 이를 통해 대규모 평가 작업을 보다 효율적으로 수행할 수 있습니다• None 설명 가능성: LLM이 제공하는 평가 결과는 이유와 함께 설명될 수 있어, 평가 과정이 투명하고 이해하기 쉽게 됩니다• None 인간 선호도와의 일치: LLM을 사용한 평가가 인간의 평가와 높은 일치율을 보이므로, 신뢰할 수 있는 평가 결과를 얻을 수 있습니다LLM-as-a-Judge는 다음과 같은 과정을 거쳐 사용됩니다:• None 평가 기준 파악하기 - 먼저 hallucination, toxicity, accuracy 또는 기타 특성 등 무엇을 평가할지 결정합니다.• None 평가 프롬프트 작성 - 평가를 안내할 프롬프트 템플릿을 작성하세요. 이 템플릿은 출력을 효과적으로 평가하기 위해 초기 프롬프트와 LLM의 응답 모두에서 필요한 변수를 명확하게 정의해야 합니다.• None 평가 LLM 선택 - 특정 평가를 수행하기 위해 사용 가능한 옵션 중에서 가장 적합한 LLM을 선택합니다.• None 평가 생성 및 결과 보기 - 데이터 전체에서 평가를 실행합니다. 이 프로세스를 사용하면 수동으로 주석을 달 필요 없이 포괄적인 테스트를 수행할 수 있으므로 신속하게 반복하고 LLM의 프롬프트를 구체화할 수 있습니다.이 방법은 특히 RAG(질문 응답 생성) 시스템의 평가에도 유용하게 사용될 수 있습니다.https://huggingface.co/learn/cookbook/llm_judge를 따라 한번 적용해 봅니다.1. 사람의 평가 데이터 세트 생성첫 번째 단계는 30개 정도 예제에 대해 사람의 평가 데이터 세트를 만듭니다.각 질문/답변 커플에 대한 2개의 인간 평가와 점수를 포함하는 피드백QA 데이터 (https://huggingface.co/datasets/McGill-NLP/feedbackQA)를 사용합니다.두 사람의 평가자가 부여한 점수의 피어슨 상관관계로 측정한 두 평가자 간의 일치도를 보면 0.53이 나옵니다.이를 해결하기 위해 ratings.loc[ratings["score_1"] == ratings["score_2"]] 인 동일한

yun.cheese 코틀린 매력에 푹 빠진 개발자의 생생한 경험을 통해, 실제 서비스 개발에 바로 적용할 수 있는 코틀린 활용 꿀팁들을 얻어가세요!noah.you 복잡한 보험의 요구사항들을 해결하기 위한 이유 있는 코틀린 사용 사례! 좋은 사례들 많으니 많이 보고 가세요!ari.a 카카오페이에서는 왜 서비스의 백엔드를 개발할 때 코틀린을 사용하는 걸까요? 궁금하신 분들에게 카펀의 코틀린 사용 사례를 추천드립니다!안녕하세요. 카카오페이 보험마켓파티에서 보험 비교 추천, 내 차 관리 서비스 등을 개발하고 운영하는 카펀입니다.여러분은 어떤 언어를 사용하여 개발을 하고 계신가요? 카카오페이에서는 저희 보험 서비스를 비롯한 다양한 서비스의 백엔드 서비스 개발에 코틀린을 사용하고 있습니다.카카오페이에 합류하기 전에는 코틀린을 경험해 본 적이 없었지만, 실제로 사용하면서 코틀린의 다양한 장점과 편리함에 매료되었습니다. 예를 들면 다음과 같은 코틀린의 매력이 있습니다.• 코틀린을 사용함으로써 서비스를 보다 견고하고 안정적이며, 효율적으로 운영하고 있습니다.• 특정 도메인에 대한 내용을 쉽게 모아서 관리하거나, 저희 서비스만을 위한 라이브러리를 간편하게 만들었습니다.• 목적과 대상이 명확한 테스트 코드 작성 역시 코틀린을 통해 손쉽게 작성하였습니다.카카오페이에 합류해 코틀린으로 여러 서비스를 개발하고 운영하면서 직접 경험한 코틀린의 매력을 소개해 보고자 합니다. 여러 매력 포인트 중 코틀린의 4가지 매력 포인트를 정리했습니다. 저와 마찬가지로 안정적인 웹 서비스 개발에 관심 있는 백엔드 개발자 분들이 읽어 보시면 좋습니다.생성 시 값이 검증되는 객체 만들기어떤 값을 나타내는 VO1를 만들 때, 이따금 입력 값을 변환하거나 검증이 필요한 경우가 있습니다. 검증 로직을 별도 클래스로 분리할 수도 있지만, 매번 별도로 검증 로직을 호출해야 한다면 실수로 검증을 누락할 가능성이 있습니다. 코틀린의 다양한 기능을 활용하여 간결하면서도, 검증을 통과하였음이 보장되도록 작성하는 예시를 소개합니다.자동차 번호를 나타내는 VO가 있습니다. 코틀린의 Value Class를 사용합니다.Value Class는 코틀린에서 값을 나타내기 위한 wrapper 클래스입니다. 단 하나의 불변 필드만을 가질 수 있고, JVM 환경에서 컴파일 시 class를 벗겨 내고 내부의 값으로 대체합니다. 덕분에 primitive 타입의 값을 객체와 같이 다룰 수 있으며, 동시에 wrapper 클래스 사용 시의 오버헤드 문제를 해결할 수 있습니다. 자세한 내용은 Reference의 Project Valhalla 내용을 확인해 주세요.자동차 번호에는 아래와 같은 규칙이 있다고 가정하겠습니다.• 자동차 번호 형식은 아래 중 하나여야 함인스턴스 생성 시, 아래 과정을 거치고 싶습니다.• 지역명은 주어진 목록 내에서만 사용 가능(서울, 경기, 대전 등등), 아닐 경우 예외 발생• 지역명이 없는 경우 앞 숫자는 2~3자리, 뒤 숫자는 4자리• 지역명이 있는 경우 앞 숫자는 1~2자리, 뒤 숫자는 4자리이를

이 글은 Perplexity(https://www.perplexity.ai/)와 함께 작성하였습니다.SKT고객은 Perplexicy Pro를 1년간 무료로 이용할 수 있습니다.: https://perplexity.sktadotevent.com/Elasticsearch는 오픈소스 프로젝트로 시작했으며, 그동안 여러 번의 라이선스 정책 변경을 겪었습니다.처음에는 Apache 2.0 라이선스 하에 배포되었지만, 2021년 Elastic은 Elastic License 2.0과 Server Side Public License로 라이선스를 변경했습니다.이후 2024년 8월 30일에는 다시 AGPL-3.0을 추가하는 발표(Elasticsearch is Open Source, Again)를 하면서 주목을 받고 있습니다.이러한 변화는 오픈소스 커뮤니티뿐만 아니라 이를 사용하는 기업들에도 큰 영향을 미치고 있습니다.이번 글에서는 Elasticsearch가 왜 다시 라이선스 정책을 변경했는지, 그리고 이를 사용하는 기업들이 어떻게 대응해야 하는지 살펴보겠습니다.1. Elasticsearch 라이선스 변경의 역사1.1 Apache 2.0에서 Elastic License 2.0으로의 전환Elasticsearch는 처음에 Apache 2.0 라이선스를 사용했으나, 2021년 1월 Elastic은 Elastic License 2.0과 SSPL로 전환했습니다.Elastic이 이러한 변화를 선택한 이유는 클라우드 제공자, 특히 AWS와의 경쟁 때문입니다.AWS는 Elasticsearch를 기반으로 한 자체 서비스를 제공하면서도, 이에 대한 기여나 비용 지불 없이 수익을 창출했기 때문에 Elastic은 이를 견제하고자 라이선스를 변경했습니다.Elastic License 2.0은 소스 코드를 공개하지만 상업적인 클라우드 서비스에서의 사용을 제한하는 라이선스로, Elastic의 기술적 자산을 보호하는 수단으로 활용되었습니다.AWS는 이에 대응해 OpenSearch 프로젝트를 시작하며 Apache 2.0 라이선스를 계속 유지했습니다.이에 대해서는 이전 블로그, “Elastic License 2.0 그리고 진화하는 오픈소스 라이선스“에서 자세히 다룬 바 있습니다.1.2 Elastic License 2.0는 오픈소스 라이선스가 아니다그러나 Elastic License 2.0은 **Open Source Initiative (OSI)**에서 인정하는 오픈소스 라이선스가 아니었습니다.이는 오픈소스 커뮤니티에서 논란을 불러일으켜습니다.Elastic의 결정은 오픈소스의 자유로운 사용과 상업적 이익 사이에서 갈등을 불러일으켰고, 기업들이 오픈소스를 도입할 때 라이선스 문제에 대한 경각심을 높이는 계기가 되었습니다.2024년 8월, Elastic은 GNU Affero General Public License v3 (AGPL-3.0)를 Elasticsearch와 Kibana의 무료 부분에 대한 라이선스 옵션으로 추가한다고 발표했습니다.AGPL-3.0은 네트워크를 통한 소프트웨어 사용에 대해서

Amazon SageMaker는 머신러닝 모델을 더 쉽게 구축, 훈련, 배포할 수 있도록 지원하며 데이터 준비부터 모델 배포까지 일련의 과정을 효율적으로 처리할 수 있게 도와주는 서비스입니다.일반적으로 Sagemaker로 배포한 모델은 API Gateway와 Lambda를 이용해서 외부에 serverless로 서빙할 수 있는데요, SageMaker Endpoint를 서빙하는 자세한 방법은 여기 를 참고하시기 바랍니다.위 방법으로 모델을 서빙하면 모델의 응답이 끝날 때까지 기다렸다가 응답을 돌려주게 됩니다.LLM을 서빙할 경우 모델의 특성상 응답 생성 시간이 오래 걸릴 수도 있는데, 만약 모델의 응답을 토큰 단위로 streaming 하려면 어떻게 해야할까요?AWS 에 따르면 현재 API Gateway는 응답 스트리밍 기능을 지원하지 않고 있습니다.따라서 응답을 스트리밍하기 위해 API Gateway 대신 Lambda의 Function URL을 사용해야 하며, 람다함수는 Node.js로 구현해야 합니다.추가로, Lambda Function URL은 호출 시 sigV4 인증이 필요하며, 이를 우회하려면 CloudFront에 Origin Access Control을 붙여서 사용해야 합니다.본 블로그에서는 예시로 S3에 저장된 모델을 배포하는 코드를 작성해보았습니다.아래 코드는 SageMaker Studio 환경에서 돌아가는 것을 가정합니다. (로컬 python 환경에서 돌리려면 몇 가지 패키지만 더 import 해주시면 됩니다. )이 외에도 HuggingFace Hub등 다양한 source에서 모델을 가져와 배포할 수 있습니다.이제 위 엔드포인트를 호출하고 클라이언트로 응답을 전송하는 Lambda Function을 생성해야 합니다.AWS 콘솔에서 아래 단계를 거쳐 스트리밍 처리가 가능한 Lambda Function를 생성합니다.생성된 Lambda Function 함수 개요에서 함수 URL을 Copy 합니다.이제 실제로 SageMaker Endpoint를 호출하고 응답을 스트리밍 처리하여 클라이언트로 전송하는 Lambda Function 코드를 작성합니다.응답을 스트리밍하려면 node.js를 사용해야 하고, 일반적인 handler가 아닌 streamifyResponse() 디코더를 사용해 핸들러를 작성해야 합니다.다음으로 Lambda Function URL 호출 시 sigV4 인증을 우회하기 위해 CloudFront를 생성하고 이를 위에 생성한 Lambda 함수와 연결합니다.여기를 참고해서 CloudFront OAC 를 생성하고 배포하세요.배포가 완료된 CloudFront의 도메인을 복사해서 호출 테스트에 활용합니다.호출 시에는 request 헤더에 payload의 sha256 해시를 필수로 포함해야 하며, payload에 "stream":true 옵션을 넣어주어야 응답을 스트리밍할 수 있습니다.호출 결과를 보면 로 응답 결과를 토큰 단위로 가져오는 것을 볼 수 있습니다.Amazon SageMaker는 강력한 MLOps 기능 등을 제공하며, LL

일본에서 처음 만나는 여기어때, 브랜드의 글로벌 확장 이야기🌟여러분, 여기어때 재팬을 아시나요?여기어때가 해외여행 부문을 확장하기 위해 올해 여기어때의 첫 해외법인 <여기어때 재팬>을 설립했는데요! 다들 아셨나요? 🎉일본에서 여기어때의 새로운 시작을 공표하기 위해 지난 5월 30일에는 도쿄 시부야에서 사업설명회를 열었어요. 현지 파트너사에게 여기어때 재팬의 설립 배경, 목적, 그리고 사업 전략들을 알리는 자리였는데요.여기어때의 첫 해외 데뷔 전인 만큼, 함께 준비하는 여러 팀들이 각자의 사이드에서 고민이 깊었습니다.그중 저희는 행사장 곳곳에서 경험하는 모든 요소들을 어떻게 ‘여기어때스럽게’ 보여줄지, 행사의 전반적인 디자인 콘셉트을 잡는 것이 가장 중요했어요.이번 글에선 해외 시장에 진출한 여기어때 재팬의 모습과 오픈 세리머니 현장을 자세히 소개하고자 합니다!여기어때 재팬 로고 디자인 특징여기어때 재팬 로고 디자인일본 법인을 소개하기 위해 가장 먼저 필요한 디자인 작업은 일본어 버전의 여기어때 로고를 만드는 것이었어요. 여기어때는 한글로 만들어진 워드마크 형식의 로고로, 여기어때 재팬 로고도 동일하게 워드마크 형식으로 제작하게 되었어요.일본어 로고를 만들 때, 기존 국문 로고를 단순히 번역하는 것이 아닌 현지화(Localization)한 디자인에 특히 공을 들였는데요. 여기어때 로고의 형태적 특징인 둥근 획의 시작과 직선으로 끝나는 반원기둥 형태와 둥근 꺾임을 글자 디자인에 적용했고, 로고 끝에 있는 마침표 온점(.)은 일본에서 사용하는 마침표 표기법 특징인 고리점(。)으로 작업해 디테일을 살렸습니다.여기어때 재팬 시그니처신규 일본어 로고를 제작하면서 그에 맞는 브랜드 시스템과 시그니처도 추가 개발했어요.다양한 형태의 시그니처는 로고 외에도 ‘여기어때 오리지널’을 나타내기 위한 그래픽 수단으로 활용하는데요. 여기어때 비즈니스를 직관적으로 보여주는 앱 아이콘과 일본어 로고를 결합한 대외용 대표 시그니처와 브랜드가 전하는 첫인사를 표현한 <はじめて>를 더한 메시지 결합형 시그니처까지 두 가지 버전을 제작했습니다.이 외 브랜드 컬러나 브랜드 그래픽 모티프, 사용 폰트 등 디자인 시스템은 기존의 여기어때 브랜드 시스템을 연결하여 여기어때와 여기어때 재팬의 일관된 브랜딩을 지속했습니다.はじめて、ヨギオテ!はじめて、ヨギオテ!여기어때 재팬의 오프닝 행사 타이틀 메세지는 첫인사를 건네는 ‘はじめて(하지메떼)’에요. 👋어떤 일을 처음 시작할 때 또는 경험할 때 쓰는 ‘はじめ(하지메)’라는 표현을 활용해, 첫 만남, 첫 시작, 첫 경험의 의미를 중의적으로 담았습니다. 이번 행사를 통해 인상적인 첫인사를 건네고, 좋은 인연이 시작됐으면 좋겠다는 의미를 전달했어요.이러한 의미를 함축적으로 표현할 수 있는 디자인 콘셉트를 잡고, 이를 바탕으로 행사의 톤 앤 매너와 무드의 비주얼을 정립했습니다.한국과 일본 여행을 연결한국과 일본의 여행을 연결하는 ‘여기어때’타이틀 메세지가 전달하고자 하는 의미를 행사의 디자인 컨셉으로도 연결했는데요. 한국과 일본의 여행을 연결하는

들어가며안녕하세요, PBO(Platform Business Operation)에서 MUSINA WMS(이하 MWMS)를 개발하고 있는 백엔드 엔지니어 임상진입니다.무신사는 빠른 배송과 반품, 오프라인과 글로벌 시장 확대를 위해 물류 시스템 개선에 몰두하고 있습니다.과거 2023년까지 총 4개 물류센터에서 2가지의 상이한 외주 솔루션을 사용해 운영되고 있었습니다.그림1. 3D 소터(자동 분류 설비)물류센터를 운영하기 위해서는 WMS라는 시스템이 필수적인데요. 우리가 사용하던 외주 솔루션은 내재화된 시스템이 아니었기 때문에 시시각각 변경되는 요구사항에 즉각 대응하거나 비즈니스를 확장하기에 매우 불리했습니다. 특히 일부 기능은 MUSINSA OMS(이하 MOMS)에 개발되어야만 했습니다.잠깐, WMS와 OMS가 뭘까요?WMS는 Warehouse Management System(창고 관리 시스템)의 약자로, 창고나 물류센터에서 재고 관리, 입출고, 작업 계획, 자동화 설비, 자재 배치 등을 효율적으로 관리하기 위해 사용하는 시스템입니다.OMS는 Order Management System(주문 관리 시스템)의 약자로, 주문을 관리하고 처리하는 시스템입니다. 주로 커머스나 물류, 유통 등에서 사용되며, 제품 주문의 수집부터 출하, 배송, 재고 관리까지 모든 단계를 추적하고 최적화하는 역할을 합니다.따라서, 무신사는 빠르고 유연한 신규 비즈니스 확대를 목적으로 작년부터 MWMS 개발을 시작했고, 현재 무신사의 모든 first-mile 인프라를 MWMS로 전환했습니다.MWMS 개발 배경그림2. MWMS 로고MWMS 프로젝트는 구체적으로 아래 문제를 해결하기 위해 시작되었습니다.하나, 빠른 비즈니스 확장 불가.외주 솔루션은 필요한 기능을 적시에 지원하지 못하고, 성능 문제로 작업 효율이 매우 떨어졌습니다.신규 비즈니스나 자동화 설비 도입 시 개발 및 일정 조정에 시간이 오래 걸리며, 데이터 분석 및 의사결정에 필요한 정보를 적시에 제공받지 못했습니다.둘, 비용 절감.무신사의 자체 WMS가 없어 운영사를 중간에 거쳐야 했으나, 자체 시스템이 있다면 비용을 큰 폭으로 절감할 수 있습니다.3개월의 남은 작업 일정신규 WMS 개발 프로젝트가 기획된 이후, 수개월간 개발을 진행했으나 담당 개발자의 잦은 업무 변경과 불명확한 작업공수 산정 등의 이유로 개발 완료 일정이 여러 차례 지연되었습니다.어떤 이유로든 시간은 우리를 기다려주지 않습니다. 기존 운영사의 계약 만료 시점이 벌써 임박했습니다. 이에 따라 개발 완료일정 또한 단 3개월 앞으로 다가왔으나, 진척도는 20% 수준이었습니다.급한 대로 개발자 채용을 시작했지만, 당장 필요한 인원을 빠르게 모으기는 어려웠기에 TF를 구성했고 저 또한 이때 투입되었습니다.프로젝트의 성공을 위한 액션 아이템에 앞서, 팀에서 의지를 다지며 얘기했던 내용을 원칙으로 정리하면 아래와 같습니다.1. 단기 목표 중심적으로 일하자.2. 할 수 있는 만큼 해내자.3. 오버 커뮤니케이션하자.그리고 실천한 액션.먼저 첫 번째 원칙에 따라 우리