지하철 노선도 한 장을 보고 두 가지 질문을 받았다고 생각해 보자.“빨간색 노선은 무엇인가?”“A역에서 B역까지 가려면 어디에서 갈아타야 하는가?”같은 그림이지만 필요한 처리는 다르다. 첫 질문은 색과 노선 이름을 연결하면 된다. 두 번째 질문은 역과 노선의 연결 관계를 따라가야 한다.AI도 질문에 따라 그림을 처리하는 방식을 바꿀 수 있을까? 복잡한 질문에는 시각 정보를 조금 더 처리하게 할 수 있을까?AdaLoop는 질문에 맞춰 비전 인코더의 계산을 조절하고, 일부 층을 반복 사용해 내부 시각 정보를 갱신하는 방법이다. 언어 모델이 답을 길게 생각하도록 하는 것과 함께, 그 앞의 시각 처리에도 추가 계산을 배분한다.이 글은 Han 등의 공개 논문 AdaLoop: Thinking with the Vis..

이미지를 보고 자연스러운 설명을 만드는 모델이 있다고 하자. 그런데 메뉴판에 적힌 가격을 바꿔도 답변이 그대로라면, 이 모델은 이미지를 얼마나 읽고 있는 것일까?이번 AI 스터디에서는 Kanana-2 Vision Encoder를 공부하고 비평가 역할을 맡았다. 흥미로웠던 부분은 성능 점수 자체보다, 그 점수와 학습 곡선이 어디까지 설명해 주는지를 따져 보는 과정이었다.이 글에서는 카카오가 공개한 개발 방식과 결과를 먼저 살펴보고, 스터디에서 정리한 여섯 가지 질문을 이어서 다룬다. 카카오의 공식 개발기와 모델 카드, 개발기가 인용한 GenLIP 논문을 함께 참고했다. GenLIP는 Kanana 자체를 설명하는 논문이 아니라 별도의 기반 연구다. 아래 수치는 각 자료의 보고값이며 직접 재현한 측정치는 아니..

