Abstract The project involves developing a converged application server that acts as a bridge between HTTP-based microse...

최근 GPT-4와 같은 대규모 언어 모델(large language model, 이하 LLM)의 사용이 보편화되면서 이를 활용한 애플리케이션이 활발히 개발되고 있습니다. 예를 들어 24시간 영어 선생님 역할을 하는 애플리케이션이나 고객 서비스 문의에 사람처럼 답변하는 애플리케이션과 같은 방식으로 LLM은 우리 생활 곁으로 가까이 다가오고 있습니다.그러나 이러한 LLM 기반 애플리케이션을 직접 개발해 상용 서비스화하는 것은 여전히 어려운 과제입니다. 만능처럼 보이는 LLM은 그저 현재 문맥을 파악한 뒤 확률에 따른 답변을 생성해 그럴듯한 응답을 제공하는 데 집중하기 때문에 엉뚱한 답변 등으로 서비스 품질이 떨어지는 것을 막으려면 여러 가지 기술을 적용하는 복잡한 과정이 필요하기 때문입니다.LLM이 유의미한 답변을 제공하도록 개발하기 위해서는 데이터셋 준비, 모델 학습, 배포 등의 절차가 필요합니다. 즉, 원하는 도메인에 해당하는 데이터셋을 수집하고 이를 LLM이 학습할 수 있는 형태로 가공해야 하며, 모델을 학습하고 평가할 수 있는 환경을 구축해야 하고, 완성된 모델을 사용자가 문제없이 활용할 수 있도록 안정적으로 배포하고 모니터링해야 합니다.이러한 과정을 효율적으로 관리할 수 있도록 지원하는 것이 바로 이번 글에서 다룰 LLMOps의 역할입니다. LLMOps는 전반적인 LLM의 라이프 사이클을 관리하면서 데이터 사이언티스트와 소프트웨어 엔지니어가 원활히 협업할 수 있도록 돕는 역할도 수행합니다.최근 LLMOps는 LLM 학습과 배포뿐 아니라 프롬프트 엔지니어링과 에이전트 제작, 종합적인 테스트 환경까지 더 넓은 범위를 포함해 지원하기 시작했습니다. 이는 관리가 필요한 도메인이 LLM 자체뿐 아니라 LLM 애플리케이션 제작에 꼭 필요한 컴포넌트들까지로 확장됐기 때문입니다. 따라서 LLMOps는 이제 모델 관리를 넘어 LLM 애플리케이션의 전체 워크플로를 지원하는 방향으로 정의가 변화하고 있습니다.MLOps와의 차이점은 무엇인가요?그렇다면 LLMOps는 머신 러닝 개발의 워크플로를 지원하는 MLOps와는 어떤 차이가 있을까 요? 아래는 일반적인 LLM 애플리케이션의 기본적인 추론(inference) 과정입니다.LLM 애플리케이션은 ML 추론 과정과 같이 입력, 전처리, 모델(모델에 질의하는 과정), 후처리 순서로 추론하지만, 그 과정에 RAG(Retrieval-Augmented Generation, 검색 증강 생성)와 프롬프트 엔지니어링 등 LLM만의 복잡한 과정이 추가됩니다. 이런 부분에서 MLOps와 차이가 있다고 할 수 있습니다.그뿐만 아니라 모델을 평가하는 방식에도 차이가 있습니다. ML에서는 0 혹은 1로 평가하거나 일정 기준에 따른 점수로 표현되는 지표를 통해 평가하는 방식을 사용하는데요. LLM은 답이 숫자 형태가 아니라 자연어 형태로 나오기 때문에 답변의 유창성이나 관련성, 일관성 같은 사람의 개입이 필요한 평가 항목이 추가로 존재합니다. 따라서 LLMOps는 사람이 결과를 쉽게 평가할 수 있는 환경을 함께 제공해야 합니다.이

