기억력이 금붕어라

기부 멘토링 - 이호재

Hojae Lee — Sat, 6 Dec 2025 18:39:42 +0900

[2025년 12월 최종 업데이트]

안녕하세요. 저에게 가끔 오는 멘토링(1:1, 커피챗, 코칭 등등)을 하는데, 이를 원할히 하기위한 가이드 문서를 작성했습니다.

서로의 시간은 아주 소중하고, 멘토링을 지속 가능하게 하려고 만들었므로, 꼭 지켜주시길 바랍니다.

제 간단 소개

총 경력 4년차의 전직 AWS SA, 현직 Datadog Technical Enablement Manager 입니다.
짧은 기간동안 국내 스타트업, 국내 중견기업, 글로벌 테크기업까지 경험했습니다.
AWS에서 Solutions Architect로 근무했습니다.
최근(25년 12월)에 Datadog의 Technical Enablement Manager 포지션으로 이직했습니다.
제 멘토링은 국내에서 외국계 테크 기업을 목표로 하는 신입/Early Career(최대 2-3년차) 엔지니어 분들에게 가장 적합합니다. (개발자분들에게는 적합하지 않습니다.)

저와 멘토링

저와 멘토링 할 수 있는 것: 신입/Early Career 영문 이력서 리뷰, AWS, Datadog를 아우르는 글로벌 테크 기업 Behavior/Tech Interview 준비
멘토링 가능 시간 확인: (이메일로 연락을 먼저 주세요. 본인의 상황, 이력등 제가 멘티분을 이해할 수 있도록 컨텍스트를 최대한 자세하게 같이 첨부해주세요.)
비용: 45분에 15불
- 이 멘토링으로 제가 돈 벌 생각은 전혀 없습니다.
- 모든 돈은 Unicef에 기부 하시고 기부한 내용으로 비용 확인 합니다.
- 서로간의 책임감을 올리고, 좀 더 높은 퀄리티의 멘토링이 되기 위한 최소한의 비용입니다.
- 기부 금액은 세금 보고 시 환급 받을 수 있습니다.
- 세상에 조금이나마 좋은 영향을 끼치고 싶어서 이기도 합니다.
기부 방법
- Unicef(https://unicef.org/) 홈페이지
- Donate 버튼 클릭
- ‘Give Once’ 클릭 - 일회성을 뜻함
- 비용 입력
- ‘Keep my one-time $ gift’ 클릭
- 기타 개인 정보 및 결제
- 기부를 마치고 영수증을 저한테 메일 포워딩
  - 이메일: hoje0711@naver.com
기부를 마치고 1:1 가능 시간에 예약 합니다. (이메일로 연락을 먼저 주세요. 본인의 상황, 이력등 제가 멘티분을 이해할 수 있도록 컨텍스트를 최대한 자세하게 같이 첨부해주세요.)
- 예약 이름과 기부 이름이 동일해야 합니다.
환불 규정
- 기본적으로 Unicef 기부 금액은 환불이 되지 않습니다. 그러니 신중히 해주세요.
- 혹시, 예약한 시간을 신청자가 못지키게 되면
  - 최소 멘토링의 1시간 전에는 알려주셔야 하며, 그러면 다른 시간에 다시 예약 하시면 됩니다.
  - 이후에는, 패널티로 다시 기부 해주셔야 합니다.
- 제가 시간을 못지키게 되면,
  - 멘토링의 1시간 이전에 이메일로 알려드리며, 시간을 다시 잡게 됩니다.
  - 이후 취소는, 저도 패널티로 30분은 기부 없이 멘토링 하게 됩니다.
기타 문의는 제 이메일이나 링크드인 메신저로 연락 주시면 됩니다.
- 이메일: hoje0711@naver.com
- 링크드인: https://linkedin.com/in/leehojae
오프라인으로 만남 요청하시는 분들은, 기부 전에 저와 시간 및 장소를 위 연락처로 협의를 먼저 하셔야 합니다. 일반적으로는 아래 장소에서 하며, 커피샵에서 만남 시 커피 한잔은 별도로 사주셔야 합니다. 이동 시간까지 치면 온라인 멘토링 보다는 더 제 시간과 에너지를 사용하기 때문입니다.
- 장소: 선릉역 인근 카페
  감사합니다.

[1/2] Amazon Bedrock AgentCore를 이용해서 Context-Aware Meeting Assistant 만들기

Hojae Lee — Tue, 11 Nov 2025 20:32:45 +0900

개요

25년 10월 13일, Amazon Bedrock AgentCore 서비스가 GA 되었습니다.

Bedrock AgentCore는 "From PoC to Production at Scale"을 핵심 가치로 내세우고 있는데요.

1) 도대체 Bedrock AgentCore는 무엇이고 2) 어떻게 PoC부터 Production까지, 그것도 대규모로 에이전트 서비스를 운영 할 수 있다는걸까요?

AgentCore를 활용해 Context-Aware Meeting Assistant를 만들어보면서, Bedrock AgentCore를 이해해보겠습니다.

시나리오

여러분은 AnyCompany사의 개발자입니다. 그런데, 여러분 회사의 세일즈팀의 이직율이 너무 높아서, 고객 히스토리에 대한 인수 인계가 잘 안되고 있습니다. 담당 세일즈가 바뀔 때마다 세일즈는 이전에 했던 질문을 고객에게 다시 해야하고, 이는 고객의 AnyCompany에 대한 불신을 높이고 있습니다. 물론, 세일즈가 CRM에 굵직한 이벤트는 기록을 하겠지만, 기존 고객의 세세한 성향이나, 누가 Decision Maker이고 Blocker인지와 같은 고객 인사이트에 대한 정보는 기존 세일즈의 머리속에만 기록되어있거든요. 결국 새로 바뀐 세일즈는, 고객 맞춤형 전략을 세울 수 없게 되고, 고객과의 Trust를 훼손시킬 각오를 하면서 다시 정보를 수집해야하는 상황에 놓입니다.

