17일 사이에 4개 연구소가 트리플·쿼드릴리온 파라미터급 LLM을 연달아 공개했습니다. 2026년 4월 7일 GLM-5.1을 시작으로 MiniMax M2.7(4/11), Kimi K2.6(4/20), DeepSeek V4(4/24)까지 — 모두 SWE-Bench에서 57~80% 구간에 들어오는 수치를 기록했고, 비교 기준선은 GPT-5.4(57.7%)와 Claude Opus 4.6(57.3%)입니다.왜 이 시기에 몰렸을까?2026년 초부터 중국 AI 연구소들 사이에서 Huawei Ascend 910B 클러스터 가용성이 높아졌다는 보고가 나왔습니다. GLM-5.1이 Ascend 910B 10만 개로 학습됐다고 명시한 점이 하나의 신호입니다. NVIDIA 수출 제한이 오히려 국산 하드웨어 스택 성숙을 앞당겼..

1. 테이프 코드명이 AI 커뮤니티를 뒤흔든 하루2026년 4월 초, AI 모델 비교 플랫폼 LM Arena에 이름이 이상한 모델 세 개가 조용히 등장했습니다. maskingtape-alpha, gaffertape-alpha, packingtape-alpha. 모두 테이프 종류입니다. 공식 설명도, 제작사 표기도 없었습니다. 그런데 몇 시간 만에 개발자 커뮤니티 피드가 이 모델 얘기로 가득 찼고, 모델들은 그날 안에 조용히 사라졌습니다.그리고 2026년 4월 21일, OpenAI는 ChatGPT Images 2.0을 공식 출시했습니다. 커뮤니티가 "덕테이프(duct-tape) 계열"이라고 불렀던 그 모델이 맞습니다. 2. 무슨 일이 있었나 - 확인된 사실 vs 추론직접 살펴보니 설계 방향이 꽤 달랐습니다..

2026년 4월 30일, OpenAI가 Codex CLI 0.128.0을 배포하면서 /goal 명령이 조용히 추가됐습니다. 자율 반복 루프를 CLI에서 직접 돌릴 수 있다는 점에서 Claude Code 생태계의 Ralph loop와 비교 대상으로 자주 언급되고 있습니다. 직접 살펴보니 설계 방향이 꽤 달랐습니다. 이 글에서는 두 도구의 작동 방식과 실용적 제약을 정리해봤습니다. Codex CLI /goal은 어떻게 돌아가나공식 문서 기준으로는, /goal은 토큰 예산 기반의 반복 루프입니다. 목표를 설정하면 plan → act → test → review → iterate 순서로 단계를 반복하고, 목표가 달성되거나 토큰 예산이 소진되면 종료됩니다.구현 방식이 흥미롭습니다. goals/continuatio..

새 마이크로서비스를 만들 때마다 패키지 구조부터 고민되는 이유MSA 프로젝트에 투입되면 가장 먼저 마주치는 질문이 있다. "이 서비스의 패키지 구조를 어떻게 잡을 것인가?" Layered로 갈 것인가, Hexagonal로 갈 것인가, Clean Architecture를 적용할 것인가. 팀 내에서 한번쯤 이 논쟁을 해본 경험이 있을 것이다. 그리고 대부분은 "일단 Layered로 시작하자"로 결론이 난다. 문제는 6개월 뒤, 서비스가 복잡해졌을 때 구조를 바꾸려면 이미 늦었다는 것이다.문제 정의: 왜 MSA에서 프로젝트 구조가 중요한가모놀리식에서는 구조 설계를 잘못해도 하나의 코드베이스 안에서 리팩터링할 수 있다. MSA에서는 사정이 다르다. 서비스 하나가 곧 독립된 배포 단위이고, 한번 잡은 구조는 해당..

Docker Desktop에서 OrbStack으로 도구를 교체했더니 DB가 비어있었다docker context use orbstack을 실행한 순간, 기존 컨테이너와 볼륨이 모두 사라진 것처럼 보인다. docker volume ls를 쳐봐도 목록이 텅 비어있다. Docker Desktop에서 수개월간 쌓아온 개발 데이터가 증발한 것처럼 느껴지는 그 순간, 실제로 데이터가 사라진 것은 아니다. 문제는 두 런타임이 서로 다른 Linux VM 위에서 동작한다는 것이다. context를 전환하는 것만으로 볼륨이 자동 이관되지는 않는다.왜 단순 context 전환으로는 부족한가Docker Desktop과 OrbStack은 각각 독립된 Linux VM을 사용한다. Docker CLI의 context는 "어떤 Doc..

1. 학습을 시작한 계기초기에는 API Gateway를 단순한 라우팅 레이어로 정의했다. 요청을 각 마이크로서비스로 전달하는 역할만 수행하면 충분하다고 판단했다. 하지만 서비스가 분리되면서 인증 처리 위치가 문제로 떠올랐다.User, Event, Reservation, Payment 서비스 각각에서 JWT를 검증하는 구조를 고려했지만, 이는 두 가지 문제를 만든다.JWT 검증 로직의 중복 구현인증 우회 가능성특히, Queue Token 없이도 POST /reservations/hold를 직접 호출하면 Reservation Service까지 요청이 도달하는 문제가 발생했다.즉, 대기열을 우회한 좌석 선점이 가능한 구조였다.이 지점에서 설계 기준이 바뀌었다.인증은 각 서비스가 아니라 진입 지점에서 통합 처리..