말랑말랑 개발기

Claude Code Meetup Seoul FDE Night 2026 후기

귤랑귤랑 — Wed, 22 Apr 2026 18:53:30 +0900

Worxphere

날짜: 2026년 4월 17일 금요일
시간: 18:30 – 21:00
장소: 서울 교대역 인근
주최: Claude Community Events (Anthropic 후원)
공동 주최: Worxphere · SpaceY(DIO)
진행: 최훈민 (Claude Community Ambassador, Seoul)

FDE, 아직 번역되지 않은 직무

지난 금요일 Claude Code FDE Night에 참석했다. Cognition 최규환 님, defytheodd 이선민 님, SpaceY 황현태 님, Worxphere 김요섭 CTO, 채널톡 최한길 님 — FDE라는 포지션을 각자의 자리에서 치열하게 정의해 온 분들의 이야기를 한자리에 모은 자리였다.

FDE(Forward Deployed Engineer)는 지금 한국에서 막 언어가 만들어지고 있는 직무다. 실리콘밸리에서조차 회사마다 역할 정의가 다르고, 한국에서는 더더욱 레퍼런스가 부족하다. 각자의 현장에서 쌓인 경험을 꺼내 놓고 공통 언어를 만드는 자리가 필요했고, 이번 행사가 그 시작점이 되었다고 느꼈다.

이 글은 그날 들은 이야기를 내 나름으로 정리하고, 내가 FDE 직무로 옮긴 뒤 쌓여 온 고민과 겹쳐 보는 기록이다.

1. FDE란 무엇인가 — "조직 내 줄기세포"

FDE 직무로 바뀐 후, 가장 먼저 고민한 건 "FDE의 정의"였다.

고객사에 직접 파견되어 그 고객의 문제를 풀며 제품을 커스터마이징하고 적용하는 포지션. 하지만 '문제를 해결하고 가치를 만드는 사람'은 내가 생각하는 개발자의 정의 그 자체이기도 하다. 그렇다면 FDE는 어떤 점에서 특별해야 할까?

행사장에서 나온 한 문장이 기준점이 됐다.

"FDE는 조직 내 줄기세포 같은 역할이다. PM, 비즈니스, 개발 사이 어디든 붙어서 고객의 문제를 푼다."

FDE는 Palantir에서 시작된, AI 등장 이전부터 존재해 온 직군이다. 단순히 개발하는 사람이 아니라, 의사결정자를 고객에게 가장 가까이 배치해 스코핑부터 의사결정까지 직접 수행하는 포지션이다. 컨설턴트(문제 정의) + 엔지니어(직접 구현) + 세일즈(계약 확장)가 한 몸에 섞인 직군 — 이 정의가 AI 시대에도 핵심을 관통한다.

2. FDE 모션이라는 단어 — 직군이 아니라 운영 방식

이번에 가장 먼저 머릿속에 박힌 단어는 "FDE 모션(motion)"이었다.

"FDE 모션이란, FDE라는 직군을 어떻게 배치하고, 어떻게 고객사와 일하고, 어떻게 딜을 따고 제품을 적용해 나가는지에 대한 운영 방식 전체를 가리킨다."

"Sales Motion", "PLG Motion"처럼 영어권에서 익숙한 표현인데, 우리에게는 아직 낯설다. 중요한 건 FDE를 "사람" 단위가 아니라 "모션" 단위로 보면 회사마다 왜 정의가 다른지가 자연스럽게 설명된다는 점이다. 이번 행사의 절반 이상이 사실은 이 "모션의 차이"에 대한 이야기였다.

3. 회사마다 다른 FDE — Palantir · Gecko · Cognition

같은 "FDE"라는 이름 아래 회사마다 모션을 다르게 설계하고 있었다.

Palantir — Echo(Deployment Strategist) + Delta(FDE) 페어링

Palantir에서는 두 포지션이 한 팀으로 움직인다.

Echo (Deployment Strategist) — 고객사 의사결정자와 관계 형성, 제품 정의, 딜 메이킹 등 비즈니스·전략 영역
Delta (FDE) — 고객사 기술 담당자와 스펙 조율, 컨피규레이션, 실제 개발 수행

Palantir FDE의 첫 번째 일은 온톨로지 구축이다. 가장 작은 단위부터 정의해 데이터플로우를 만들고, 고객의 불명확한 요구사항을 제품에 맞게 변환한다. "지식을 어떻게 구조화할 것인가" 가 FDE의 출발점이라는 점이 인상 깊었다.

Gecko Robotics — 제로투원과 도메인 침투

Gecko Robotics는 제품 자체를 제로투원으로 만든다. 로봇으로 수집한 데이터의 기술적 이점을 PMF(Product-Market Fit)로 전환하는 것이 FDE의 미션. 교과서, 가이드라인, 공정 설계를 직접 읽으며 도메인 지식을 습득하고, 그것을 제품으로 구현한다. UAE 오일·가스 산업에서 엔지니어링 프로세스를 2~5개월 단축시켰다는 사례가 나왔다.

Cognition — AI가 FDE의 역할을 확장시켰다

가장 주목한 부분이다. Cognition에서는 AI 도구의 발전 덕분에 Delta가 Echo의 일까지 흡수하기 시작했다. 3,000억 원 규모 프로젝트의 의사결정자들을 만나고 사내 정치까지 파악하며, SCM·Jira·온프렘 시스템 등 인테그레이션을 커스터마이징한다.

리소스 투입 패턴도 인상적이다. 프로젝트 초기에는 FDE 공수의 약 90%를 투입하고, 고객이 온보딩되어 자립한 뒤에는 10% 수준으로 감소한다. FDE는 "들어가서 자립시키고 나오는" 모델에 가깝다.

4. FDE 모션의 단점 — 많이들 간과하는 것

이번 세미나에서 가장 인상 깊었던 건, 연사들이 FDE의 매력만큼이나 단점을 솔직하게 펼쳐 두었다는 점이다.

운영 코스트가 매우 크다. 고객에게 Over-fit된 가치를 주려면 그만큼 FDE를 채용해야 한다. 채용·해고가 자유롭지 않은 한국에서는 리스크가 더 크다.
업무량이 극단적으로 많다. 여러 지역 고객을 맡으면 주 15시간 이하로 일하는 주가 거의 없고, 주말 근무가 일상이며 번아웃이 빠르게 온다.
고객은 보통 자기가 뭘 원하는지 모른다. 그것을 Clarify 하는 일 자체가 FDE의 큰 부분이다.
다수 고객을 동시에 상대하면 벡터가 사방으로 퍼진다. 어떤 요구는 제품 방향성과 정면으로 어긋나기까지 한다.
한 번 들어가면 빠져나오기 어렵다. 이 부분은 뒤에서 다룰 "디펜던시" 문제와 곧장 연결된다.

이 단점 목록을 들으며, 우리 팀이 무리해서 FDE 모션을 흉내 내는 순간 가장 먼저 무너질 지점이 어디일지 떠올렸다.

5. FDE 모션 도입의 전제 조건

FDE 모션이 작동하려면 제품과 조직 양쪽이 함께 준비되어 있어야 한다.

제품 측면 — 커스터마이징 가능한 인프라
Palantir, Gecko, Cognition의 공통점은 제품을 "무조건 일반화(Generalize)"한다는 것이다. 로직을 하드코딩하지 않고, JSON/YAML 같은 설정값 중심으로 어느 고객에게도 통하도록 설계한다. 커스터마이징이 어려운 구조에서 FDE 모션을 굴리면, 결과물은 결국 쓰레기 코드와 Tech Debt로만 쌓인다.

조직 측면 — 명확한 의사결정자(Division)
다양성이 늘수록 "이 제품이 무엇을 위한 것인지"를 잊기 쉽다. 어떤 요구를 수용하고 어떤 요구를 배제할지 선언할 수 있는 한 명, 혹은 한 그룹이 반드시 필요하다.

이 두 조건은 사실 우리 팀 입장에서도 그대로 체크리스트가 된다. "우리는 일반화된 제품을 가진 팀인가?" "현업의 요청 중 무엇을 거절할 권한이 있는가?" — FDE 모션을 도입하기 전에 답해야 하는 질문이다.

6. 우리 팀에서 저절로 일어난 분화 — Delta와 Echo

이런 이야기들을 들으며 우리 팀을 돌아봤다.

처음에는 AX(AI Transformation)팀이 모든 것을 떠안으려 했다. AX팀이 도메인을 학습하고, 데이터를 정리하고, 자동화를 만들고, 조직 내 전파까지 담당하려 했다. 하지만 곧 한계가 드러났다. 더 많은 도메인 지식과 더 나은 그림을 그릴 수 있는 쪽은 결국 니즈를 가진 현업이었다. AX팀이 아무리 빠르게 학습해도, 현업의 암묵지에는 닿지 못하는 영역이 있었다.

결국 우리 팀은 AX에 필요한 데이터와 인터페이스를 발괴하고, 데이터 태깅을 제공하는 역할(= Delta)을 맡고, 해당 도메인의 전문가가 직접 사용법을 익혀 조직 안으로 전파하는 역할(= Echo)을 수행하게 됐다. 의도하지 않았는데 Delta와 Echo의 역할이 저절로 나뉘진 셉이다.

흥미로운 건, 채널톡에서도 같은 분화가 일어났다는 점이다. 채널톡은 미드마켓에 AX 컨설턴트(DS)가 직접 투입되고, FDE는 AX Ops로서 DS가 빠르게 세팅할 수 있도록 "공장"을 만든다. 결국 우리 팀의 분화는 우연이 아니라, 비슷한 문제를 푸는 조직에서 자연스럽게 도달하는 패턴에 가깜다.