결국, AnyCompany사의 Leadership이 결단을 내립니다. 바로 단순한 FAQ 챗봇을 넘어서는, 고객의 Context까지 기억할 수 있는 Intelligent Meeting Assistant를 만들어보자는 것이죠.

아, 그런데 막막합니다.

어디서부터 시작을 해야할까요?

타임라인

Week 1

일단 시작이 반이라고, Lambda에 Claude API를 붙여서 테스트를 해봅니다.

프로토타입이 잘 작동하는군요. 생각보다 빠르게 일이 풀릴지도 모르겠습니다.

Month 1

Leadership이 본격적으로 requirements에 대한 요구를 해오기 시작합니다.

1. 동시 1000명까지 세일즈가 미팅 어시스턴트를 이용할 수 있어야 한다.

2. 여러 미팅을 걸쳐서 AI 에이전트가 기억을 해야한다.

음... 이럴 줄 알았습니다. 골치 아픕니다.

도대체 어디서부터 손대야할지도 모르겠네요.

확실한건, 프로토타입 아키텍처로는 프로덕션 수준의 구현이 절대 불가능하다는 것입니다.

Month 3

일단 에이전트는 제쳐두고, 인프라부터 손대봅니다.

여러분은 Leadership의 requirements를 다음과 같이 정리했습니다.

1. Session Isolation & Session Management

기본적으로, 한 명의 세일즈는 수 백명의 고객을 갖고 있고, 한 명의 고객과도 여러 건의 미팅을 진행하게 됩니다.

그렇다면?

1. 세일즈끼리 데이터가 섞이면 안됩니다. 그러면 누가 어떤 고객을 담당하고 어떤 미팅을 담당하는지 체크가 안되겠죠.

2. 한 세일즈가 보유하고 있는 여러 고객간의 데이터가 서로 섞이면 안됩니다. 고객 A한테 가서 고객 B의 얘기를 한다? 재앙입니다.

3. 한 고객의 여러 미팅에 대한 데이터가 서로 섞이면 안됩니다. 기껏 미팅간 타임라인을 정리해놨더니, 이게 섞이면 안됩니다.

따라서, 잘은 모르겠지만... 기본적으로 뭔가 격리가 필요해보이고, 뭔가 이에 대한 관리를 할 수 있어야 할 것 같습니다.

이를 Session Isolation & Session Management라고 정리해봅니다.

2. Memory Management for AI Agents

여러 미팅을 걸쳐 AI 에이전트가 기억을 할 수 있어야 합니다. 그러려면 일단, 고객과의 대화 내용을 저장해야합니다.

메모리 관리가 필요하겠군요.

3. Scaling Infrastructure for Concurrent Users

동시에 1000명의 고객을 감당하려면, 인프라가 트래픽 증감에 따라 자동으로 늘어나고 줄어들어야 할 것 같습니다.

오토 스케일링이 필요할 것 같습니다.

자, 그러면 개발자인 여러분은 기본적으로 저 3개 requirements에 대한 인프라를 직접 구축해야합니다.

그런데, 아뿔싸. 여러분의 Leadership은 벌써 결과물이 나오기를 기대하고 있습니다.

인프라 구축보다 퇴사가 빠를 것 같아서 잠깐 고민하다가, 집에 있는 토끼같은 아이들을 생각하며 참습니다.

에이전트 개발이나 비즈니스 로직 구현은 커녕, 인프라 구축부터 막막합니다.

하루 이틀 안에 끝날 일이 아닙니다.

방법이 없을까요?

여러분은 혹시나하는 마음에, 새로나온 AWS 서비스를 찾아보다가, Bedrock AgentCore라는 서비스를 발견했습니다.

과연 이 서비스가 여러분의 구세주가 될 수 있을까요?

이제 Bedrock AgentCore에 대해 한번 살펴보도록 하죠.

Bedrock AgentCore

AWS Official docs가 말하길,

Bedrock AgentCore는 AI 에이전트를 대규모로 안전하게 구축, 배포, 운영할 수 있도록 설계된 완전 관리형 플랫폼이라고 하네요.

그런데, 6개의 서비스 중에서, AgentCore의 핵심 서비스 2개가 여러분의 마음을 사로잡습니다.

1. AgentCore Runtime

Agent Runtime offers a secure, serverless and purpose-built way to deploy and scale AI agents and tools using any agent framework and any model. Runtime unlocks fast cold starts, industry-leading long-running execution, true session isolation, built-in identity, and support for multi-modal payloads. Simply host your existing agent or tool code in Runtime to get started.

2. AgentCore Memory

Memory enables agents to retain knowledge and learn continuously by leveraging built-in and/or custom strategies for automatically extracting and storing key types of memory from every interaction. This allows agents to be context-aware across sessions.

아직 잘은 모르겠지만, 여러 키워드가 눈에 띕니다.

1. Session Isolation & Session Management

2. Memory Management for AI Agents

3. Scaling Infrastructure for Concurrent Users

왠지..

1번은 AgentCore Runtime의 true session isolation 기능이

2번은 Context-aware across sessions 기능이

3번은 Serverless and scale AI agents 기능이 해결을 해줄 것 같습니다.

그리고 또 한달의 시간이 흘렀습니다.

과연 여러분은 프로덕션 수준의 AI 에이전트 서비스를 위한 인프라를 한달만에 구축할 수 있었을까요?

