도입

AMA-teras는 Electron 기반의 데스크톱 AI 코딩 에이전트(Coding Agent)입니다.

대화하면서 계획, 구현, 디버깅, 테스트를 진행합니다.

부족한 기능을 발견하면 필요한 도구나 구현을 생성하고, 이를 통합하는 단계까지 진행합니다.

단, 생성된 것이 그대로 본체에 섞이는 것은 아닙니다.

AMA-teras에서는 생성물을 격리된 git worktree에서 만들고, 검증 게이트(Verification Gate)를 통과한 뒤, 마지막에 인간이 승인해야 본체로 승격됩니다. 외부로의 발신이나 쓰기도 승인 다이얼로그를 거치지 않으면 실행할 수 없도록 설계되어 있습니다.

이 기사는 M94에서 일어난 「본체가 스스로 Bluesky의 GIF 첨부 대응을 구현한」 로그입니다.

이번에 일어난 일

M94에서는 Bluesky 게시물에서 GIF 첨부에 필요한 대응이 발견되었습니다.

이에 따라 core 진화 작업(Evolution Job)이 구현을 생성했습니다.

생성된 구현은 그대로 본체에 섞지 않고, 진화 작업(Evolution Job)으로 취급했습니다.

이번에 승격된 작업은 다음과 같습니다.

job-42

job-47

이 두 가지를 승격하여, Bluesky GIF 첨부에 필요한 대응을 본체에 도입했습니다.

여기서 중요한 것은 「AI가 코드를 작성했다」는 것만이 아닙니다.

오히려 중요한 것은, AI가 작성한 코드가 멋대로 본체에 섞이지 않는다는 점입니다.

중요한 것은 “멋대로 섞이지 않는 것”

AMA-teras의 자기 진화에서는 생성물을 격리된 git worktree에서 만듭니다.

본체의 작업 트리(Working Tree)에 직접 쓰게 하는 것이 아니라, 작업(Job)마다 분리된 장소에서 변경 사항을 만듭니다.

그렇기 때문에 도중에 망가지더라도 본체에 즉각적인 영향을 주지 않습니다.

승격 전에는 검증 게이트를 통과합니다.

• typecheck
• 테스트
• 실제 구동 스모크 테스트 (Smoke Test)

이러한 과정을 거친 후, 본체로의 승격에는 인간의 승인을 필수적으로 요구합니다.

「스스로 구현하는 것」과 「스스로 본체에 섞는 것」은 분리되어 있습니다.

AMA-teras의 자기 진화는 후자를 완전히 자동화하지 않는 설계입니다.

도중에 수정한 토대

M94 주변에서는 GIF 첨부 그 자체뿐만 아니라, 자기 진화를 안전하게 돌리기 위한 토대도 수정했습니다.

jobs.json의 분할 쓰기(Torn Write) 방지

진화 작업의 상태를 다루는 jobs.json에서 분할 쓰기(Torn Write)를 방지하는 대응을 넣었습니다.

대응은 다음 두 가지입니다.

• 쓰기의 직렬화 (Serialization)
• 원자적 교체 (Atomic Replacement)

작업 관리 파일이 깨지면, 구현 자체가 올바르더라도 진화 작업의 상태 관리가 망가집니다.

자기 진화에서는 생성된 코드뿐만 아니라, 작업의 장부(Ledger)도 본체의 일부입니다.

maxTurns를 늘림

core / renderer 작업의 maxTurns를 변경했습니다.

• 변경 전:
  60

• 변경 후:
  120

진화 작업이 도중에 중단되면, 구현이나 수정이 완료되지 않은 채로 남게 됩니다.

이번에 core / renderer 작업에서 사용하는 상한을 120으로 늘렸습니다.

Windows의 테스트 플레이크(Test Flake) 해결

Windows의 테스트 플레이크도 해결했습니다.

