저는 NeNe 시리즈라고 불리는 오픈 소스 비즈니스 도구 제품군을 구축해 오고 있습니다.

아이디어는 간단합니다:

소규모 팀은 명확한 API와 읽기 쉬운 경계(boundaries)를 가진 유용한 비즈니스 소프트웨어를 자체 인프라에서 직접 실행할 수 있어야 합니다.

대부분의 도구는 아직 개선 중이지만, 방향성은 이미 명확합니다:

• 셀프 호스팅 (self-hosted)
• API 우선 (API-first)
• 일본 내 운영이 필요한 경우 이중 언어 (bilingual) 지원
• OpenAPI 문서화
• AI 에이전트를 위한 MCP 준비 완료
• 한 명의 개발자나 소규모 팀이 이해할 수 있을 만큼 작은 규모

그 기반은 저의 PHP 8.4 API 우선 마이크로 프레임워크(micro-framework)인 NENE2입니다.

저장소(Repository):

https://github.com/hideyukiMORI/NENE2

GitHub 프로필:

https://github.com/hideyukiMORI

왜 일본 특화 비즈니스 도구인가요?

일본에서 운영되는 많은 팀은 혼합된 워크플로우를 가지고 있습니다.

기술 팀은 영어가 편할 수 있습니다.

하지만 비즈니스 워크플로우는 여전히 매우 로컬(local) 중심적입니다:

• 적격 청구서 (qualified invoices)
• 수신 문서 보관 (received-document retention)
• 결제 대조 (payment reconciliation)
• 일본 은행 CSV 형식
• 이중 언어 관리자 화면
• 소규모 회사 운영

범용 도구들도 작동할 수 있습니다.

하지만 때때로 로컬 워크플로우가 그 틈새로 새어 나옵니다.

그것이 바로 NeNe 시리즈가 단순한 "또 다른 CRUD 앱 모음"이 아닌 이유입니다.

이것은 특정 비즈니스 경계를 이해하는 작고 셀프 호스팅 가능한 도구를 구축하려는 시도입니다.

제품들

이 시리즈에는 몇 가지 집중된 도구들이 포함되어 있습니다.

NeNe Invoice

일본 소규모 비즈니스를 위한 셀프 호스팅 견적 및 청구서 관리 도구입니다.

적격 청구서, 견적서, 송장, 결제, PDF 출력 및 관리자 UI 워크플로우에 집중합니다.

저장소(Repository):

https://github.com/hideyukiMORI/nene-invoice

일본어 실습 기사:

https://qiita.com/xioncc/items/7439c9832a6795b4d48e

NeNe Vault

PDF 및 비즈니스 문서를 위한 수신 문서 아카이브입니다.

검색, 감사 이력 (audit history), 그리고 보존 중심의 워크플로 (workflows)를 통해 수신된 송장 (invoices), 영수증, 계약서를 저장하는 데 집중합니다.

Repository:

https://github.com/hideyukiMORI/nene-vault

Japanese hands-on article:

https://qiita.com/xioncc/items/2f3726347e4504363534

NeNe Deal

경량화된 B2B 딜 파이프라인 (deal pipeline) 관리 도구입니다.

기회 (opportunities), 단계 (stages), 간단한 예측 (forecasts)을 처리하며, 고객/견적 초안 데이터로서 NeNe Invoice로의 인계 (handoff)를 지원합니다.

Repository:

https://github.com/hideyukiMORI/nene-deal

Japanese hands-on article:

https://qiita.com/xioncc/items/5f7f0e3687d77f07e00e

NeNe Contact

임베드 가능한 연락처 양식 (contact forms) 및 운영자 수신함 (inbox)입니다.

운영자가 양식을 구축하고, 스크립트 태그 (script tag)로 이를 임베드하며, 제출 내용을 수신하고, 상태를 관리하며, 알림을 라우팅 (route)할 수 있게 합니다.

Repository:

https://github.com/hideyukiMORI/nene-contact

Japanese hands-on article:

https://qiita.com/xioncc/items/580750a119ffaa1641af

NeNe Records

API-first 방식의 타입 지정 CMS (typed CMS) / 유연한 엔티티 플랫폼 (entity platform)입니다.

사용자가 엔티티 타입 (entity types), 타입 지정 필드 (typed fields), 레코드 (records), 공개 페이지 (public pages), 그리고 OpenAPI/MCP 대응 작업 (operations)을 정의할 수 있습니다.

Repository:

https://github.com/hideyukiMORI/nene-records

이들을 하나로 묶는 것은 무엇인가요?

제품들은 서로 다르지만, 동일한 방향성을 공유합니다.

1. API-first 경계 (boundaries)

API가 곧 계약 (contract)입니다.

관리자 화면, 공개 페이지, 통합 (integrations), 그리고 AI 도구들은 문서화된 HTTP API를 통해 작동해야 합니다.

이를 통해 동작을 더 쉽게 테스트하고, 검토하며, 안전하게 노출할 수 있습니다.

2. 공유 언어로서의 OpenAPI

각 제품은 OpenAPI를 통해 공개 API를 문서화하는 것을 목표로 합니다.

이는 인간 개발자에게 중요합니다.

또한 AI 에이전트 (AI agents)에게도 매우 중요합니다.

API가 명시적이라면, 도구(tool)는 데이터베이스 구조를 추측하지 않고도 해당 작업(operation)에 매핑될 수 있습니다.