놀랍게도 그렇습니다.

여러분이 구축한 인프라를 리버스 엔지니어링 해보도록 하죠.

잘은 모르겠지만... MicroVM이라는게 보이는군요. Isolation에 핵심적인 요소일 것 같습니다.

조금 검색을 해봅니다. 아하, MicroVM이라는 것이 AWS의 오픈소스 Firecracker 기술을 기반으로 하는군요.

일반 VM보다 훨씬 빠르게 시작되고, 세션이 종료되면 메모리를 완전히 초기화해서 보안을 보장한다고 하네요.

각 세션마다 독립된 MicroVM이 할당되니, 완벽한 물리적 격리가 이루어지는 셈입니다.

그런데 잠깐, 여기서 헷갈리는 부분이 있습니다. Actor ID라는 것도 보이는데, 이건 뭘까요?

조금 더 찾아보니, Actor ID는 Runtime의 세션 격리와는 별개로, Memory 서비스에서 메모리를 조직화하는 개념이군요.

이 구조에서는 각 고객을 Actor ID로 할당해서, 각 고객의 여러 미팅을 논리적으로 그룹화하는 것으로 보입니다.

이렇게 하면 담당 세일즈가 바뀌어도, 새로운 세일즈는 Actor ID만 조회하면 해당 고객과의 모든 미팅 히스토리와 인사이트를 즉시 파악할 수 있겠네요.

영리한 구조네요.

Runtime은 각 세션(미팅)을 물리적으로 완전히 격리하고, Memory는 Actor ID(고객) 아래 여러 세션(미팅)을 계층적으로 조직화해서 컨텍스트를 일관되게 유지하는군요.

~~1. Session Isolation & Session Management~~

2. Memory Management for AI Agents

~~3. Scaling Infrastructure for Concurrent Users~~

좋아요. 1번과 3번은 해결했습니다.

그럼 2번은 어떻게 해결해야할까요?

Memory Management라... 이름만 들어도 상당히 골치아파보이는데 말이죠.

다이어그램 안에 Short-term Memory와 Long-term Memory라는 것이 보이네요.

뭔지는 몰라도, 저게 메모리 역할을 하는 것 같습니다.

그리고 단어의 뉘앙스로 추측해보건대, Short-term Memory는 단기간 데이터를 저장하고, Long-term Memory는 장기간 데이터를 저장하는 것 같습니다.

AWS Official docs를 찾아봅시다.

아, 이제 알겠습니다. 미팅 대화(transcript)를 Short-term Memory에 저장하게 되면, AgentCore의 LLM이 고객 인사이트를 추출하고, 기존 Long-term Memory와 비교해 중복을 제거하거나 업데이트한 후 저장하는 구조군요.

오, 공간 효율적입니다.

굳이 Short-term Memory에 저장된 모든 대화를 굳이 계속 보관하는게 아니라, 대화에서 추출된 고객에 대한 인사이트만 Long-term Memory에 저장을 하는거네요. 그래도 여러 미팅에 걸친 고객에 대한 Context를 일관되게 유지할 수 있으니까요. 혹시 나중에 RAG를 위해서 전체 대화가 필요하면 S3에 따로 export를 하면 되니, 요건에 따라 선택할 수 있는 옵션이 늘어난 셈입니다.

아하, 대화에서 이런식으로 고객에 대한 인사이트를 추출하는군요.

어떻게 인사이트를 추출할지 정의하는 것을 Strategy라고 하는 것 같습니다.

일단은 이름만 알고 넘어갑니다.

~~1. Session Isolation & Session Management~~

~~2. Memory Management for AI Agents~~

~~3. Scaling Infrastructure for Concurrent Users~~

이렇게 2번도 해결을 했습니다.

그러면 이제, 여러분이 서비스를 어떻게 구현했는지 살펴봅시다.

아키텍처를 보니 그리 특별한 것은 없네요. 다만 Long-term Memory와 RAG가 둘 다 구현되어있는 것으로 보이는데, 둘의 차이가 조금 혼란스럽습니다. 이 부분은 다음 문서에서 다뤄보도록 하겠습니다.

아, 한 세일즈가 여러 고객에 대한 컨텍스트를 관리하는 것만 구현을 했나보네요.

좋아요. 오히려 AgentCore의 각 기능이 어떻게 서비스에 녹아드는지 이해하기가 더 쉬워졌습니다.

지금은 고객이 없기 때문에 고객을 추가해봅니다.

행복하면 좋으니, 회사의 이름은 Happy Company라고 하겠습니다.

여기서 Customer Snapshot은, Long-term memory에 저장된 고객 인사이트를 디스플레이하는 대시보드로 보이고, Meeting History는 Short-term Memory에 저장된 미팅 데이터를 보여주는 곳으로 보이네요.

아직 미팅을 한번도 진행하지 않았기 때문에, Customer Snapshot과 Meeting History 모두 고객에 대한 데이터가 없는 것으로 나옵니다.

세 가지 섹션으로 나뉘어져 있군요.

왼쪽 섹션에는, 고객의 대화를 적는 곳, 그리고 오른쪽 두 섹션은 고객 특화된 질문과 답변을 하는 곳으로 보입니다.

노란색 박스를 살펴보겠습니다.

고객이 Hi, I'm Kate, founder of a small eco-friendly clothing brand called Happy Company 라고 말하네요.

그런데 Personalized AI Coaching Answer을 보니, 특별하게 고객 특화된 답변을 하는 것 같지 않습니다.

보라색 섹션을 봐도, 이 대답은 이전 대화 내역 없이 만들어졌다고 나오네요.

아하, 아직 Short-term Memory에 저장된 대화가 Long-term Memory로 추출이 되지 않았군요.