자기 진화의 승격 조건에 테스트를 포함하고 있는 이상, 테스트가 불안정하면 구현의 좋고 나쁨과는 별개의 이유로 승격 판단이 흔들립니다.

따라서 플레이크를 방치하지 않고, 승격 게이트의 신뢰성을 높여야 할 대상으로 취급했습니다.

운영 측의 배움

이번 하이라이트는 「AI가 Bluesky GIF 첨부를 구현했다」는 것입니다.

하지만 운영 측의 배움은 그것만이 아닙니다.

자기 진화의 본체는 화려한 자동 구현만이 아닙니다.

망가진 상태를 감지하고, 격리하고, 검증하고, 마지막에 사람이 판단할 수 있는 구조가 더 중요합니다.

과거의 로그에서도 AMA-teras는 이 부분에서 여러 번 실패했습니다.

예를 들어, Bluesky에서는 검색만 401 에러가 발생하는 문제가 있었습니다.

원인은 app password가 아니라, BlueskyReader의 기본 fetchImpl이 두 번째 인자인 Authorization 헤더를 버리고 있었기 때문이었습니다.

로그인은 다른 기본 경로를 사용했기 때문에 성공했지만, 검색만 인증 없이 bsky.social로 날아가고 있었습니다.

테스트에서는 모두 fetch를 주입(Injection)하고 있었기 때문에, 운영 환경에서만 기본값을 사용하는 상태였습니다.

이때는 bluesky / zenn / hn / hatena의 기본값을 수정하고, 주입 없는 경로를 테스트에서 고정했습니다.

실기(実機)에서는 순회 성공과 10건의 검색을 확인했습니다.

또한, Zenn 공개 관련해서는 승인 경로 및 대장(ledger)의 상태 관리에서 여러 문제가 발생했습니다.

• 스마트폰 승인이 bulkRespond를 통과하기 때문에, 중복 요약이 적용되지 않았음 - 5초 사이에 3건이 Zenn으로 커밋되어, 동일한 기사가 공개 리포지토리(repository)에 2건 올라갔음
• published: true로 push 해도, Zenn 측에서는 403 상태로 읽을 수 없는 기사가 있었음 - 대장이 "실제로 읽을 수 있는가"가 아니라 "우리가 발행했다고 간주하는가"를 기록하고 있었음
• DraftStore.list()가 로딩할 때마다 posted를 staged로 다시 되돌리고 있었음

이것들은 모두 구현상의 문제인 동시에, 운용상의 가드(guard) 문제이기도 했습니다.

M94의 자기 진화에서도 마찬가지입니다.

"코드를 생성할 수 있었다"는 것만으로는 부족합니다.

생성물이 어디에서 만들어졌고, 어떤 검증을 거쳤으며, 누가 마지막으로 승인했는지가 남아야 합니다.

요약

M94에서는 Bluesky 게시물에 GIF 첨부를 위해 필요한 대응 사항을 발견하였고, core 진화 작업(job)이 구현을 생성했습니다.

그 후, job-42와 job-47을 승격시켰습니다.

다만, AMA-teras의 자기 진화에서 주인공으로 삼고 싶은 것은 "자동으로 쓰는 것"만이 아닙니다.

주인공은 다음과 같습니다.

• 격리된 git worktree에서 생성한다 - typecheck · 테스트 · 실제 구동 스모크 테스트(smoke test)를 통과한다
• 본체로의 승격은 인간의 승인을 필수적으로 한다
• 외부로의 발신 · 쓰기도 승인 다이얼로그를 통한다
• 망가진 상태를 감지하고, 대장이나 작업(job) 관리의 토대도 고친다

AMA-teras의 자기 진화는 "자동으로 쓰는 것"보다 "안전하게 승격하는 것"에 중심을 두고 있습니다.

다음에 공개할 로그에서도 성공한 구현뿐만 아니라, 가드(guard)나 실패에 관한 실화를 다루겠습니다.

Discussion