2026년 오픈소스 트렌드, 공개보다 검증 가능성이 중요한 이유

GitHub에 코드를 공개하는 것과 그 코드가 신뢰받는 것은 다른 문제입니다. 구글·AWS·마이크로소프트가 같은 에이전트를 세 번 만들어 오픈 프로토콜로 붙인 실험, 이력서보다 "무엇이 깨졌을 때 고쳤는가"를 따지는 채용 현장, 그리고 공개는 했지만 원인은 밝히지 않은 중국의 발사 연기 발표까지 — 오늘 다섯 소식은 '공개' 자체보다 그 공개가 얼마나 검증 가능한가로 무게중심이 옮겨가고 있음을 보여줍니다.

구글 vs AWS vs 마이크로소프트, 같은 에이전트를 세 번 만든 이유

핵심: 구글 ADK, AWS Strands, 마이크로소프트 Agent Framework로 동일한 리서치 에이전트를 세 번 만들어 A2A 프로토콜 하나로 연결했습니다.

GitHub 저장소 xbill9/multicloud-a2a-subagent는 세 하이퍼스케일러의 에이전트 프레임워크가 프로토콜 차원에서 이미 호환되고 난 다음에도 실제로 무엇이 다른지를 확인하기 위한 프로젝트입니다. 세 클라우드 모두 자체 에이전트 프레임워크를 제공하며, 모두 A2A를 지원합니다. A2A(Agent2Agent)는 서로 다른 팀이 각기 다른 프레임워크로 만든 에이전트끼리 서로 호출할 수 있게 해주는 개방형 프로토콜로, 에이전트가 자신의 기능과 접속 방법을 담은 카드를 /.well-known/agent-card.json에 게시하고 JSON-RPC over HTTP로 통신하는 방식입니다. 이 프로젝트는 A2A v1.0을 사용합니다.

실험 설계는 하나의 브리핑, 하나의 지시문, 하나의 검색 도구, 하나의 단어 예산을 세 스택에 동일하게 적용하고, 프레임워크·모델·서빙 방식만 다르게 둔 것입니다. 하나의 코디네이터가 같은 과제를 세 에이전트에 동시에 던지고 결과를 채점합니다.

구분	Google ADK	AWS Strands	Microsoft Agent Framework
에이전트 클래스	LlmAgent	Agent	Agent
모델	gemini-2.5-flash	us.amazon.nova-micro-v1:0	gpt-5-mini (Foundry)
호스팅	Cloud Run (us-central1)	Bedrock AgentCore (us-west-2)	Container Apps (westus2)
A2A 변환 방식	to_a2a()	a2a-sdk reference routes	A2AExecutor

이 프로젝트의 구글 ADK 쪽 구현을 더 깊이 들여다본 별도의 글도 같은 저장소를 바탕으로 공개됐습니다.

출처: dev.to | 원문 보기 ↗

ADK 에이전트를 클라우드런에서 A2A로 서빙하기

핵심: 구글 ADK는 오픈소스 에이전트 프레임워크로, to_a2a() 함수 한 줄로 A2A 서버를 만들 수 있지만 배포 환경에 따라 예상 밖의 문제가 드러났습니다.

ADK(Agent Development Kit)는 구글의 오픈소스 AI 에이전트 개발 프레임워크로, 모델과 배포 환경에 종속되지 않고 Vertex AI나 API 키를 통해 Gemini를 구동합니다. 이 프로젝트에서는 LlmAgent에 to_a2a()를 씌운 것이 ADK를 다른 벤더 클라이언트가 호출 가능한 A2A 서버로 바꾸는 가장 짧은 경로였고, Dockerfile 없이 소스에서 바로 Cloud Run에 배포했습니다.

배포 직후 자신의 에이전트 카드(agent-card.json)를 curl로 확인하는 과정에서 문제가 드러났습니다. to_a2a(agent, host, port)가 host:port를 카드의 interface URL에 그대로 적어 넣는데, Cloud Run에서는 프로세스가 0.0.0.0:8080에 바인딩되기 때문에 공개 HTTPS 엔드포인트가 도달 불가능한 평문 주소를 광고하는 상태가 된 것입니다. 이 문제는 노트북 환경에서는 바인드 주소와 다이얼 주소가 같은 문자열이라 재현되지 않고, 배포 환경에서만 드러납니다.