최대 1분의 비동기적 추출 시간이 걸린다고 하더니, 그것 때문인 것 같습니다.

미팅을 저장하고 이전 화면으로 돌아가봅니다.

Customer Snapshot을 먼저 보겠습니다.

고객에 대한 정보와 Deal의 상태같은 고객에 대한 인사이트가 새롭게 업데이트 되었네요. 성공입니다!

그리고 Meeting History 역시, 해당 미팅에 대한 Summary가 잘 생긴 것을 볼 수 있습니다.

이번에는 새로운 미팅을 만들고 다시 고객의 대화를 입력해보겠습니다.

Hi again, this is Kate from Happy Company.

Thanks for the proposal you shared last week - I'd like to understand more about AWS hosting options and how pricing works. Also, can we migrate our existing customer database without any data loss during the transtion?

그리고 오른쪽 노란색 박스를 보면, Assistant가 Given your eco-friendly clothing brand's specific needs 라고 하네요.

어라, 이번 미팅에서는 분명히 Kate가 자기가 clothing brand의 설립자라고 말을 한적이 없는데 말이죠!

역시 성공입니다! 고객 특화된 답변을 주고 있군요.

그리고 보라색 섹션을 보면, Long-term Memory에서 고객 인사이트를 활용해서 대답한 것을 확인할 수 있습니다.

Memory의 Namespace structure를 살펴봐도, 고객, 미팅 모두 각각의 unique한 ID를 갖고 있는 것이 확인이 되는군요.

성공적으로 isolation이 이뤄졌습니다!

지금까지 미팅간 데이터가 서로 섞이지 않는다는 것을 확인했으니, 이번엔 마지막으로 고객간 데이터가 서로 섞이지 않는다는 것을 확인해보겠습니다.

새로운 고객을 만들고,

고객 대시보드에 들어가보면, Customer Snapshot과 Meeting History가 모두 비어있네요.

성공입니다. 고객간 데이터 역시 섞이지 않고 분리가 되는군요!

여러분은 이렇게 짧은 기간에, 별도의 인프라 구축 없이 Context-Aware Meeting Assistant를 만들 수 있었던건 AgentCore 없이는 불가능했을 것 같다는 생각을 해봅니다.

정말로 AgentCore를 사용하니 From PoC to Production at Scale이 가능했네요!

Amazon Aurora DSQL의 낙관적 동시성 제어 (Optimistic Concurrency Control)

Hojae Lee — Wed, 23 Jul 2025 13:42:29 +0900

자세한 내용 : https://gemini.google.com/app/b79936baaab7f162

4줄 요약 :

1. 현대 웹/앱 워크로드 환경에서 동일한 밀리초에 동일한 레코드로 경합이 벌어질 가능성이 매우 낮다.

2. 따라서 충돌이 일어나지 않을 것이라고 낙관적으로 가정하고, 데이터베이스의 퍼포먼스를 챙긴다.

3. 반짝 세일처럼, 동일한 밀리초에 동일한 레코드로 충돌이 벌어질 것 같으면 큐로 처리한다.

4. 단, 트레이드 오프로 애플리케이션 단에서 견고한 충돌 감지 및 리트라이 로직이 필요하다.

낙관적 원칙: 조화를 가정하고 마지막에 검증하라

낙관적 동시성 제어(OCC)는 충돌이 드물 것이라는 "낙관적인" 가정에 기반합니다. 이 방식은 잠금의 선행 비용을 피함으로써 처리량을 극대화하는 데 우선순위를 둡니다.

동시성 처리 부담의 철학적 전환

PCC와 OCC 사이의 선택은 '동시성 처리의 부담'을 어디에 둘 것인가에 대한 근본적인 철학의 전환을 의미합니다. PCC는 그 부담을 전적으로 데이터베이스 시스템에 지웁니다. 데이터베이스는 복잡한 잠금 테이블을 관리하고, 교착 상태를 감지하며, 트랜잭션을 대기시키는 책임을 집니다. 이로 인해 애플리케이션 코드는 데이터가 사용 가능해질 때까지 단순히 대기하면 되므로 상대적으로 단순해질 수 있습니다.

반면, OCC는 그 부담의 상당 부분을 애플리케이션 계층으로 이전시킵니다. 데이터베이스의 역할은 원자적인 '확인 후 설정(check-and-set)' 연산을 제공하는 것으로 단순화됩니다. OptimisticLockException과 같은 예외를 포착하고, 전체 비즈니스 트랜잭션을 재시도할지, 몇 번이나 재시도할지, 그리고 모든 재시도가 실패했을 때 어떻게 처리할지를 결정하는 것은 온전히 애플리케이션의 책임이 됩니다.

결과적으로, 동시성 모델의 선택은 단순한 데이터베이스 성능 튜닝 결정을 넘어, 전체 시스템 아키텍처에 관한 결정이 됩니다. Aurora DSQL과 같이 OCC 기반 시스템을 선택하는 팀은 더 정교한 애플리케이션 수준의 오류 처리 및 재시도 로직에 투자할 준비가 되어 있어야 합니다. 데이터베이스 수준의 복잡성을 희생하여 잠재적으로 더 높은 처리량을 얻는 대신 애플리케이션 수준의 복잡성을 감수하는 이 트레이드오프가 바로 "낙관적 베팅"의 핵심입니다.

가설 1: 현대 웹 스케일 워크로드의 본질은 본래 낙관적이다

