Pi를 완제품 에이전트가 아니라 얇은 코딩 하네스로 보고, Package와 Extension으로 필요한 능력을 붙이는 방식을 정리한다.

OpenCode를 Claude Code 계열 터미널 코딩 에이전트의 오픈소스 대안으로 보고, 기본 UX와 Plugin 확장 구조를 중심으로 정리한다.

Git을 로컬 변경 관리, History 이해, 원격 저장소, GitHub 플랫폼, 자동화 설정으로 나누어 기존 글의 위치를 정리한다.

저장소 안의 특별한 파일을 Git, GitHub, 개발 도구가 각각 어떻게 인식하는지 정리한다.

커밋 직전에 자동 검사를 거는 Git hook의 역할과 Husky, pre-commit, prek의 사용 패턴을 정리한다.

Java Roadmap의 JVM 영역을 Zoom-in해 Class Loading, Linking/Initialization, Runtime Data Areas, Frame, Interpreter/JIT, GC와 Native 경계를 하나의 실행 흐름으로 연결한다.

Java를 문법 목록이 아니라 Language, JVM 실행 모델, Standard Library, Concurrency/JMM, 그리고 JPA 같은 생태계 Branch로 나눠 전체 지형과 학습 경계를 잡는다.

Program Execution 전체 지도 지금까지 소스 코드가 컴파일되고, 링크되고, 프로세스가 되어 메모리에 배치되고, 필요할 때 커널 Service를 요청하는 흐름을 따라왔다. 마지막에는 결국 CPU가 Machine 코드를 실행한다. 컴파일러가 만든 Machine 코드는 CPU 안에서 실제로 어떻게 실행되는가? 1. 소스 코드와 ...

Program Execution 전체 지도 지금까지는 네이티브 프로그램을 기준으로 컴파일, 링크, Load, 프로세스, 가상 메모리, System Call을 따라왔다. 그런데 Java, Go, JavaScript, WebAssembly를 보면 실행 구조가 서로 다르다. Runtime이 있다는 말은 정확히 무엇이며, 언어마다 Runtime은 ...

Program Execution 전체 지도 앞선 글에서는 애플리케이션이 System Call을 통해 커널 Service를 요청하는 경계를 살펴봤다. 그런데 컴파일러가 만든 코드, 라이브러리, 운영체제는 서로 따로 만들어질 수 있다. 서로 다른 바이너리는 인자 위치, 반환값, Data 배치 같은 약속을 어떻게 맞출까? 이 바이너리 수준의 ...