이렇게 정교하게 설계된 오픈소스 프로젝트를 GitHub에 공개하는 것과, 그 코드를 이력서에 올려 채용으로 연결하는 것은 전혀 다른 이야기입니다.

출처: dev.to | 원문 보기 ↗

학위보다 중요한 것, GitHub에 올린 프로젝트가 채용을 못 만드는 이유

핵심: 채용담당자는 "이 사람이 배울 수 있는가"가 아니라 "월요일부터 일할 수 있는가"를 봅니다.

필리핀의 개발자·IT·구직 페이스북 그룹에서 가장 자주 보이는 게시물은 이런 형태입니다. "BSIT 졸업, 자격증 [목록] 보유, 구직 중, 배울 의지 있음, DM 주세요." 이런 게시물이 수백 개씩 올라오지만 아무도 답하지 않는 경우가 흔합니다. 학위는 배울 수 있다는 것을 증명하고 그래서 면접까지는 이어지지만, 채용담당자가 실제로 묻는 것은 다릅니다.

글은 "경험"의 의미를 이렇게 정의합니다 — 본인이 만든 무언가 때문에 프로젝트가 멈춘 순간, 그리고 그것을 다시 고친 순간을 겪어본 적이 있는가. 연차나 스택의 문제가 아니라 그 순간을 몇 번 겪었는지가 기준입니다. 투두 앱, 이커머스 클론, 날씨 대시보드 같은 튜토리얼 프로젝트는 이미 모든 문제가 풀린 상태로 설계돼 있어 따라 하는 동안 생각할 필요가 없고, 완성 후 GitHub에 올려도 "지시를 따를 수 있다"는 것만 증명할 뿐입니다.

GitHub에 코드를 공개하는 방식과 이유가 산업마다 다르게 요구되는 것처럼, '공개' 자체가 곧바로 신뢰로 이어지지 않는 사례는 다른 분야에서도 찾을 수 있습니다.

출처: dev.to | 원문 보기 ↗

'절대적 성공'을 위해 미뤄진 중국의 달 탐사

핵심: 중국 유인우주 프로그램은 창어 7호가 "발사 조건을 충족하지 못했다"고 짧게 발표했을 뿐, 구체적 원인은 밝히지 않았습니다.

중국의 "유인우주(Manned Space)" 프로그램은 일요일 성명에서 "신중하고 확실하게 진행하며 절대적 성공을 보장한다는 원칙에 따라, 종합 평가 결과 창어 7호는 발사 조건을 충족하지 못해 올해 예정된 발사 창 내에 수행할 수 없다"고 밝혔습니다. 남중국해 섬에 위치한 원창 우주발사장에서 발사가 지연된 원인에 대해서는 별도 설명이 없었습니다. 창어 7호는 궤도선, 착륙선, 로버, 소형 탐사기(미니 호퍼)로 구성돼 있으며 창정 5호 로켓으로 일요일 이르면 발사될 예정이었고, 목표는 달 남극의 섀클턴 크레이터 인근 착륙입니다.

가장 유력한 지연 원인은 태풍 나라(Narra)로, 최대 시속 45마일(중간 강도 열대폭풍급) 바람을 동반한 채 발사장이 있는 하이난섬과 중국 본토 사이 해역을 맴돌고 있습니다. 합동태풍경보센터에 따르면 이 태풍은 앞으로 2~3일간 이 지역에 계속 머무를 것으로 예상돼 원창 발사장에 악천후를 몰고 올 가능성이 큽니다. 공식 확인은 없지만 소셜미디어에서는 다음 달 남극 도달에 적합한 발사 창이 내년 2월이나 3월에나 다시 열릴 수 있다는 이야기가 나오고 있으며, 극지 착륙지의 태양광 조건과 착륙 전 90일간의 궤도 정찰 계획이 이런 긴 간격의 배경으로 꼽힙니다. 이 지연은 미국과 중국이 달 남극에 유의미한 거점을 마련하려는 경쟁 속에서 나온 것으로, 창어 7호 같은 로봇 임무는 향후 2~4년 내 이어질 수 있는 유인 임무의 선행 비행 성격을 갖습니다.

정확한 원인을 공개하지 않은 채 결과만 발표하는 방식과 정반대로, 143년 전에는 재해의 세부 정황이 전신을 타고 실시간으로 전 세계에 공개된 사례가 있었습니다.

출처: Ars Technica | 원문 보기 ↗

