Akan.js Manifesto
왜 Akan.js를 만드는가
개발자는 중요한 일에 인생을 써야 한다
Akan.js는 현대 소프트웨어 팀이 프로젝트 경계, 중복된 소스코드, 프레임워크 접착 작업, 서로 다른 코딩 스타일에 너무 많은 시간을 잃고 있다는 문제의식에서 출발했습니다. 우리는 비즈니스를 설명하는 하나의 명확한 방법을 만들고, 그 의도가 web, app-oriented client, server, database, deployment까지 흐르게 하고 싶습니다.
문제의식
너무 많은 일이 제품을 위한 일이 아니다
하나의 비즈니스에는 보통 frontend, backend, database model, mobile surface, admin screen, deployment pipeline, test setup, monitoring path가 필요합니다. 의도는 같은데 각 계층은 개발자에게 그것을 다른 언어로 반복해서 설명하라고 요구합니다.
팀이 커질수록 코딩 스타일의 차이는 또 다른 숨은 비용이 됩니다. 사람들은 코드가 어디에 있어야 하는지, 기능 이름을 어떻게 붙여야 하는지, 데이터가 어떻게 이동해야 하는지, 왜 방금 본 모듈과 다른 모듈의 모양이 다른지 묻는 데 시간을 씁니다.
그 시간에는 인간적인 비용이 있습니다. 개발자는 피할 수 있는 와이어링과 설정 때문에 밤과 휴가를 낭비해서는 안 됩니다. 필요한 일을 제대로 하고, 그 다음에는 우리의 삶을 살아야 합니다.
컨벤션은 의사소통 도구다
Ruby on Rails는 업계에 convention over configuration이라는 강력한 문장을 남겼습니다. Akan.js는 이 개념이 인간 프로그래머와 AI 코딩 에이전트 모두에게 필요하다고 봅니다.
workspace가 공유된 규칙으로 정렬되어 있으면 의사소통 비용이 줄어듭니다. service, signal, document, store, page는 각자의 역할을 갖습니다. 낯선 기능을 열어도 어디서 시작해야 하는지 알 수 있습니다.
AI 에이전트에게 컨벤션은 더 직접적인 레버리지입니다. 예측 가능한 파일과 계약은 탐색 공간을 줄이고, 오류율을 낮추며, 기존 형태에서 다음 형태를 추론할 수 있게 해 토큰 사용량을 크게 줄입니다.
비즈니스를 한 번만 쓴다
page, signal, service, store, document, deployment artifact마다 같은 의도를 따로 설명하지 않아도 되어야 합니다.
와이어링을 줄인다
프레임워크는 제품 개발을 작게 만들어야지, 팀의 가장 좋은 시간을 도구 연결에 쓰게 해서는 안 됩니다.
스타일을 공용 언어로 만든다
모든 모듈이 익숙한 형태를 따르면 다른 사람이나 에이전트가 쓴 코드도 내가 쓴 코드처럼 읽힙니다.