3. MCP는 앱을 호출해야 합니다

이 내용에 대해서는 이전 글에서 작성한 바 있습니다:

https://dev.to/hideyukimori/mcp-should-not-mean-letting-ai-touch-your-database-57p1

저의 경험 법칙(rule of thumb)은 다음과 같습니다:

MCP 도구는 애플리케이션의 기능을 래핑(wrap)해야 하며, 애플리케이션을 우회해서는 안 됩니다.

즉, 다음과 같은 구조를 의미합니다:

AI 에이전트 (AI Agent)
  -> MCP 도구 (MCP Tool)
  -> 문서화된 HTTP API
...

이것이 아닙니다:

AI 에이전트 (AI Agent)
  -> MCP 도구 (MCP Tool)
  -> 직접적인 SQL 쿼리 (direct SQL query)
...

4. 의도적으로 지루한 아키텍처 (Boring architecture)

이 스택은 의도적으로 마법 같지 않게 설계되었습니다.

대부분의 제품은 다음과 같은 형태를 따릅니다:

핸들러 (Handler)
  -> 유스케이스 (Use Case)
  -> 레포지토리 (Repository)

프론트엔드는 클라이언트입니다.

데이터베이스는 레포지토리 뒤에 머뭅니다.

MCP 레이어는 HTTP API 뒤에 머뭅니다.

이것은 지루합니다.

하지만 그것이 바로 특징(feature)입니다.

왜 PHP인가?

PHP는 소규모 비즈니스 소프트웨어 분야에서 여전히 중요하기 때문입니다.

배포가 매우 용이합니다.

호스팅이 쉽습니다.

비즈니스 시스템을 다루는 많은 개발자에게 익숙합니다.

현대의 PHP는 엄격하고, 타입이 지정되며(typed), 테스트 가능하고, API 우선(API-first) 방식으로 구축될 수 있습니다.

NENE2는 거대한 풀스택 프레임워크를 재현하는 대신, PHP를 작고 명시적으로 유지하려는 저의 시도입니다.

NENE2란 무엇인가?

NENE2는 이러한 도구들 중 상당수의 밑바탕이 되는 작은 프레임워크입니다.

다음 기능을 제공합니다:

• PSR 스타일의 HTTP 런타임 (HTTP runtime)
• 명시적인 라우팅 (explicit routing)
• 문제 세부 정보 에러 응답 (Problem Details error responses)
• OpenAPI 계약 (OpenAPI contracts)
• 데이터베이스 경계 (database boundaries)
• 인증 미들웨어 (auth middleware)
• 선택적인 프론트엔드 스타터 패턴 (optional frontend starter patterns)
• 로컬 MCP 서버 지원 (local MCP server support)

Laravel을 대체하려는 것이 아닙니다.

인간과 AI 에이전트 모두가 이해할 수 있는 비즈니스 API를 구축하기 위한 작은 토대입니다.

첫 번째 DEV 기사:

https://dev.to/hideyukimori/i-built-a-tiny-php-framework-for-ai-readable-business-apis-48eo

이것은 여전히 진행 중인 작업입니다

포트폴리오의 성숙도를 과장하고 싶지 않습니다.

일부 도구들은 정식 출시(formal release)에 가까워졌습니다.

일부는 여전히 개선(refining) 중입니다.

일부 배포 경로는 현재 Docker-first 방식이며, 공유 호스팅(shared-hosting)이나 관리형(managed) 경로는 여전히 발전하는 단계에 있습니다.

제가 지금 발행하고 있는 글들의 목표는 모든 제품이 완성되었다고 주장하는 것이 아닙니다.

목표는 아키텍처(architecture), 방향성, 그리고 실제로 작동하는 소프트웨어를 가시화하는 것입니다.

제가 찾고 있는 것

저는 특히 다음과 같은 사항에 관심이 있는 분들의 피드백을 기다리고 있습니다:

• 셀프 호스팅 (self-hosted) 비즈니스 소프트웨어
• API-first PHP
• OpenAPI 컨트랙트 (contracts)
• MCP 및 AI 에이전트 경계 (boundaries)
• 실제 운영 워크플로우를 위한 소규모 도구
• 일본에서 운영되는 팀을 위한 소프트웨어

만약 여러분이 유사한 도구를 구축하고 있거나, AI 에이전트가 비즈니스 API와 어떻게 상호작용해야 하는지에 대해 고민하고 있다면, 여러분의 관점을 듣고 싶습니다.

링크

• GitHub 프로필: https://github.com/hideyukiMORI
• NENE2: https://github.com/hideyukiMORI/NENE2
• NeNe Invoice: https://github.com/hideyukiMORI/nene-invoice
• NeNe Vault: https://github.com/hideyukiMORI/nene-vault
• NeNe Deal: https://github.com/hideyukiMORI/nene-deal
• NeNe Contact: https://github.com/hideyukiMORI/nene-contact
• NeNe Records: https://github.com/hideyukiMORI/nene-records
• nene-mcp: https://github.com/hideyukiMORI/nene-mcp

저는 여전히 NeNe 시리즈와 NENE2를 개선하고 있습니다.

하지만 그 형태는 점점 더 명확해지고 있습니다:

AI가 읽을 수 있는 경계(AI-readable boundaries)를 가진, 소규모의, 셀프 호스팅(self-hosted) 방식의, API-first 비즈니스 도구.