행사에서 제시된 "AX FDE = 고객의 입장에서 일하는 방식을 AI Native로 바꾸는 역할"이라는 문장은, 우리 팀의 방향을 가장 또렷하게 요약해 주었다.

7. K-FDE — 한국형 운영 모델

한국 맥락에서 FDE는 또 다른 얼굴을 한다.

K-FDE 사례 A — defytheodd 이선민 님

6개월 페이즈 1 후 주 5일 → 주 1일 전환에 성공
멀티 에이전트 시스템을 레거시에 통합, 24시간 자동 룰 수집·패턴 분석
초기 라포 형성 단계에서는 회식·야근·음주가 K-FDE의 정체성이라고 농담처럼 말했지만, 농담만은 아니다

K-FDE 사례 B — SpaceY 황현태 님

3개월 계약을 1~2주 만에 완료하고, 남은 시간에 AX 컨설팅으로 전환
2인 팀 구성 — 한 명은 FDE 기술, 한 명은 조직문화 파악과 멘탈 서포트
폐쇄망, SAP-ERP 연동 등 선배 개발자들의 우려에 휴먼 리더블(human-readable) 코드로 대응
A팀장·B팀장·회장의 우선순위를 파악해 리소스 재분배

여기에 향로 님이 정리한 한국 FDE의 구조적 한계를 겹쳐 보면 K-FDE가 단순한 농담이 아닌 이유가 분명해진다.

온프렘 비중이 높다. SaaS로 빠르게 배포하지 못하고 백엔드를 직접 가서 바꿔야 한다. FDE의 강점인 속도가 죽는 구조다.
위계적 조직 문화. 경력 낮은 FDE가 전무급에게 "이건 이렇게 해야 합니다"라고 직접 말하기 어렵다. 그래서 한국·중동에서는 "나보다 높은 직급의 사람을 미리 설득해 미팅에 모셔오는" 우회 전략이 필요하다.
엔터프라이즈 조직 경험 부족. 젊은 FDE가 대기업 의사결정 구조를 파악하기 어려워, 2인 팀이 거의 필수가 된다.

K-FDE는 이런 구조적 제약 위에서 진화해 온 한국형 운영 모델이다. 한국에서 FDE는 엔지니어 + 컨설턴트 + 조직 리더의 교집합에 가깝다.

8. 엔터프라이즈 AX의 세대론

한 세션에서 정리된 AX 진화 단계가 깔끔했다.

세대	전략	한계
1세대	사내 AX팀이 모든 현업 문제를 해결	지속 불가능 (사실상 평생 운영해야 하는 모델)
2세대	전 직원에게 Claude Code 교육	주니어 이탈 발생
3세대	부서 단위 AX — 한 달에 80개 자동화 구현	조직 차원 확산 속도 이슈
4세대 (현재)	꼭지점 AX — 팀 리더를 AI Native Builder로	리더가 바뀌면 팀이 바뀐다

우리 팀이 어디 세대에 있는지 돌아보게 됐다. 1세대에서 2~3세대로 가는 길목, 4세대를 준비해야 하는 시점이다. "팀장만 AI Native가 되어도 팀이 바뀐다"는 명제는, 우리가 다음 분기 로드맵에서 누구를 가장 먼저 끌어와야 하는지를 명확히 가리키고 있었다.

9. 워크스피어 사례 — "임원 우선 AX"라는 다른 답

세대론과 별개로, 워크스피어 김요섭 CTO의 발표는 또 다른 답을 보여줬다. 임원부터 바꿈다는 Top-down 전략이다.

전사 약 550명, 비프로덕트 조직 약 250명 규모
임원 12명에게 Claude Code 기반 에이전트 20개씩 제공, 본인·조직 업무를 먼저 AX
주간 보고를 AI 에이전트 기반으로 실시간 전환
그다음에야 FDE 팀이 비개발 직원 팀 단위로 투입

핵심 논리는 단순했다. "개발 도구만 바꿔서는 생산성이 안 오른다. 일하는 방식과 직무 정의 자체를 다시 설계해야 하는데, 임원이 AX 되지 않으면 그 변화가 작동하지 않는다."

세대론의 4세대(꼭지점 AX)가 "팀 리더"를 꼭지점으로 본다면, 워크스피어는 그 꼭지점을 더 위로 올려 "임원"으로 잡았다. 우리 팀에 이 모델을 그대로 옮기긴 어렵지만, "현업 리더 한 명을 진짜로 AI Native로 바꾸는 것이 자동화 100개보다 가치 있다"는 메시지는 분명히 가져갈 수 있는 통찰이었다.

10. 전사 AX, 그리고 남은 숙제들

회사 전체를 AX한다는 목표 앞에는 풀어야 할 문제가 많다.

사내 전체 데이터를 어떻게 모으고 관리할지 — 거버넌스
방대하고 다양한 데이터를 빠르게 서빙할 인터페이스
Knowledge Graph를 어떤 방식으로 구성할지
성과를 어떻게 측정할지

벡터DB는 더 이상 정답이 아니다

예전에는 "벡터DB는 반드시 써야 한다"는 강박이 있었다. 하지만 100% RAG 구성이 정말 효율적인지는 의문이고, 최근에는 Markdown 파일을 잘 쌓고 태깅하는 방식으로 관리하는 팀도 있다. Karpathy의 미니멀 도구들(LLM Wiki, Auto Research, Karpathy Loop)이 효과를 내고 있다는 발표도 같은 맥락이다.

이제 벡터DB는 완전한 정답이 아니다. 지식에 어울리는 구조로 쌓아야 한다. RAG, CAG, Graph DB, pgvector, 혹은 RDB까지 — 어떤 지식에서 어떤 방식이 적합한지는 앞으로 테스트하며 찾아갈 문제다. 우리 팀도 사실 작년에 "일단 벡터DB부터"라는 결정으로 시작했었는데, 1년이 지난 지금은 어떤 데이터는 그냥 RDB가 더 낫고, 어떤 데이터는 Markdown이 더 낫다는 감각이 쌓이고 있다.

Context Graph의 첫 단추는 "정의 통일"

한 세션에서 가장 현실적인 문장이 나왔다.

"A팀의 '매출'과 B팀의 '매출'이 다르게 해석된다. 그래서 Data Catalog로 정의부터 통일한다."

Context Graph라는 거창한 개념이, 사실은 부서별 용어 통일에서 시작된다는 감각. 누가·어떤 조직·어느 시점·어떤 상황에서 발화한 지식인지를 태깅하는 것. 이건 기술 문제가 아니라 조직의 언어를 정렬하는 문제다. 워크스피어가 SAP에 직접 붙지 않고 Data Lake를 중간 허브로 두는 방식도, 결국 "전사가 같은 데이터를 같은 정의로 본다"는 같은 방향의 해법이다.

측정도 쉽지 않다

워크스피어는 Claude Code 도입 성과를 3레이어로 본다.

토큰 사용량 리더보드 — 사용했는가
컨텍스트 인프라 사용 품질 — 잘 쓰고 있는가
DORA 메트릭 — 결과적으로 생산성이 올랐는가

하지만 결국 강조한 건 "정교한 측정보다 명확한 아웃컴 기반 평가가 효율적"이라는 것. 개발 조직은 벨로시티, 비개발 조직은 실행력 향상. 이 선이 현실적이다. 우리 팀도 한동안 측정 인프라를 만드는 데 공수를 너무 많이 썼는데, "측정을 측정하는" 함정에 빠지지 않으려면 이 감각이 필요하다.

11. 노이즈 95%의 시대 — 무엇을 버리고 무엇을 남길 것인가

이선민 님이 던진 한 문장이 오래 남았다.

"노이즈가 95%인 시대다. 그 노이즈를 Align해 주는 것이 FDE의 역할 중 하나다."

같은 세션에서 본인이 직접 정리한 "버린 것 / 남긴 것" 리스트가 인상적이었다.

버린 것: Hermes Agent. "OpenFlow보다 낫다"는 말로 시도했지만, 본인 레거시 환경에는 맞지 않았다. Self-improving이라는 말과 달리 결국 노가다가 들어갔다.
남긴 것: Karpathy의 한 장짜리 도구들과 그 철학을 계승한 오픈소스. 코드베이스에 적용 즉시 토큰 사용량과 목표 달성 시간이 모두 줄었다.

황현태 님의 발언도 같은 맥락이었다. "기술적 하입에는 관심 없다. 핵심은 문제 해결이고, 문제 파악보다 더 어려운 것이 엔터프라이즈의 이해관계자 지형 파악이다."

FDE의 진짜 일은 새로운 도구를 빠르게 시도하고, 아닌 건 즉시 버리는 사이클을 본인 안에 갖는 것에 가깝다. 이 감각은 우리 팀에도 그대로 적용된다. 신기술의 90%는 결국 우리 팀 데이터·조직·고객에 맞지 않는다. 그것을 솔직하게 인정하고 빠르게 흘려보내는 능력이, 1년이 지난 뒤 팀의 자산을 결정한다.

12. 기술 너머, 진짜 벽은 암묵지다

여기까지는 기술이 해결할 수 있는 영역이다.

하지만 Context Graph를 제대로 구축하려면 결국 각 부서의 암묵지를 어떻게 형식화할 것인가로 귀결된다. 기술자는 이 암묵지를 어떻게 공통화하고 부여할지 고민하며, 그에 맞는 적당한 인터페이스를 설계해야 한다.

한 연사의 말이 인상 깊었다.

"지식 매니저 역할이 다시 부활하고 있다. 코드 PR처럼, 지식 변경사항도 리뷰 가능한 단위로 관리해야 한다."