대다수의 현대 클라우드 네이티브 애플리케이션은 읽기 대 쓰기 비율이 압도적으로 읽기 쪽으로 치우쳐 있습니다. 수많은 사용자가 상품을 조회하지만 특정 순간에 구매하는 사용자는 소수인 전자상거래 사이트, 많은 이들이 스크롤하지만 소수만 게시물을 올리는 소셜 미디어 피드, 또는 콘텐츠 관리 시스템을 생각해보면 명확합니다.

Amazon Bedrock AgentCore란 무엇일까?

Hojae Lee — Mon, 21 Jul 2025 23:53:22 +0900

Amazon Bedrock AgentCore는 관리형 서비스(Managed Service)입니다.

역할: 개발자가 만든 AI 에이전트를 대규모로 안전하게 배포하고 운영할 수 있도록 도와주는 AWS의 클라우드 서비스입니다.
주요 기능: Runtime(실행 환경), Observability(모니터링), Identity(보안 및 접근 제어), Gateway(외부 연결 관리) 등 운영에 필요한 인프라와 기능을 제공합니다.
비유: 건축가가 설계한 건물을 실제 지을 수 있는 안정적인 대지와 공사 현장, 그리고 감시 시스템을 제공하는 것과 같습니다. 개발자는 건물 자체의 설계도만 제공하면 나머지는 AWS가 관리해 줍니다.

결론: 두 기술의 관계

LangChain과 Amazon Bedrock AgentCore는 서로 대체하는 관계가 아니라, 함께 사용될 수 있는 보완적인 관계입니다.

개발자는 LangChain을 사용하여 에이전트의 복잡한 동작 로직을 구현할 수 있습니다.
그리고 이렇게 개발한 에이전트를 Amazon Bedrock AgentCore에 배포하여, 보안, 확장성, 모니터링 등 엔터프라이즈급 운영 환경을 손쉽게 확보할 수 있습니다.

따라서 LangChain이 **에이전트를 "어떻게 만들지"**에 초점을 맞춘다면, AgentCore는 **만들어진 에이전트를 "어떻게 운영하고 확장할지"**에 초점을 맞춘 서비스입니다.

즉, LangChain같은 프레임워크를 안전하게 운영할 수 있는 인프라를 제공하는 서비스임.

마치 Bedrock이 여러 LLM 모델을 운영하는 인프라를 제공하듯이.

(Preview) Amazon S3 Vectors 정리 (Vector Index, Vector Dimension, 기존 서비스와의 비교)

Hojae Lee — Mon, 21 Jul 2025 23:44:03 +0900

대규모 벡터를 지원하는 최초 클라우드 스토리지

https://aws.amazon.com/ko/blogs/korea/introducing-amazon-s3-vectors-first-cloud-storage-with-native-vector-support-at-scale/

Amazon S3 Vectors 소개: 대규모 벡터를 지원하는 최초 클라우드 스토리지 (미리 보기) | Amazon Web Service

오늘 AWS는 벡터 업로드, 저장 및 쿼리에 드는 총 비용을 최대 90% 절감할 수 있고 내구성이 뛰어난 목적별 벡터 스토리지 솔루션인 Amazon S3 Vectors의 평가판을 발표합니다. Amazon S3 Vectors는 대규모

aws.amazon.com

Vector Index란?

1. Vector Embedding은 텍스트, 이미지, 오디오와 같은 비정형 데이터를 컴퓨터가 이해할 수 있는 수치형 벡터로 변환하는 기술임.

2. Embedding Vector는 단순히 단어 자체가 아니라, 단어의 의미적 맥락을 담게 됨. "따듯한 아메리카노" 나 "따스한 커피 한 잔" 같은 의미적으로 유사한 문장은 서로 매우 가까운 위치에 있는 벡터로 표현됨.

3. 수많은 데이터를 임베딩해서 벡터로 저장하면, 특정 질문에 가장 유사한 벡터를 찾아야 함. 이때, 인덱스가 없다면, 모든 벡터를 하나씩 비교해야 함. (brute force = 매우 비효율적)

4. Vector Index는 수많은 고차원 벡터들을 효율적인 검색이 가능한 구조로 재구성하는 것을 말함.

5. 주요 Vector Indexing 기법

현재는 그래프 기반 인덱싱이 널리 쓰이고 있음

Vector Dimension이란?

차원이 늘어날수록 벡터 공간은 기하급수적으로 커집니다. 이로 인해 벡터들 간의 거리가 점점 멀어지게 되고, 데이터가 공간 전체에 희박하게(sparse) 분포하게 됩니다.

차원을 무작정 줄이면 벡터가 데이터를 표현하는 **능력(표현력)**이 현저히 떨어집니다.

정보 손실: 복잡하고 미묘한 의미 차이를 담을 공간이 부족해집니다. 예를 들어, "고양이가 귀엽다"와 "고양이가 사랑스럽다"는 미묘하게 다르지만, 차원이 너무 낮으면 두 문장이 동일한 벡터로 표현될 수 있습니다.
분별력 감소: 의미적으로 다른 벡터들이 서로 뭉쳐서 구분이 어려워집니다. 이로 인해 유사도 검색을 할 때 엉뚱한 결과가 섞여 나올 가능성이 높아져서 **정확도(Recall)**가 크게 떨어집니다.

"적정한" 차원은 정해진 답이 없습니다. 서비스의 요구사항과 제약 조건을 종합적으로 고려하여 결정해야 합니다. AWS 전문가의 관점에서 다음과 같은 요인들을 고려해볼 수 있습니다.

적정한 차원을 산정하는 방법

1. 데이터의 복잡성

높은 차원이 필요한 경우: 긴 문서, 복잡한 이미지, 의학 정보 등 풍부한 의미적 맥락을 담아야 하는 데이터는 더 높은 차원이 필요합니다.
낮은 차원으로 충분한 경우: 짧은 문장(예: 상품평 한 줄), 단순한 객체 등 상대적으로 의미가 단순한 데이터는 낮은 차원으로도 충분한 표현력을 가질 수 있습니다.

