Nyxdoc은 읽기, 쓰기, 논의가 각각 분명한 계약을 드러내야 한다는 생각 위에 세워집니다. 그래야 에이전트와의 협업이 그때그때 운에 맡겨지는 게 아니라, 정밀하고 예측 가능한 일이 됩니다.
문서는 구조부터 파악됩니다. 요약 정보와 섹션 메타데이터, 주소 가능한 블록을 통해 작업에 필요한 부분만 가져올 수 있습니다.
변경은 범위가 정해진 수정안으로 제출되고, 변경 경계에 맞게 검증되며, 분명한 이력과 함께 저장됩니다.
코멘트는 작업 의도와 상태, 범위를 담아 에이전트가 처리할 수 있는 대기열이 되고, 사람은 그 과정을 점검할 수 있습니다.
지금의 에이전트는 몇 줄을 바꾸기 위해 큰 문서를 통째로 다시 읽는 경우가 많습니다. 비효율적이고 취약합니다. 이 방식은 먼저 빠른 지도를 보여주고, 그다음 필요한 블록만 좁혀서 가져오게 만듭니다.
이건 단순히 효율성만의 문제가 아닙니다. 에이전트가 무엇을 봤고, 무엇을 바꿨고, 왜 그랬는지를 설명하기 쉬워집니다.
전체 재작성은 책임 경계를 흐립니다. 범위가 정해진 수정 방식은 모든 변경에 경계를 부여합니다. 어떤 이력에서 시작했는지, 무엇을 어떻게 바꾸는지, 어떤 조건을 확인했는지가 남아야 충돌 감지와 diff 검토, rollback이 가능해집니다.
팀은 이미 코멘트로 일을 표현합니다. Nyxdoc은 그걸 제품의 기본 모델로 끌어올립니다. 코멘트는 문단 옆에 붙은 텍스트가 아니라, 스코프와 의도, 우선순위, 라이프사이클을 가진 요청이 됩니다.
경계 없는 자동화는 불안을 만들고, 좋은 경계는 자동화를 유용하게 만듭니다.
중요한 수정은 블랙박스 액션에 숨어 있지 않고, 히스토리와 diff로 검토 가능해야 합니다.
Rollback은 실패 경로가 아닙니다. 에이전트를 중요한 루프에 넣고 싶다면 반드시 필요한 조건입니다.