macOS나 Windows에서 Ubuntu VM 사용하고 싶으신 적이 있나요?ㅎㅎ저는 은근 자주 있는데요. 이럴 때 Multipass를 사용하면 빠르고 간단하게 Ubuntu VM을 생성할 수 있습니다.Multipass는 macOS, Windows, Linux에서 사용할 수 있습니다.공식 홈페이지에서 다운로드 받아 설치할 수 있습니다.어플리케이션을 활용한 Multipass로 Ubuntu VM 생성과 관리Multipass의 GUI 어플리케이션을 사용하면 클릭 몇 번으로 간단하게 Ubuntu VM을 생성할 수 있습니다.Multipass 애플리케이션을 실행합니다.애플리케이션을 실행하면 아래와 같이 사용가능한 Ubuntu 이미지를 보실 수 있습니다.원하는 버전의 Ubuntu 이미지를 선택하여 "Launch" 버튼을 눌러 기본 설정으로 새로운 VM을 생성할 수도 있고,VM을 세부 설정을 하고 싶으시다면 "Launch" 옆의 "⚙︎" 버튼을 눌러서 세부 설정을 하실 수 있습니다.원하는 VM 이름과 리소스(cpu, memory, disk)를 지정합니다.위의 사진은 VM의 이름은 "custom-vm", 자원은 cpus는 2, memory는 4GiB, Disk는 50GiB로 하고 네트워크 브릿지를 설정한 예시입니다.(네트워크 브릿지가 기존에 설정이 되어있지 않다면, 라는 안내 문구가 나올 수 있습니다.이에 대해서는 아래의 Multipass 설정에서 다루겠습니다.)이제 "Launch" 버튼을 클릭하면 VM이 생성됩니다.1분 정도 기다리면 생성된 VM을 쉽게 사용할 수 있게 세팅이 됩니다. "Open shell"을 눌러 시작할 수 있습니다.좌측 사이드 바에서 Instances 에 들어가서 VM들을 관리할 수 있습니다.Instances에 들어가면 아래의 이미지처럼 VM들에 대한 상태와 정보를 볼 수 있고 실행과 중지, 삭제까지 모두 가능합니다.Multipass에 대한 설정도 좌측 사이드 바의 를 통해서 할 수 있습니다.위에서 진행하다가 라는 문구로 네트워크 브릿지를 선택해야한다면 아래처럼 설정할 수 있습니다.명령줄을 통한 Multipass로 Ubuntu VM 생성과 관리먼저, Multipass를 통해 현재 사용 가능한 이미지를 확인합니다.사용 가능한 이미지를 확인한 후, 아래와 같은 명령어를 통해 VM을 생성할 수 있습니다.그럼 현재 가장 최신 버전의 Ubuntu LTS를 사용하고 memory 2G, disk 10G, cpu 2 를 가지는 이라는 이름의 VM을 만들어 봅시다.명령어 이후에는 기본적으로 VM이 시작되어 있습니다.그렇기 때문에 종료하는 법을 먼저 익혀보도록 하겠습니다. 종료는 아래의 명령어를 통해 할 수 있습니다.를 해보면 정상적으로 이 Stopped 상태가 된 것을 확인할 수 있습니다.그러면 시작은 어떻게 할까요. 종료 명령어로 유추할 수 있듯이 아래의 명령어를 통해 할 수 있습니다.VM을 삭제하고 싶을 때는 아래의 명령어를 사용하면 됩니다.그런데 를 했을 때 아직 vm이 보이는 것을 발견할 수 있습니다.이 이유는 만 실행했을 때는 해당 VM 의

