셀파스 개발팀의 2026년 상반기 결산
2026년 상반기, AI로 가속화된 셀파스 개발팀의 변화를 돌아봅니다.
2026년 상반기, AI로 가속화된 셀파스 개발팀의 변화를 돌아봅니다.
에이전틱(Agentic) 개발 흐름
개발팀은 상반기동안 에이전틱 개발 흐름을 적극적으로 수용하고 받아들였습니다. 그 과정에서 집중한 부분은 AI 산출물의 '예측 가능성'와 '인수 조건'이었습니다. 인간과 AI가 모두 쉽게 이해하고 디버깅할 수 있는 코드베이스, 그리고 결과물의 신뢰성을 책임질 수 있는 장치가 과감한 위임을 가능케하는 핵심이라고 판단했습니다.
예측 가능성은 일관된 코드패턴, 안정된 아키텍쳐, 그리고 가이드 문서를 통해 통제합니다.
- 글로 표현된적 없던 코드 패턴과 아키텍처를 정비하여 가이드문서로 남겼습니다
- 존재하는 코드가 앞으로 생성될 코드의 참조가 될 수 있도록 기존 코드의 일관성을 강화했습니다.
결과물의 신뢰성은 인수조건을 명시한 테스트를 통해 가져갑니다.
- AI의 모든 산출물에는 테스트가 포함되도록 가이드했습니다.
- PR(pull request)에서 엔지니어는 본문의 내용과, 코드에서 선언된 테스트, 그리고 CI 통과여부만 확인합니다.
- PR 코멘트에 자동으로 첨부되는 자체 제작한 이야기(Iyagi) 스토리북을 통해 프론트엔드 작업의 전/후를 시각적으로 비교 할 수 있습니다.

이전부터 코드패턴을 논의하고 PR 리뷰를 통해 일관된 코드를 작성하고자 했던 팀 차원의 노력이 많은 빛을 발했습니다.
셀파스 엔지니어의 역할은 코드를 직접 작성하는 것에서, 개발 사이클의 처음과 끝에서 문제를 정의하며 기술하고, AI를 통해 생성된 결과물을 검수하는 것으로 변하고 있습니다.

이런 바뀐 흐름속에서 하루에 많게는 수백개의 파일이 변경되었고, 1~2주일에 한번 있던 정기배포일에 수천개의 변경 파일과 수십개의 기능이 기다리고 있었습니다.
트렁크 기반 개발 (Trunk based development)로의 전환
메인(main) 배포 시 변경 파일이 많다는 것은 그만큼 검증해야 할 기능이 많고 각종 컨플릭(conflict) 및 회귀 버그들이 생길 가능성이 높음을 의미했습니다. 또한 각종 스키마와 데이터 마이그레이션까지 한번에 챙겨야하다보니, 정기배포의 위험성이 커졌습니다.
논의 끝에 각종 피쳐 브랜치들이 모이는 중간단계의 개발브랜치를 없애고, 메인에 직접 병합하고 수시로 배포하는 트렁크 기반 개발 방식을 채택했습니다. 작업물(PR)의 크기를 줄이고 컨플릭을 즉시 해결하여, 위의 문제들이 구조적으로 방지되도록 하는 것이 포인트였습니다.
- PR의 단위를 독립적으로 배포 가능한 형태로 만들었습니다.
- 피쳐 플래그(feature flag)를 적극 활용하여 미완성 기능을 배포하고, 스키마와 데이터 마이그레이션을 다루는 패턴을 도입했습니다.
- 결과적으로 버그의 수정, 요청 기능에 대한 배포 속도와 프로젝트 진행의 가시성이 비약적으로 상승했습니다.
작년에 개발팀이 하루 평균 0.1번 (10일에 한번) 메인 배포를 했다면, 현재는 하루 평균 5번 배포하고 있습니다.

