최근 **Agentic AI(에이전트 AI)**가 화두임. 단순히 묻는 말에 대답하는 챗봇을 넘어, 스스로 사고하고 도구를 사용하며 행동하는 AI들이 주목받고 있음.
이 흐름 속에서 흥미롭게 본 프로젝트 중 하나인 Moltbook을 분석하고, 이를 바이브 코딩(Vibe Coding) 기법으로 재해석하여 AI 에이전트들을 위한 Custom 소셜 네트워크 CYPHER를 만든 과정을 공유함.
🤔 Moltbook이 뭐지? Moltbook은 AI 에이전트들을 위한 소셜 네트워크임. 인간이 아닌 AI들이 가입하고, 글을 쓰고, 댓글을 달며 서로 상호작용하는 공간.
단순한 시뮬레이션 게임 같아 보이지만 구조는 꽤 진지함.
클라우드 인프라를 코드 레벨(IaC)이나 콘솔에서 수동으로 구축하다 보면, 가장 흔하게 마주하는 문제가 바로 Connectivity(연결성) 이슈다.
최근 Oracle Cloud Infrastructure(OCI)에서 새로운 VCN을 구축하고 인스턴스를 프로비저닝했음에도 불구하고, SSH(TCP 22) 접속이 Operation timed out으로 실패하는 현상을 겪었다. Public IP가 할당되었고 Security List(방화벽)가 개방되었음에도 발생한 이 문제는, 클라우드 네트워크의 라우팅 결정(Routing Decision) 메커니즘을 명확히 이해하지 못했을 때 발생하는 전형적인 구성 오류다.
본 포스트에서는 OCI 네트워크의 핵심 컴포넌트를 아키텍처 관점에서 정의하고, IGW(Internet Gateway)와 Route Table의 상관관계를 패킷 흐름 중심으로 분석하여 해결 과정을 정리한다.
이전 포스팅에서는 프로세스의 개념과 구조에 대해 다뤘음. 이번에는 프로세스의 생성부터 종료까지의 라이프사이클과, 이를 관리하는 스케줄링 메커니즘을 커널 레벨의 관점에서 아주 깊이 있게 낱낱이 파헤쳐보겠음.
1. 프로세스의 메모리 구조와 상태 실행 중인 프로세스는 단순히 코드의 집합이 아님. 메모리 상에서 다음과 같은 독자적인 공간을 점유함.
Text (Code) Section: 실행할 기계어 코드가 저장되는 영역. 읽기 전용으로 공유 가능함. Data Section: 전역 변수(Global Variable) 및 정적 변수(Static Variable)가 저장됨. Heap Section: 런타임 중에 동적으로 할당되는 메모리 (malloc, new).
운영체제(OS)에서 메모리 관리는 시스템 성능과 안정성에 직결되는 핵심 주제임. 오늘은 그 중에서도 현대 OS의 표준 메모리 관리 기법인 **Paging(페이징)**에 대해 알아보겠음.
1. Paging이란 무엇인가? Paging은 외부 단편화(External Fragmentation) 문제를 해결하기 위해 고안된 메모리 관리 기법임.
과거에는 프로세스를 물리 메모리에 **연속적(Contiguous)**으로 할당해야 했음. 이로 인해 메모리 중간중간에 작은 빈 공간들이 남게 되어, 공간의 합은 충분하지만 실제로는 큰 프로세스를 할당할 수 없는 외부 단편화 문제가 발생했었음.
Paging은 이 고정관념을 깬 방식임.
Physical Memory를 Frame이라는 고정 크기 블록으로 나눔.