안녕하세요, 현대자동차 기초소재연구센터에서 근무하는 박상인 연구원입니다.사람들은 인공지능, LLM 같은 기술을 접할 때 내가 하기 귀찮은 일들을 알아서 해주기를 막연하게 기대합니다. 좋은 인공지능 모델은 좋은 데이터가 필요하다 라는 표현은 개발자에게는 상당히 직관적이고 고무적인 표현이지만, 인공지능을 개발하다 보면 데이터가 부족하다 라는 문제에 직면합니다.위의 그림은 Open-LLM의 대서막을 장식한 LLaMA(Large Language Model Meta AI)가 공개된 후 스탠포드 대학에서 알파카(Alpaca) 모델을 개발할 때 사용한 개발 모식도입니다. ChatGPT 3.5의 다빈치 모델로 주어진 명령(Prompt)에 맞는 데이터를 생성해서, 알파카(Alpaca) 모델(사전 학습 모델은 LLaMA 사용)의 학습 데이터로 사용했습니다. 이번 Tutorial에서는 LLM 모델 기반으로 특정 PDF 문서에서 질문과 답변을 자동으로 생성하는 내용을 다루고자 합니다. 이렇게 생성된 질문과 답변은 LLM의 학습용 데이터로 활용될 수 있습니다.RAG Tutorial #5 내용 시작합니다출처 : Stanford University Alpaca이번 Tutorial은 위 모식도의 학습 데이터 생성 부분을 최대한 비슷하게 구현하는 것을 목표로 합니다. 데이터를 생성할 PDF 문서의 EDA : 내용이 많을수록 좋은 정보가 있을 확률이 높음 Template를 활용한 Prompt 작성 : 컴퓨터가 이해할 수 있는 형태로 요구사항을 작성 LLM의 학습 데이터 생성 파이프 라인 정의 : 구성 요소의 결합을 통한 Chain 정의데이터를 생성할 PDF 문서는 2024 현대자동차 지속가능성 보고서 로 하려고 합니다.https://www.hyundai.com/content/dam/hyundai/ww/en/images/company/sustainability/about-sustainability/hmc-2024-sustainability-report-ko.pdf 에서 다운로드 받아 주시고, 현재 폴더( 상대 경로 : ./파일명 )에 저장하겠습니다.# Import 될 라이브러리는 아래와 같습니다.from langchain.document_loaders import PyPDFLoaderfrom langchain_community.chat_models import ChatOllamafrom langchain.prompts import PromptTemplatefrom langchain_core.output_parsers import JsonOutputParserfrom langchain_core.pydantic_v1 import BaseModel, Fieldimport jsonfrom langchain_core.output_parsers import StrOutputParserImplementation : 데이터를 생성할 PDF 문서의 EDA# 데이터를 생성할 PDF 문서의 EDAloader=PyPDFLoader("./hmc-2024-sustainability-report-ko.pdf") # 상대 경로 : ./파일명 docs=loader.load()num_char = []for i in range(0,len(docs)): num_char.append(len(docs[i].page_content))import matplotlib.pyplot as pltplt.hist(num_char,bins=50)plt.title('Number of characters per page of the document')plt.show()page_2000=[]for i in range(0,len(docs)): if len(docs[i].page_content)>2000: page_2000.append(i)print(f'해당 문서의 전체 페이지 : {len(docs)}')print(f'2000자 넘게 있는 페이지 : {len(page_2000)}')위의 코드는 PDF 문서를 불러와서 페이지의 글자수가 2000자가 넘는 페이지만 따로 기록해 놓는 코드입니다. 페이지 별 글자수를 시각화해서 확인해보면, 대부분의 페이지가 글자수 2000개를 넘는 것을 확인할 수 있습니다. 글자수가 많을수록 정보가 많고 생성할 데이터가 많을 것이다. 라는 가정으로 EDA를 진행했습니다. 문서는 총 125페이지로 이루어져 있고, 2000자가 넘는 페이지는 총 86개입니다. page_2000[0]를 통해서 2000자가 넘는 가장 첫번째 페이지에 접근할 수 있습니다.PyPDFLoader 클래스는 PDF 문서를 불러와서 한 페이지의 내용을 List의 개별 요소에 저장을 합니다. 이번 Tutorial에서는 페이지 마다 질문-답변을 n개씩 만드는 방식으로 구현할 예정이라 별도의 Chunking은 진행하지 않습니다. 따라서, 2000자가 넘는 페이지의 전체 내용이 Context로 LLM에게 제공됩니다.Implementation : Template를 활용한 Prompt 작성Tutorial #3에서 Prompt는 LLM이 어떻게 동작할지 사용자가 제어할 수 있는 일종의 틀(Template) 이라고 소개 드렸습니다. LLM에게 2000자가 넘는 페이지를 보고 스스로 질문-답변을 만들어 줘 라고 하면 될 것 같은데, 컴퓨터가 잘 알아들을 수 있는 형태로 전달해야 합니다. LLM의 출력을 제어하기 위해 다양한 요소가 조합된 Prompt 작성에 대한 내용을 소개합니다.# Template를 활용한 Prompt 작성class Topic(BaseModel): Question: str = Field(description="Answer always Korean. Questions created based on given context") Answer: str = Field(description="Answer always Korean. Answers based on generated questions")parser = JsonOutputParser(pydantic_object=Topic)prompt_template = """Answer always Korean. Generate ques

