글

들어가며 MacBook Air M4에 16GB 통합 메모리가 달려있다. PyTorch로 3B 모델을 학습시키면 몇 분 안에 팬이 돌아가고, 무팬 모델에서는 서멀 스로틀링이 걸린다. Bit-Axon은 이 제약을 아키텍처 단에서 해결한 3.2B 파라미터 하이브리드 언어 모델이다. 핵심 아이디어는 삼층 샌드위치 구조다: 24개 레이어를 세 구간으로 나누어 각각 다른 연산 방식을 적용한다. L L L a a a y y y e e e r r r 1 1 9 7 - - - 8 1 2 : 6 4 : : █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ S S S P W M u A r + e + M A M o x o E o E n - S S M → → → 문 심 출 맥 층 력 흡 추 합 수 론 성 ( ( ( O O 선 ( ( 형 1 n ) ) + 메 어 희 모 텐 소 리 션 ) ) ) 이 구조는 단순한 직관적 분할이 아니다. Transformer 아키텍처가 직면한 세 가지 근본적인 한계 — 제곱 복잡도, 메모리 폭발, 연산 밀도 — 에 대해 각 구간이 다른 해결책을 제시한다. 이 포스트에서는 각 레이어 그룹의 수학적 기초부터 MLX 프레임워크 최적화, 서멀 인식 학습까지, MacBook에서 LLM을 구동하는 전체 설계를 살펴본다. ...

들어가며 AWS는 200개가 넘는 서비스를 제공하며, 각 서비스는 고유한 API 프로토콜과 요청/응답 구조를 가지고 있다. 이들을 하나하나 수동으로 구현하는 것은 현실적으로 불가능에 가깝다. DevCloud에서는 AWS의 내부 모델링 언어인 Smithy를 리버스 엔지니어링하여 거의 전체 AWS 서비스의 Go 코드를 자동 생성하는 파이프라인을 구축했다. 이 포스트에서는 Smithy 모델을 파싱하여 Go 코드를 생성하는 전체 흐름과, 자동 생성된 코드를 기반으로 로컬 AWS 에뮬레이터를 구동하는 방법을 살펴본다. 하지만 더 근본적인 질문은 이것이다: 왜 IDL에서 코드를 생성하는가? 단순한 “생산성 자동화” 이상의 의미를 파악하려면, 먼저 이 접근이 해결하려는 근본적인 문제를 이해해야 한다. ...

들어가며 클라우드 네이티브 애플리케이션을 개발하다 보면 느끼는 불편함이 있다. CI 파이프라인에서 AWS를 호출하면 비용이 청구되고, VPN이 없으면 개발이 멈추며, 온보딩에는 자격 증명 설정이 필요하다. DevCloud는 이 문제를 로컬에서 해결하는 AWS 에뮬레이터다. boto3 호환성 테스트에서 **671/699 케이스 통과 (96%)**를 달성했다. 이 숫자는 단순한 테스트 통과율이 아니라, 프로토콜 설계가 얼마나 정확한지를 보여주는 지표다. 왜 AWS 에뮬레이션이 어려운가 해결책을 설명하기 전에, AWS 에뮬레이션이 왜 근본적으로 어려운지 이해할 필요가 있다. 대부분의 API는 프로토콜이 하나다. gRPC 서비스는 protobuf를 쓰고, REST API는 JSON을 쓰며, GraphQL은 자체 쿼리 언어를 사용한다. AWS는 서로 다른 다섯 가지 프로토콜을 서비스별로 사용하며, 각 프로토콜마다 직렬화 규칙, 에러 포맷, 인증 방식이 다르다. 단일한 “AWS API"는 존재하지 않는다 — 사실상 하나의 서비스 모델을 공유하는 다섯 개의 프로토콜 구현체를 만드는 셈이다. ...

들어가며 KVS v1.0.0이 출시되었다. KVS는 Go로 작성된 간단한 인메모리 키-값 스토어로, Go 모듈로 임포트하여 사용하거나 독립형 서버로 배포할 수 있다. 이 글에서는 v1.0.0에 포함된 주요 기능들을 소개하고, 특히 핵심 데이터 구조인 Red-Black Tree와 LSM Tree의 구현을 심층적으로 살펴본다. 왜 또 다른 키-값 스토어인가? 이미 Redis, LevelDB, BoltDB 등 훌륭한 키-값 스토어들이 존재한다. 그렇다면 왜 KVS를 만들었을까? KVS는 학습과 실험을 목적으로 시작된 프로젝트다. 실제 프로덕션급 데이터베이스를 구현하면서 겪는 설계 결정과 트레이드오프를 직접 경험해보고자 했다. 결과적으로 다음과 같은 특징을 갖춘 스토어가 되었다: ...

들어가며 ACOR은 Aho-Corasick 알고리즘을 Go로 구현하고 Redis를 백엔드 저장소로 사용하는 라이브러리다. 최신 버전에서는 네 가지 주요 기능이 추가되었다: Index APIs - 매칭된 키워드의 위치 정보 제공 Redis 토폴로지 지원 - Sentinel, Cluster, Ring 지원 커맨드라인 도구 - 터미널에서 바로 사용 가능 서버 어댑터 - HTTP와 gRPC로 서비스 배포 이 포스트에서는 각 기능의 사용법과 특징을 살펴본다. Index APIs 기존 API와의 차이점 이전에는 Find와 Suggest API가 어떤 키워드가 매칭되었는지만 알려줬다. 텍스트 하이라이팅이나 위치 기반 분석을 위해서는 별도로 인덱스를 계산해야 했다. ...