Kafka에서 send()나 produce()를 호출했다고 곧바로 업무 처리가 끝난 것은 아니다. 프로듀서가 전송을 준비한 시점, 브로커가 레코드를 받아들인 시점, 컨슈머가 업무를 처리한 시점, 처리 위치를 커밋한 시점은 서로 다르다.중복과 누락을 이해하려면 이 경계를 나눠 봐야 한다. 이 글에서는 orders 토픽의 주문 이벤트를 예로 프로듀서의 전송·확인 응답·멱등성, 컨슈머의 그룹·리밸런싱·커밋을 연결하고 Python 예제로 마무리한다.1. 프로듀서는 레코드를 어떻게 보내는가프로듀서는 애플리케이션의 데이터를 Kafka 레코드로 만들어 보낸다. 레코드에는 토픽, 키, 값, 선택적인 파티션·타임스탬프·헤더 등이 들어갈 수 있다.topic: orderskey: order-Avalue: {"event_id..

주문이 생성되면 결제를 처리하고, 재고를 갱신하고, 알림을 보내고, 분석용 데이터도 쌓아야 한다. 주문 서버가 이 작업들을 모두 직접 호출하면 연결 대상이 늘어날수록 장애와 지연의 영향도 커진다.Kafka를 두면 주문 서버는 이벤트를 기록하고, 필요한 시스템들이 각자의 속도로 이벤트를 읽도록 구성할 수 있다. 이 구조를 이해하는 출발점은 Kafka가 데이터를 보관하는 분산 로그이며, 파티션을 단위로 저장과 처리를 나눈다는 점이다.이 글에서는 주문 이벤트를 예로 토픽·파티션·오프셋, 디스크 저장 구조, 복제와 클러스터를 연결한 뒤 로컬에서 메시지를 주고받는 세팅까지 살펴본다.1. Kafka를 사이에 두면 무엇이 달라질까Apache Kafka는 이벤트를 발행하고, 저장하고, 구독해 처리하는 분산 이벤트 스트..

같은 코드를 실행해도 컴퓨터마다 설치된 언어와 라이브러리 버전이 다르면 결과가 달라질 수 있다. Docker는 애플리케이션과 필요한 실행 환경을 이미지로 묶고, 이를 컨테이너로 실행해 환경 차이를 줄이는 도구다.컨테이너와 가상 머신은 어떻게 다를까?가상 머신은 일반적으로 하이퍼바이저 위에서 각 게스트 운영체제를 실행한다. 반면 리눅스 컨테이너는 호스트의 리눅스 커널을 공유하면서 프로세스와 파일 시스템 등을 격리한다. 그래서 별도의 게스트 OS 전체를 매번 실행하지 않고도 애플리케이션을 분리할 수 있다.공유하는 커널과 격리 방식이 다르므로 컨테이너를 가상 머신과 동일한 보안 경계로 가정하면 안 된다. 또한 macOS나 Windows의 Docker Desktop에서 Linux 컨테이너를 실행할 때는 Linu..

데이터 분석은 파일을 한 번 읽어 계산하는 것으로 끝나지 않는다. 새로운 데이터가 계속 들어오면 수집, 정제, 저장과 분석을 반복할 수 있어야 한다. 이 흐름을 설계하는 것이 데이터 파이프라인이고, 리눅스는 그 작업을 실행하고 살펴보는 데 자주 사용하는 환경이다.데이터 파이프라인은 무엇을 연결할까?예를 들어 서비스의 주문 데이터와 접속 로그로 하루 매출을 집계한다고 해 보자. 주문은 데이터베이스에, 접속 기록은 로그 파일에 쌓인다. 둘을 필요한 주기로 수집하고, 시간대와 자료형을 맞추고, 분석할 수 있는 장소에 저장한 뒤 대시보드에 제공해야 한다.이 예시의 흐름은 수집 → 정제 → 저장 → 분석이다. 실제 파이프라인은 저장 후 변환하거나 여러 경로로 나뉠 수도 있다. 중요한 것은 단계 이름보다 각 단계의..

GPT-5.1-Codex-Max 시스템 카드 읽기: 코딩 에이전트의 성능과 안전성은 어떻게 읽어야 할까?코딩 에이전트에 버그 수정을 맡기면 코드를 생성하는 것만으로 작업이 끝나지 않는다. 파일을 읽고, 수정하고, 명령을 실행하고, 테스트 결과를 해석해야 한다. 그 사이 사용자가 고친 내용도 지켜야 한다. 이런 시스템의 평가 점수는 무엇을 믿고 맡길 수 있는지 얼마나 알려 줄까?OpenAI의 GPT-5.1-Codex-Max System Card를 읽는 데 필요한 기준은 세 가지다. 무엇을 평가했는지, 무엇을 성공으로 셌는지, 어떤 환경에서 실행했는지를 함께 보는 것이다. 이 글은 표지에 2025년 11월 18일로 적힌 공식 시스템 카드 PDF를 기준으로 한다. 제품 설정과 위험 판단도 그 문서 시점의 설명..

Codex 논문 읽기: AI가 만든 코드는 어떻게 평가할까?자연어 설명을 보고 Python 함수를 만드는 AI를 평가하려면 무엇을 확인해야 할까? 참조 코드와 비슷하게 썼는지보다 중요한 것은 요구한 동작을 실제로 수행하는지다. 그런데 후보를 여러 개 만들기 시작하면 질문이 하나 더 생긴다. 정답이 후보 안에 있기만 하면 되는가, 아니면 사용자에게 정답 하나를 골라 줘야 하는가?Mark Chen 등의 2021년 논문 Evaluating Large Language Models Trained on Code는 코드 학습, 실행 평가, 여러 후보의 생성과 선택을 연결해 이 문제를 다룬다. 이 글은 논문 v2를 기준으로 읽는다. 여기서 Codex는 당시 연구한 코드 생성 모델이다. 이후 같은 이름을 사용하는 코딩 ..