암묵지를 다루는 일이 소프트웨어 엔지니어링의 언어로 재조립되고 있다는 신호다. FDE가 푸는 문제가 점점 "지식의 버전 관리"와 가까워진다는 뜻이기도 하다. 우리 팀에서도 최근 "이 자동화는 누구의 어떤 판단 기준 위에 서 있는가"를 함께 기록하기 시작했는데, 이게 곧 우리 식의 Context Graph 0.1버전이 되어 가고 있다.

그리고 실제로 그 방향의 도구들이 움직이고 있었다. 시퀀스 배치와 Human-in-the-loop 설정을 GUI로 편집할 수 있는 Harness Editor, 프로세스를 시각화·표준화해서 FDE 의존성을 낮추는 장치들. 이런 도구가 성숙해질수록 "FDE가 나가면 프로젝트가 멈춘다"는 만성적 문제도 줄어들 것이다.

FDE의 진짜 일은, 어쩌면 여기서부터 시작되는 것 같다.

13. SDLC에서 Context-DLC로

가장 큰 프레임을 건드린 문장도 있었다.

"SDLC(Software Development Life Cycle)는 이제 AI-DLC, 혹은 Context-DLC로 재정의된다."

코드를 짜는 라이프사이클이 아니라, 컨텍스트를 설계·관리·전달하는 라이프사이클이 새로운 기본값이 된다는 말이다. 프론트엔드·백엔드의 직무 구분을 넘어 자사만의 새로운 "Arena"와 직무 정의가 필요하다는 논의도 같은 맥락이었다.

CTO의 역할조차 "개발 조직 아키텍처를 설계하는 사람"에서 "사람과 AI가 협업할 구조를 설계하는 사람"으로 전환되고 있다는 워크스피어의 언급은, 이 흐름을 가장 직접적으로 요약한다. 우리 팀의 그림도 결국 같은 방향이다. "어떤 코드를 짤 것인가"보다 "어떤 컨텍스트를 어떤 형식으로 쌓을 것인가"가 다음 분기의 진짜 질문이 된다.

14. 왜 이런 자리가 필요한가

행사장에서 가장 자주 들린 질문은 "그래서 FDE가 정확히 뭐 하는 사람이에요?"였다.

정답이 아직 정해지지 않은 직무이기에, 각자의 답을 들고 모이는 것 말고는 방법이 없다. 실리콘밸리의 FDE, 한국의 K-FDE, 엔터프라이즈의 FDE, 스타트업의 FDE — 모양은 조금씩 달라도 결국 고객 현장에서 AI Native 방식으로 가치를 만드는 사람이라는 공통점은 또렷했다.

이 공통점을 한 번 더 확인할 수 있었다는 것만으로도 좋은 자리였다. 이런 모임이 계속 이어지면 좋겠다.

맺음 — 다음은 우리 차례

돌아오는 길에 정리한 내 답은 이렇다.

FDE는 고객의 문제를 푸는 엔지니어다. 하지만 이 시대의 FDE는 "고객이 일하는 방식을 AI Native로 바꾸는 사람"이다. 컨텍스트를 설계하는 사람이다.

다음 FDE Night에서도 또 배우고 싶다. 그때까지 우리 팀은 우리만의 Context Graph를 한 걸음씩 쌓아 두려 한다.

자리를 만들어주신 분들, 그리고 귀한 인사이트를 나눠주신 연사분들께 깊이 감사드린다.

참고

퓨처콘 5th 참여 후기

귤랑귤랑 — Fri, 26 Dec 2025 23:22:47 +0900

참여자 전원 찰칵

지난 11월 30일, 퓨처콘 프론트엔드 행사에 운영진으로 참여했습니다.
이전 회차에서는 참가자로 많은 자극을 받았던 행사였고, 그만큼 이번에는 도움을 받는 입장이 아니라 조금이나마 기여해보고 싶다는 마음으로 지원하게 되었습니다.

운영진으로 참여해보니, 행사를 ‘참여하는 것’과 ‘만드는 것’은 확실히 다르다는 걸 느꼈습니다.
참가자일 때는 잘 보이지 않던 수많은 세세한 결정들과 준비 과정들이 있었고, 그런 요소들이 모여 하나의 경험을 만든다는 것을 알게 되었습니다. 저는 이번이 운영진을 처음 도전해본 것인데 이전에 여러 번 행사를 주최해본 경험이 많으신 운영진 분들과 이야기하면서, 제게 부족했던 관점이나 시야를 많이 채워가는 느낌도 받았습니다.
제가 얼마나 도움이 되었는지는 모르겠지만, 이런 고민을 직접 해볼 수 있었다는 것만으로도 제게는 의미 있는 경험이었습니다. 처음에는 도움을 주고 싶은 입장에서 시작하였지만 오히려 제가 더 많이 배웠다고 느꼈습니다.

행사을 진행하며 자유 토론 시간에 많은 이야기를 나누었는데, 특히 업무에서 AI를 어떻게 활용하고 있는지에 대한 이야기가 인상 깊었습니다.
AI를 활용해 문서를 자동으로 정리하고 프로젝트 전반을 RAG 형태로 구성해 검색 가능하게 만든 사례, 코드 리뷰를 자동화한 사례 등을 들을 수 있었습니다.
단순히 “AI를 쓴다”는 수준을 넘어, 실제 업무 흐름 안에서 어떻게 녹여내고 있는지를 알 수 있어 흥미로웠습니다.

자유 토론 시간에는 소프트 스킬에 대한 이야기도 많이 오갔습니다.
주니어에서 시니어로 성장할수록 기술적인 성장만큼이나 소프트 스킬의 역량 또한 중요해진 다는 점에서 공감이 갔습니다. 소프트 스킬은 단기간에 키울 수 있는 영역이 아니므로 결국 지금부터 차근차근, 내가 부족한 부분을 인식하고 채워나가야 한다는 생각이 들었습니다.
커뮤니케이션에 대한 이야기를 하며, ‘동기면담’을 통해 사람들에게 동기를 부여하고 감정적으로 공감하며 팀의 문화를 이끌어갈 수 있다는 이야기를 들었습니다. 이 부분에 호기심을 가지게 되었고, 이후 따로 동기면담 온라인 세션에 참여하고 관련 책을 읽어보는 계기가 되기도 했습니다. 저에게 부족한 부분이 많다는 것을 깨닫고 기술 외적인 영역에서도 계속해서 배우고 싶다는 마음이 커졌습니다.

이번 퓨처콘 행사는 개발자들과 고민을 나누고 자유롭게 토론하는 것 자체로도 재미있었고, 앞으로 어떤 방향으로 성장하고 싶은지 다시 생각해보게 만든 시간이었습니다.
주어진 일에만 머무르기보다, 문제를 정의하고 정리하며, 기술과 사람 사이를 연결할 수 있는 엔지니어로 조금씩 성장해가고 싶습니다.

행사를 함께 만들어주신 운영진 분들, 그리고 좋은 주제로 이야기를 나눠주신 발표자와 참가자 분들께 감사드립니다!

운영진 찰칵~

다들 베테랑 운영진들이셔서 행사를 준비할 때 많은 도움이 되었다. 나는 준비할 때는 별로 도움이 못된 것 같아서 당일에 현장에서 발로 뛰는 것으로 대신...ㅠㅠ

참여자 기념 굿즈 수제 제작중

참여자 굿즈를 수제로 제작해보는 것도 쏠쏠하게 재밌었다ㅎㅎ

[회고] React API 공식문서 다 읽었다

귤랑귤랑 — Wed, 11 Jun 2025 23:29:30 +0900

참여 기간: 2024년 11월 ~ 2025년 5월 (6개월)
스터디 주제: React 공식 문서 읽기
참여 동기: 퓨처콘 행사에서 React 공식문서 발표를 듣고 체계적인 학습의 필요성을 느낌
목표: React API 문서 독파
진행 방식: 4인 그룹, 1인 1문서 발표, 회차당 2시간 (30분 발표 + 토론), AI 도구 적극 활용
학습 범위: React API 참고서
기록: 스터디 노션 페이지

참여 계기

'We are the future!' 프론트엔드 커뮤니티의 퓨처콘 행사에서 'React 공식문서'에 대한 발표를 듣고 공식문서 스터디에 관심을 갖게 되었습니다.

React 개발자이면서 공식 문서를 체계적으로 정독해본 적이 없다는 사실이 부끄럽게 느껴졌고, 이번 기회에 제대로 학습해보고자 스터디에 참여하게 되었습니다.

공식 문서 스터디를 진행하고 싶거나 참고하고 싶은 분들을 위해 진행 방식을 공유해보려고 합니다. AI를 적극 활용하여 학습하였고 이 방법이 많은 도움이 되었다고 생각합니다.

진행 방식

React API 문서를 기반으로 1인당 1개 문서를 배정받아 학습한 후, 스터디 모임에서 발표하는 방식으로 진행했습니다. 총 4명이 참여하여 문서당 30분씩 발표와 토론 시간을 가졌고 매회 2시간씩 진행했습니다.

도구 활용

1. Greptile을 통한 React 소스코드 분석

AI 도구인 Greptile의 Chat 기능을 활용하여 React 소스코드를 분석하며 학습했습니다.

이 도구의 가장 큰 장점은 GitHub 레포지토리를 기반으로 질문할 수 있다는 점입니다. 공식 문서에서 설명하는 개념의 실제 구현체를 찾아보고, 코드 레벨에서 동작 원리를 살펴볼 수 있었습니다.