동일한 연산을 수행하면서 성능 하락이 없으면서도 추론 능력을 향상시키는 방안을 통해 모델 서빙을 수행합니다.배치 전략과 트랜스포머 연산, 추론 전략으로 나눠서 살펴봅니다.LLM 서빙에서 배치 전략은 모델의 처리량과 지연 시간을 최적화하는 데 중요한 역할을 합니다.• None 정적배치: 일반 배치로 고정된 크기의 배치가 채워질 때마다 처리하는 방식입니다. 입력 데이터를 배치할 때 한번에 N개 입력을 받아 모두 추론이 끝날때까지 기다리는 방식입니다. 지연 시간이 크게 증가할 수 있어 실시간 서비스에는 적합하지 않습니다.• None 동적배치: 동적 배치는 일정 시간 동안 들어온 요청들을 모아서 한 번에 처리하는 방식입니다. GPU 자원을 효율적으로 활용하여 처리량을 높일 수 있지만 배치 간격만큼 지연 시간이 발생합니다.• None 연속배치 : LLM에 가장 적합한 방식으로 연속 배치는 토큰 단위로 요청을 처리하며, 배치 크기를 동적으로 조절합니다. GPU 자원을 효율적으로 활용하는 방법으로 요청이 완료되는 즉시 결과를 반환할 수 있어 지연 시간을 줄일 수 있습니다. vLLM 등의 라이브러리가 사용됩니다.동일한 계산을 수행하더라도 메모리 사용량을 줄이고 속도를 높이는 트랜스포머 연산 기술을 이용하여 서빙 최적화를 수행합니다.• None 플래시 어텐션 (Flash Attention): 플래시 어텐션은 트랜스포머의 Self Attention 연산 시 발생하는 메모리 처리량 병목 현상을 해결하는 GPU 최적화 기법입니다. 어텐션 연산 과정을 변경해 학습 과정에서 필요한 메모리를 시퀀스 길이에 비례하도록 개선하여 HBM과 SRAM 사이의 I/O를 최소화하여 기존 방식보다 약 2배 이상 지연 시간을 줄일 수 있습니다. 역전파 과정에서 다시 순전파를 계산하는 방식으로 연산을 중복해서 실행하더라도 메모리 접근을 최소화하여 성능을 향상시킵니다.• None 플래시 어텐션2 : 플래시 어텐션에 2배 속도를 향상시킨 방식입니다. 알고리즘을 개선하여 softmax 등의 불필요한 연산을 제거하고 행렬곱 위주의 연산을 수행합니다. 시퀀스 길이 방향의 병렬화를 추가하였습니다.• None 상대적 위치 인코딩: 토큰의 절대적인 위치에 따라 임베딩을 더하는 방식이 아닌 토큰과 토큰 사이의 상대적인 위치 정보를 추가하는 방식입니다. RoPE, ALiBi 등이 있습니다.• None 커널퓨전: 반복적인 여러 개의 연산을 하나의 GPU 커널로 결합하여 오버헤드를 줄이는 최적화 기법입니다. 플래시 어텐션이 이 방법을 사용합니다.• None 페이지드 어텐션: OS의 가상 메모리 관리 기법을 LLM의 어텐션 메커니즘에 적용한 기술입니다. KV(Key-Value) 캐시를 페이지 단위로 관리하여 GPU 메모리 사용을 최적화합니다. GPU 메모리에서 KV캐시를 토큰 순서에 따라 바로 옆에 저장할 수 있도록 미리 예약합니다.• None 추론디코딩: 쉬운 단어는 더 작고 효율적인 모델이 예측하고 어려운 단어는 더 크고 성능이 좋은 모델이 예측하는 2개 모델을 사용하는 방식입니다. 작은 드래프트 모

