TL;DR

  • Claude Code를 사용한 뒤 수작업 코딩에 대한 회의가 바뀌었고, 부러진 팔로 작업하던 중 생산성이 3배로 늘어남.
  • OpenEngine은 소프트웨어 개발 생명주기(SDLC)의 사람 개입이 필요하지 않은 작업을 자동화하는 오픈소스 소프트웨어 팩토리임.
  • 작업 지시서(workorder)에 따라 이름 지정, 구현, 테스트, 다섯 종류의 검토 에이전트와 영향 분석을 실행함.
  • 검토 결과를 구현 에이전트에 한 차례 되돌려 명백한 누락을 보완하고, 풀 리퀘스트(PR)는 최종적으로 사람이 승인함.
  • GitHub 권한 확인 캐싱으로 최대 5분간 접근 권한이 취소된 사용자가 OpenEngine을 계속 사용할 수 있는 절충을 택했으며, iOS·Android·웹 개발 적용을 시험할 계획임.

AI 코딩에 대한 생각이 바뀌기까지

  • 2025년에 Google을 퇴사하고 중요하다고 생각하는 소프트웨어를 만들기 시작함.
  • 당시 GitHub Copilot을 조금 사용했지만 출력 품질이 부족하다고 느껴 대부분의 코드를 직접 작성함.
  • 2026년 초 친구의 추천으로 Claude Code를 사용하기 시작했고, 일관되게 매우 좋은 코드를 생성하는 것을 경험함.
  • 몇 달에 걸쳐 코드를 직접 작성하는 방식에 대한 입장이 서서히 바뀜.

에이전트 코딩을 시작하게 된 계기

  • 2026년 3월 교통사고로 쇄골이 부러졌으며, 사고는 본인의 책임이라고 밝힘. 몇 달 동안 한쪽 팔을 쓰지 못해 직접 코딩하는 속도가 느려짐.
  • 1월에 Claude Code v1이 나왔을 때는 에이전트가 자신만큼 잘할 수 있다고 믿지 않아 사용하지 않았음.
  • 수술을 기다리며 움직임이 제한된 상황에서 Claude 구독을 시작함.
  • 팔이 부러진 상태에서도 생산성이 3배로 늘었고, 당시 만들던 SaaS 제품 ScheduleLord의 기능을 3배 빠르게 구현함.
  • 코드와 테스트, 문서를 생성하는 품질은 본인과 동등했음. 다만 결과물이 본인과 똑같은 방식으로 작성되는 것은 아니어서 상당한 방향 제시가 필요했지만, 구현 속도와 코드에 대한 확신은 매우 높았음.

소프트웨어 팩토리를 만들기로 한 과정

  • ScheduleLord를 만들던 중 콜로라도주 잉글우드의 공유 작업 공간에서 Shea를 만남.
  • Shea는 소프트웨어 개발 생명주기(SDLC)를 자동화해 원하는 제품을 더 빠르고 나은 방식으로 만들 수 있다고 설명함.
  • 약 한 달간 논의한 뒤 함께 OpenEngine을 만들기로 함.

SDLC를 자동화하는 OpenEngine

  • OpenEngine은 소프트웨어 팩토리임.
  • 오픈소스이므로 살펴보고 포크하거나 개선할 수 있음.
  • 개발자가 이미 사용하는 환경에 맞추기 위해 GitHub 및 Slack 연동을 제공하며, 기존에 소통하는 곳에서 프롬프트를 보내고 작업 방향을 제시할 수 있음.
  • 이미 비용을 내고 있는 실행 환경을 사용하도록 ACP로 기존 하네스(harness)에 연결함.
  • 소프트웨어 개발에서 사람의 개입이 필요하지 않은 부분을 없애는 것이 목표임.
  • 예상과 달리 시스템이 작동할 뿐 아니라, 이제는 자신보다 더 나은 코드를 작성한다고 볼 여지도 있음.

코드 품질과 속도를 높이는 작업 흐름

  • OpenEngine 설치 후 사용하는 개념은 작업 지시서(workorder)임. 작업할 티켓을 주는 것과 같음.
  • 각 작업 지시서는 특정 업무를 수행하는 에이전트인 노드(node)를 실행함.

이름 지정

  • 이름 지정 노드가 나중에 작업 지시서를 찾을 수 있도록 이름을 정함.
  • GitHub 이슈 등의 추가 데이터를 가져와 작업 범위에 대한 맥락을 보강한 뒤 이름을 지정함.