예를 들어, 동시성 렌더링에 대해 질문하면 실제 React 소스코드를 기반으로 한 답변을 받을 수 있고, 해당 코드가 위치한 파일로 직접 이동하여 전체 코드도 확인할 수 있습니다. 이를 통해 문서로만 접했던 개념들을 구체적인 구현체와 함께 학습할 수 있었습니다.

Greptile chat

2. Perplexity Deep Search를 통한 질의 응답

스터디를 진행하다 보면 모든 참여자가 막히는 순간들이 있었습니다. 이럴 때는 Perplexity의 딥서치 기능을 활용하여 신뢰할 수 있는 출처를 기반으로 한 답변을 얻을 수 있었습니다. 단순한 검색과 달리 여러 자료를 종합하여 근거 있는 설명을 제공해주어 깊이 있는 이해에 도움이 되었습니다.

3. Cursor를 활용한 실습 코드 작성

새로운 개념에 대한 활용이 궁금한 경우 Cursor AI에게 해당 개념을 활용한 실습 예제를 요청했습니다. 이를 통해 이론으로만 이해했던 내용을 실제 코드로 구현해보며 더 구체적으로 학습할 수 있었습니다.

useTransition과 flushSync 방식에서 Suspense fallback 동작 차이

서버 컴포넌트 직렬화와 RSC Payload 시각화

4. Notion을 활용한 체계적 기록 관리

이전에 디스코드로 다른 스터디를 진행한 적이 있는데 공부한 내용은 GitHub에, 추가 조사 내용은 채팅과 스레드에 기록했습니다. 이렇게 하였을 때, 정보가 분산되고 채팅 내용이 유실되어 나중에 다시 찾아보기 어렵다는 단점이 있었습니다.

이번 스터디에서는 처음부터 Notion에 체계적인 구조를 만들어 진행했습니다. 각 문서별로 페이지를 만들고, 학습 내용과 느낀 점을 댓글로 남겨 나중에도 쉽게 찾아볼 수 있도록 했습니다. 이로 인해 스터디 당시의 기억을 다시 한 번 상기할 수 있다는 장점이 있었습니다. (문서는 리더이신 정민님께서 작성해주셨습니다.)

문서를 리스트업 하고 추가 내용은 댓글로 관리

기억에 남는 주제

React DOM APIs: createRoot, hydrateRoot 등의 기본 렌더링 API
React Hooks: useState, useEffect, useContext 등 기본 훅부터 useDeferredValue, useTransition 등 동시성 훅까지
React 19 신규 APIs: use, useOptimistic, useActionState 등
Server Components: RSC 아키텍처와 구현 방식
Server Actions: 폼 처리와 서버 상태 업데이트
React 동시성 렌더링과 Lane 시스템: 우선순위 조절, 비트마스크를 활용한 스케쥴링 매커니즘

회고 및 느낀점

이전에는 "공식 문서는 필요할 때 찾아서 보면 된다"고 생각했습니다. 라이브러리는 지속적으로 업데이트되는데, 지금 읽어봤자 나중에는 의미가 없어지지 않을까 생각했기 때문입니다.

하지만 체계적으로 읽어보니 생각이 완전히 바뀌었습니다. React의 전체적인 그림을 이해할 수 있었고, 각 API의 존재 이유와 적절한 사용 시점을 알 수 있었습니다. 특히 사용자가 주의해야 할 내용들이 상세히 설명되어 있고, CodeSandbox를 통해 직접 실행 결과를 확인할 수 있게 한 점에서 어떤 책보다도 친절한 공식문서라는 것을 깨달았습니다.

책 스터디와 달리 공식 문서는 React와 직접 연관되어 있어 가장 최신 정보를 받아볼 수 있다는 점도 큰 장점이었습니다. 실제로 스터디 진행 중 React 19가 출시되면서, v18에서의 변경점을 통해 React가 추구하는 방향성을 실시간으로 이해할 수 있었습니다.

무엇보다 이해한 내용을 말로 정리하고, 스터디원들과 질의응답하는 과정이 학습에 큰 도움이 되었습니다. 다른 사람의 질문을 통해 미처 생각하지 못했던 관점들을 발견할 수 있었고, 실제 코드리뷰할 때도 그 효과를 체감할 수 있었습니다.

스터디를 마친 지금, 모든 내용을 100% 기억하고 있지는 않지만, 어떤 문제가 생겼을 때 어디서 해답을 찾을 수 있는지는 알게 되었습니다. 단순히 라이브러리 사용법을 익히는 것을 넘어서, React 팀의 철학과 방향성까지 함께 이해할 수 있었던 것이 가장 큰 수확입니다.

6개월이라는 긴 여정이었지만, 함께 학습하고 토론할 수 있는 좋은 동료들이 있었기에 완주할 수 있었습니다!

Lottie-web의 Node.js v21 이상 버전 SSR 이슈

귤랑귤랑 — Wed, 11 Jun 2025 11:05:09 +0900

Lottie-web 라이브러리를 Node 21 이상에서 실행했을 경우 발생한 문제와 해결방안에 대해 설명합니다.

문제 상황

lottie-web이 SSR(Server Side Rendering) 환경에서 'document is not defined' 오류가 발생합니다.

// 문제가 발생하는 코드 (Node v21 이상에서 에러 발생)
import lottie from 'lottie-web'  

const handler = useCallback(async() => {
  lottie.loadAnimation()
})

이슈 원인

Node.js v21 이상부터 발생
lottie-web v5.13.0 에서 수정 반영 되었으나 패키지의 release 문제로 여전히 오류 발생

왜 이런 문제가 발생했을까요? lottie.js에 답이 있습니다.

이슈 상세

lottie는 클라이언트에서만 실행되도록하는 방어로직을 navigator 유무로 체크합니다.

하지만 Node.js 21부터 서버사이드에도 navigator가 추가 되었기 때문에 오류가 발생합니다.

아래 PR에서 논의되고 있으니 관심이 있다면 살펴보셔도 좋습니다.
https://github.com/airbnb/lottie-web/pull/3096

fix: document validation for SSR by IcaroG · Pull Request #3096 · airbnb/lottie-web

Fixes #2739 #3047 #3077

github.com

lottie에서 어떻게 수정 반영 했는지 알아보겠습니다.

// 기존
(typeof navigator !== 'undefined') && /* lottie 코드 */

lottie 5.13.0 이전 버전까지는 navigator 유무로 브라우저 환경과 Node.js 환경을 구분합니다.
Node.js v21 이전에는 서버에서 navigator 객체가 없기 때문에 옳은 조건이지만 Node.js v21 이후에는 navigator 객체가 존재하기 때문에 런타임 에러가 발생합니다.

lottie 5.13.0 부터 아래와 같이 document도 확인하는 코드가 추가되었습니다.

// Node v21 대응, lottie-web v5.13.0 이후
(typeof document !== 'undefined') && (typeof navigator !== 'undefined') && /* lottie 코드 */

5.13.0 버전에서 패치되었으나 release 에서 문제 발생하여 아직 반영이 안되었다고 합니다

만일 꼭 Node21 이상을 사용해야한다면, lottie-web에서 이 문제가 해결될 때까지는 dynamic import 방식을 사용하면 오류를 피할 수 있습니다.

// dynamic import로 실행 시 오류 발생하지 않음
const handler = useCallback(async() => {
  const { default: lottie } = await import('lottie-web');
  lottie.loadAnimation()
})

실제 코드를 보고 싶다면 아래 링크에서 확인할 수 있습니다.

기존 코드

lottie-web

After Effects plugin for exporting animations to SVG + JavaScript or canvas + JavaScript. Latest version: 5.13.0, last published: 20 days ago. Start using lottie-web in your project by running `npm i lottie-web`. There are 915 other projects in the npm reg

www.npmjs.com

Node v21 대응 코드

lottie-web/build/player/lottie.js at bede03d25d232826e0c9dca1733d542d8a7754fb · airbnb/lottie-web

Render After Effects animations natively on Web, Android and iOS, and React Native. http://airbnb.io/lottie/ - airbnb/lottie-web

github.com

[회고] 2025년 1분기 만다라트

귤랑귤랑 — Sun, 30 Mar 2025 01:10:15 +0900

2024년 한 해 동안 만다라트 모임을 진행했었고, 한 달의 생활을 돌아보는 시간이 의미 있다는 생각이 들어 올해도 같은 멤버들과 만다라트 모임을 이어오고 있다.
1년 동안 만다라트를 해오면서 터득한 나만의 팁이 있는데, 바로 한 해 동안 해야 할 일을 너무 구체적으로 잡지 않는 것이다. 구체화하는 데 시간도 많이 들고, 시간이 지나면서 시행착오를 거치며 내 생활 방식에 맞게 목표도 변경되기 때문이다. 그래서 큰 틀의 목표만 잡고, 나머지 세부적인 계획은 해당 달에 구체적으로 작성하고 회고하는 방식으로 진행하고 있는데, 이 방식이 나에게 더 잘 맞는다고 느낀다 :) 만다라트의 의미는 내가 가야 할 목표 지점을 향해 이정표를 주는 것이기 때문에, 처음부터 너무 빡빡하게 잡아서 실천하려고 하는 것보다 어느 정도 러프하고 유동적으로 진행하는 것이 더 좋았다. 아무튼, 1분기에 내가 이룬 것은 다음과 같다.

분기 결산

개발 및 공부

사이드 프로젝트
- 여행 앱 (진행 중이며 2차 런칭을 앞두고 있음)
- 그동안 써보고 싶었던 방식을 잔뜩 취향에 맞게 써보는 중
AWS 자격증 응시
사내 프롬프톤 참여
- LLM + RAG 로 벡터 검색 구현
- 3등 수상
스터디
- 리액트 공식문서 스터디 (70% 진행)
- 리액트 딥 다이브 스터디 (완료)
- 알고리즘 스터디 (시작)
- RAG 스터디 (시작)
- 모던 자바스크립트 딥 다이브 (시작) : 책 저자가 개최하는 스터디라 너무 궁금하다
- 1주일 1회 글쓰기 챌린지 (50% 진행)