코드가 제품에 반영되는 주기가 비약적으로 짧아지면서, 수많은 새로운 도메인과 사용자 경험이 생겼고 제품팀 안에서도 이를 추적하고 공유하는것이 어려워지기 시작했습니다.
셰르파 넥서스(Sherpa Nexus)와 다양한 봇(bot)들
기존 작업 흐름에선 작업의 내용을 구현자에게 직접 물어보는 패턴이 흔했습니다. 하지만 누구나 제품의 어느 영역이든 수정할 수 있는 환경에선 구현자를 특정하기 어렵고, 지식이 여러 사람과 장소에 파편화되어 옳은 답변을 하기 힘들어집니다.
여기서 원할 때 무엇이든 질문하고 답변을 얻을 수 있는 사내 에이전트의 필요성이 생겼습니다.
- 안드레 카파시(Andrej Karpathy)의 llm wiki에서 영감을 얻어, 슬랙과 깃헙을 시간단위로 컴파일하고 인덱싱하는 지식창고를 만들었습니다.
- 이렇게 만들어진 넥서스는 제품의 기능과 방향, 정책, 내부 회의 결과, 진행중인 프로젝트 등 구성원들의 다양한 물음에 답하고 있습니다.

또한 마케팅 컨텐츠를 탐색하고 작성하는 양파(Yangpa)씨와 센트리(sentry)와 QA에서 발생한 버그를 자동으로 수정 후 PR을 만드는 셰르파 코드(Sherpa Code)가 슬랙, 리니어, 깃헙등의 플랫폼에서 활약하고 있습니다.
여기까지의 결과로
- 26년 상반기는 작년(25년) 하반기 대비 높은 아웃풋을 향상된 품질로 제공했습니다.
- PR의 수가 310% 증가했습니다. AI가 99% 의 PR을 생성했습니다.
- 버그의 빈도는 평균 32% 감소했습니다.
- 버그 처리속도가 평균 230% 증가했습니다.
- 비 개발직군도 셰르파 코드봇을 이용해 버그 수정이나 간단한 기능구현을 하고 있습니다.
- 제품팀(개발팀 + PO)은 도메인 관찰과 모델링에 많은 시간을 쏟고 있습니다.
- 개발팀은 구현 외에 기술적 리뷰와 각 도메인 (BE, FE, 인프라)의 파수꾼 역할을 하는 가이드와 가드레일 규칙 정비에 시간을 쏟고 있습니다.
남아있는 숙제
개발팀의 진화는 현재 진행형입니다. 상반기는 에이전틱 개발 흐름을 적극 도입하고, 과정에서 드러난 PR리뷰와 배포 등 병목의 연쇄적 해소로 갈음할 수 있겠습니다. 변화의 도입과 그 이후의 대응 모두 구성원들의 공감과 이해가 뒷받침된 결과입니다. 반면 앞으로 해결해야하는 숙제도 많습니다.
생산성은 향상되었지만 엔지니어의 코드 베이스 장악력은 희석되었습니다.
'보면 안다'와 '안봐도 안다'는 꽤 큰 차이가 있습니다. 제한된 인간의 컨텍스트 윈도우에 어떤 이해와 지식을 선택적으로 캐싱하고 있을지를 결정해야 합니다.
무엇을 모르는지 모르는 상태 (unknown unknown)를 경계해야 합니다. 구조적 관점에서 예측 불가능한 버그의 크기와 빈도를 제한할 수 있는 장치를 고민해야 합니다.
개선이 비즈니스적 가치와 연결되어야 합니다. 토큰을 많이 쓰는 것을 넘어 그것의 비즈니스적 가치를 높이려면 어떻게 해야 할까요? 무엇을 왜 만드는지, 그리고 해결책이 문제 해결과정에 어떻게 스며들지가 더 중요한 문제가 되었습니다.
앞으로 개발팀이 어떤 모습이 될지는 감히 예측하기 어렵습니다.
다만 AI가 가진 힘을 잘 이해하고 그에 수반되는 변화의 반발자국 뒤에서, 오직 우리 도메인의 문제를 효과적으로 해결하고 고객에 전달하는 것에 집중하고자 합니다.
현재 셀파스 개발팀은 이렇게 일하고 있습니다. 그리고 셀파스는 채용중입니다.
궁금하거나 관심이 가신다면, 부담없이 연락(tlonist@sherpas.team) 주세요!