2. 비즈니스 목표와 중요성 (정확도 vs. 속도/비용)

정확도가 최우선인 경우: 고객 추천 시스템이나 질문-답변(Q&A) 시스템처럼 정확한 검색 결과가 비즈니스 성공에 직결되는 경우, 어느 정도의 비용과 성능 저하를 감수하고라도 높은 차원을 선택해야 합니다.
속도나 비용이 더 중요한 경우: 대규모 데이터에 대한 실시간 검색, 단순한 카테고리 분류 등 정확도 손실을 어느 정도 용인할 수 있는 경우, 낮은 차원을 선택하여 비용과 속도를 최적화할 수 있습니다.

3. AWS 서비스의 제약 조건

메모리: Amazon OpenSearch Service나 Amazon Aurora와 같은 AWS 서비스의 인스턴스 타입마다 메모리 용량이 제한적입니다. 차원이 높을수록 더 큰 인스턴스가 필요하고, 이는 곧 비용 증가로 이어집니다.
네트워크 대역폭: 데이터 크기가 커지면 인스턴스 간의 통신 부하도 커질 수 있습니다.

4. 경험적 분석 및 실험 (가장 중요한 부분)

이론적인 접근 외에 실제 데이터를 가지고 실험하는 것이 가장 정확합니다.

단계별 접근: 예를 들어, 512차원, 768차원, 1024차원 등 몇 가지 후보 차원을 정합니다.
성능 지표 측정: 각 차원에서 실제 데이터를 대상으로 검색을 수행해 **정확도(Recall@K)**와 **응답 속도(Latency)**를 측정합니다.
최적점 찾기: 정확도가 일정 수준 이상으로 오르지 않는 지점이나, 응답 속도가 급격히 느려지기 시작하는 지점을 찾습니다. 이 두 지표가 균형을 이루는 지점이 바로 최적의 차원입니다.

디테일한 대답 : https://g.co/gemini/share/9872b9bd25ac

다른 서비스와 통합 역시 가능함 :

S3 Vectors를 다른 AWS 서비스와 통합
S3 Vectors는 Amazon Bedrock, Amazon SageMaker, Amazon OpenSearch Service 등의 다른 AWS 서비스와 통합되어 벡터 처리 기능을 강화하고 AI 워크로드를 위한 포괄적인 솔루션을 제공합니다.

S3 벡터 데이터를 Amazon OpenSearch Service로 내보내기
장기간에 걸친 벡터 데이터를 Amazon S3에 비용 효율적으로 저장하고 실시간 쿼리 성능을 높이기 위해 우선순위가 높은 벡터를 OpenSearch로 내보내는 계층형 전략을 적용하여 비용과 성능의 균형을 이룰 수 있습니다.

기존 서비스와의 비교

https://gemini.google.com/app/9076cc67a98d27f7

프라이빗 커피챗

Hojae Lee — Sun, 20 Apr 2025 14:41:01 +0900

주소 : https://meet.hojaelee.com

프라이빗 커피챗

☕ 프라이빗 커피챗 초대코드가 있다면 새로운 대화를 예약하고, 이미 예약했다면 전화번호로 상태를 확인하세요. 초대코드로 대화 예약 예약 상태 확인

meet.hojaelee.com

개발 계획

단기 계획

~~- 내 캘린더 보고 내 캘린더에 비어있는 시간에만 초대 가능하게 하기~~

~~- 지금은 남의 status로 들어가볼 수 있으니까 status 보려면 자기 핸드폰번호 뒷자리 추가로 입력하게 하기?~~

- SaaS화

- 영구 초대코드 + 일회용 초대코드 (한번 쓰면 만료) 기능

- admin page에서 permanent code 변경할 수 있도록 하기

~~- 예약 신청시 나한테 메일로 알려주는 기능~~

- 스케줄 변경, 취소 기능

- 거절시 거절 사유 적고 메일

장기 계획

~~- meet.hojaelee.com으로 라우팅 시키기~~

- 도커로 말아서 ~~시놀로지로 돌려보기~~

- 구글 플랫폼 써서 올려보자.

- QR코드로 접속하면 코드 입력은 생략하게 하면 되겠다. (가변 인쇄)

- 사용자 데이터 암호화해서 저장

- 예정된 1on1 시간이 지나면 곧바로 사용자 데이터 삭제

Behind the scene

~~- ChatGPT만 사용해서 개발함.~~

- MCP 이용해서 자동화 고민

https://www.youtube.com/watch?v=ecY5VBpruOA&t=6s

https://www.youtube.com/watch?v=GRtrfdSeR20

소요 시간

4월 19일 6시간

4월 20일 8시간

4월 21일 12시간 <- 기본적인 기능 구현 완성 (개인 캘린더 조회 및 google meet invite까지)

4월 22일 2시간 <- 여기까지 모바일 UI/UX, dev/prod 환경 분리, 시놀로지에 배포

