우리는 우리의 AI가 코드를 작성하고, PR을 검토하며, 스스로 배포하도록 합니다.

스스로 닫힌 루프

2026년 2월 3일. 커밋 메시지는 이렇게 적혀 있습니다: “feat(ci): GitHub Actions에서 자율적인 Claude를 위한 폐쇄 루프 검증 추가.”

이 커밋은 몇 주 동안 쌓여온 회로를 완성했습니다. 결과: AI가 코드를 작성하고, 테스트하고, 검토하고, PR을 생성하고, 결과를 검증하는 완전 자율적인 개발 루프 — 모든 과정이 인간의 손길 없이 이루어집니다.

루프는 다음과 같습니다:

1. GitHub에 이슈가 등록됩니다.
2. Claude가 이슈와 코드베이스를 읽습니다.
3. Claude가 새로운 브랜치에서 수정 사항을 작성합니다.
4. Claude가 테스트를 실행합니다.
5. 테스트가 실패하면, Claude가 오류를 읽고 코드를 수정합니다.
6. 테스트가 통과하면, Claude가 요약과 함께 PR을 생성합니다.
7. 별도의 Claude 인스턴스가 PR을 검토합니다.
8. 인간이 모든 것을 검토하고 병합 여부를 결정합니다.

1단계부터 7단계까지는 자동으로 진행됩니다. 8단계만이 인간의 개입이 필요합니다.

우리가 여기까지 온 과정

이것은 하루아침에 이루어진 일이 아닙니다. 6주 동안 점진적으로, 한 가지 기능씩 구축되었습니다.

1주차: 이슈 해결 (12월 25일). 가장 간단한 버전으로 시작했습니다: Claude가 GitHub 이슈를 읽고, 수정을 작성하고, 브랜치를 푸시합니다. 테스트도, 검토도 없습니다. 단지 “여기 수정할 가능성이 있는 브랜치가 있으니 확인해 보세요.”

2주차: PR 생성 (12월 26-27일). 단순히 브랜치를 푸시하는 대신, Claude가 제목, 설명 및 연결된 이슈가 포함된 적절한 풀 리퀘스트를 생성합니다. 이제 수정 사항이 팀에 수동으로 브랜치를 확인하지 않고도 보입니다.

3주차: 코드 검토 (2월 초). 새로운 PR에 대해 별도의 Claude 워크플로우가 트리거됩니다. 코드에서 버그, 보안 문제 및 스타일 위반을 검토합니다. PR에는 인간 검토자의 코멘트처럼 코멘트가 나타납니다.

4주차: 폐쇄 루프 검증 (2월 3일). 마지막 단계: Claude가 PR을 제출하기 전에 테스트를 실행합니다. 테스트가 실패하면, 오류 출력을 읽고 코드를 수정한 후 다시 시도합니다. 테스트 스위트가 통과할 때만 PR이 생성됩니다.

매주 하나의 레이어가 추가되었습니다. 각 레이어는 전체 시스템을 더 신뢰할 수 있게 만들었습니다.

AI 기반 개발에 대해 우리가 배운 것

AI는 자유가 아닌 제약이 필요하다. 초기에 Claude는 가벼운 UI 버그를 수정하기 위해 세 개의 모듈을 리팩토링하고 데이터베이스 스키마를 변경하기도 했습니다. 우리는 명시적인 제약을 추가하는 법을 배웠습니다: “이슈와 직접 관련된 파일만 수정하세요. 리팩토링하지 마세요. 기능을 추가하지 마세요. 버그를 수정하세요.”

간결한 요약이 상세한 설명보다 낫다. Claude의 첫 PR 설명은 2,000단어에 달했습니다. 아무도 읽지 않았습니다. 우리는 프롬프트를 조정하여 200단어 이하의 요약을 요구했습니다. “무엇이 변경되었고 왜"를 두 문장으로. 검토자가 검토를 시작하는 데 필요한 전부입니다.