안녕하세요. 모두싸인 제품그룹 Saas플랫폼팀 프론트엔드 엔지니어 노바(Nova)입니다.이번 포스팅에서는 모두싸인의 버전별로 격리된 배포 환경에서 발생하는 문제를 해결하기 위해 개발한 최신 버전 업데이트 기능에 대해 소개하려고 합니다. SPA(Single Page Application) 환경에서 유저들이 최신 버전을 안정적이고 빠르게 이용할 수 있도록 구현한 기술적 해결 방안과 개발 과정을 공유하겠습니다.📌 개발 배경버전마다 격리된 배포 환경모두싸인의 배포 환경은 React, Vite, AWS S3, CloudFront를 기반으로 구축되어 있으며, 새로운 버전을 배포할 때 구 버전과의 리소스 충돌을 방지하기 위해 버전별로 격리된 구조를 가지고 있습니다.예를 들어, 버전 1.0.0은 v1.0.0 디렉토리 하위에 배포되고, 버전 1.0.1은 v1.0.1 디렉토리 하위에 배포되는 식으로 각각 독립된 경로를 사용합니다.v1.0.0 ㄴ static ㄴ js ㄴ a.chunk.js ㄴ b.chunk.js ㄴ index.html v1.1.0 ㄴ static ㄴ js ㄴ a.chunk.js ㄴ b.chunk.js ㄴ index.html이 구조는 코드 분할(Code Splitting) 및 지연 로딩(Lazy Loading)으로 인해 최신 버전에서 구 버전의 청크(chunk) 파일을 가져오는 문제를 예방하고, 새로운 버전이 배포되더라도 이전 버전을 이용 중인 유저가 지속적으로 안정적인 서비스를 이용할 수 있도록 설계되었습니다.다음 이미지와 같이 3.100.0 버전을 이용 중일 때 새로 배포된 3.101.0의 리소스를 불러오지 못해 에러가 발생하는 문제를 해결할 수 있습니다.버전별 격리를 통해 최신 버전이 배포된 상황에서도 이용 중이던 3.100.0 버전 환경의 리소스를 사용할 수 있도록 합니다.버전마다 격리된 SPA 환경에서 발생하는 버전 문제그러나 버전이 격리된 배포 환경에서는 새로운 버전이 배포되었음에도 불구하고 유저가 계속해서 구 버전을 이용하는 문제가 발생했습니다. 그 이유는 SPA 환경의 특성상, 초기에 단 한 번만 index.html 파일을 불러오고, 해당 HTML 파일에 명시된 경로를 통해 필요한 리소스(CSS, JavaScript 파일 등)를 로드하기 때문입니다. 이후 웹 페이지를 이용하는 동안에는 추가적으로 HTML 파일을 다시 요청하지 않으며, 로드된 리소스들이 세션이 유지되는 동안 계속 사용됩니다. 따라서 유저가 새로운 index.html을 불러오기 전까지는, 새로운 버전의 웹 페이지가 배포되었더라도 유저의 브라우저는 초기에 로드된 구 버전의 리소스를 계속 참조하게 됩니다. 결과적으로 유저는 최신 업데이트나 수정 사항이 반영된 새로운 버전을 이용하지 못하고, 계속해서 구 버전의 애플리케이션을 이용하는 문제가 발생하게 됩니다.특히 모바일 브라우저의 특성상 유저가 탭이나 창을 닫지 않고 장시간 동일한 세션을 유지하는 경우가 더 많아 이 문제가 더 자주 발생했습니다.이러한 상황에서 유저는 다음과 같은 문