4월 28일 5시간 <- bug fix (refresh token, google auth (uri mismatch)

AWS의 Solutions Architect는 무엇을 하는 사람들일까?

Hojae Lee — Wed, 16 Apr 2025 21:07:26 +0900

⚠️ Disclaimer :
본 게시글은 AWS의 어떠한 의견도 대변하지 않습니다. 개인적인 의견이므로 사실과 다른 내용이 있을 수 있습니다.

많은 분들이 AWS의 Solutions Architect 자격증을 취득하면서, Solutions Architect라는 포지션을 접해봤으리라 생각한다.

하지만 자격증은 테크니컬한 지식만을 평가할 뿐, 그보다 몇 배는 더 중요한 비즈니스에 대한 이해도는 평가하지 않는다.

그래서 Solutions Architect를 개발자나 인프라 엔지니어와 비슷하게 이해하고 지원했다가 당황하는 분들이 꽤 있다.

예를 들어서, AWS의 Solutions Architect는 세일즈 조직 아래에 소속된다. 왜 그럴까? 세일즈 조직에 속한 테크 포지션이라니?

이게 무슨 의미일까?

링크드인 DM으로 포지션에 관해 이런 저런 질문을 주는 분들이 가끔 계신데, 이참에 2년 7개월간의 AWS에서의 여정을 마무리하면서 이에 관해 정리해보고자 한다. 이 글은 Lessons Learned의 역할도 겸하고 있으니 혹시라도 부족한 내용이나 잘못된 내용이 있으면 DM으로 피드백 주시면 감사히 반영하고자 한다.

❗️SA 조직 내에는 여러 팀이 있고 팀마다 SA의 역할이 많이 다르다. 또한 SA의 레벨에 따라 요구되는 역량과 커버리지도 많이 달라진다. 이 글에 담긴 내용은 AWS SA가 하는 다양한 역할 중 일부일 뿐이다. 그런 점을 감안하고 편안하게 읽어주시면 감사할 것 같다.

1) AWS의 Solutions Architect를 한 문장으로 정의 내린다면?

사람마다 SA에 대해 여러 정의를 가질 수 있지만, 입사 때부터 내 매니저님이 말씀해주신 AWS SA의 정의는 다음과 같다.

AWS 서비스로 이루어진 모범 사례를 고객들이 충분히 이해할 수 있도록 도와주는 사람

기술 중심의 백그라운드를 가진 분들은 SA를 단순히 최신 기술을 다루고 아키텍처를 설계하는 엔지니어로 생각할 수 있다. 실제로 SA는 누구보다 빠르게 새로운 기술을 익히고 실전에서 활용해야 하는 포지션이 맞다. 하지만 SA가 기술을 습득하는 목적은 어디까지나 기술 자체를 즐기기 위한 것이 아니라 고객의 비즈니스 성공을 지원하기 위해 기술을 전달하고 적용하는 데 목적이 있다.

2) AWS의 Solutions Architect가 하는 주요 역할은 무엇일까? (Role)

다음은 AWS에서 official하게 제시하는 Solutions Architect의 주요 역할이다 :

솔루션즈 아키텍트는

1) AWS를 대표하여 고객사들에게 클라우드 전략을 소개하고 클라우드 전환 업무를 지원하는 중요한 역할을 수행합니다. 고객사들을 직접 방문하여 관련 임직원들에게 AWS 클라우드 아키텍처에 대한 정보를 공유하고 기술적 지원을 제공하게 됩니다. AWS를 대표한다는 점에서 기술적으로 확고한 지식을 보유하고 있어야 하며 고객사의 소프트웨어 아키텍트 및 개발자들과 기술 회의를 주도할 수 있는 역량을 갖추고 있어야 합니다.

2) 고객사의 클라우드 아키텍처와 애플리케이션 아키텍처가 클라우드의 장점(안정성, 안전성, 민첩성, 비용효율성, 운영효율성, 지속가능성 등)을 반영하고 있는지 함께 검토하고 솔루션을 제공하게 됩니다.

또한 3) 기존 시스템의 마이그레이션 및 새로운 기술을 활용한 비즈니스 기회에 대해서도 의견을 주고 받으며 고객의 혁신을 선도하는 역할을 담당합니다.

세 줄로 정리해보면 다음과 같다 :

1) 고객사에게 AWS 클라우드 전략을 소개하고 클라우드 전환 업무를 지원
2) 고객사의 클라우드 아키텍처가 클라우드의 장점을 반영하고 있는지 리뷰하고 솔루션 제공
3) 기존 시스템을 AWS로 마이그레이션하고, 최신 기술을 고객 비즈니스에 어떻게 적용할 수 있을지 함께 고민하며 제안

참고로 기술적으로 탄탄한 지식을 가질 것을 당연하게 전제하는 것을 볼 수 있다.

3) Solutions Architect가 하는 일에는 어떤 것들이 있을까? (Tasks/Activities)

SA가 하는 활동은 정말 많다. 대표적인 활동만 나열해도 다음과 같다 :

고객 미팅
퍼블릭 스피킹 (외부 발표)
인터널 세션 (내부 공유 세션)
블로그 작성
워크샵 기획 및 진행
데모 제작
PoC(기술 검증) 수행
이니셔티브 리딩 (예: AWS Tech Camp 리드)
제품 기능 피드백 및 건의

이렇게 많은 활동을 보면서, 몸이 하나인데 이걸 어떻게 다 하지? 라는 생각이 들 수 있다.

다행히도 이 모든 일들을 반드시 다 수행해야 하는 것은 아니다.

SA는 누군가 정해준 To-do 리스트를 하나 하나 지워나가는 방식으로 일하지 않는다.

오히려, 각 고객의 상황에 따라 가장 필요한 활동이 무엇인지 스스로 판단하고, 그에 따라 유연하게 움직인다.

그렇기 때문에 SA에게는 우선 순위 판단 능력과 시간 관리 능력이 매우 중요하다.

4) Solutions Architect는 왜 존재하는걸까?

이 질문은 SA는 테크 포지션인데 왜 세일즈 조직에 속할까? 라는 의문과 본질적으로 맞닿아 있다.

개발자나 엔지니어로 일하다가 오시는 분들이 가장 헷갈릴만한 부분이다.