143년 전 전신이 전 세계에 실시간으로 알린 크라카타우 폭발

핵심: 1883년 8월 27일 크라카타우 화산 폭발로 섬 두 개가 사라졌고, 3만6000명 이상이 목숨을 잃었습니다.

가장 먼저 도착한 전신은 네덜란드령 동인도(현 인도네시아)의 바타비아(현 자카르타)에서 발송돼 싱가포르에 전달됐습니다. "크라카타우(화산섬)에서 무서운 폭발음", 곧이어 "돌이 떨어진다. 안예르 인근 마을이 휩쓸려 갔다"는 소식이 이어졌고, 화요일 정오 무렵에는 "크라카타우산이 있던 자리에 이제 바다가 자리하고 있다"는 소식으로 피해 규모가 명확해졌습니다. 8월 27일 아침 화산 폭발은 자바와 수마트라 사이 해협의 섬 두 개를 완전히, 세 번째 섬은 대부분 파괴했습니다. 3만6000명 이상이 사망했으며 대다수는 폭발이 촉발한 대규모 쓰나미로 인한 것이었습니다.

빅토리아 시대의 통신 기술 덕분에 전 세계 사람들이 이 재해의 즉각적·장기적 영향을 실시간에 가깝게 기록할 수 있었던 역사상 최초의 사례였고, 이후 몇 년간 쌓인 관측은 현대 화산학의 토대가 됐습니다. 폭발 후 대기 중을 떠돈 화산 입자는 강렬한 색의 노을을 만들어냈고, 이는 에드바르 뭉크의 '절규' 배경에도 영향을 줬을 가능성이 있습니다. 화산에서 분출된 황이 대기 중 에어로졸을 형성해 햇빛을 반사하면서, 폭발 이후 수개월에서 수년 사이 북반구 비열대 지역의 여름 평균기온이 섭씨 0.6도(화씨 1.1도) 낮아졌습니다. 오늘날 화산학자들은 이때 쌓인 지식을 바탕으로 과거의 대규모 분화가 가뭄, 홍수, 흉작, 전염병, 사회 불안 같은 역사적 사건에 영향을 미쳤을 가능성을 추적하고 있으며, 독일 브레머하펜 소재 독일해양박물관의 환경사학자 카트린 클레만은 "너무나 다양한 방식으로 사회가 영향을 받았다 — 흉작이나 홍수, 추운 여름이나 정말 추운 겨울처럼"이라고 말합니다.

출처: Ars Technica | 원문 보기 ↗

이게 나에게 의미하는 것

멀티클라우드 에이전트 배포를 검토 중이라면, xbill9/multicloud-a2a-subagent 저장소가 드러낸 것처럼 to_a2a() 같은 헬퍼가 배포 환경의 바인드 주소를 에이전트 카드에 그대로 새겨 넣는지부터 curl로 직접 확인하는 편이 안전합니다. 구직 중인 주니어 개발자라면, 튜토리얼을 그대로 따라 만든 프로젝트를 GitHub에 올리는 것보다 배포 후 실제로 무언가 깨졌을 때 원인을 찾아 고친 과정을 남기는 프로젝트가 면접에서 더 설득력을 갖습니다. 우주 개발 뉴스를 챙겨보는 독자라면, 창어 7호의 다음 발사 창이 내년 2~3월경으로 거론되고 있는 만큼 그 시점 전후의 공식 발표를 주시할 만합니다.

정리: 오늘의 시사점

오늘 다섯 소식이 공통으로 보여주는 것은 '공개' 그 자체보다 그 공개가 담고 있는 정보의 검증 가능성입니다. 구글·AWS·마이크로소프트 세 클라우드의 에이전트 프레임워크는 A2A라는 같은 프로토콜을 공개적으로 지원하지만, 실제로는 to_a2a()의 호스트 주소 버그처럼 코드를 직접 열어봐야만 드러나는 문제를 남겼습니다. 필리핀 개발자들의 GitHub 포트폴리오는 프로젝트를 얼마나 올렸는지가 아니라 무엇이 깨졌을 때 고쳤는지를 요구받았고, 중국의 창어 7호 발표는 지연이라는 결과만 공개하고 원인은 밝히지 않았습니다. 반대로 143년 전 크라카타우 전신 보도는 파괴의 세부 정황까지 실시간으로 세계에 전달돼 오늘날까지 이어지는 화산학의 근거 자료가 됐습니다.