카카오가 제4회 전국 장애/비장애 대학생 창업경진대회에 후원사로 참여했습니다. "사람을 이해하는 기술로 필요한 미래를 더 가깝게"라는 카카오의 미션과 맞닿아 있는 행사를 후원할 수 있어 무척 뜻 깊은 일이었습니다.지난 2025년 2월 4일부터 7일까지, 부산 벡스코와 한화리조트에서 열린 이번 대회는 전국의 대학생들이 모여 혁신적인 아이디어를 펼치는 뜨거운 무대였습니다. 장애 학생과 비장애 학생이 한 팀을 이루어 지속가능한 성장(ESG) 모델의 웹/모바...

greg.ss 클라우드에 관심 있지만 시간이 없어 AWS re:Invent 2024를 살펴보지 못하셨나요? 그렇다면 직접 미국까지 다녀온 제이코와 아리가 보고 듣고 정리한 이 글을 추천드려요!shine.by 클라우드 컴퓨팅에 관심 있는 누구나 놓칠 수 없는 AWS re:Invent 2024의 최신 기술들을 쉽고 명확하게 접할 수 있는 글입니다. 앞으로의 개발 방향성에 대한 영감을 얻고 싶다면, 이 글을 통해 최신 기술 트렌드를 확인해 보세요!안녕하세요. 카카오페이 크레딧클랜에서 대출 플랫폼을 개발하는 제이코, 마케팅테크팀에서 프로모션 플랫폼을 개발하는 아리입니다. 저희는 카카오페이 기술 직군을 대표하여, 2024년 12월 2일부터 6일까지 미국 라스베이거스에서 열린 AWS re:Invent 2024에 다녀왔습니다.이번 행사에서는 생성형 AI 서비스인 Amazon Q, 맞춤형 AI 모델 구축을 지원하는 Amazon Bedrock, 분산형 데이터베이스인 Amazon Aurora DSQL, 대규모 데이터 분석을 위한 Amazon S3 Tables 등 다양한 기술이 소개되었습니다. 이 중에서, 제이코는 Amazon Aurora DSQL을 다룹니다. Amazon Aurora DSQL은 Multi-Region 및 Active-Active 기능을 지원하며 무제한 확장성과 높은 가용성을 제공하는 서버리스 분산형 SQL 데이터베이스입니다. 아리는 Amazon S3 Tables를 다룹니다. Amazon S3 Tables는 테이블 버킷을 이용한 새로운 데이터 관리 솔루션으로, 표 형식 데이터에 최적화된 Apache Iceberg 기반의 완전 관리형 테이블 형식 스토리지를 제공합니다.AWS re:Invent는 매년 클라우드 기술의 최신 트렌드를 한눈에 살펴볼 수 있는 중요한 행사입니다. 이번 글에서는 특히 Amazon Aurora DSQL과 Amaon S3 Tables와 같은 혁신적인 데이터베이스 기술을 다루는 만큼, 데이터베이스 관리와 데이터 분석에 관심 있는 분들에게 유익한 정보가 되길 바랍니다. 먼저, Amazon Aurora DSQL에 대해 살펴보겠습니다.안녕하세요, 카카오페이 크레딧클랜의 제이코입니다. 이번 AWS re:Invent 2024에서는 Amazon Aurora DSQL이 새롭게 소개되었습니다. Amazon Aurora DSQL은 사실상 무제한의 확장성과 높은 가용성을 제공하며 인프라 관리가 필요 없는 서버리스 분산 SQL 데이터베이스입니다. 이제부터, Amazon Aurora DSQL이 등장한 배경과 핵심 특징, 구성 요소 및 활용 방법에 대해 자세히 살펴보겠습니다.Amazon Aurora DSQL의 주요 특징을 살펴보기 전에, 먼저 이 기술이 등장하게 된 배경부터 살펴보겠습니다.AWS는 2014년에 Amazon Aurora를 출시했습니다. Amazon Aurora는 MySQL 및 PostgreSQL과 완벽하게 호환되면서 MySQL보다 5배, PostgreSQL보다 3배 높은 처리량을 제공합니다. 또한, 기존 상용 데이터베이스 대비 1/1