이를 이해하기 위해서는 세일즈 퍼넬과 파이프라인을 이해해야 한다.

세일즈 퍼넬(Sales Funnel): 잠재 고객이 실제 구매 고객으로 전환되기까지의 전반적인 여정을 단계별로 시각화한 것
세일즈 파이프라인(Sales Pipeline): 영업 담당자가 현재 진행 중인 딜(기회)을 단계별로 관리하고 추적하는 도구

AWS에서 공식적으로 사용하는 용어와 이미지는 아니다. 하지만 맥락은 같다.

SA의 역할은 단순히 고객 미팅을 하고, 데모를 만들고, 무대 앞에 나가서 멋지게 발표하면 끝나는게 아니다.

이러한 활동들을 왜 하는지 이해해야 한다.

아까 언급한 대표적인 SA의 활동들 역시 곰곰이 따져보면 세일즈 퍼넬을 넓히거나 세일즈 파이프라인을 가속하기 위한 방법들이다.

몇 가지 예를 들어보자면 :

고객 미팅 - 세일즈 파이프라인을 가속하기 위한 활동

퍼블릭 스피킹 - 세일즈 퍼넬을 넓혀 잠재 고객(lead)을 확보하기 위한 활동

SA는 세일즈 조직의 기술 전문가로서 세일즈(영업 전문가)를 도와서 세일즈 퍼넬을 넓히고 세일즈 파이프라인을 가속할 책임이 있다.

세일즈 퍼넬과 세일즈 파이프라인에 대한 설명 : https://chatgpt.com/share/67ffa41d-d650-8005-9a2d-47f48d4cd75c

5) 마무리 하면서

다른 사람들처럼 나 역시 SA 인터뷰를 준비하면서 도대체 AWS의 SA가 뭘 하는 포지션인지 많이 궁금했던 기억이 난다.

이 글이 AWS의 SA 포지션을 준비하거나 고민하시는 분들께 조금이라도 도움이 되면 좋겠다.

옵시디언에서 파일 트리에 뜨는 이미지 숨기기

Hojae Lee — Sat, 1 Mar 2025 12:16:16 +0900

https://www.perplexity.ai/search/opsidian-aebeseo-butyeoneohgih-skC4z_DSTeOqgFy734ROSQ

opsidian 앱에서 붙여넣기한 이미지가 파일에 뜨는게 거슬려

옵시디언에서 이미지 관리 문제를 해결하는 몇 가지 방법이 있습니다. 옵시디언에 이미지를 붙여넣으면 기본적으로 루트 폴더에 저장되어 지저분해질 수 있습니다. 이 문제를 해결하려면: 1. 옵

www.perplexity.ai

맥북에서 option, command 뒤바꾸기 (외장 키보드)

Hojae Lee — Wed, 26 Feb 2025 14:21:50 +0900

https://www.clien.net/service/board/cm_mac/16768241

펌)윈도우 키보드를 맥에서 사용하는 방법 + 설정변경하는 방법 : 클리앙

일반 키보드와 애플키보드의 차이점 애플키보드 -컨트롤 / option(alt) / command 순으로 키보드가 배열되어 있습니다.(좌측하단에 키보드배열) 윈도우키보드 - 컨트롤 / 윈도우 / alt 순으로 키보드가

www.clien.net

Agent by Google 스터디

Hojae Lee — Tue, 14 Jan 2025 11:28:55 +0900

Agent_by_Google_1735943219.pdf

4.54MB

최근에 구글이 AI Agent에 대한 백서를 정리해서 내놓았다.

그 위에 필기 끄적인 것들을 업로드했다.

그리고 Agent에 대해 설명을 잘 해준 유튜브 영상을 첨부한다.

https://www.youtube.com/watch?v=HujQhD8J2LQ&t=24s

기억력이 금붕어라

기부 멘토링 - 이호재

[1/2] Amazon Bedrock AgentCore를 이용해서 Context-Aware Meeting Assistant 만들기

개요

Amazon Aurora DSQL의 낙관적 동시성 제어 (Optimistic Concurrency Control)

낙관적 원칙: 조화를 가정하고 마지막에 검증하라

동시성 처리 부담의 철학적 전환

가설 1: 현대 웹 스케일 워크로드의 본질은 본래 낙관적이다

Amazon Bedrock AgentCore란 무엇일까?

Amazon Bedrock AgentCore는 **관리형 서비스(Managed Service)**입니다.

결론: 두 기술의 관계

(Preview) Amazon S3 Vectors 정리 (Vector Index, Vector Dimension, 기존 서비스와의 비교)

대규모 벡터를 지원하는 최초 클라우드 스토리지

적정한 차원을 산정하는 방법

1. 데이터의 복잡성

2. 비즈니스 목표와 중요성 (정확도 vs. 속도/비용)

3. AWS 서비스의 제약 조건

4. 경험적 분석 및 실험 (가장 중요한 부분)

프라이빗 커피챗

개발 계획

Behind the scene

AWS의 Solutions Architect는 무엇을 하는 사람들일까?

1) AWS의 Solutions Architect를 한 문장으로 정의 내린다면?

2) AWS의 Solutions Architect가 하는 주요 역할은 무엇일까? (Role)

3) Solutions Architect가 하는 일에는 어떤 것들이 있을까? (Tasks/Activities)

4) Solutions Architect는 왜 존재하는걸까?

5) 마무리 하면서

옵시디언에서 파일 트리에 뜨는 이미지 숨기기

맥북에서 option, command 뒤바꾸기 (외장 키보드)

Agent by Google 스터디

Amazon Bedrock AgentCore는 관리형 서비스(Managed Service)입니다.