영어

스픽
- 일단 수업을 따라 가고 있는데, 말하고 싶은 주제를 찾아서 연습해보는게 좋을듯

커뮤니티

링크드인 첫 게시글 업로드
직장 동료분과 커피챗 후 별도 개발자 모임 참석
- 자기 계발과 발전에 관심이 많은 분을 만나 좋은 에너지를 받았고 모임도 초대 받아서 참석함. 세상에는 잘하는 사람들이 너무 많고, 앞으로 더 노력해야 이 직업을 유지할 수 있겠다는 생각을 가짐
자바 카페 스터디 참석
- 이번 기수는 쉬어가는 느낌으로 리더가 아닌 팀원으로 참여 (과연 쉬어가는 게 맞을지...)
지인 추천으로 이력서 넣어봄. 이전에 스터디에서 뵈었던 분인데 감사하게도 연락 주심. 아직 결과는 없음.

취미

뮤지컬 관람
커피 취미가 강화되어 새 전기포트와 그라인더 구매! 매우 만족

아쉬웠던 점

재테크 공부를 더하지 못함
- 재테크 디스코드 방에 들어가보긴 했는데… 아직 무슨 말인지 잘 모르겠는게 더 많음. 기본 공부부터 해야겠다…
운동 시작하지 못함
블로그/링크드인 등의 기록을 꾸준히 하지 못함 (벌써 써야할게 한가득…)
블로그 글을 쓰기 챌린지를 시작했는데 생각보다 의미 있는 글쓰기를 하지 못하는 중
- 스터디와 병행하면서 1주일 1개는 좀 벅차다
영어 공부에 전혀 집중하지 못했다… 일상 생활에 스며들듯이 하고 싶은데 아직 흥미있는 컨텐츠를 못찾음
무릎과 위장 건강이 악화되었다. 건강에 신경 쓸 것.

다음달에 주력할 점

RAG 스터디, 리액트 공식문서 스터디, 자바스크립트 딥 다이브 스터디
- 알고리즘 스터디는 새로 시작할 스터디와 시간이 겹쳐 드랍 할 듯...

전반적으로 개발 스터디에 시간을 투자하고 집중하는 1분기였다. 그런데 앞으로도 배워야 할 것들이 많아서 걱정이다. 아직도 실력이 많이 부족하다고 느끼고 초조하다.
재테크에 대해 아예 무지했는데, 어느 정도 들여다보고 소액 투자를 시작해서 소소하게 수익을 얻은 것에 만족하고 있다. 관심을 가지게 된 것에 감사해야겠다. 역시 나 같은 초보자가 돈을 모을 수 있는 가장 좋은 방법은 저축이다.
예전에는 휴식할 때 죄책감을 가지고 뭐라도 하려고 했었다. 예를 들어, 교통 시간을 아껴서 책을 읽는다든지 아티클을 읽는다든지 했다.
그런데 사내 동료분과 커피챗을 한 후로 휴식의 중요성에 대해 깨달은 바가 있어, 요즘은 그런 시간에 좋아하는 영상을 보거나 그냥 자는 등 휴식으로 채우고 있다. 이렇게 하니 스트레스가 줄어들고 집중도가 높아졌다. 1분기는 좀 쉬었기도 하고, 다음 달부터는 새 스터디를 시작하니 교통 시간을 활용해서 뭐라도 조금 해봐야겠다.

Cursor MCP 공식문서 읽어보기

귤랑귤랑 — Sun, 23 Mar 2025 22:38:37 +0900

요즘 MCP에 대한 주목이 높아졌다는걸 체감하고 있습니다. 개발자와 스몰토크 나누면 꼭 나오는 주제이기도 하고요.

이미 현업에서 업무 생산성을 높이기 위해 적용한 사례도 들려오고 있습니다.

하지만 저는 아직 MCP를 어떻게 사용할 수 있을지 감이 안잡히지 않더라고요. 따라서 공식 문서와 튜토리얼을 보면서 천천히 적용해보려 합니다.

Cursor AI를 IDE로 사용중인데 Cursor에서 MCP를 지원한다고 하네요. Claude Desktop을 사용한다면 간편하게 구축할 수 있어 보이는데, 저는 Cursor에서 적용해 보고 싶습니다.

일단 Cursor에서 MCP를 사용하기 위해서는 0.45.x이상의 버전이 필요하니 업데이트를 꼭 해주세요. https://www.cursor.com/changelog

저는 0.47.x 버전을 사용중입니다.

일단 이번 시간은, 가볍게 Cursor 공식문서에 작성된 MCP 페이지를 읽어보도록 하겠습니다.

모델 컨텍스트 프로토콜(MCP)

MCP란 무엇인가?

모델 컨텍스트 프로토콜(MCP)은 애플리케이션이 LLM에 컨텍스트와 도구를 제공하는 방법을 표준화하는 오픈 프로토콜입니다. MCP는 Cursor의 플러그인 시스템으로 생각할 수 있으며, 표준화된 인터페이스를 통해 다양한 데이터 소스와 도구에 Agent를 연결하여 기능을 확장할 수 있게 해줍니다.

용도

MCP를 사용하면 Cursor를 외부 시스템 및 데이터 소스에 연결할 수 있습니다. 이는 코드 외부에서 프로젝트 구조를 Cursor에 설명할 필요 없이 기존 도구와 인프라에 Cursor를 통합할 수 있음을 의미합니다.

MCP 서버는 stdout에 출력하거나 HTTP 엔드포인트를 제공할 수 있는 어떤 언어로도 작성할 수 있습니다. 이러한 유연성 덕분에 선호하는 프로그래밍 언어와 기술 스택을 사용하여 MCP 서버를 빠르게 구현할 수 있습니다.

예시

데이터베이스: Cursor가 스키마를 수동으로 입력하거나 데이터를 직접 조작하는 대신 데이터베이스를 직접 쿼리할 수 있습니다.
Notion: Cursor가 기능을 구현하도록 안내하기 위해 Notion에서 데이터를 읽을 수 있습니다.
GitHub: Cursor가 PR 생성, 브랜치 생성, 코드 찾기 등을 할 수 있습니다.
메모리: Cursor가 작업하는 동안 정보를 기억하고 회상할 수 있습니다.
Stripe: Cursor가 고객 생성, 구독 관리 등을 할 수 있습니다.

아키텍처

MCP 서버는 표준화된 프로토콜을 통해 특정 기능을 노출하는 경량 프로그램입니다. Cursor와 외부 도구 또는 데이터 소스 사이의 중개자 역할을 합니다.

Cursor는 MCP 서버에 대해 두 가지 전송 유형을 지원합니다:

stdio 전송

로컬 머신에서 실행
Cursor에 의해 자동으로 관리됨
stdout을 통해 직접 통신
로컬에서만 접근 가능
입력: Cursor가 자동으로 실행하는 유효한 셸 명령어

SSE 전송

로컬 또는 원격으로 실행 가능
사용자가 관리하고 실행
네트워크를 통해 통신
여러 머신 간에 공유 가능
입력: MCP 서버의 /sse 엔드포인트 URL

