Tech 게시글

2페이지

TechAIetc

Claude & Codex #4 Claude Code로 Issue부터 PR까지 개발하기

GitHub Issue, Worktree, Pull Request를 GitHub Actions 자동 검증까지 연결한다

이전 글에서는 AGENTS.md와 CLAUDE.md를 이용해 Claude Code와 Codex가 프로젝트를 어떤 기준으로 이해해야 하는지 정리했다. 이번에는 그 기준 위에서 하나의 기능을 개발한다. GitHub Issue에서 이번 작업의 목표와 범위를 정하고, Worktree로 작업 공간을 분리한 뒤 Claude Code가 분석부터 구현과 Local Verification까지 진행한다. 변경이 Pull Request로 올라가면 GitHub Actions가 Build, Test, Lint를 다시 검증한다. CI/CD Pipeline 자체를 어떻게 구축하는지는 별도 글에서 다룬다. 이번 글의 범위는 Iss

Claude Code로 GitHub Issue부터 Pull Request 자동 검증까지 진행하는 개발 워크플로우
TechAIetc

Claude & Codex #3 AGENTS.md와 CLAUDE.md로 프로젝트 Context 구성하기

Claude Code와 Codex가 같은 Architecture와 개발 규칙을 공유하도록 설정한다

이전 글에서는 AGENTS.md, CLAUDE.md, Rules, Skills에 어떤 정보를 나눠 담아야 하는지 정리했다. 이번에는 Android와 Backend가 함께 있는 모노레포에 Context를 구성한다. 공통 Architecture와 개발 규칙은 Root에 두고, 특정 Module에서만 필요한 기준은 더 가까운 위치로 나눈다. 마지막에는 파일을 만드는 데서 끝내지 않고 Claude Code와 Codex가 의도한 Context를 읽고 같은 기준으로 프로젝트를 해석하는지까지 확인한다. 처음부터 AGENTS.md, CLAUDE.md, .claude/rules/, SKILL.md를 전부 만들 필요는

Claude Code와 Codex 프로젝트 Context 구성
TechAIetc

Claude & Codex #2 AGENTS.md, CLAUDE.md, SKILL.md 작성 가이드

Context Engineering으로 개발 Agent와 Review Agent의 프로젝트 기준 맞추기

앞선 글에서는 Claude Code가 기능을 구현하고 Codex가 완성된 변경을 다시 보는 방식으로 역할을 나눴다. 하지만 구현과 Review를 분리하는 것만으로 두 Agent의 판단 기준까지 같아지지는 않는다. 예를 들어 프로젝트에서 외부 API 호출과 DB 반영을 다음처럼 분리했다고 해보자. 외부 API 응답을 기다리는 동안 DB Transaction을 유지하지 않기 위한 설계다. Claude Code는 이 기준을 알고 기능을 구현했다. 반면 Codex가 설계 의도를 모른다면 Pull Request에서 다음과 같은 Review를 남길 수도 있다. 외부 API 호출과 Metadata 저장을 하나의 T

AGENTS.md CLAUDE.md SKILL.md 역할과 Claude Code Codex Context 구성
TechAIetc

Claude & Codex #1 Single-Agent에서 Multi-Agent로 가는 이유

Single-Agent, Multiple Agents, Multi-Agent System과 Orchestration의 차이

Claude Code 하나만으로도 코드 분석부터 구현, Test, Diff 확인까지 이어갈 수 있다. 하나의 Agent로도 상당한 개발 과정을 처리할 수 있다. 그런데 작업이 커지면 요구사항 분석, Architecture 판단, 구현, 검증, Review까지 하나의 Agent와 Context에 모이게 된다. 그래서 여러 Agent를 사용하는 구조가 등장한다. 목적은 단순히 AI의 수를 늘리는 것이 아니다. 역할을 분리하고, 독립적인 작업을 병렬화하고, 한 Agent의 결과를 다른 Agent가 다시 검토할 수 있는 구조를 만드는 것이다. 다만 Multi-Agent, Context Engineering,

Single-Agent Multiple Agents Multi-Agent System과 Claude Code Codex 개발 Workflow
TechAndroid

Room에서 KSP가 필요한 이유: Room Compiler와 코드 생성 원리

Room에서 DAO와 Database 구현체가 자동 생성되는 과정을 KSP, Room Compiler, Room Runtime의 역할을 중심으로 설명

Room을 처음 설정하다 보면 ksp라는 의존성이 갑자기 등장한다. Room으로 로컬 데이터베이스를 만들려는 것인데, 왜 별도의 KSP가 필요한 걸까? 핵심은 Room의 동작 방식에 있다. 개발자는 DAO와 Database의 형태를 선언하지만, 실제 SQLite를 다루는 구현 코드는 직접 작성하지 않는다. Room Compiler가 빌드 과정에서 이 구현 코드를 생성하며, Room 3.x에서는 이 코드 생성 과정에 KSP가 필요하다. 이 글에서는 Ariadne의 파일 Metadata 캐시를 예제로 다음 관계를 정리한다. 이 다섯 가지의 역할을 구분하면 Room 설정에서 왜 ksp(...)가 필요한지도

TechAndroid

Android에서 SQLite 대신 Room을 권장하는 이유

SQL 검증, 객체 매핑, DAO, Migration으로 이해하는 Room

Android 공식 문서는 SQLite API를 직접 사용하는 대신 Room을 사용하는 방식을 권장한다. 그렇다고 SQLite가 좋지 않은 데이터베이스라는 의미는 아니다. Room 역시 내부적으로 SQLite를 사용한다. 따라서 질문은 Room을 사용할 것인가, SQLite를 사용할 것인가? 보다는 SQLite를 저수준 API로 직접 사용할 것인가, Room을 통해 사용할 것인가? 에 가깝다. 그렇다면 Room은 SQLite를 직접 사용할 때 발생하는 어떤 문제를 해결해주는 걸까? --- 1. 반복적인 저수준 코드를 줄인다 SQLite를 직접 사용하면 쿼리를 실행한 이후에도 직접 처리해야 하는 작업이