코드 검토는 실제 문제를 잡아낸다. AI가 AI가 생성한 코드를 검토할 때 유용한 것을 찾을 수 있을지 회의적이었습니다. 하지만 찾습니다. 누락된 오류 처리, 잠재적인 null 참조, 사용되지 않는 임포트, 보안 문제. AI 코드 검토자는 완벽하지 않지만, 인간이 빠르게 스캔할 때 잡는 문제의 80%를 잡아냅니다 — 그리고 몇 초 만에 처리합니다.

관심사의 분리는 중요하다. 코드를 작성하는 AI와 코드를 검토하는 AI는 분리되어야 합니다. 같은 모델이지만, 다른 맥락, 다른 프롬프트, 다른 관심사를 가집니다. 작성자는 낙관적입니다 (“여기 내 해결책이 있습니다”). 검토자는 회의적입니다 (“무슨 문제가 생길 수 있을까?”). 두 가지 관점이 필요합니다.

메타 현실

명백한 사실을 말해봅시다: 우리는 자율 AI 에이전트를 위한 플랫폼을 구축하고 있으며, 자율 AI 에이전트를 사용하여 그것을 만들고 있습니다.

우리의 사용자는 샌드박스 환경에서 코드를 실행하고, 파일을 읽고 쓰며, 자율적으로 작업을 완료하는 AI 에이전트를 운영합니다. 우리의 개발 프로세스는 CI 환경에서 코드를 실행하고, 파일을 읽고 쓰며, 자율적으로 작업을 완료하는 AI 에이전트를 실행합니다.

차이는 표면적입니다: 우리의 사용자는 LikeClaw의 웹 인터페이스를 사용하고, 우리의 CI는 GitHub Actions를 사용합니다. 기본 패턴은 동일합니다: 작업을 정의하고, AI가 실행하게 하며, 결과를 검토합니다.

이는 우연이 아닙니다. 우리는 사용자에게 가르치는 동일한 원칙을 사용하여 개발 파이프라인을 구축했습니다. 그리고 이 파이프라인을 운영하면서 배우는 것들이 우리가 그들을 위해 구축하는 제품을 개선합니다. 이는 선순환입니다.

숫자

자율 개발 파이프라인을 활성화한 이후:

• AI가 생성한 PR: 수십 개
• 이슈에서 PR까지 평균 시간: 몇 분, 몇 시간 아님
• 제출 전에 잡힌 테스트 실패: 주당 여러 건
• AI가 작성한 코드로 인한 생산 사고: 제로 (지금까지)

마지막 숫자가 가장 중요합니다. 제로 생산 사고. 모든 AI가 작성한 변경 사항은 병합 전에 테스트, AI 검토 및 인간 검토를 거쳤습니다. 세 겹의 안전망이 작동합니다.

이것은 시작에 불과하다

오늘날, AI는 버그 수정, 의존성 업데이트 및 간단한 기능 구현을 처리합니다. 내일은 더 복잡한 작업을 처리할 것입니다: 다중 파일 리팩토링, 성능 최적화, 테스트 생성.

핵심 통찰은 AI가 코드를 작성할 수 있다는 것이 아닙니다. AI가 적절한 가드레일과 함께 개발 워크플로우에 참여할 수 있다는 것입니다. 테스트, 검토 및 인간의 감독이 AI가 생성한 코드를 안전하게 만듭니다. 이 중 어느 하나라도 제거하면 위험이 발생합니다. 세 가지 모두를 유지하면 팀의 생산성을 배가시키는 도구가 됩니다.

우리는 하루에 7.5개의 커밋을 하는 작은 팀입니다. 그 중 일부는 인간이 작성한 것입니다. 일부는 AI가 작성한 것입니다. 모든 커밋은 인간의 승인을 받았습니다.

이것이 소프트웨어 개발의 미래입니다. AI가 개발자를 대체하는 것이 아니라, AI가 개발자를 가속화하는 것입니다. 적절한 가드레일을 갖춘 채로. 새벽 3시에. 팀이 잠든 사이에.