stdio 서버의 경우, 명령어는 Cursor가 실행할 수 있는 유효한 셸 명령어여야 합니다.
SSE 서버의 경우, URL은 SSE 엔드포인트의 URL이어야 합니다(예: http://example.com:8000/sse).

각 전송 유형은 다른 사용 사례를 가지며, stdio는 로컬 개발에 더 간단하고 SSE는 분산 팀에 더 많은 유연성을 제공합니다.

MCP 서버 구성

MCP 구성 파일은 다음 구조의 JSON 형식을 사용합니다:

// stdio 형식을 사용하는 MCP 서버 예시
// Cursor가 자동으로 이 프로세스를 실행
// Node.js 서버를 `npx`로 실행
{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "mcp-server"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

env 필드를 사용하면 MCP 서버 프로세스에서 사용할 수 있는 환경 변수를 지정할 수 있습니다. 이는 API 키 및 기타 민감한 구성을 관리하는 데 특히 유용합니다.

구성 위치

사용 사례에 따라 이 구성을 두 위치에 배치할 수 있습니다:

프로젝트 구성: 프로젝트별 도구의 경우, 프로젝트 디렉토리에 .cursor/mcp.json 파일을 생성합니다. 이렇게 하면 특정 프로젝트 내에서만 사용 가능한 MCP 서버를 정의할 수 있습니다.
전역 구성: 모든 프로젝트에서 사용하려는 도구의 경우, 홈 디렉토리에 ~/.cursor/mcp.json 파일을 생성합니다. 이렇게 하면 모든 Cursor 작업 공간에서 MCP 서버를 사용할 수 있습니다.

Agent에서 MCP 도구 사용하기

Composer Agent는 MCP 설정 페이지의 Available Tools 아래에 나열된 MCP 도구가 관련성이 있다고 판단되면 자동으로 사용합니다. 의도적으로 도구 사용을 유도하려면 이름이나 설명으로 도구를 참조하여 Agent에게 도구를 사용하도록 지시하면 됩니다.

도구 승인

기본적으로 Agent가 MCP 도구를 사용하려고 할 때, 승인을 요청하는 메시지가 표시됩니다. 도구 이름 옆의 화살표를 사용하여 메시지를 확장하고 Agent가 도구를 호출하는 인수를 확인할 수 있습니다.

Yolo 모드

Yolo 모드를 활성화하면 Agent가 터미널 명령어가 실행되는 방식과 유사하게 승인 없이 MCP 도구를 자동으로 실행할 수 있습니다.

도구 응답

도구가 사용되면 Cursor는 채팅에 응답을 표시합니다. 이 이미지는 샘플 도구의 응답과 도구 호출 인수 및 도구 호출 응답의 확장된 보기를 보여줍니다.

제한 사항

MCP는 매우 새로운 프로토콜이며 여전히 활발히 개발 중입니다. 알아두어야 할 몇 가지 알려진 주의사항이 있습니다:

도구 수량: 일부 MCP 서버 또는 많은 MCP 서버를 활성화한 사용자는 Cursor가 사용할 수 있는 많은 도구를 가질 수 있습니다. 현재 Cursor는 처음 40개의 도구만 Agent에 전송합니다.
원격 개발: Cursor는 로컬 머신에서 stdio를 통해 직접 또는 sse를 사용하여 네트워크를 통해 MCP 서버와 직접 통신합니다. 따라서 SSH 또는 기타 개발 환경을 통해 Cursor에 액세스할 때 MCP 서버가 제대로 작동하지 않을 수 있습니다. 향후 릴리스에서 이를 개선할 예정입니다.
MCP 리소스: MCP 서버는 도구와 리소스라는 두 가지 주요 기능을 제공합니다. 도구는 현재 Cursor에서 사용 가능하며 Cursor가 MCP 서버가 제공하는 도구를 실행하고 출력을 추가 단계에서 사용할 수 있게 합니다. 그러나 리소스는 아직 Cursor에서 지원되지 않습니다. 향후 릴리스에서 리소스 지원을 추가할 예정입니다.

출처: Cursor 공식 문서

[번역] Model Context Protocol (MCP)

귤랑귤랑 — Sun, 16 Mar 2025 22:44:00 +0900

LLM과 더불어 관심도가 높은 MCP에 대해 잘 설명한 글을 발견해서 옮겨봅니다.

MCP는 AI 애플리케이션을 위한 USB-C 포트 같은 것입니다.

USB-C가 다양한 주변기기에 장치를 연결하는 표준화된 방법을 제공하듯, MCP는 AI 앱이 다양한 데이터 소스와 도구에 연결하는 방법을 표준화합니다. 자세히 살펴보겠습니다!

핵심 구조

MCP는 호스트 애플리케이션이 여러 서버에 연결할 수 있는 클라이언트-서버 아키텍처를 따릅니다.

주요 구성 요소는 다음과 같습니다:

호스트
클라이언트
서버

자세히 알아보기 전에 개요를 살펴보겠습니다

호스트와 클라이언트:

호스트: AI 앱(Claude 데스크톱, Cursor)으로 AI 상호작용을 위한 환경을 제공하고, 도구와 데이터에 접근하며, MCP 클라이언트를 실행합니다.

MCP 클라이언트: MCP 서버와의 통신을 가능하게 하기 위해 호스트 내에서 작동합니다.

다음은 MCP 서버입니다...

서버

서버는 특정 기능을 노출하고 데이터에 대한 접근을 제공합니다.

3가지 주요 기능:

도구(Tools): LLM이 서버를 통해 작업을 수행할 수 있게 합니다
리소스(Resources): 서버의 데이터와 콘텐츠를 LLM에 노출합니다
프롬프트(Prompts): 재사용 가능한 프롬프트 템플릿과 워크플로우를 만듭니다

클라이언트-서버 통신

클라이언트-서버 통신을 이해하는 것은 자신만의 MCP 클라이언트-서버를 구축하는 데 필수적입니다.

이 그림으로 시작하여 단계별로 분석해 보겠습니다...

1️⃣ & 2️⃣: 기능 교환(capability exchange)

클라이언트는 서버 기능을 알아보기 위해 초기화 요청을 보냅니다.

서버는 자신의 기능 세부 정보로 응답합니다.

예: 날씨 API 서버는 API 엔드포인트를 호출하는 도구(tools), 프롬프트(prompts), 그리고 API 문서를 리소스(resource)로 제공합니다.

3️⃣ 알림(Notification)

클라이언트는 성공적인 연결을 확인하고 추가 메시지 교환이 계속됩니다.

마무리하기 전에 한 가지 중요한 세부 사항이 더 있습니다...

양방향 통신

전통적인 API와 달리 MCP 클라이언트-서버 통신은 양방향입니다.

필요한 경우 샘플링을 통해 서버는 API 키 없이도 클라이언트의 AI 기능(LLM 완성 또는 생성)을 활용할 수 있습니다.

한편 클라이언트는 모델 접근 및 권한에 대한 통제를 유지합니다.

출처: threadreaderapp.com/thread/1900170356494917936.html

[번역+추가내용] Vite v5에서 v6로 마이그레이션 하기

귤랑귤랑 — Tue, 4 Mar 2025 21:57:57 +0900

출처 : https://vite.dev/guide/migration

Vite

Next Generation Frontend Tooling

vite.dev

원본글

읽으면서 궁금한 내용을 추가로 작성하였습니다.

Environment API

새로운 실험적 Environment API의 일환으로 큰 내부 리팩토링이 필요했습니다. Vite 6는 대부분의 프로젝트가 새로운 메이저 버전으로 빠르게 업그레이드할 수 있도록 호환성을 깨지 않으려 노력했습니다. 생태계의 대부분이 새 API를 안정적으로 사용하기 시작할 때까지 기다릴 예정입니다. 일부 엣지 케이스가 있을 수 있지만, 이는 주로 프레임워크와 도구의 저수준 사용에만 영향을 미칠 것입니다. 릴리스 전에 생태계의 메인테이너들과 협력하여 이러한 차이점들을 완화했습니다. 문제점을 발견하시면 이슈를 열어주세요.

Vite의 구현 변경으로 인해 일부 내부 API가 제거되었습니다. 이러한 API를 사용하고 계셨다면 기능 요청을 해주시기 바랍니다.

Vite Runtime API

실험적인 Vite Runtime API는 Module Runner API로 발전했으며, 이는 Vite 6에서 새로운 실험적 Environment API의 일부로 출시되었습니다. 이 기능이 실험적이었기 때문에 Vite 5.1에서 도입된 이전 API의 제거는 호환성을 깨뜨리는 변경사항은 아니지만, 사용자들은 Vite 6로 마이그레이션하면서 Module Runner에 맞게 코드를 업데이트해야 합니다.

주요 변경점
1. 임포트 경로 변경: vite/runtime → vite/module-runner
2. API 이름 변경: createViteRuntime → createModuleRunner
3. 인스턴스 메서드 변경: runtime.destroy() → runner.close()
4. Environment API의 일부로 통합됨

서버사이드 렌더링이나 runner가 필요한 테스트 환경에서 주로 사용

(+그런데 서버사이드 렌더링은 프레임 워크를 주로 사용하기 때문에 직접 구축하는 것이 아니라면 사용할 일이 없어보입니다)

import { createModuleRunner } from 'vite/module-runner';
import express from 'express';

const app = express();

app.get('*', async (req, res) => {
const runner = await createModuleRunner({
root: process.cwd(),
});

try {
// SSR 엔트리 포인트 모듈 실행
const { render } = await runner.executeUrl('./src/entry-server.tsx');

// 클라이언트 요청 URL에 대한 HTML 렌더링
const html = await render({ url: req.originalUrl });

res.status(200).set({ 'Content-Type': 'text/html' }).end(html);
} catch (e) {
console.error(e);
res.status(500).end('서버 오류가 발생했습니다');
} finally {
await runner.close();
}
});

app.listen(3000);

일반적인 변경사항

resolve.conditions의 기본값

이 변경사항은 resolve.conditions / ssr.resolve.conditions / ssr.resolve.externalConditions를 설정하지 않은 사용자에게는 영향을 미치지 않습니다.

Vite 5에서는 resolve.conditions의 기본값이 []였고 일부 조건이 내부적으로 추가되었습니다.

ssr.resolve.conditions의 기본값은 resolve.conditions의 값이었습니다.

// vite.config.ts (Vite 5)
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
plugins: [react()],
// resolve.conditions를 명시적으로 설정하지 않음
// 내부적으로 'module', 'browser', 'development/production' 조건이 추가됨

// SSR 설정
ssr: {
// ssr.resolve.conditions를 명시적으로 설정하지 않음
// 기본적으로 resolve.conditions 값을 상속
}

Vite 6부터는 일부 조건이 더 이상 내부적으로 추가되지 않으며 설정값에 포함되어야 합니다.

resolve.conditions: ['module', 'browser', 'development|production']
ssr.resolve.conditions: ['module', 'node', 'development|production']

// vite.config.ts (Vite 6)
import { defineConfig, defaultClientConditions, defaultServerConditions } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
plugins: [react()],
resolve: {
// 이제 명시적으로 조건을 설정해야 함
conditions: defaultClientConditions // ['module', 'browser', 'development/production']
},

// SSR 설정
ssr: {
resolve: {
// 이제 명시적으로 서버 조건을 설정해야 함
conditions: defaultServerConditions // ['module', 'node', 'development/production']
}
}
})

이러한 옵션의 기본값은 해당 값으로 업데이트되었으며, ssr.resolve.conditions는 더 이상 기본값으로 resolve.conditions를 사용하지 않습니다. development|production은 process.env.NODE_ENV의 값에 따라 production 또는 development로 대체되는 특수 변수입니다. 이러한 기본값은 vite에서 defaultClientConditions와 defaultServerConditions로 내보내집니다.