구현

  • 구현자(implementor) 노드가 대부분의 코드를 작성함.
  • 구현 코드를 작성하고 구현이 완료됐는지 확인하는 테스트도 작성함.

검토

  • 검토자(Reviewer) 단계는 검토 노드 5개, 재순위화기(Reranker), 영향 분석, 사람의 검토로 구성됨.
  • 검토 결과를 구현자에게 한 차례 전달해 놓친 명백한 부분을 해결하도록 함.

검토자 역할

  • 다섯 검토자는 각기 다른 영역을 살펴보도록 설계됨.
  • 보안: 코드 변경에 잠재적인 보안 위험이 있는지 탐지함.
  • 버그 및 작업 준수: 버그를 찾고 요청된 대로 작업이 구현됐는지 확인함.
  • 성능: 캐싱 제안 등 성능 개선 방법을 살피고 구현이 최적인지 확인함.
  • 간결성: 구현자가 코드와 주석을 과도하게 작성하지 않았는지 살핌.
  • 중복 제거(DRY) 및 코드 중복: 라이브러리 코드를 사용하고 있는지 살피며, 반복 사용되는 코드에는 추상화를 적용하도록 함.

재순위화

  • 재순위화기는 검토자들의 결과에서 잡음을 걸러내고 PR 코드 검토에 중요한 사항만 드러냄.
  • 사람인 검토자가 해당 사항을 처리할 가치가 있는지 판단함.

영향 분석

  • 영향 분석 노드는 변경된 내용을 모두 검토하고 영향의 크기를 표시함.
  • 초록색은 주요 요소에 영향을 미칠 가능성이 낮아 병합해도 안전할 것으로 보이는 변경임. 초록색 PR을 사람의 검토 없이 병합할 수 있다고 신뢰해도 되는지 현재 시험 중임.
  • 주황색은 잠재적으로 위험한 부작용을 일으킬 수 있는 변경임. 절충이 필요한 경우가 많으며, 그 가치가 있는지 사람이 판단함.
  • 빨간색은 상당한 변경일 가능성이 높고 보안상 영향이나 호환성 파괴 변경을 포함할 수 있음. 병합 전에 절충점과 변경 내용을 충분히 이해할 수 있도록 사람의 검토가 필요함.

사람의 검토

  • 검토자 단계의 마지막은 변경 사항에 대한 사람의 승인임.
  • GitHub에서 PR을 확인할 수 있으며, GitHub 연동을 통해 승인하고 병합하면 OpenEngine에서도 승인된 것으로 표시됨.

추가 검토로 코드 품질 높이기

  • 검토 단계를 추가해 높은 품질의 코드 변경을 만들고 변경이 올바르게 이뤄졌다는 신뢰를 높임.
  • 증거 수집 기능을 추가로 검토 중임. 기본 구상은 스크린샷, 동영상, 스테이징 환경, 문서로 변경 사항이 의도한 기능을 구현한다는 증거를 제시하는 것임.
  • 이를 통해 사람이 코드를 내려받아 직접 확인하지 않고도, 모든 것이 올바르게 동작하는지 품질을 보증하는 검토를 제공하고자 함.

실제 사례

  • GitHub 연동을 구현하면서 권한 문제가 다수 발생함.
  • 사용자가 GitHub 저장소에 접근할 권한이 있는지 확인해야 했고, 매번 GitHub에 다시 확인하지 않도록 캐싱을 구현함.
  • 이 캐싱에는 보안상 절충이 따름. GitHub 접근 권한이 취소된 사용자도 최대 5분 동안 OpenEngine을 계속 사용할 수 있음. 다만 감수할 만한 절충이라고 판단함.
  • 연동 구현 당시 우선순위는 기능 구현이었으며 권한 확인은 최우선 과제가 아니었음. OpenEngine의 검토 절차가 이런 명백한 위험 요소를 살핀 점이 유용했음.

더 큰 확신과 함께 더 빠르게 만들기

  • OpenEngine으로 작업 속도가 빨라짐.
  • iOS, Android, 웹 개발에서 시험할 몇 가지 개인 프로젝트를 만드는 방안을 검토 중임.
  • OpenEngine을 내려받아 설치하고 개선 의견을 제공해 달라고 요청함.
  • 제품 결정에 의견을 반영하고 논의를 이어가기 위해 Slack 참여를 안내함.