natsu standard
가격
솔루션 · 한 달 뒤에 고치기 두려울 때

첫 배포는 누구나, 한 달 뒤의 수정은 여기서만

AI로 만든 앱을 한 달 뒤에 열면 무엇을 왜 그렇게 만들었는지 아무도 모릅니다. Natsu Standard는 승인한 설계와 실행 기록을 같은 그래프 위에 두어, 돌아와도 어디를 고칠지 보이게 합니다.

승인본

승인한 설계가 따로 저장됩니다

사람이 승인한 L1은 승인본으로 남습니다. AI가 구현하면서 Feature 폴더를 고쳐도, 승인본과 다르면 검사기가 그 차이를 그래프 위에 표시하고 main에 병합하지 않습니다. 배포는 main에서만 나갑니다.

승인본
예약 요청
회원 확인
빈 자리?
예약 저장
마감 안내
알림 보내기
일치
코드
예약 요청
회원 확인
빈 자리?
예약 저장
마감 안내
알림 보내기
고치는 길

고치는 것도 같은 공정입니다

  1. 01관제나 디버그에서 이상한 단계를 가리킵니다.
  2. 02AI가 그 Feature의 합의와 설계를 읽고 수정안을 냅니다.
  3. 03사람이 바뀐 그래프를 읽고 승인합니다.
  4. 04AI가 구현하고 시험하고, 승인본과 대조한 뒤 배포합니다.
왜 가능한가

기억이 아니라 기록 위에서 고칩니다

합의가 남아 있습니다

왜 그렇게 만들었는지는 합의 기록이 답합니다.

Feature 하나만 읽습니다

고칠 Feature는 자기 API와 Port와 L1만 알면 됩니다. 전체를 다시 읽지 않습니다.

실행이 보입니다

어제 그 단계를 지난 요청 수와 시간이 그래프 위에 있습니다.

운영 단계에서 더 볼 수 있습니다

배포 뒤의 관제와 디버그가 제품 단원에 있습니다.

한 달 뒤에 고치기 두려울 때 · Natsu Standard