resolve.conditions 또는 ssr.resolve.conditions에 사용자 정의 값을 지정한 경우, 새 조건을 포함하도록 업데이트해야 합니다. 예를 들어, 이전에 resolve.conditions에 ['custom']을 지정했다면, 대신 ['custom', ...defaultClientConditions]를 지정해야 합니다.

이런 식으로 조건에 따라 진입점을 정의해둔 경우에 해당합니다.

// 라이브러리의 package.json
{
  "name": "my-component-library",
  "exports": {
    ".": {
      "mobile": "./dist/mobile.js",
      "desktop": "./dist/desktop.js",
      "dark": "./dist/dark-theme.js",
      "light": "./dist/light-theme.js",
      "default": "./dist/index.js"
    }
  }
}

JSON stringify

Vite 5에서는 json.stringify: true로 설정했을 때 json.namedExports가 비활성화되었습니다.

// vite.config.ts (Vite 5)
import { defineConfig } from 'vite'

export default defineConfig({
  json: {
    stringify: true, // JSON을 문자열로 변환하고 namedExports 비활성화
    namedExports: true // 기본값이지만 stringify: true일 때 무시됨
  }
})

// Vite 5에서 JSON 임포트 결과
import data from './data.json'
console.log(data) // JSON 파일 내용이 문자열로 변환됨: "{"name":"홍길동","age":30}"

Vite 6부터는 json.stringify: true로 설정해도 json.namedExports가 비활성화되지 않으며 해당 값이 존중됩니다. 이전 동작을 원하시면 json.namedExports: false로 설정하시면 됩니다.

또한 Vite 6는 json.stringify의 새로운 기본값으로 'auto'를 도입했으며, 이는 큰 JSON 파일만 문자열화합니다. 이 동작을 비활성화하려면 json.stringify: false로 설정하세요.

// vite.config.ts (Vite 6)
import { defineConfig } from 'vite'

export default defineConfig({
  json: {
    stringify: true, // JSON을 문자열로 변환하지만 namedExports 설정은 영향 없음
    namedExports: true // 이제 stringify: true와 함께 사용 가능
  }
})

// Vite 6에서 JSON 임포트 결과 (stringify: true, namedExports: true)
import data, { name, age } from './data.json'
console.log(data) // JSON 파일 내용이 문자열로 변환됨: "{"name":"홍길동","age":30}"
console.log(name) // "홍길동" - 명명된 내보내기도 사용 가능
console.log(age) // 30 - 명명된 내보내기도 사용 가능

HTML 요소의 에셋 참조에 대한 확장된 지원

Vite 5에서는 <link href>, <img src> 등과 같은 일부 지원되는 HTML 요소만 Vite에 의해 처리되고 번들링될 에셋을 참조할 수 있었습니다. 다른 요소나 속성에 있는 파일 경로는 그대로 유지되어 번들링이나 최적화가 되지 않았습니다.

<!-- Vite 5에서 처리되는 에셋 참조 -->
<link href="./styles/main.css" rel="stylesheet">
<img src="./images/logo.png" alt="로고">
<script src="./scripts/main.js"></script>

이로 인해, 다음과 같은 문제가 발생합니다.

- 파일 경로가 빌드 후 구조에 맞게 업데이트되지 않음
- 에셋이 번들링되지 않아 별도의 HTTP 요청 발생
- 최적화(압축, 변환 등)가 적용되지 않음
- 해시 기반 캐싱 혜택을 받지 못함

Vite 6는 더 많은 HTML 요소에 대한 지원을 확장합니다. 전체 목록은 HTML 기능 문서에서 확인할 수 있습니다.

<!-- Vite 6에서는 이 모든 요소가 처리됨 -->
<video src="./video.mp4"></video>
<audio src="./audio.mp3"></audio>
<div style="background-image: url('./pattern.png')"></div>

<!-- 빌드 후 -->
<video src="/assets/video.a1b2c3d4.mp4"></video>
<audio src="/assets/audio.e5f6g7h8.mp3"></audio>
<div style="background-image: url('/assets/pattern.i9j0k1l2.png')"></div>

특정 요소에서 HTML 처리를 제외하려면 해당 요소에 vite-ignore 속성을 추가할 수 있습니다.

<!-- 이 요소는 Vite에 의해 처리되지 않음 -->
<img src="./images/logo.png" vite-ignore>

<!-- 동적 URL을 사용하는 경우 유용 -->
<img src="<%= dynamicImagePath %>" vite-ignore>

<!-- CDN 이미지 등 외부 리소스를 그대로 유지하고 싶을 때 -->
<img src="https://example.com/images/banner.jpg" vite-ignore>

postcss-load-config

postcss-load-config가 v4에서 v6으로 업데이트되었습니다. 이제 TypeScript postcss 설정 파일을 로드하기 위해 ts-node 대신 tsx 또는 jiti가 필요합니다. 또한 YAML postcss 설정 파일을 로드하기 위해 yaml이 필요합니다.

Sass가 이제 기본적으로 최신 API 사용

Vite 5에서는 Sass에 대해 기본적으로 레거시 API가 사용되었습니다. Vite 5.4에서 최신 API에 대한 지원이 추가되었습니다.

Vite 6부터는 Sass에 대해 기본적으로 최신 API가 사용됩니다. 여전히 레거시 API를 사용하고 싶다면 css.preprocessorOptions.sass.api: 'legacy' / css.preprocessorOptions.scss.api: 'legacy'로 설정할 수 있습니다. 그러나 레거시 API 지원은 Vite 7에서 제거될 예정입니다. 최신 API로 마이그레이션하려면 Sass 문서를 참조하세요.

라이브러리 모드에서 CSS 출력 파일 이름 사용자 정의

Vite 5에서는 라이브러리 모드의 CSS 출력 파일 이름이 항상 style.css였으며 Vite 설정을 통해 쉽게 변경할 수 없었습니다.

Vite 6부터는 기본 파일 이름이 JS 출력 파일과 유사하게 package.json의 "name"을 사용합니다. build.lib.fileName이 문자열로 설정된 경우, 해당 값도 CSS 출력 파일 이름에 사용됩니다. 다른 CSS 파일 이름을 명시적으로 설정하려면 새로운 build.lib.cssFileName을 사용하여 구성할 수 있습니다.

마이그레이션하려면, style.css 파일 이름에 의존했던 경우 패키지 이름을 기반으로 한 새 이름으로 참조를 업데이트해야 합니다. 예를 들어:

{
"name": "my-lib",
"exports": {
"./style.css": "./dist/my-lib.css"
}
}

Vite 5처럼 style.css를 유지하고 싶다면 대신 build.lib.cssFileName: 'style'로 설정할 수 있습니다.

출처 : https://vite.dev/guide/migration

Vite

Next Generation Frontend Tooling

vite.dev

이해 안가는 부분에 대한 내용을 추가하였으니 정확한 글은 원본을 확인해주세요.

[회고] 리액트 훅을 활용한 마이크로 상태관리 스터디

귤랑귤랑 — Wed, 12 Feb 2025 20:43:46 +0900

참여 기간 : 2024년 9월 7일~12월7일 (3개월)
스터디 주제 : '리액트 훅을 활용한 마이크로 상태 관리' 책을 매주 스터디
스터디를 신청한 이유 : 책을 통해 리액트 훅과 상태 관리에 대해 공부하고 각자 프로젝트에서 어떻게 적용하고 있는지 고민을 나누기 위해 스터디를 진행했다.
스터디를 참여 시작할 때 세웠던 목표
- 1. 책 완독
- 2. 코드 레벨에서 이해하기
진행 과정
- 한 주에 1~2장을 읽고 내용을 정리한다.
- 스터디날 발표자를 랜덤으로 선정하여 해당 회차 스터디를 진행한다.

지난 12월, 3개월간 진행된 자바카페 2024년 하반기 스터디가 마무리되었습니다. 마지막 발표회에서 제가 리더를 맡았던 '리액트 훅을 활용한 마이크로 상태 관리 (다이시 카토)' 스터디의 회고를 발표하게 되었습니다.

회고 발표

스터디 회고 발표 자료는 Gamma를 활용하여 효율적으로 제작하고 웹으로 배포하였습니다. 짧은 시간 투자로 퀄리티 있는 자료를 만들 수 있었습니다. https://react-hook-study-rm5cjw0.gamma.site/

스터디 마지막 시간에는 구성원 모두가 회고를 진행했고, 각자의 의견과 효과적이었던 학습 방법들을 정리해보았습니다

학습 방법

1. 깊이 있는 라이브러리 분석

9명의 스터디원들이 함께 GitHub 소스 코드를 분석하며 라이브러리의 동작 원리를 심도 있게 이해하고자 했습니다.
React 훅 기반 상태관리 라이브러리들의 내부 구현을 살펴보며 심화 지식을 쌓았고, Javascript에 대한 깊은 이해의 중요성을 깨달았습니다.
greptile 등의 AI 도구를 활용하여 효율적인 코드 분석을 진행했습니다.

2. 최신 기술 트렌드 분석

교재 내용을 넘어 React 18, 19 로드맵과 React Compiler 등 최신 기술 동향을 함께 탐구했습니다.
상태 관리 라이브러리 선택에 대한 다양한 관점을 공유하며 기술적 시야를 확장했습니다.

3. 활발한 학습 커뮤니티 형성

정규 스터디 시간 외에도 컨퍼런스 후기, 기술 아티클, 개인 프로젝트 경험 등을 지속적으로 공유했습니다.
구성원들의 적극적인 참여가 서로에게 동기부여가 되어 긍정적인 학습 문화를 조성할 수 있었습니다.

교재 평가

장점