안녕하세요! 2025년 첫 포스팅은 OCR 관련 포스팅으로 돌아왔습니다.23년도말 OCR 서비스 비교평가 포스팅이 제 예상보다 많은 분들에게 사랑(?) 받아 얼떨떨했는데요약 1년이 지난 이 시점에, 좀더 어려운 난이도의 표와 손글씨가 혼재되어 있는 이미지의 데이터를 테이블화 시켜야 하는 Task를 수행하며 OCR서비스들을 다시 한 번 사용하게 되었습니다.그 중, 꽤 괜찮은 성능을 보여준 Google Cloud Vision API 사용법에 대해 차근차근 정리해보았습니다.OCR 관련 Google의 official documentation 에서 확인해보실 수 있습니다.저는 Colab 노트북 환경에서 진행했습니다.Google Cloud Vision API는 Google Cloud에서 제공하는 강력한 컴퓨터 비전 API로, 다양한 이미지 분석 기능을 지원하는 인공지능 서비스입니다.머신러닝 기반의 Vision 모델을 활용하여 이미지 속 객체, 텍스트, 라벨, 얼굴, 로고, 랜드마크 등을 자동으로 인식하고 분석할 수 있습니다.아래와 같이 여러 기능을 제공하고 있고, 저는 과 을 테스트 했습니다.• None 손글씨 인식 가능 (비정형 데이터도 일부 지원)• None OBJECT_LOCALIZATION: 이미지 내 여러 객체의 위치와 바운딩 박스 추출자 이제 본격적으로 사용법에 대해 소개해보겠습니다. 먼저 API를 통한 호출 방식과 서비스 계정 인증을 통한 방식을 살펴보려 합니다.기존 코드에서는 Google Vision API Key를 사용하여 REST API 방식으로 요청을 보냈습니다.즉, HTTP 요청 ( )을 직접 만들어 Vision API 엔드포인트 ( )로 보냈습니다.• None• None API Key만 있으면 어디서든 호출 가능• None 를 통해 수동으로 JSON 요청 생성 및 전송✅ 이미지에서 텍스트 추출 및 시각화 가능Colab 노트북에서 Google Vision API를 사용하려면 Service Account 인증 방식을 사용해야 합니다.• None 새 프로젝트 생성 (또는 기존 프로젝트 사용)두 가지 세팅을 해주셔야 하는데, 에서 카드 등록 해놓아야 하고(결제 부분은 생략하겠음!)그 다음엔 에 들어가서 서비스 계정을 발급받아야 하는데 아래에서 자세히 설명하겠습니다아, 그 전에 한 가지 해야할거!콘솔 최상단에 있는 검색창에 "Cloud Vision API" 검색 후 를 활성화 시켜주어야합니다.으로 보이면 설정 완료!• None Google Cloud IAM 관리 이동 하면 아래와 같은 개요 페이지가 보일 겁니다• None• None "Cloud Vision API User" 선택 해도 되고, 저는 그냥 개인 계정이라서 “소유자”로 지정했어요• None 방금 생성한 서비스 계정의 맨 우측에 작업을 누르면 가 보이실 거에요"키 관리" > "키 추가" > "새 키 만들기"• None 파일이 다운로드됨비공개 키는 안전한 곳에 저장해두세요!자 이제 환경 세팅은 다 끝났고, Colab 으로 돌아가서 API를 본격적으로 써봅시다3️⃣ Google

