149 개의 포스트
제공된 내용에는 본문이 포함되어 있지 않고, 제목·작성자 정보·페이지 내비게이션만 있습니다. 따라서 Kanana-o 음성 생성 고도화 과정의 핵심 주장이나 기술적 세부 사항을 정확히 요약할 수 없습니다. ### 확인 가능한 정보 - 글 제목: **Beyond AI That Speaks Well: Making Kanana-o Speak the Way Users Want** - 관련 한국어 제목: **잘 말하는 AI를 넘어, 원하는 대로 말하는 AI로: Kanana-o 음성 생성 고도화 과정** - 작성자: martin.gale, abigail.r, edwin.ai - 본문 대신 다음·이전 글 링크와 검색 메뉴만 제공됨 본문 내용을 추가로 보내주시면 요청하신 형식에 맞춰 섹션별로 한국어 요약을 작성하겠습니다.
원문 읽기(새 탭에서 열림)토스뱅크는 DS와 MLE 사이의 역할 경계를 사람이나 파일이 아닌 명시적인 인터페이스로 정의하면서 ML 모델 배포 협업을 개선했습니다. 노트북 전달 방식에서 `.py` 파일 공유를 거쳐, 전처리·추론·후처리를 구현한 모델 패키지를 `pip install`로 배포하는 구조로 발전했습니다. 여기에 모노레포, 공통 추상화, CI, AI 코딩 스타일 규칙을 결합해 배포 속도와 일관성을 높였습니다. ## 노트북 전달 방식의 한계 - Phase 0에서는 DS가 주피터 노트북에서 학습과 추론 코드를 모두 작성하고, MLE가 이를 바탕으로 서빙 코드를 처음부터 다시 작성했습니다. - 라이브러리, 설정 파일, 소스 코드가 흩어져 있어 실행 환경을 재현하기 어려웠습니다. - 노트북에서 동작하던 전처리나 설정을 MLE가 다르게 해석하는 문제가 발생했습니다. - 모델 수가 늘어날수록 파일 요청과 커뮤니케이션 비용이 크게 증가했습니다. - 역할의 경계가 코드가 아니라 사람 사이에 있었기 때문에 책임과 작업 범위가 불명확했습니다. ## `.py` 파일로 추론 로직 분리 - Phase 1에서는 DS가 노트북에서 핵심 추론 로직을 별도의 `.py` 파일로 분리했습니다. - 노트북은 학습과 실험에 집중하고, 실제 모델 로직은 코드 파일로 관리했습니다. - MLE 리뷰와 CI 검증을 거치도록 하면서 DS의 의도를 더 정확히 보존할 수 있었습니다. - 그러나 모델마다 함수 이름이 `predict()`, `run()`, `inference()` 등으로 달라 인터페이스가 통일되지 않았습니다. - 서빙 환경으로 코드를 옮길 때 환경 차이로 수정이 필요했고, 로깅·메트릭·에러 처리를 공통으로 적용하기도 어려웠습니다. - 노트북에서 전역 설정을 변경한 코드가 여러 모델이 실행되는 서빙 프로세스에 영향을 주는 문제도 있었습니다. ## 인터페이스를 통한 역할 분리 - Phase 2에서는 `commons-ml-model` 패키지에 모델의 표준 구조를 정의했습니다. - 추상화 클래스가 다음 세 가지 인터페이스를 제공합니다. - `pre_process`: 입력 데이터 전처리 - `inference`: 모델 추론 - `post_process`: 결과 후처리 - DS는 위 메서드의 구현체를 작성하고 모델을 하나의 패키지로 배포합니다. - MLE는 해당 패키지를 설치해 서비스에 연결하므로 코드를 직접 복사하거나 재작성하지 않습니다. - 추상화 클래스가 추론 전후에 공통으로 다음 기능을 처리합니다. - 요청 추적을 위한 `trace_id` - 추론 시작·완료 로그 - 실행 시간 측정 - 메트릭 기록 - 결과적으로 DS는 모델 동작에 집중하고, MLE는 서비스 인프라와 운영 기능을 담당하게 됐습니다. - 공통 관측 기능을 추상화 클래스 한 곳에서 수정하면 모든 모델에 일괄 적용할 수 있습니다. ## 모노레포와 `uv` 워크스페이스 - 여러 모델 패키지와 공통 추상화 패키지를 하나의 저장소에서 관리했습니다. - `uv` 워크스페이스를 사용해 DS와 MLE가 같은 코드베이스에서 작업하고 리뷰할 수 있도록 했습니다. - 공통 인터페이스 변경과 모델 패키지 수정이 하나의 PR에서 함께 이뤄졌습니다. - CI, 버전 관리, 배포 정책을 저장소 단위로 통일할 수 있었습니다. - 공통 패키지 변경이 모든 모델에 영향을 줄 수 있다는 위험도 존재합니다. - 모델과 패키지가 늘면서 빌드가 느려졌고, Poetry에서 `uv`로 전환해 빌드 속도를 약 3~5배 개선했습니다. ## AI 시대의 코드 스타일 통일 - AI가 코드를 작성하면서 같은 기능도 예외 처리, 네이밍, enum 사용 방식 등이 사람마다 달라지는 문제가 생겼습니다. - 인터페이스가 같더라도 코드의 세부적인 작성 방식이 달라 리뷰 비용이 증가했습니다. - 팀 규칙 모음인 `pfmls-stylepack`을 도입해 AI가 코드 작성 단계부터 팀 컨벤션을 따르도록 했습니다. - Hook을 활용해 네이밍, 예외 처리, 고정값과 enum 사용 기준 등을 자동 적용했습니다. - 규칙이 적용된 코드에는 그 이유를 표시해 리뷰어가 변경 의도를 쉽게 파악하도록 했습니다. - 협업 표준을 두 층위로 나눴습니다. - 구조 표준화: 인터페이스로 담당 범위와 코드 형태 통일 - 스타일 표준화: 컨벤션으로 구현 방식과 코드 결 통일 ## 도입 과정에서 얻은 교훈 - 인터페이스는 너무 엄격하면 DS의 모델별 커스터마이징을 막고, 너무 느슨하면 다시 구현 방식이 제각각이 될 수 있습니다. - 초기에는 가이드 문서를 제공하고 DS와 MLE가 첫 모델을 페어로 함께 만드는 방식이 효과적입니다. - 공통 라이브러리는 한 번의 수정으로 전체 모델에 개선을 적용할 수 있지만, 반대로 전체 모델에 장애를 전파할 수도 있습니다. - 기존 모델 패키지를 참고 코드로 제공하면 새로운 구성원의 러닝 커브를 줄일 수 있습니다. - AI 활용이 늘어날수록 기능의 책임뿐 아니라 코드 작성 방식까지 명시적으로 관리해야 합니다. 실무적으로는 모델 배포 과정에서 “누가 무엇을 한다”를 문서로만 정의하기보다, 추상화 클래스와 패키지 구조로 강제하는 것이 효과적입니다. 먼저 전처리·추론·후처리 같은 최소 인터페이스를 정하고, 공통 로깅·메트릭·CI를 그 바깥에 배치하는 방식부터 시작하는 것을 추천합니다.
원문 읽기(새 탭에서 열림)Science One Framework는 AI가 생성한 연구 결과의 모든 주장에 실제 근거를 연결하는 Chain-of-Evidence(CoE) 방식으로 환각과 재현성 문제를 줄이는 자율 연구 프레임워크다. 문헌 검색, 실험 탐색, 논문 작성 전 과정에서 증거 사슬을 구축하고, CoE Audit로 인용·점수·코드·방법의 일치 여부를 독립 검증한다. 실험 결과, 기존 시스템의 참고문헌 환각률이 최대 21%에 달한 반면 Science One Framework는 유령 참고문헌 없이 높은 재현성과 성능을 달성했다. ## 자율 연구 시스템에서 검증 가능성이 중요한 이유 - LLM 기반 연구 에이전트는 문헌 조사, 가설 수립, 실험 실행, 논문 작성까지 자동화하고 있다. - 그러나 생성 과정에서 발생한 오류가 다음 단계로 누적·증폭될 수 있다. - 대표적인 문제는 다음과 같다. - 존재하지 않는 논문을 참고문헌으로 생성 - 논문에 설명한 방법과 실제 실행 코드가 불일치 - 논문에 보고된 실험 점수가 코드를 다시 실행했을 때 재현되지 않음 - 따라서 논문의 문장 품질만이 아니라, 각 주장과 근거 사이의 연결을 검증해야 한다. ## Chain-of-Evidence(CoE)의 원칙 - CoE는 데이터베이스 트랜잭션의 ACID처럼 신뢰할 수 있는 연구 산출물이 갖춰야 할 속성을 정의하는 개념적 프레임워크다. - 핵심은 두 가지다. - **완전성**: 연구 산출물의 모든 주장에 기록된 증거 사슬이 있어야 한다. - **정확성**: 연결된 증거가 실제로 해당 주장을 뒷받침해야 한다. - 검증 대상이 되는 주장은 다음과 같다. - 참고문헌의 존재 여부 - 논문에 보고된 실험 수치 - 연구 방법 설명 - 최종 결론 - 증거는 학술 논문, 실험 로그, 실제 실행된 코드, 결과 테이블 등으로 연결된다. - 존재하지 않는 참고문헌, 재현되지 않는 점수, 코드와 다른 방법 설명은 모두 증거 사슬이 끊어진 사례다. ## 문헌을 근거로 고정하는 Problem Investigator - Semantic Scholar API를 사용해 주제별 인용 그래프를 구축한다. - 최대 100개의 전문 PDF를 읽어 구조화된 연구 브리프를 만든다. - 최종 논문의 참고문헌은 모델의 기억에서 생성하지 않고, API를 통해 실제로 검색·확인된 자료에서 가져온다. - 이 방식으로 존재하지 않는 참고문헌이 논문에 포함되는 문제를 방지한다. ## 병렬 탐색을 수행하는 Discovery Engine - 여러 탐색 브랜치를 병렬로 운영해 새로운 아이디어를 탐색하고 성능이 좋은 아이디어를 개선한다. - 각 독립 사이클에서 다음 작업이 수행된다. - Solver 에이전트가 해결책을 구현 - 문제별 evaluator가 결과를 평가 - 성능이 높은 브랜치를 반복적으로 개선 - 모든 evaluator의 원시 출력은 엄격한 읽기 전용 기록으로 저장된다. - 따라서 논문에 기재된 점수를 실제 평가 결과와 대조할 수 있다. ## 주장과 근거를 연결하는 Paper Writer와 Claim Verifier - 논문을 렌더링하기 전에 모든 사실 주장을 구조화하고, 각 주장에 인라인 증거 태그를 붙인다. - 증거 태그는 해당 주장을 뒷받침하는 특정 작업 공간 산출물에 연결된다. - Claim Verifier는 각 주장을 선언된 출처와 대조한다. - 주장이 근거보다 과장된 경우 삭제하기보다 근거가 뒷받침하는 수준으로 보수적으로 다시 작성한다. - 이를 통해 논문 내용이 실제 수행된 연구와 일치하도록 유지한다. ## CoE Audit의 네 가지 검증 CoE Audit는 생성된 논문, 코드, 해결책, 참고문헌을 대상으로 수행하는 사후 자동 감사 프로토콜이다. - **점수 검증** - 논문에서 보고된 점수를 추출한다. - 제출된 코드를 완전히 독립적으로 다시 실행해 결과를 비교한다. - **명세 위반 검사** - 코드가 실제 문제를 해결하는지 확인한다. - 평가 지표를 악용하거나 정답 파일을 직접 읽는 등의 부정한 구현을 검사한다. - **참고문헌 검증** - 모든 참고문헌을 학술 API와 대조한다. - 존재하지 않는 유령 참고문헌을 식별한다. - **방법-코드 정렬 검사** - LLM 심사자가 논문의 방법론 설명과 코드를 나란히 비교한다. - 논문이 실제 구현보다 복잡하거나 다른 알고리즘을 설명하는지 확인한다. ## 실험 결과 - ADRS 벤치마크의 5개 시스템 최적화 과제(Prism, Cloudcast, EPLB, LLM-SQL, transaction scheduling)에서 5개 시스템이 생성한 총 75편의 논문을 평가했다. - Science One Framework는 네 가지 무결성 검사 모두에서 기존 기준 시스템보다 우수했다. - 참고문헌 환각률은 0%였다. - 반면 기존 시스템에서는 최대 21%의 참고문헌이 존재하지 않았다. - 제출 코드의 독립 재실행을 통한 점수 검증에서 완벽한 결과를 보였다. - 방법 설명과 실제 코드의 일치도 역시 가장 높았다. - 일부 기준 시스템은 실제 코드가 단순한 결정론적 휴리스틱임에도 “하이브리드 뉴로-심볼릭 솔버”처럼 과장된 방법을 기술했다. - 검증 절차를 강화했음에도 연구 성능이 저하되지 않았다. - 5개 ADRS 과제에서 인간 전문가 수준 이상을 기록했다. - Cloudcast와 EPLB에서는 전체 시스템 중 최고 성능을 달성했다. - 외부 일반화 평가에서도 MLE-Bench의 의료 영상, 세밀한 이미지 인식, 3D 인식 관련 대회에 적용되었으며, 일부 과제에서 Gold Medal 성과를 기록했다. ## 실용적인 시사점 자율 연구 시스템은 논문을 완성한 뒤 사실을 확인하는 방식보다, 문헌·코드·실험 로그·결과를 생성 시점부터 연결하는 구조가 바람직하다. 특히 자동화된 연구 결과를 실제 의사결정이나 후속 연구에 사용하려면, 논문 자체뿐 아니라 독립적인 코드 재실행, 참고문헌 확인, 방법-코드 비교를 포함한 CoE Audit 같은 검증 절차를 함께 운영해야 한다.
원문 읽기(새 탭에서 열림)양자 컴퓨터는 아날로그 제어 신호의 드리프트 때문에 장시간 계산 중에도 지속적인 재보정이 필요하며, 기존 방식은 계산을 완전히 중단해야 한다는 한계가 있다. Google Quantum AI는 양자 오류 검출 데이터를 강화학습의 학습 신호로 활용해, 계산을 수행하는 동안 수천 개의 제어 매개변수를 자동 조정하는 방법을 제시했다. Willow 프로세서 실험과 대규모 시뮬레이션에서 이 방식은 논리적 안정성과 오류율을 개선해, 장시간 안정적인 양자 계산에 한 걸음 다가섰다. ## 양자 컴퓨터에서 지속적인 보정이 필요한 이유 - 양자 컴퓨터는 주파수, 진폭, 위상 같은 아날로그 제어 신호로 큐비트를 조작한다. - 하드웨어와 환경의 미세한 변화로 제어 매개변수가 드리프트하면 오류가 증가한다. - 기존에는 성능을 회복하려면 양자 계산을 완전히 종료한 뒤 전체 시스템을 재보정해야 했다. - 유용한 양자 알고리즘이 수일에서 수개월 동안 실행되어야 한다는 점에서, 계산과 보정의 분리는 큰 병목이다. ## 양자 오류 정정과 오류 검출 데이터 - 큐비트를 직접 측정하면 중첩 상태가 붕괴하므로, 여러 물리 큐비트로 논리 큐비트를 구성하는 양자 오류 정정(QEC)을 사용한다. - 물리 큐비트의 패리티 검사는 아날로그 잡음을 이진 오류 검출 이벤트로 변환한다. - 검출 이벤트는 오류가 특정 시공간 영역에서 발생했다는 사실은 알려주지만, 정확한 위치까지 알려주지는 않는다. - AlphaQubit 같은 신경망 디코더와 Tesseract 같은 알고리즘 디코더가 검출 데이터를 분석해 오류 위치를 추정하고 논리 정보를 복원한다. - 그러나 디코더는 오류를 수정할 뿐, 오류의 원인이 제어 불량인지 환경적 요인인지까지 해결하지는 못한다. ## 물리 모델 중심 보정의 한계 - 기존 양자 보정은 물리 법칙과 수작업으로 설계한 모델에 의존했다. - 실제 하드웨어에서는 복잡한 상호작용과 드리프트를 정확히 모델링하기 어렵기 때문에 성능에 한계가 생긴다. - 환경과의 상호작용으로 인한 결맞음 상실은 완전히 제거할 수 없지만, 부정확한 보정과 하드웨어 드리프트는 개선할 여지가 있다. - AlphaQubit이 기존 알고리즘 디코더를 능가한 것처럼, 양자 제어에서도 데이터 기반 학습이 기존 모델의 한계를 넘을 수 있다는 관점이 제시된다. ## 오류를 강화학습의 피드백으로 활용 - 강화학습 에이전트는 명시적인 제어 규칙 대신 행동 결과를 관찰하며 전략을 개선한다. - QEC에서 이미 생성되는 오류 검출 이벤트를 오류 수정뿐 아니라 학습 신호로도 활용한다. - 에이전트는 검출 이벤트의 변화를 관찰하면서 수천 개의 제어 매개변수를 동적으로 조정한다. - 제어 시스템은 새로운 오류를 줄이고, 계산 중 발생하는 드리프트를 지속적으로 상쇄한다. - 즉, 오류를 단순히 사후에 수정하는 것이 아니라 오류 패턴에서 원인을 학습해 제어 자체를 개선한다. ## Willow 프로세서 실험 결과 - Google의 Willow 초전도 프로세서에 의도적인 제어 매개변수 드리프트를 주입해 방법을 검증했다. - 강화학습 제어는 오류 정정 코드의 논리적 안정성을 3.5배 향상시켰다. - 프로세서가 신뢰할 수 있는 양자 메모리로 동작하는 시간이 그만큼 연장됐다. - 전문가가 수행한 기존 보정 이후에도 강화학습 미세 조정을 적용하자 논리 오류율이 추가로 20% 감소했다. - 최종적으로 표면 코드에서는 오류 정정 주기 1,000회당 1회 미만, 색상 코드에서는 100회당 1회 수준의 논리 오류율을 기록했다. ## 대규모 시스템으로의 확장 가능성 - 연구진은 수백 개의 큐비트와 수만 개의 제어 매개변수를 포함한 수치 시뮬레이션을 수행했다. - 초기에는 보정되지 않은 시스템의 물리 오류율이 높았지만, 강화학습 에이전트가 학습하면서 오류율을 점진적으로 낮췄다. - QEC를 적용하면 물리 큐비트 수가 증가할수록 논리 오류율이 지수적으로 억제되는 양상이 나타났다. - 중요한 점은 강화학습이 물리 오류율을 낮추는 속도가 시스템 크기에 크게 의존하지 않았다는 것이다. - 따라서 향후 더 큰 양자 컴퓨터에서도 학습 반복 횟수가 시스템 규모에 비례해 폭증하지 않을 가능성을 보여준다. ## 실용적인 의미 양자 오류 정정은 오류를 복구하는 역할을 넘어, 제어 시스템을 계속 학습시키는 센서로도 활용될 수 있다. 강화학습 기반 자동 보정이 실제 대규모 하드웨어에서 안정적으로 확장된다면, 계산을 중단하지 않고 드리프트에 대응하는 장시간·고신뢰성 양자 컴퓨터 구현에 기여할 수 있다.
원문 읽기(새 탭에서 열림)Meta는 Python Software Foundation(PSF) 후원을 10년째 이어가며, Python과 오픈소스 생태계의 지속 가능성이 자사 기술 스택의 장기적 안정성과 직결된다고 강조합니다. Python은 Meta의 가장 widely used 언어로, 제품 백엔드·AI 연구·인프라·개발 도구 전반에 활용됩니다. Meta는 PSF 후원을 통해 Python 핵심 개발, PyPI 보안, 교육 및 커뮤니티 행사를 지원하고 다른 기업과 개인의 참여도 촉구합니다. ## Meta에서 Python이 중요한 이유 - Python은 Meta에서 가장 많이 사용되는 프로그래밍 언어입니다. - Instagram과 Threads를 비롯한 제품의 백엔드, 인프라, AI 연구 등 다양한 영역에서 활용됩니다. - Meta 엔지니어들이 Python 핵심 유지보수와 Python Enhancement Proposal(PEP) 작성에 참여하고 있습니다. - Meta에서 시작된 머신러닝 프레임워크 PyTorch는 오픈소스 커뮤니티와 함께 개발된 뒤 독립 재단으로 분리되었습니다. - 빠른 타입 체커이자 언어 서버인 **Pyrefly** 등 Python 개발 생산성과 성능 향상을 위한 오픈소스 도구도 개발하고 있습니다. - AI 투자, 데이터 기반 제품 확장, 대규모 인프라 운영에서 Python의 역할이 계속 커질 것으로 보고 있습니다. ## PSF 후원이 필요한 이유 - 오픈소스를 사용하는 기업은 언어와 생태계의 보안성·건강성·혁신을 유지할 공동 책임이 있습니다. - Python으로 제품을 출시하고 모델을 학습시키는 과정은 개발자 커뮤니티와 PSF의 조직적 지원에 기반합니다. - Meta는 PSF 후원을 자사 기술 스택의 장기적인 안정성을 위한 전략적 투자로 봅니다. - 특정 기업의 필요를 넘어, 전 세계 개발자가 사용하는 공통 기반을 유지하는 데 기여한다는 의미가 있습니다. ## 개발자 상주 프로그램과 핵심 기술 지원 - PSF 후원금은 Python과 생태계 개선에 전념하는 정규 개발자를 고용하는 **Developer-in-Residence** 프로그램에 사용됩니다. - 이 프로그램은 자원봉사자에게만 의존하기 어려운 핵심 작업을 지속적으로 수행할 수 있게 합니다. - Python 패키지 저장소인 **PyPI**의 보안 강화에도 자금이 투입됩니다. - PyPI 보안 개선은 개발자가 패키지를 안전하게 게시하고 설치하도록 지원하며, Meta 내부 개발자에게도 직접적인 이점이 있습니다. ## 교육과 커뮤니티 생태계 지원 - Meta는 PyCon US와 같은 주요 Python 행사를 지원합니다. - 무료 또는 할인 입장권, 워크숍 및 서밋, 커뮤니티 모금 활동 등을 후원합니다. - PyLadies와 같은 그룹에 대한 지원은 다양한 배경의 인재가 Python 커뮤니티에 참여하도록 돕습니다. - 기술 인프라뿐 아니라 교육과 커뮤니티 성장이 Python의 장기적인 지속 가능성에 필수적이라고 설명합니다. ## PSF에 참여하는 방법 - **일회성 기부:** 원하는 금액을 한 번 기부할 수 있습니다. - **PSF 회원 가입:** 후원 수준에 따라 PSF의 방향에 관한 논의와 투표에 참여할 수 있으며, 금전 대신 시간으로 기여하는 방식도 있습니다. - **조직 후원:** 기업은 연간 후원 등급을 선택해 지속적으로 지원할 수 있습니다. - 조직 후원자는 PSF 웹사이트, 연례 보고서, 주요 행사에서 기업명과 로고를 공개할 수 있습니다. - 높은 등급의 후원자는 더 큰 브랜드 노출, 커뮤니티 행사 참여, 발표 및 특별 프로그램 참여 기회를 얻을 수 있습니다. 기업은 자사 제품과 인프라가 의존하는 오픈소스 프로젝트를 단순히 소비하는 데 그치지 말고, 재정 지원·개발 참여·커뮤니티 후원으로 생태계에 환원하는 것이 좋습니다. 개인 개발자 역시 기부, 회원 가입, 행사 참여와 같은 작은 방식으로 Python의 지속 가능성에 기여할 수 있습니다.
원문 읽기(새 탭에서 열림)Google Research는 건물별 지붕 반사율(albedo)을 분석한 데이터를 50개 이상 글로벌 도시로 확대 공개했다. Sentinel-2 위성 영상과 30cm급 상업 위성 영상을 AI로 결합해 개별 건물 단위의 저반사 지붕을 식별하고, 도시가 쿨 루프(cool roof) 도입 지역을 우선순위화할 수 있도록 한 것이다. 연구에 따르면 이러한 표적형 개입은 전 세계 도시의 극심한 더위를 최대 0.5°C까지 완화할 가능성이 있다. ## 도시 열섬과 쿨 루프의 필요성 - 극심한 더위로 매년 약 50만 명이 사망하며, 도시 지역은 전 세계 평균보다 약 두 배 빠르게 따뜻해지고 있다. - 어두운 지붕과 도로는 태양 에너지를 많이 흡수하고, 녹지 부족은 도시의 열 배출을 어렵게 만든다. - 지붕의 반사율을 높이면 건물이 흡수하는 태양 복사 에너지를 줄여 지표면 온도를 낮출 수 있다. - 쿨 루프는 비교적 비용 효율적인 열 완화 수단으로, 취약 지역과 취약 계층을 보호하는 데 활용될 수 있다. ## 건물 단위 반사율을 산출하는 AI 방법 - 기존 Sentinel-2 기반 반사율 데이터는 전 세계적으로 이용 가능하지만 해상도가 10m라 개별 지붕을 구분하기 어렵다. - 연구진은 다음 두 종류의 데이터를 결합했다. - Sentinel-2: 전 세계 범위와 방사학적 정확성 제공 - Airbus Pléiades Neo: 30cm급 고해상도 공간 정보 제공 - 머신러닝과 방사 보정 기법을 적용해 서로 다른 파장대의 정보를 융합하고, 도시 각 픽셀의 종합적인 스펙트럼 반사 특성을 재구성했다. - 그 결과 반사율 분석 해상도를 10m에서 30cm로 높여 개별 건물별 분석이 가능해졌다. ## 정확도 검증과 활용 가능성 - 콜로라도주 볼더에서 항공 초분광 영상으로 수집한 지상 기준 데이터와 결과를 비교했다. - 30cm급 융합 반사율 지도는 기준 데이터 대비 RMSE 0.04를 기록해 높은 정밀도를 보였다. - 도시 전체나 동네 평균이 아니라 다음과 같은 건물을 직접 선별할 수 있다. - 반사율이 낮은 대형 건물 - 열 취약 지역에 위치한 건물 - 쿨 루프 개조 효과가 클 것으로 예상되는 건물 - 이를 통해 도시 계획자는 제한된 예산을 가장 효과적인 건물과 지역에 우선 배분할 수 있다. ## Heat Resilience Earth Engine App - Google은 분석 결과를 의사결정자가 활용할 수 있도록 고해상도 Earth Engine 앱으로 공개했다. - 주요 기능은 다음과 같다. - **건물 단위 시각화:** 저반사 지붕을 건물 중심점 형태로 표시 - **기준선 분석:** 현재 도시·건물의 반사율을 파악하고 시간에 따른 변화를 추적 - **데이터 다운로드:** 지역 분석과 정책 수립을 위해 고해상도 데이터 반출 - **동적 확대:** 인구조사 구역 단위 집계에서 개별 건물 정보로 단계적으로 확대 - 공개 데이터는 도시가 쿨 루프 정책, 기후 적응 계획, 반사 표면 도입 전략을 수립하는 데 활용될 수 있다. ## 50개 이상 도시로 확대된 데이터 - 이번 공개 데이터는 9개 국가의 50개 이상 도시를 포함한다. - 주요 대상 도시로 다음 지역이 언급됐다. - 유럽: 런던, 아테네, 바르셀로나 - 브라질: 리우데자네이루, 상파울루 - 미국: 로스앤젤레스, 오스틴, 뉴욕 - 2024년에는 14개 도시를 대상으로 시범 적용했으며, 일부 도시는 이를 바탕으로 쿨 루프 조례와 기후 적응 계획을 추진했다. - 데이터와 앱은 공개되어 도시 정부, 연구자, 계획 담당자가 직접 탐색하고 분석할 수 있다. 도시 계획자는 Heat Resilience Earth Engine App에서 취약 지역과 저반사 건물을 먼저 확인한 뒤, 현장 검증과 비용·효과 분석을 결합해 쿨 루프 사업의 우선순위를 정하는 것이 바람직하다.
원문 읽기(새 탭에서 열림)LINE Part Time Jobs는 기존 2타워 임베딩 기반 리랭킹의 콜드 스타트와 검색 쿼리 미반영 문제를 해결하기 위해, 임베딩 공간을 날짜별로 안정화하는 후처리 방식을 도입했습니다. 저차원 SVD와 직교 Procrustes 정렬을 통해 매일 재학습되는 임베딩의 연속성을 유지했고, 그 결과 오프라인 전환 nDCG가 약 9%, 클릭 nDCG가 약 4.5% 향상되었습니다. A/B 테스트에서도 서비스 전체 KPI 4.7%, 매출 6.5% 증가를 달성했습니다. ## LINE Part Time Jobs 검색 리랭킹 구조 - 검색 시스템은 다음 두 단계로 구성됩니다. - **검색(retrieval):** 사용자의 쿼리에 맞는 구인 공고 후보를 수집 - **리랭킹(reranking):** 수집된 후보를 사용자별로 재정렬 - 기존에는 별도 배치 파이프라인에서 생성한 사용자·아이템 2타워 임베딩을 활용했습니다. - 사용자 임베딩과 아이템 임베딩의 코사인 유사도를 계산해 검색 결과 순위를 정했습니다. - 이 방식은 실시간 연산 부담을 줄일 수 있지만 다음 한계가 있었습니다. - 검색 쿼리와 역, 거리 같은 화면별 정보가 임베딩에 충분히 반영되지 않음 - 검색 외 추천 모듈이나 LINE 공식 계정에서 발생한 행동까지 함께 포함됨 - 검색 화면에 특화된 사용자 의도를 정밀하게 반영하기 어려움 ## 전용 리랭킹 모델 도입 과정의 문제 ### 공고 교체로 인한 콜드 스타트 - LINE Part Time Jobs의 공고는 월초에 대부분 교체됩니다. - 새로운 공고에 대한 클릭·지원 데이터가 충분히 쌓이기 전에는 전용 리랭킹 모델이 학습할 데이터가 부족합니다. - 그 결과 공고 교체 직후 모델 성능이 크게 저하되는 콜드 스타트 문제가 발생했습니다. ### 매일 변하는 임베딩 공간 - 2타워 모델은 성능 유지를 위해 주기적으로 랜덤 가중치에서 처음부터 재학습됩니다. - 재학습할 때마다 임베딩 공간의 방향과 좌표계가 달라질 수 있습니다. - 따라서 오늘 생성한 임베딩과 어제 생성한 임베딩은 실제 의미가 비슷해도 벡터 좌표상 직접 비교하기 어렵습니다. - 학습 시점과 추론 시점에 서로 다른 버전의 임베딩을 사용하면 다운스트림 리랭킹 모델의 입력 분포가 달라져 성능이 떨어질 수 있습니다. ## 임베딩 안정화 방식 - 각 날짜의 임베딩을 전날 안정화된 임베딩 공간에 맞춰 정렬합니다. - 첫날 임베딩은 별도 변환 없이 기준으로 사용합니다. - 이후에는 전날 결과를 다음 날의 기준으로 삼아 임베딩 공간을 순차적으로 연결합니다. - 이 방식은 특정 기준일에 모든 임베딩을 맞추는 대신, 시간에 따른 공간의 연속성을 유지합니다. - 결과적으로 임베딩 피처와 다운스트림 모델의 업데이트 시점을 엄격히 일치시키지 않아도 됩니다. ## 저차원 SVD와 직교 Procrustes ### 저차원 SVD - 아이템 임베딩과 사용자 임베딩을 각각 행렬 \(T\), \(W\)로 표현합니다. - 2타워 모델의 점수는 \(TW^\top\)로 계산되지만, 이 대규모 행렬을 직접 분해하지는 않습니다. - 대신 저차원 SVD를 사용해 변환 행렬 \(M_T\), \(M_W\)를 구합니다. - 변환 결과는 다음과 같습니다. - 아이템 임베딩: \(T' = TM_T\) - 사용자 임베딩: \(W' = WM_W\) - 이를 통해 각 학습에서 생성된 임베딩을 보다 표준화된 저차원 표현으로 변환합니다. ### 직교 Procrustes 정렬 - 당일 임베딩과 전날 안정화된 임베딩이 최대한 일치하도록 직교 변환을 계산합니다. - 직교 변환은 회전과 반전만 수행하므로 벡터 간 거리와 내적 구조를 보존합니다. - 따라서 임베딩의 유사도 기반 점수 계산 특성을 유지하면서 일별 공간 차이를 보정할 수 있습니다. ## 대규모 데이터 처리를 위한 구현 - 데이터 규모가 크기 때문에 알고리즘을 Apache Spark 기반 분산 처리로 구현했습니다. - 저차원 SVD에서는 원 논문의 QR 분해 대신 숄레스키 분해를 사용했습니다. - Gramian 행렬 \(G = A^\top A\)를 계산 - \(G = R^\top R\) 형태로 숄레스키 분해 - QR 분해에서 필요한 상삼각 행렬 \(R\)을 효율적으로 획득 - 직교 Procrustes에서는 다음과 같이 처리했습니다. - 대규모 행렬곱 \(M = B^\top A\)는 Spark로 분산 계산 - \(M\)은 임베딩 차원 \(e \times e\)의 작은 행렬이므로 SVD는 단일 노드에서 NumPy로 계산 - 대규모 벡터 데이터와 소규모 변환 행렬을 구분해 계산 자원을 효율적으로 배분했습니다. ## 안정화 효과와 평가 결과 - 안정화 전에는 서로 다른 날짜의 임베딩 상관관계가 거의 0에 가까웠습니다. - 안정화 후에는 다음 수준의 유사도를 유지했습니다. - 일주일 후: 약 0.88 - 한 달 후: 약 0.87 - 안정화하지 않은 임베딩을 다운스트림 모델에 추가하면 공간 불일치로 nDCG가 약 1~5% 하락했습니다. - 안정화된 임베딩을 사용한 경우: - 전환 nDCG 약 9.0% 향상 - 클릭 nDCG 약 4.5% 향상 ## A/B 테스트 결과와 해석 - 안정화된 임베딩과 콜드 스타트 대응책을 결합한 모델을 온라인 실험했습니다. - 검색 화면 단독 KPI에서는 통계적으로 유의미한 개선이 뚜렷하지 않았습니다. - 그러나 서비스 전체 기준으로는 다음 성과를 얻었습니다. - KPI 4.7% 향상 - 매출 6.5% 향상 - 이는 임베딩이 검색 화면뿐 아니라 서비스 전반의 사용자 행동과 장기적인 선호를 반영했기 때문으로 분석됩니다. - 검색 이후 다른 페이지로 이동하거나 다른 추천 모듈에서 지원하는 행동까지 긍정적인 영향을 받은 것으로 보입니다. - 기존 2타워 모델 구조나 학습 파이프라인을 변경하지 않고 임베딩 후처리만 추가했다는 점도 운영상 중요한 장점입니다. ## 실용적인 결론 재학습마다 좌표계가 달라지는 임베딩을 다운스트림 모델의 피처로 사용할 때는 날짜별 공간 정렬이 효과적인 해결책이 될 수 있습니다. 특히 저차원 SVD와 직교 Procrustes를 결합하면 임베딩의 유사도 구조를 유지하면서 버전 불일치와 드리프트를 줄일 수 있으므로, 기존 모델을 크게 변경하기 어려운 대규모 추천·검색 시스템에 적용하기 적합합니다.
원문 읽기(새 탭에서 열림)인메모리 캐시는 성능을 높이지만, 고정된 메모리 크기로 운영하면 수요가 낮을 때 비용이 낭비되고 수요가 많을 때 캐시 미스로 성능이 저하된다. 선형 탄력적 캐싱은 메모리 점유 비용과 캐시 미스 비용의 균형을 ‘스키 대여 문제’로 모델링해, 워크로드에 따라 페이지별 보관 시간과 캐시 크기를 동적으로 조정한다. Spanner 실험에서는 메모리 사용량을 15.5%, 총소유비용(TCO)을 약 5% 줄이면서 캐시 미스 증가는 5.5%에 그쳤다. ## 고정 크기 캐시의 비용 문제 - 기존 캐시는 미리 정한 메모리 용량 안에서 LRU 같은 정책으로 데이터를 제거한다. - 캐시가 너무 작으면 디스크나 다른 저장 시스템에 대한 접근이 늘어 성능이 떨어진다. - 반대로 피크 수요에 맞춰 캐시를 크게 잡으면 평상시 사용하지 않는 메모리 비용이 발생한다. - 특히 클라우드와 서버리스 환경에서는 메모리 용량과 사용 시간이 직접 비용으로 연결된다. ## 스키 대여 문제로 모델링한 캐싱 - 각 데이터 페이지는 다음 두 선택지 사이에서 판단된다. - **대여:** 데이터를 RAM에 유지하면서 메모리 비용을 계속 지불한다. - **구매:** 데이터를 제거해 메모리 비용을 아끼지만, 재요청 시 캐시 미스에 따른 지연 및 I/O 비용을 부담한다. - 페이지를 너무 오래 보관하면 메모리 비용이 커지고, 너무 빨리 제거하면 캐시 미스 비용이 커진다. - 전통적인 스키 대여 알고리즘은 누적 대여 비용이 재취득 비용과 같아지는 시점에 데이터를 제거하는 손익분기 전략을 사용한다. - 연구진은 최악의 경우를 보장하는 방식뿐 아니라, 실제 워크로드의 반복적인 접근 패턴을 학습해 더 나은 TTL을 예측하는 방법을 적용했다. ## TTL과 물리적 캐시 용량의 분리 - 이론적으로 캐시의 핵심 문제를 다음 두 부분으로 나눌 수 있음을 보였다. - 각 페이지를 얼마나 오래 보관할지 결정하는 문제 - 캐시가 실제로 가득 찼을 때 어떤 페이지를 제거할지 결정하는 문제 - 페이지 요청 시 스키 대여 알고리즘이 해당 페이지의 TTL을 계산한다. - TTL이 만료되기 전 재접근이 없으면 페이지를 자동으로 제거한다. - 캐시가 물리적으로 가득 차면 LRU 같은 전통적인 제거 정책이 보조적으로 작동한다. - 이 분리 덕분에 동적 캐시 크기 조절을 기존 캐시 시스템에 비교적 간단히 통합할 수 있다. ## Spanner의 경량 머신러닝 적용 - Spanner의 초당 수십억 건 요청을 처리하기 위해 TTL 예측 모델은 매우 가벼워야 했다. - 연구진은 몇 줄의 C++ 코드로 변환 가능한 얕은 결정 트리를 사용했다. - 모델이 고려한 주요 특징은 다음과 같다. - 데이터 페이지의 크기 - 캐시 미스 발생 시 데이터를 다시 가져오는 비용 - 수행되는 데이터베이스 연산의 유형 - 페이지의 과거 접근 패턴 - 결정 트리는 해석 가능하므로, 어떤 데이터가 오래 캐시할 가치가 있는지도 분석할 수 있다. ## Spanner 운영 환경의 실험 결과 - 고정 크기 캐시와 비교했을 때: - 메모리 사용량 **15.5% 감소** - 캐시 미스 **5.5% 증가** - 총소유비용(TCO) 약 **5% 감소** - 캐시 미스 증가는 비용이 낮은 데이터에 집중됐다. - 저장 시스템에 실제로 발생한 I/O 비용 증가는 약 **0.5%**에 불과했다. - 즉, 모든 캐시 미스를 동일하게 줄이기보다, 재취득 비용이 큰 데이터는 유지하고 저렴한 데이터는 적극적으로 제거하는 비용 인식형 전략이 효과적이었다. ## 공개 캐시 트레이스 검증 - Google 인프라에만 특화된 결과인지 확인하기 위해 다양한 공개 캐시 추적 데이터를 사용했다. - 고정 크기 캐시의 기준 정책으로는 페이지 크기가 서로 다른 상황을 처리할 수 있는 GDSF를 사용했다. - 여러 탄력적 캐시 변형을 비교했다. - 손익분기 스키 대여 정책 - 무작위화된 스키 대여 정책 - 학습된 TTL을 사용하는 정책 - 애플리케이션 수준의 특징이 없는 공개 데이터에서는 각 페이지별 최적 TTL을 학습했다. - 트레이스를 학습과 테스트로 나누고, 테스트 전에 일정 기간 캐시를 채우는 워밍업 절차를 적용했다. - 학습 데이터에서 관찰된 페이지는 미리 계산한 TTL을 사용하고, 처음 등장한 페이지는 기본 스키 대여 정책으로 처리했다. ## 다양한 워크로드에서의 효과 - 실험 결과, 탄력적 캐싱은 다양한 워크로드에서 고정 크기 캐시보다 일관되게 낮은 비용을 보였다. - 메모리 비용이 캐시 미스 비용보다 비싸질수록 탄력적 캐싱의 절감 효과가 커졌다. - 비슷한 메모리 규모를 사용하는 경우에도 탄력적 정책이 더 낮은 캐시 미스율을 보였다. - 캐시 크기를 수요에 맞춰 자동 조정하기 때문에 유휴 메모리 낭비를 줄이면서 성능을 유지할 수 있다. 실무에서는 모든 페이지를 동일하게 취급하는 LRU만 사용하기보다, 페이지 크기와 재조회 비용을 반영해 TTL을 차등 설정하는 방식이 유용하다. 특히 메모리 비용이 높고 데이터별 재취득 비용 차이가 큰 클라우드 데이터베이스에서는 선형 탄력적 캐싱을 적용해 비용 절감 효과를 측정해볼 만하다.
원문 읽기(새 탭에서 열림)넷플릭스는 콘텐츠 출시 준비 과정에서 수작업으로 입력된 미디어 전달 일정이 자주 부정확하거나 누락된다는 문제를 발견했습니다. 이에 제작 진행 데이터와 메타데이터를 활용한 머신러닝 모델로 Locked Cut과 최종 IMF 전달까지 남은 일수를 예측하고, 출시 지연 위험을 줄이려 합니다. 백테스트 결과 예측 일정은 수작업 일정에 비해 정확도와 제공 범위가 높았으며, 출시 직전 일정 오차와 출시 지연 사이의 상관관계도 완화했습니다. ## 콘텐츠 출시 준비와 일정 리스크 - 넷플릭스 콘텐츠는 개발, 프리프로덕션, 제작, 후반작업, 출시 준비 단계를 거쳐 공개됩니다. - 후반작업이 끝나면 최종 오디오·비디오 파일인 IMF가 전달되고, 이를 기반으로 다음 작업이 진행됩니다. - 아트워크와 예고편 제작 - 자막 생성 - 관람등급 지정 - 품질관리(QC) - 일부 작업은 최종본이 아닌 Locked Cut으로 미리 시작할 수 있습니다. - 다만 Locked Cut 이후 IMF가 크게 변경되면 추가 conformance 작업이 필요합니다. - IMF를 기다리면 일정이 압축될 수 있고, Locked Cut으로 일찍 시작하면 수정 비용이 발생하는 트레이드오프가 존재합니다. ## 수작업 일정의 한계 - 콘텐츠 파트너가 제작 일정에 Locked Cut과 IMF의 예상 전달일을 수동으로 입력합니다. - 실제 제작은 일정 변경, 인력·장비 충돌, 예기치 못한 문제 등으로 지속적으로 변동됩니다. - 그 결과 다음 문제가 발생합니다. - 일부 콘텐츠에는 예상 전달일 자체가 없음 - 기존 예상일이 실제 전달일과 크게 다름 - 출시 준비팀이 언제 작업을 시작해야 할지 판단하기 어려움 - 넷플릭스는 축적된 제작 데이터를 활용해 일정 누락을 보완하고 예상일의 정확도를 높이려 했습니다. ## 일정 오차와 출시 지연의 관계 - 일정 부정확성을 측정하기 위해 **Accumulated Error Days(AED)**라는 지표를 만들었습니다. - AED는 예상 전달일과 실제 전달일 사이의 편차를 시간에 따라 누적한 값으로, 두 일정 곡선 사이의 면적에 해당합니다. - 출시 지연이 발생한 콘텐츠는 지연이 없는 콘텐츠보다 평균 AED가 유의미하게 높았습니다. - 특히 전달일에 가까운 마지막 기간의 AED가 출시 지연과 더 강한 상관관계를 보였습니다. - 따라서 장기적인 평균 오차뿐 아니라 출시 직전 일정이 얼마나 정확한지가 출시 리스크 관리에 중요합니다. ## 머신러닝 기반 전달일 예측 - 예측 모델은 부스티드 트리 회귀 모델로, 진행 중인 제작물에 대해 IMF 또는 Locked Cut 전달까지 남은 일수를 예측합니다. - 다음과 같은 데이터를 입력값으로 활용합니다. - 제작 진행 상황과 관련된 운영 신호 - 콘텐츠 및 타이틀 메타데이터 - 계절성 신호 - 제작 과정의 매일 업데이트된 스냅샷 데이터를 사용해, 각 날짜 시점의 제작 상태를 모델링합니다. - 이 방식의 장점은 다음과 같습니다. - 새로운 정보가 들어올 때마다 최신 예측 생성 - 제작 단계가 달라도 적용 가능한 유연한 모델 구축 - 시간에 따라 변하는 동적 특성 반영 - 수작업 일정이 없는 콘텐츠에도 항상 예측일 제공 ## 종합적인 모델 평가 지표 - 실제 전달일과 비교해 예측일의 정확도를 평가하기 위해 여러 지표를 사용했습니다. - 평균·중앙값 절대 오차(MAE 등) - 평균·중앙값 오차를 통한 과대·과소 예측 편향 - 오차 표준편차를 통한 예측 분포의 변동성 - 전달일까지 일정 기간 이상 차이 나는 큰 오차의 비율 - 수작업 일정은 전달일까지 남은 기간별로 일정이 존재하는 콘텐츠의 비율인 coverage도 측정했습니다. - 예측 모델은 항상 날짜를 제공하도록 설계되어 수작업 일정의 공백을 보완할 수 있습니다. ## 수작업 일정 대비 개선 효과 - 백테스트에서 예측 일정은 대부분의 전달 시점과 평가 지표에서 수작업 일정보다 우수했습니다. - IMF와 Locked Cut 모두에서 평균 절대 오차가 크게 감소했습니다. - 큰 오차나 이상치도 수작업 일정에서 예측 일정으로 전환했을 때 줄어들었습니다. - 예측 모델은 단순히 최종 시점의 정확도를 높이는 것뿐 아니라 더 일찍 유용한 신호를 제공합니다. - Locked Cut 전달 6개월 전부터 예측일이 수작업 일정보다 정확했던 콘텐츠 비율은 76%였습니다. - 예측 일정의 MAE는 6.1주였으며, 수작업 일정이 같은 수준에 도달하려면 전달 11주 전까지 기다려야 했습니다. - AED를 6개월 또는 더 짧은 기간에 걸쳐 계산했을 때도 예측 IMF·Locked Cut 일정이 수작업 일정 대비 AED를 낮췄습니다. - 이러한 효과는 여러 구매 조직과 콘텐츠 유형, 즉 시리즈와 단편 콘텐츠 전반에서 대체로 나타났습니다. ## 기존 업무 흐름에 예측 일정 적용 - 전달 예상일은 이미 관련 팀의 업무 과정에 포함되어 있기 때문에, 예측 날짜를 도입해도 기존 프로세스를 전면 개편할 필요가 없습니다. - 다만 수작업 일정과 예측 일정이 동시에 존재하면 어느 쪽을 더 신뢰할지 판단해야 합니다. - 예측 일정이 평균적으로 더 정확하더라도 모든 상황에서 수작업 일정을 능가하는 것은 아니므로, 두 일정의 신뢰도를 비교하고 상황별로 선택하는 운영 체계가 필요합니다. - 제공된 글은 이 문제를 해결하기 위한 후속 방식 설명 중간에서 끝나 있어, 최종 의사결정 규칙이나 운영 정책은 확인할 수 없습니다. 실무적으로는 예측일을 기존 일정의 대체재라기보다, 누락된 일정을 보완하고 위험 신호를 조기에 제공하는 계층으로 도입하는 것이 적절합니다. 특히 출시 직전 AED와 일정 오차를 지속적으로 모니터링하면 출시 지연 가능성이 높은 콘텐츠에 우선 대응할 수 있습니다.
원문 읽기(새 탭에서 열림)토스의 TUES(Toss User Engagement Segment)는 유저의 서비스 이용 패턴을 기반으로 전체 MAU를 서로 겹치지 않게 분류하는 플랫폼 관점의 세그먼트다. V1은 앱 오픈 시 서비스 이용 확률과 K-Means를 활용했지만, 이용 깊이와 복합적인 서비스 사용 패턴을 충분히 반영하지 못했다. V2는 이용 횟수, Soft Clustering, 서비스별 관여도를 도입해 유저의 현재 상태와 다음 성장 액션을 더 정교하게 파악할 수 있도록 개선됐다. ### 플랫폼 관점의 유저 세그먼테이션이 필요한 이유 - 서비스별로 “A 서비스를 이용한 유저”, “B 서비스를 이용한 유저”를 따로 분류하면 한 유저가 여러 그룹에 중복 포함된다. - 플랫폼 전체 유저를 분석하려면 서로 겹치지 않으면서 전체를 포괄하는 MECE한 분류 체계가 필요하다. - TUES는 유저가 어떤 서비스를 주로 이용하고, 토스 앱을 어떤 목적과 패턴으로 사용하는지 파악하기 위한 도구다. ### TUES V1: 서비스 이용률 기반 분류 - 유저가 앱을 열 때마다 각 서비스를 이용할 확률을 계산했다. - 예: 한 달간 앱을 60회 열고 토스페이를 20회 이용하면 이용률은 33%다. - 서비스별 이용률 분포가 비슷한 유저를 K-Means Clustering으로 묶었다. - 머신러닝 결과를 그대로 사용하지 않고, 주요 서비스와 특징을 분석해 비즈니스와 제품 관점에서 이해하기 쉬운 세그먼트로 재구성했다. - 주요 세그먼트는 다음과 같다. - **고관여**: 여러 서비스를 높은 수준으로 이용하는 유저 - **서비스 지향군**: 토스뱅크, 토스증권, 조회, 혜택, 송금 등 특정 서비스를 주로 이용하는 유저 - **단순 방문**: 앱은 방문하지만 서비스를 거의 이용하지 않는 유저 ### TUES의 주요 활용 - **세그먼트 전환 전략 수립** - 세그먼트별 Retention 차이를 바탕으로 이탈을 줄이고 다음 단계로 이동시키는 전략을 세운다. - 단순 방문 유저를 서비스 지향 유저로, 서비스 지향 유저를 고관여 유저로 전환하는 흐름을 분석한다. - **제품 Growth 전략** - 각 제품의 주요 사용자가 어떤 TUES 세그먼트에 속하는지 파악해 성장 전략을 설계한다. - **유저 행동 분석** - 세그먼트가 언제, 어떤 계기로 바뀌는지 분석할 수 있다. - 이탈 유저, 부활 유저, 서비스 간 이동 패턴도 플랫폼 관점에서 확인할 수 있다. - **탑라인 지표 분석** - 전사 MAU가 변했을 때 어떤 세그먼트가 증감했는지 확인해 변화의 원인이 된 서비스를 추적한다. - 유저 단위로 MAU 증감 원인을 MECE하게 분석할 수 있다. - **타겟 마케팅** - 서비스별 상황에 적합한 세그먼트를 선정해 푸시 등 마케팅에 활용한다. - 토스의 마케팅 도구 TUBA에도 기본 세그먼트로 제공돼 마케터가 쉽게 사용할 수 있다. ### TUES V1의 한계 - **이용 깊이를 반영하지 못함** - 앱 오픈당 서비스를 한 번 이용한 유저와 여러 번 이용한 유저가 동일하게 취급됐다. - **다른 서비스의 관여도를 파악하기 어려움** - 같은 조회서비스 지향 유저라도 혜택서비스를 함께 이용하는 정도가 다르지만 이를 표현하지 못했다. - **한 유저를 하나의 세그먼트로만 분류** - Hard Clustering 방식이라 여러 서비스를 동시에 사용하는 유저의 복합성을 담기 어려웠다. - **신규 핵심 서비스 반영 부족** - 토스쇼핑, 앱인토스, 토스페이 등 새 서비스가 기존 분류에서 ETC로 처리됐다. ### TUES V2의 개선 방식 - **이용률에서 이용 횟수 기반으로 변경** - 서비스별 이용 횟수를 앱 오픈 횟수당 Feature로 사용해 서비스 이용의 깊이를 반영했다. - **Soft Clustering 도입** - 유저를 하나의 세그먼트에 고정하지 않고 여러 세그먼트에 대한 소속 정도를 계산한다. - 여러 서비스를 함께 사용하는 유저의 복합적인 이용 패턴을 표현할 수 있다. - **세 단계 세그먼트 구조 적용** - 서비스별 관여도 - 전체 앱 관여도 - 주 이용 서비스 - 이 구조를 통해 유저가 특정 세그먼트에 속한 이유를 더 상세히 설명하고, 다음 행동(Next Action)을 구체적으로 설계할 수 있게 됐다. ### V2로 가능해진 분석 - 예를 들어 “준고관여·혜택서비스 지향 유저가 고관여로 이동하려면 어떤 서비스 관여도를 먼저 높여야 하는가?”를 분석할 수 있다. - 서비스별 관여도가 Cross Activation 전략의 출발점이 된다. - 각 서비스 조직(Silo)은 자신의 서비스 관여도를 높이는 활동이 전사 세그먼트와 성과에 미친 영향을 정량적으로 추적할 수 있다. - 서비스 이용자와 미이용자의 관여도 수준을 비교해 제품 Growth 전략의 우선순위를 정할 수 있다. ### 향후 발전 방향 - 서비스 유사도 등을 활용해 세그먼트 전환 전략을 빠르게 도출하는 분석 프레임워크 구축 - 유저 프로파일과 서비스 이용 패턴을 결합한 전략적 유저 맵 개발 - MTVi 등 다른 분석 프레임워크와 결합해 세그먼트별 서비스 가치를 정량화 TUES의 핵심은 단순한 유저 분류가 아니라, “현재 어떤 유저인지”와 “어떤 액션을 통해 다음 단계로 이동시킬지”를 연결하는 데 있다. 플랫폼 서비스에서는 서비스별 지표만 따로 보기보다, 전체 관여도와 서비스 간 이용 패턴을 함께 분석하는 세그먼트 체계를 구축하는 것이 효과적이다.
원문 읽기(새 탭에서 열림)Cloudflare는 Ensemble AI의 핵심 인력을 영입해 AI 인프라와 추론 효율성 분야를 강화한다. 목표는 대규모·멀티모달 모델을 더 작고 빠르며 저렴하게 실행해, 개발자가 전 세계에서 AI 애플리케이션을 안정적으로 배포하도록 돕는 것이다. 이를 위해 모델 구조 개선, 메모리·연산량 감소, GPU 활용률 향상에 집중한다. ### Ensemble AI의 모델 효율화 기술 - Ensemble AI는 2023년 설립 이후 대규모 모델의 메모리, 연산량, 배포 비용을 줄이는 기술을 개발해왔다. - 단순한 양자화나 하드웨어 최적화가 아니라, 신경망의 구조 자체를 더 작고 효율적으로 만드는 접근을 취한다. - **NdLinear**는 트랜스포머의 표준 선형 계층을 대체하는 기술이다. - 다차원 활성값을 평탄화하지 않고 직접 처리한다. - 어텐션 헤드, 채널, 공간 차원 등 데이터의 의미 있는 구조를 보존한다. - 이를 통해 파라미터 수와 계산량을 줄인다. - **NdLinear-LoRA**는 대규모 모델을 파인튜닝할 때 학습해야 하는 파라미터 수를 줄이는 방식이다. - 양자화, 벡터 양자화와 결합하면 모델의 메모리 사용량과 실행 비용을 더욱 낮출 수 있다. ### Cloudflare Workers AI의 추론 효율 개선 - Workers AI는 Cloudflare의 글로벌 네트워크에서 서버리스 GPU 기반 추론을 제공한다. - AI 애플리케이션이 확산될수록 모델 추론 비용은 확장성을 결정하는 핵심 요소가 된다. - 모델 크기, 메모리 사용량, 처리량, GPU 활용률을 개선하면 개발자의 비용 부담을 줄이고 더 많은 AI 서비스를 운영할 수 있다. - 대상 워크로드는 텍스트 생성뿐 아니라 다음 영역으로 확대되고 있다. - AI 에이전트 - 멀티모달 모델 - 개인화 - 파인튜닝 - 검색 결합 생성(RAG) - 강화학습 - Cloudflare는 기존의 추론 엔진 **Infire**, 텐서 압축 기술 **Unweight**, 대규모 언어 모델 실행 플랫폼을 기반으로 효율화 작업을 강화한다. ### 글로벌 AI 인프라와 모델 압축의 결합 - 개발자는 이제 모델에 접근하는 것만으로는 충분하지 않으며, 모델을 저렴하고 안정적으로 사용자 가까이에서 실행할 인프라가 필요하다. - Cloudflare의 글로벌 네트워크와 서버리스 플랫폼은 AI 실행 환경을 애플리케이션이 이미 배포된 위치에 가깝게 제공할 수 있는 기반이 된다. - Ensemble AI의 모델 압축·효율적 아키텍처 기술을 결합하면 다음 효과를 기대할 수 있다. - 낮은 추론 비용 - 빠른 응답 속도 - 향상된 GPU 활용률 - 대규모 배포의 운영 복잡성 감소 - 다양한 모델 크기와 파인튜닝 방식에 대한 실험 용이성 ### 향후 목표 - Cloudflare는 강력한 AI 모델을 전 세계 규모로 실행하면서도 추론 경제성을 개선하는 것을 목표로 한다. - 새 팀은 대규모 언어 모델과 고급 AI 아키텍처의 서빙 비용을 낮추고, 효율적인 모델 실행과 확장 가능한 배포 방식을 발전시킬 예정이다. - 궁극적으로 개발자가 비용과 운영 부담에 막히지 않고 AI 애플리케이션을 구축·배포할 수 있는 플랫폼을 제공하려는 전략이다. 실용적으로는 AI 서비스를 설계할 때 모델 성능만 비교하기보다 파라미터 수, 메모리 사용량, GPU 활용률, 추론 지연시간, 글로벌 배포 비용을 함께 평가해야 한다. Cloudflare의 방향은 이러한 운영 비용을 모델 구조와 인프라 양쪽에서 동시에 줄이려는 접근으로 볼 수 있다.
원문 읽기(새 탭에서 열림)인터넷과 AI가 피부 질환 정보를 찾는 데 도움을 주지만, 정보를 이해하고 적절한 다음 행동을 결정하는 일은 여전히 어렵다. Google Research는 피부 질환 후보를 제시하는 AI가 일반인의 질환명 파악 능력과 검색 만족도를 크게 높인다는 점을 확인했지만, 병원 방문 시점 등 안전한 후속 조치 판단에는 효과가 제한적이라고 밝혔다. 따라서 피부과 AI는 진단 보조뿐 아니라 사용자의 의사결정을 지원하는 인간 중심 설계가 필요하다. ## 피부 건강 정보에서 인간 중심 연구가 필요한 이유 - 성인의 절반 이상이 인터넷으로 건강 정보를 찾고, 약 3분의 1은 AI를 활용한다. - 정보에 접근할 수 있어도 의학 용어를 모르거나 검색 결과를 잘못 해석할 수 있다. - 예: “다리에 빨간 점”이라는 증상을 보고도 실제 검색어인 “촉지성 자반(palpable purpura)”을 알기 어렵다. - 기존 연구에서는 인터넷 검색으로 질환 식별 능력은 향상될 수 있지만, 이후 어떤 행동을 해야 하는지 판단하는 능력은 반드시 좋아지지 않는 것으로 나타났다. - Google Research는 감별진단 AI 모델, 일반화 검증, SCIN 데이터셋 등을 개발해 왔으며, 궁극적으로는 피부 고민이 있는 사람들이 더 나은 결정을 내리도록 돕는 것을 목표로 삼았다. ## 대규모 실험: AI가 질환명 파악에 미치는 영향 JAMA Dermatology에 게재된 연구에서는 2,345명의 참가자에게 이미지와 병력 정보가 포함된 익명 피부 질환 사례를 제시하고, 자신의 사례라고 가정해 조사하도록 했다. - 참가자는 세 집단으로 무작위 배정됐다. - **일반 검색 대조군**: 기존 텍스트 기반 웹 검색 도구 사용 - **AI 집단**: AI가 예측한 3~7개의 질환 후보를 카드 형태로 제시하고, 각 질환의 이미지·증상·치료 정보를 제공 - **‘Wizard of Oz’ 집단**: 동일한 인터페이스를 사용하지만, AI 예측 대신 피부과 전문의 패널이 정한 실제 감별진단을 제시 - AI 도구는 확정 진단을 내리기보다 이미지와 가능한 질환을 연결해 정보를 찾기 쉽게 하는 방식으로 설계됐다. - AI 집단에서는 62% 이상이 질환명을 추측하려 했으며, 일반 검색 집단의 41%보다 높았다. - 질환명 추측 정확도는 다음과 같았다. - 일반 검색 집단: 8% - 일반 AI 집단: 23% - 전문의 감별진단을 제공한 집단: 36% - AI 사용자는 자신의 추측에 더 큰 자신감을 보였고, 검색 결과와 검색에 걸린 시간에 대한 만족도도 높았다. - 다만 전문의 감별진단을 그대로 제공한 경우에도 정확도가 완벽하지 않아, 후보 질환을 보여주는 것만으로 사용자의 이해가 완전해지는 것은 아니었다. ## 질환 식별과 다음 행동 판단은 별개의 문제 연구진은 AI가 지나치게 지시적이거나 진단적인 도구가 되지 않도록 설계했다. - 치료 및 질환 정보는 피부과 전문의가 권위 있는 자료를 바탕으로 작성했다. - 그러나 정보는 해당 질환의 일반적인 설명에 기반했으며, 개별 사례의 심각도에 맞춰 개인화되지는 않았다. - 참가자들은 다음과 같은 판단에서 여전히 어려움을 겪었다. - 집에서 관리해도 되는지 - 일반 진료를 예약해야 하는지 - 긴급하게 병원을 방문해야 하는지 - 다음 행동 판단의 정확도는 전문의 감별진단을 제공한 집단에서만 소폭 높아졌다. - 전문의 감별진단 집단: 63.5% - 일반 검색 대조군: 60% - 일반 AI 집단은 통계적으로 유의미한 개선을 보이지 않았다. - 오히려 일반 AI 집단은 피부과 전문의가 판단한 것보다 덜 긴급한 행동을 제안하는 비율이 다소 높았다. - AI 집단: 30% - 대조군: 27% - 이는 가능한 질환명을 알려주는 것만으로는 안전한 의료 결정을 보장할 수 없으며, 위험 신호와 긴급도를 명확히 안내하는 기능이 필요하다는 점을 보여준다. ## 실제 사용자와 지역사회를 대상으로 한 질적 연구 연구진은 통제된 설문만으로는 사람들이 자신의 피부 문제에 AI를 어떻게 적용하는지 충분히 알기 어렵다고 보고, 실제 피부 고민이 있는 지역사회 구성원을 대상으로 별도의 연구를 진행했다. - ACM CHI 학회에 발표된 연구는 Stanford Healthcare AI Applied Research Team, Santa Clara Family Health Plan과 공동으로 수행됐다. - 연구 대상 지역사회에는 의료 안전망인 Medi-Cal에 의존하는 사람들이 다수 포함됐다. - 참가자들은 실제 피부 고민을 가진 다양한 배경의 사람들로 구성됐다. - AI 피부 애플리케이션을 실제 환경에서 사용하게 하면서 다음을 살폈다. - 사용자가 AI 정보를 어떻게 해석하는지 - 자신의 증상과 AI가 제시한 정보를 어떻게 연결하는지 - 정보가 의료 이용이나 의사결정에 어떤 영향을 주는지 - 참가자들이 주로 사용하는 언어가 네 가지였기 때문에 애플리케이션을 각 언어로 번역했다. - 해당 언어에 능통한 자원봉사자나 직원도 참여해 의사소통을 지원함으로써, 다양한 언어권 사용자에게 적합한 설계를 연구하려 했다. 피부과 AI는 질환 후보를 빠르게 찾고 의학 정보를 이해하는 데 유용하지만, 그 결과를 곧바로 진단이나 치료 결정으로 받아들여서는 안 된다. 실제 서비스에서는 긴급 증상 안내, 불확실성 표시, 개인의 증상과 심각도를 반영한 후속 조치 안내, 의료진 상담 연결 기능을 함께 제공하는 것이 중요하다.
원문 읽기(새 탭에서 열림)Google Research는 Google Flood Hub에 사용된 홍수 예측 수문 모델의 아키텍처와 학습 파이프라인을 오픈소스로 공개했다. 이를 통해 각국 기상·수문 기관이 자체 데이터와 지역 지식을 활용해 AI 기반 하천 홍수 예측을 구축하고 운영할 수 있게 된다. 연구용 재현뿐 아니라 실제 경보 시스템과의 통합까지 지원해, 전 세계 홍수 대응 역량을 확대하는 것이 공개의 핵심 목적이다. ## 오픈소스 공개의 목적 - 홍수는 예고 없이 발생하고 장기적인 피해를 남기므로, 더 긴 예측 시간과 신속한 경보가 중요하다. - 공개된 프레임워크는 Google Flood Hub의 하천 홍수 예측 모델과 유사한 구조 및 학습 데이터를 활용할 수 있도록 설계됐다. - 연구자는 새로운 모델·데이터·학습 방식을 추가해 실험할 수 있다. - 각국의 운영 예보 기관은 자국의 관측 자료와 지역 전문 지식을 반영해 모델을 조정할 수 있다. - 기관이 데이터를 외부에 넘기지 않고 자체적으로 관리하면서도 최신 AI 예측 기술을 활용할 수 있다. ## 수문 모델의 구성과 작동 방식 - Python 패키지로 제공되며, 오픈소스 딥러닝 프레임워크인 PyTorch를 사용한다. - 입력 데이터에는 다음과 같은 정보가 포함된다. - 기후 및 기상 정보 - 토양 특성 - 지형 - 토지 피복 - 강수량과 기온 등 기상 예보 - 모델은 이러한 자료를 바탕으로 하천의 일일 유량을 예측한다. - 기본 모델 아키텍처로 LSTM(Long Short-Term Memory) 네트워크를 제공한다. - 학습에는 오픈소스 하천 데이터셋인 Caravan을 사용할 수 있다. - 사용자는 자체 유역의 관측 자료를 Caravan에 추가하거나, 이를 이용해 모델을 재학습·미세 조정할 수 있다. - 구현을 돕기 위해 Python 인터랙티브 튜토리얼과 동영상 자료도 제공된다. ## 모델 버전과 예측 성능 개선 - 저장소에는 두 가지 모델 버전이 포함된다. - 2024년 벤치마크 연구에 사용된 초기 모델 - 현재 Flood Hub의 실시간 전 세계 홍수 예측에 사용되는 개선 모델 - 개선된 v2 모델은 여러 기상 입력을 통합하는 ME-LSTM 구조를 사용한다. - 각 기상 데이터 제품을 별도의 네트워크가 임베딩한 뒤, 그 결과를 LSTM에 전달한다. - LSTM은 하천 유량에 대한 확률 분포를 생성해 불확실성까지 반영한다. - 통합되는 주요 기상 자료는 다음과 같다. - Google GraphCast - ECMWF의 IFS - NASA IMERG 위성 강수량 자료 - NOAA CPC 관측 기반 일일 강수량 - 기존 모델과 비교해 신뢰할 수 있는 예측 기간이 다음과 같이 늘었다. - 관측소가 있는 유역: 6일 연장 - 관측소가 없는 유역: 1일 연장 ## 지역 데이터와 현장 지식의 활용 - 세계기상기구(WMO)는 효과적인 재난 경보를 위해 지역 관측 자료와 Indigenous and Local Knowledge(ILK)가 중요하다고 지적한다. - 공개 프레임워크는 지역 예보 담당자가 모델 학습과 운영 과정에 직접 참여할 수 있게 한다. - 전통적인 물리 기반 수문 모델보다 구조가 단순하고 상대적으로 저렴하게 학습할 수 있다. - 지역별 강수 특성, 지형, 유역 반응, 현장 경험 등을 모델에 반영할 수 있다. - 이를 통해 중앙집중형 글로벌 모델을 지역 상황에 맞게 조정할 수 있다. ## CHMI와 Delft-FEWS 통합 사례 - Google은 체코 수문기상연구소(CHMI)와 협력해 모델의 실제 활용 가능성을 검증했다. - CHMI는 AI 모델의 예측 결과가 현지에서 보정된 전통적 개념형 수문 모델과 비슷한 수준임을 확인했다. - 또한 오픈소스 수문 프레임워크를 Delft-FEWS에 연결하는 어댑터를 개발했다. - Delft-FEWS는 국가·지역 수문 기관, NGO, 민간기업 등이 사용하는 운영 홍수 예측 플랫폼이다. - 이 통합 사례는 기존 예보 업무 흐름을 유지하면서 머신러닝 모델을 도입하는 방법을 보여주는 참고 모델이 된다. ## 라이선스와 기대 효과 - 모델 아키텍처, 문서, 학습 자료는 GitHub에 공개됐다. - Apache 2.0 라이선스를 적용해 연구자와 운영 기관이 폭넓게 사용할 수 있다. - 고가의 전통적 예보 인프라를 갖추기 어려운 지역도 고급 홍수 예측 기술에 접근할 수 있다. - 각국 기관이 독립적으로 모델을 개선함으로써 지역 맞춤형 조기경보 체계를 구축할 수 있다. - 장기적으로는 개방형·상호운용 가능한 수문 모델 생태계를 형성해 홍수 대응과 기후 적응 역량을 강화하는 것이 목표다. ## 실용적인 결론 이 프레임워크는 연구용 모델 공개를 넘어, 자체 관측 자료를 보유한 기상·수문 기관이 실제 경보 시스템에 AI를 도입할 수 있도록 만든 실무형 도구다. 도입을 검토하는 기관은 먼저 Caravan과 지역 유량 자료로 모델을 검증한 뒤, Delft-FEWS 같은 기존 운영 플랫폼과 연계하는 방식이 현실적이다.
원문 읽기(새 탭에서 열림)Google I/O 2026에서 Google Research는 AI를 과학적 발견과 헬스케어 혁신을 가속하는 ‘에이전트 시대’의 핵심 기술로 제시했다. 연구용 AI 에이전트가 가설 생성부터 코드 작성·실험·검증까지 수행하고, 건강 분야에서는 개인화된 코칭과 진료 준비를 지원한다. Google은 이러한 기술이 인간의 연구 역량을 증폭할 수 있다고 강조하면서도, 실제 연구자·의료진과의 협업 및 책임 있는 공개를 병행하고 있다. ## 과학적 발견을 가속하는 AI - **Gemini for Science** - 과학 연구 전 과정을 지원하는 실험적 도구 모음이다. - 가설 생성, 계산 실험, 문헌 분석, 연구용 에이전트 활용 등을 하나의 생태계로 묶는다. - Google Cloud, Google DeepMind, Google Labs와 협력해 개발됐다. - **Empirical Research Assistance(ERA)** - 과학자가 전문가 수준의 경험적 연구 소프트웨어를 작성하도록 돕는 연구 코딩 시스템이다. - 문제와 평가 기준을 입력하면 새로운 개념을 제안하고, 코드를 작성한 뒤 결과를 평가한다. - 트리 탐색을 사용해 수천 개의 코드 변형을 반복적으로 생성·검증하며 성능을 최적화한다. - 신경과학과 우주론 연구에 활용됐으며, 호흡기 질환 입원 예측과 캘리포니아 강 유역의 계절별 유출량 예측에도 적용됐다. - **Co-Scientist** - Gemini를 기반으로 한 다중 에이전트 협업 시스템이다. - 전문화된 여러 에이전트가 가설을 생성하고, 서로 평가·토론·수정한다. - 항균제 내성, 식물 면역, 간 섬유화 등 연구 난제를 다루는 데 활용되고 있다. - **Computational Discovery** - ERA와 AlphaEvolve를 결합한 에이전트형 연구 엔진이다. - 수천 개의 코드 변형을 병렬로 생성하고 점수화해, 사람이 수개월 걸려 시험할 모델과 가설을 빠르게 비교한다. - **Hypothesis Generation과 Literature Insights** - Hypothesis Generation은 연구자와 함께 문제를 정의한 뒤, 다중 에이전트 ‘아이디어 토너먼트’를 통해 가설을 생성·논쟁·평가한다. - 생성된 주장은 클릭 가능한 인용을 제공해 과학적 검증 가능성을 높인다. - Literature Insights는 NotebookLM을 활용해 방대한 과학 문헌의 결과를 요약하고 구조화한다. - 매년 수백만 편의 논문이 발표되는 상황에서 문헌 종합을 자동화하는 것을 목표로 한다. ## 연구 자동화와 과학 검증 - Google Antigravity 같은 에이전트형 코딩 플랫폼에서 사용할 수 있는 **Science Skills**를 제공한다. - 구조 생물정보학과 유전체 분석처럼 복잡한 연구 작업을 수시간이 아닌 수분 단위로 수행할 수 있도록 지원한다. - 학술대회의 논문 심사와 검증에도 AI를 실험적으로 적용하고 있다. - **Paper Assistant Tool(PAT)**은 ICML, STOC, NeurIPS 등에서 1만 편 이상의 논문을 검토했다. - PAT의 피드백을 통해 저자가 이론적 허점을 발견하거나 새로운 실험을 수행할 수 있었다. - **Gemini Deep Think**는 수학·물리학·컴퓨터과학 연구자들과 협력해 네트워크 퍼즐의 미해결 문제, 최적화 추측, 머신러닝 최적화 현상, 경매 경제학, 우주끈의 물리적 특이점 등 전문가 수준의 난제를 다뤘다. ## AI를 활용한 헬스케어 발전 - Google은 증상 이해부터 진료 준비, 의료 기록 해석, 진료 이후 관리까지 이어지는 건강 관리 여정 전반을 AI로 지원하려 한다. - 이러한 연구를 바탕으로 **Google Health 앱**과 **Google Health Coach**를 개발했다. - Google Health 앱은 기존 Fitbit 사용자에게 순차적으로 제공되며, 개인별 상황에 맞춘 종합적이고 적응형인 건강 코칭을 제공한다. ## 증상 분석과 진료 준비 지원 - **Symptom AI** - 대화형 건강 데이터를 분석해 사용자의 증상과 관련된 감별 진단을 추론하는 연구용 도구다. - Fitbit 앱을 통한 무작위 연구에 13,917명이 참여했다. - 독립 임상의의 맹검 비교에서 Symptom AI의 감별 진단이 다른 임상의의 결과보다 약 두 배 자주 선호됐다. - 이는 AI가 다양한 표현 방식과 실제 질병 분포를 반영한 대화 데이터를 활용할 가능성을 보여준다. - **Plan for Care** - 사용자가 의사와의 진료를 준비하도록 돕는 파일럿 연구다. - 1,779명이 참여했으며, 기준 모델과 비교해 진료 준비가 더 잘 됐다고 느낀 사용자가 15% 증가했다. - 진료를 최대한 활용할 자신감이 있다고 답한 사용자도 13% 늘었다. - **개인 건강 기록(PHR) 연구** - 모델의 문맥에 개인 건강 기록을 포함했을 때 건강 관련 AI의 효과가 어떻게 달라지는지 평가했다. - 제공된 글은 PHR 연구의 구체적인 결과가 이어지기 전에 중단되어 있어, 해당 부분의 결론은 확인할 수 없다. ## 실용적인 의미 Google이 제시한 방향은 AI를 단순한 답변 도구가 아니라 가설을 세우고 실험하며 결과를 검증하는 연구 파트너로 발전시키는 것이다. 다만 과학적 정확성, 의료 안전성, 개인정보 보호가 중요한 영역인 만큼, 실제 활용에서는 AI의 결과를 연구자와 의료진이 검토하고 제한된 범위에서 단계적으로 도입하는 접근이 필요하다.
원문 읽기(새 탭에서 열림)2026년 5월 AWS Heroes로 네 명의 커뮤니티 리더가 새롭게 선정되었습니다. 이들은 AI·서버리스·클라우드 아키텍처 지식을 공유하고, 사용자 그룹과 커뮤니티 행사를 운영하며, 교육과 멘토링으로 AWS 생태계의 성장을 돕고 있습니다. 특히 AWS re:Invent 도구 개발, 라틴아메리카 최대 규모 커뮤니티 운영, AI/ML 인증 기여 등 각자의 전문성을 바탕으로 활동해 왔습니다. ## AWS Heroes 선정의 의미 - AWS Heroes는 기술 전문성뿐 아니라 커뮤니티에 대한 기여와 지식 공유를 인정받은 리더들입니다. - 선정된 인물들은 블로그, 팟캐스트, 컨퍼런스, 사용자 그룹, 교육 행사 등을 통해 다른 개발자와 클라우드 실무자를 지원해 왔습니다. - 이번에는 이탈리아, 캐나다, 아르헨티나에서 AI, 서버리스, 클라우드 아키텍처 분야의 리더들이 선정되었습니다. ## Damiano Giorgi: AI 기반 re:Invent 세션 추천 도구 - 이탈리아 파비아 출신의 **Artificial Intelligence Hero**입니다. - 온프레미스 시스템 엔지니어에서 AWS 클라우드 솔루션 아키텍트로 전환했으며, 현재 AI의 발전과 활용에 집중하고 있습니다. - AWS User Group Pavia와 AWS User Group Milan의 운영을 돕고 있습니다. - 개인 블로그 **“Bass and Bytes”**를 통해 기술 콘텐츠를 공유합니다. - Amazon Bedrock과 Amazon Nova를 활용해 관심사에 맞는 AWS re:Invent 세션을 찾도록 돕는 **“Unofficial post:Invent Session Suggester”**를 개발했습니다. - AWS Summit Milan을 비롯해 이탈리아, 아드리아 지역, 그리스, 네덜란드 등 유럽의 다양한 컨퍼런스에서 발표하고 있습니다. ## Darryl Ruggles: 서버리스와 AI/ML 아키텍처 전파 - 캐나다 오타와 출신의 **Serverless Hero**입니다. - 소프트웨어 개발자로 오랜 기간 일한 뒤 AWS 애플리케이션 및 AI/ML 아키텍처 분야로 전문성을 확장했습니다. - 서버리스, 컨테이너, AI/ML, FinOps를 주제로 블로그, LinkedIn, 공개 프로젝트에서 지식을 공유합니다. - **“Believe In Serverless”**를 포함한 여러 온라인 AWS 커뮤니티에서 활발히 활동합니다. - 온라인과 오프라인 행사를 가리지 않고 다른 개발자들과 교류하며 서버리스 기술의 실제 활용을 돕고 있습니다. ## Ricardo Daniel Ceci: 라틴아메리카 클라우드 커뮤니티 확장 - 아르헨티나 부에노스아이레스 출신의 **Artificial Intelligence Hero**입니다. - 약 2,400명의 회원을 보유한 아르헨티나 최대 AWS 커뮤니티인 **AWS User Group Buenos Aires**를 이끌고 있습니다. - **AWS Community Day Argentina**의 수석 조직자로 활동했습니다. - 2025년 **LATAM AWS Community Leader of the Year**로 선정되었습니다. - 라틴아메리카의 클라우드 전문가, AWS Heroes, 개발자 애드보킷과 대화하는 팟캐스트를 운영합니다. - 15년 이상의 클라우드 및 웹 개발 경험을 바탕으로 스페인어권 개발자들이 클라우드와 AI에 쉽게 접근하도록 지원하고 있습니다. ## Matias Kreder: AWS 인증과 머신러닝 커뮤니티 기여 - 부에노스아이레스 출신의 **Artificial Intelligence Hero**입니다. - AWS 인증 시험의 Subject Matter Expert(SME)로 참여했으며, **AWS Certified AI Practitioner**를 포함한 여러 AI/ML 인증 개발에 기여했습니다. - AWS DeepRacer에서 세 차례 결승 진출자로 선정된 경험을 계기로 커뮤니티 활동을 시작했습니다. - 이후 지역 내 DeepRacer 대회와 머신러닝 발표·행사를 조직했습니다. - AWS User Group Buenos Aires의 리더로서 2025년 AWS Community Day Argentina를 조직했습니다. - 라틴아메리카 전역의 커뮤니티 행사에서 AI, 머신러닝, AWS 관련 주제로 발표하고 있습니다. ## 실용적인 시사점 - AWS 기술을 학습할 때 공식 문서뿐 아니라 사용자 그룹, 커뮤니티 행사, 팟캐스트, 공개 프로젝트를 함께 활용하면 실무 관점을 얻을 수 있습니다. - Amazon Bedrock·Nova 같은 생성형 AI 서비스를 실제 개발 도구에 적용한 사례는 AWS 서비스 학습과 프로토타이핑에 참고할 만합니다. - 관심 지역의 AWS Heroes나 사용자 그룹에 참여하면 발표, 멘토링, 자격증 준비, 네트워킹 기회를 얻을 수 있습니다.
원문 읽기(새 탭에서 열림)