상태관리 도구의 발전 과정을 체계적으로 설명
실제 구현 코드를 통한 실습 중심의 학습
저자의 직접적인 라이브러리 개발 경험을 바탕으로 한 명확한 설명

개선점

전반부와 후반부의 난이도 격차가 큼
일부 번역의 품질 저하로 이해가 어려운 부분 존재
라이브러리 활용에 대한 설명이 다소 피상적

스터디 운영 피드백

긍정적 요소

발표자 랜덤 선정을 통한 참여도 향상
실무 경험 공유를 통한 실질적 학습 효과
자유로운 토론 분위기 조성

개선 제안

짧은 챕터는 통합 진행 고려
체계적인 자료 아카이빙 공간 필요
더 많은 참여자의 의견을 끌어내는 방식 모색

마치며

이번 스터디를 통해 기술서적 완독이라는 목표를 달성했을 뿐만 아니라, 다양한 개발자들과의 교류를 통해 시야를 넓힐 수 있었습니다. 특히 리액트 훅과 상태관리에 대한 이해를 넘어 최신 기술 동향까지 함께 논의할 수 있어 매우 의미 있는 시간이었습니다. 앞으로도 지속적인 스터디 참여를 통해 개발자로서의 성장을 이어나가고자 합니다.

AWS Industry Week 참관 후기

귤랑귤랑 — Mon, 25 Nov 2024 21:59:01 +0900

AWS industry week 2024

1. 행사 개요

행사 일시 및 장소

2024년 11월 7일 코엑스에서 AWS Industry Week 2024에 개최되었습니다.

주요 주제

이번 AWS Industry Week 2024의 주요 테마는 '산업별 혁신과 클라우드 전환'이었습니다. 키노트는 총 6개의 주요 산업 트랙으로 구성되어 있는데요.

각 트랙을 살펴보면:

- 리테일 및 소비재

- 통신 및 미디어

- 금융 및 핀테크

- 제조 및 하이테크

- 헬스케어 및 생명 과학

- 디지털 인더스트리

이렇게 다양한 산업군을 아우르는 세션들이 준비되어 있었습니다.

2025년을 앞두고 각 기업들이 어떤 클라우드 전략을 준비하고 있는지 엿볼 수 있는 좋은 기회였습니다.

저는 특히 '리테일 및 소비재' 트랙을 통해 고객 경험 혁신과 AI 활용 사례를 우리 회사에 접목할 수 있는 인사이트를 얻고자 했습니다. 이후 포스팅에서 이 부분에 대해 더 자세히 다뤄보도록 하겠습니다.

참가 목적

첫째, 특히 비슷한 규모의 기업들이 어떤 방식으로 클라우드 전환을 성공적으로 이끌었는지 궁금했습니다.

둘째, AWS의 최신 기술 동향과 새로운 서비스들을 직접 확인하고 싶었습니다. 급변하는 클라우드 시장에서 2025년을 준비하기 위한 기술적 인사이트를 얻고 싶었습니다.

참가한 이번 행사가 얼마나 유익했는지, 이어지는 내용을 통해 하나씩 공유해드리도록 하겠습니다.

2. 리테일/소비재 기조연설 (Keynote) 내용

[기조연설 다시보기](https://kr-resources.awscloud.com/

aws-industry-week-2024?trkCampaign=industry-week&trk=f9c768e5-0f6b-4dd7-860d-0024ddf0c71a&sc_channel=em&mkt_tok=MTEyLVRaTS03NjYAAAGW60EGdofQihoK-aY5Kl1fBp-rAWbyX92uEVHl05nJRUqCQlY4FScMBaEiB-BU3HO9gpAOlPkPvpFzD9vFTxoNyCDgNDEui4WBcS6CoeJLXHltz5AYFFuNOw)

2-1. 핵심 메시지

- 리테일/소비재 산업은 불확실성 대응이 필요한 시점

- 소비자의 60%가 AI 애플리케이션 활용을 희망하고, 77%가 대화형 AI 검색을 선호하는 등 AI 수요 증가

- 리테일/소비재 산업의 경쟁력 강화를 위해 상품, 고객경험, 가격 측면의 혁신 필요

2-2. 주목할 만한 발표 내용

Amazon의 생성형 AI 활용 사례

- Amazon Rufus: 상품 상세, 리뷰, Q&A 데이터 기반의 쇼핑 관련 대화형 서비스

- 2024년 9월 베타서비스로 판매자를 위한 생성형 AI 기반 대화형 에이전트 출시

한국 리테일 소비재 산업의 생성형 AI 적용

- 직원 생산성 향상 57%, 고객 경험 향상 43%

- 이미지 생성, 컨텐츠 검수, 트렌드 분석, 카테고리 분류 등이 31%로 최다 적용

2-3. AWS 활용 전략

생성형 AI 도입을 위한 단계적 접근

- 베이스라인(사전 훈련된 모델) → 프롬프트 엔지니어링 → RAG → 도메인 특화 모델

현대화(Modernization) 4대 요소

- 모듈식 구조, API 중심, 확장성, 최적 제품

- 이를 구현하기 위한 AWS 서비스 활용 가능 (ECS, EKS, API Gateway 등)

3. 인상 깊었던 세션

3-1. 쿠팡의 대규모 데이터 기반 플랫폼과 재해 복구를 위한 아키텍쳐 소개

쿠팡은 리테일 산업에서 제품 관리, 브랜드 가치, 실시간 거래 처리, 그리고 혁신이라는 핵심 비즈니스 요소들을 지원하기 위해 데이터의 중요성을 인식했습니다.

특히 고객 참여, 상품 기획, 옴니채널 운영, 공급망 관리 등 다양한 영역에서 데이터 기반의 의사결정이 필수적이라고 판단했습니다.

그 내용들은 아래와 같습니다.

비즈니스 핵심 요건
- 제품, 가격, 그리고 판매자 관리
- 브랜드와 관계의 가치
- 실시간 거래 및 높은 처리
- 혁신과 성과 가능성

데이터/분석 활용 방법
- 고객 참여 (Customer Engagement)
- 기업 상품 기획 및 계획
- 오프라인, 디지털, 온라인 매장
- 공급망 및 유통
- 리테일 데이터 사이언스
- 핵심 리테일 비즈니스 솔루션

쿠팡에서는 4개의 계층 구조를 사용하여, 대규모 데이터를 수집, 저장, 분석, 실행을 실행하고 있었습니다.

이러한 대규모 데이터의 안정적인 운영과 보호를 위해, 쿠팡은 체계적인 재해 복구 전략을 수립했습니다.

RPO(Recovery Point Objective)와 RTO(Recovery Time Objective) 개념 도입하여 단계별 복구 전략을 도입했으며, Backup & Restore부터 Hot Standby까지 다양한 수준의 재해 복구 방안을 구축했습니다.

이를 통해 비즈니스 연속성을 보장하고 중요 데이터의 손실을 최소화하는 것을 목표로 하고 있습니다.

클라우드 재해 복구를 4단계로 나누어서 판단하고 있었습니다.

Backup & Restore (기본 수준)
- 정기적인 백업과 필요시 복원
- 비용은 낮지만 복구 시간이 김
Pilot Light
- 핵심 시스템만 준비
- 필요시 빠른 확장 가능
Warm Standby
- 축소된 형태로 시스템 운영
- 빠른 복구 가능
Hot Standby
- 실시간 복제로 즉시 전환 가능
- 가장 빠른 복구but 비용이 높음

각 레벨 별로 사용하고 있는 기술 스택은 다음과 같습니다.

Tools: Data Platform Portal, Hadoop Abstraction Layer, SQL Workbench
Data Processing Engine: Hive, Spark
Query Engine: Presto
Computing Cluster: Amazon ECS, Amazon EMR
Data Warehouse: Amazon Redshift
Storage: Amazon S3, HDFS

이중에서 쿠팡에서는 EMR에 대해 자세 다루었습니다.

EMR은 관리형 빅데이터 플랫폼인데, Hadoop, Spark, Hive 등의 오픈소스 프레임워크를 쉽게 실행할 수 있습니다.

Coupang EMR 구조

EMR을 이용하여 검색 인덱스 생성(Search Index), 데이터 수집(Data Ingestion), 가격 관리(Pricing), 재고 관리(Inventory), 리포트 및 분석(Reports & Analysis)을 효율적으로 할 수 있습니다.

EMR DR Test 프로세스

이 EMR을 사용하여 EMR DR(Disaster Recovery) Test를 단계별로 구성하였습니다.

DR Start → Recovery → DR End → Revert → DR Start

타겟 AZ(가용 영역)을 중단하고 EMR도 중단한 뒤에 복구 프로세스가 어떻게 동작하는지 관찰하고 서비스를 복구하며 이 과정을 리포트로 제출합니다.

4. 총평 및 마무리

전반적인 행사 평가

이번 AWS Industry Week 2024에는 많은 사람들이 참여하여 북적였습니다. 국내 주요 IT 기업들의 실제 AI 도입 사례와 기술적 시도들을 직접 들을 수 있어 매우 유익했습니다. 다양한 산업군의 AWS 활용 사례를 통해 우리 프로젝트에서도 AI를 어떻게 효과적으로 도입할 수 있을지 고민해 볼 수 있는 기회가 되었습니다.

개인적인 소감

이번 행사를 통해 AI 기술이 더 이상 선택이 아닌 필수가 되어가고 있음을 실감했습니다. 많은 기업과 개발자들이 AI에 깊은 관심을 보이고 있었고, 이는 곧 산업의 미래 방향성을 보여주는 것이라 생각됩니다. 개인적으로도 AI 기술에 대한 학습과 연구를 더욱 강화해야겠다는 동기부여가 되었습니다.

Track1에 많은 관심이!