당근마켓 웹뷰 플랫폼 외전 — 레거시 시스템 안전하게 제거하기오래전에 소개했던 당근마켓 웹뷰 배포 변천사에 이어지는 근황으로, 이번에는 조금 다른 주제를 다뤄보려고해요 — 새로운 기술이 정착하면 이전에 사용하던 기술은 어떻게 되는 걸까요?당근마켓에 웹 프로젝트 배포하기 #1 — 파일 기반 웹뷰당근마켓에 웹 프로젝트 배포하기 #2 — 웹 서버로 돌아가기앞선 글에서 언급했던 것 처럼 기존에 구축했던 로컬 파일 기반 웹뷰(이하 “로컬 웹뷰”)를 버리기로 결정하고 정말 오랜 시간이 지났어요.3년도 더 지난 로컬 웹뷰 deprecation 공지기존의 웹뷰와 새로 배포되는 웹뷰를 “로컬 웹뷰” / “리모트 웹뷰”라 구분하여 부르고 공지 이후 1년 간 기존 또는 새로운 웹뷰 배포들이 마이그레이션을 완료하면서 로컬 웹뷰는 사용하지 않는 기술이 되었어요.하지만 사용자가 이전에 사용된 로컬 웹뷰 기반의 딥링크로 진입하는 경우가 있었기 때문에 한 번이라도 로컬 웹뷰를 사용했던 서비스들은 하위 호환성을 위해 이중 배포를 계속 유지해야 했어요.로컬 웹뷰에서 리모트 웹뷰로 마이그레이션되는 방식로컬 웹뷰 배포는 사용자를 리모트 웹뷰로 이동시키는 코드만 포함해서 거의 변경이 없어서 시간이 지나면서 자연히 잊혀지길 원했지만, 맥락은 꾸준히 남아 프론트엔드 개발자들을 불편하게 했어요.라우팅 방식 변경, 진입 경로의 동작 변경 등 몇몇 큰 변경에서 로컬 웹뷰에도 대응하는 코드 추가가 필요했어요. 종종 필요한 대응을 빼먹고 배포를 진행하여 큰 버그가 생기고 뒤늦게 발견되기도 했어요.HTTP 리디렉션을 사용할 수 없어 JavaScript 코드에 의존했고, 로컬웹뷰 동작을 모두 기다린 후에 실행됐기 때문에 매우 느렸어요. 개발자들이 새로운 배포에서 아무리 초기 로딩을 개선하더라도 로컬웹뷰로 진입하는 경우 아무 소용이 없었어요.신규 입사한 개발자 분들이 당근마켓의 웹뷰 구조를 파악하는데 큰 진입장벽이 되었어요. 더 이상 사용하지 않는 기술임에도 불구하고 여전히 로컬웹뷰가 무엇인지 가르치거나 파악하는데 시간을 써야 했어요.모바일 앱 개발자 분들에게도 “오래되어 손대기 어려운 코드”, 인프라 엔지니어 분들에게도 “자세히 모르지만 손대면 안되는 리소스” 등 특별한 예외로 취급되었어요.문제점을 인지하고 그저 오래 기다리는 것 만으로는 기술을 퇴역시키는데는 충분하지 않았어요. 로컬 웹뷰는 말 그대로 “기술 부채”로 남았어요.우리는 이제 이 부채를 청산하기 위해 적극적인 방식으로 상황을 개선해보기로 했어요. 구체적으로는 위에서 언급한 문제들을 해결하기 위해 다음과 같은 목표를 가지고 프로젝트를 진행했어요.프론트엔드 개발자들이 더 이상 로컬 웹뷰 서빙을 하지 않는다.모바일 앱 코드에서 로컬 웹뷰를 처리하는 로직을 완전히 제거할 수 있다.로컬 웹뷰와 관련된 오래된 AWS 리소스를 완전히 정리한다.사용 패턴 분석하기“3년이요? 안쓴지 이만큼이나 지났다면 이제 그냥 제거해도 되는 것 아닐까요?” 라는 의문이 자연스럽게 나왔지만 플랫폼은 여기에 대해 최대한 보수적으로 생각할 필요가 있어요.AWS