Ansible Molecule with KIND 소개 Ansible Molecule과 KIND (Kubernetes IN Docker)를 조합하여 쿠버네티스 자동화 테스트 환경을 구축하는 방법을 소개합니다. 개요 Ansible Molecule Ansible Molecule은 Ansible Roles를 가상화 기술을 통해 고립된 환경에서 테스트할 수 있게 도와주는 프레임워크입니다. 다양한 드라이버를 지원하며, Kubernetes 환경에서는 Delegated 드라이버를 사용하여 KIND와 통합할 수 있습니다. KIND (Kubernetes IN Docker) KIND는 Kubernetes 클러스터를 Docker 컨테이너로 동작시켜주는 도구입니다. 로컬 환경에서 빠르고 가볍게 Kubernetes 클러스터를 생성할 수 있어 다음과 같은 용도로 활용됩니다: ...

Molecule 소개 Molecule는 ansible-community에서 관리하는 Ansible Role용 테스트 프레임워크입니다. Molecule을 사용하면 Ansible Role을 체계적으로 테스트할 수 있으며, 여러 인스턴스, 운영 체제, 가상화 공급자, 테스트 프레임워크 및 테스트 시나리오를 활용한 종합적인 테스트가 가능합니다. 왜 Molecule이 필요한가? Ansible Role을 개발할 때 다음과 같은 문제에 직면합니다: 수동 테스트의 한계: 매번 수동으로 Role을 실행하고 결과를 확인하는 것은 시간이 많이 소요됩니다. 다양한 환경 지원: Ubuntu, CentOS, Debian 등 다양한 OS에서 Role이 정상 동작하는지 확인해야 합니다. 지속적 통합: CI/CD 파이프라인에서 자동으로 테스트를 수행해야 합니다. 코드 품질: Ansible 코드의 품질을 일관되게 유지해야 합니다. Molecule은 이러한 문제를 해결하기 위해 다음 기능을 제공합니다: ...

현업에서 의사소통이나 업무를 수행할 때, 사용해보거나 우연히 알게된 용어들을 잊어버리지 않고 종종 찾아보기 위해서 기록해보려 한다. 소프트웨어 엔지니어링뿐만 아니라 비즈니스 전반에서 활용되는 용어들을 정리했다. 목차 MECE Dogfooding ISO 8601 Ice Breaking Housekeeping Job On-the-fly SLA/SLO/SLI Dogpile Effect Thundering Herd Zero Trust Shift Left Technical Debt MECE 출처: 중복과 누락없는 논리적 분석 MECE Mutually Exclusive Collectively Exhaustive의 약자로 어떤 문제를 해결하기 위한 방안이 겹치지 않으면서 빠짐없이 나누는 것을 의미한다. 중복과 누락 없이라고 할 수 있을 것이다. ...

들어가며 ACOR v0.2.0을 릴리즈했다. 이번 버전은 프로젝트 구조를 Go 표준으로 정리하고 몇 가지 버그를 수정하는 데 집중했다. 표준 프로젝트 구조로 변경 v0.2.0에서는 Go 커뮤니티의 표준 프로젝트 레이아웃을 따르도록 구조를 변경했다 (#2). Go 프로젝트가 성장하면서 파일 구조를 체계적으로 관리할 필요가 있었다. Standard Go Project Layout 가이드라인을 참고하여: pkg/: 외부에서 import 가능한 패키지 코드 internal/: 내부 전용 코드 cmd/: 메인 애플리케이션 이런 구조를 적용함으로써 프로젝트의 의도를 더 명확히 전달할 수 있게 되었다. 지원 Go 버전 변경 Go 버전 지원 정책을 업데이트했다 (#5). ...

들어가며 ACOR v0.1.0을 릴리즈했다. 이번 버전은 새로운 기능 추가보다는 프로젝트의 기반을 현대화하는 데 집중했다. Go 생태계의 변화에 맞춰 의존성 관리와 CI/CD 시스템을 최신 표준으로 전환했다. 왜 Go modules로 전환했는가 ACOR은 처음 Glide를 사용해 의존성을 관리했다. Glide는 Go에 공식 의존성 관리 도구가 없던 시절, 커뮤니티에서 널리 사용되던 도구였다. 하지만 Go 1.11부터 Go modules가 공식으로 도입되면서 상황이 바뀌었다. Glide의 한계는 명확했다: 유지보수 중단: Glide는 더 이상 활발히 개발되지 않는다 버전 관리: 정확한 버전 고정과 의존성 트리 관리가 번거롭다 재현성: 다른 환경에서 동일한 빌드를 보장하기 어렵다 Go modules는 이 문제들을 해결한다. go.mod 파일 하나로 의존성을 관리하고, Semantic Versioning을 기반으로 버전을 제어한다. 무엇보다 Go 도구 체인에 내장되어 있어 별도 설치가 필요 없다. ...