Citizen Developer SDLC: 비개발 직원이 AI로 구축한 소프트웨어를 개인 프로토타입에서 전사가 신뢰하는 프로덕션으로 전환하는 6단계 라이프사이클
Alex Lieberman (@businessbarista), Arman Hezarkhani (@ArmanHezarkhani, Suchi Patel, Ashwin Kadaru (@AshwinKadaru)*
A Tenex.co 프레임워크.
TLDR
Citizen SDLC는 아이디어, 프론트 도어, 트리아지, 프로비저닝, 빌드, 운영 및 변경이라는 6단계 라이프사이클로, 비개발 직원이 AI로 구축한 소프트웨어를 개인 프로토타입에서 관리되는 프로덕션으로 전환합니다. 모든 단계를 관통하는 하나의 원칙이 있습니다: AI는 노동을 수행하고, 결정적 코드는 가드레일을 설정하며, 인간은 예외 상황을 처리합니다. 이 프레임워크가 등장한 이유는 AI가 코드 작성 비용을 거의 0으로 낮추고 병목 지점을 다운스트림, 즉 구축된 결과물이 정확한지 확인하고, 라이브 상태가 된 후에는 증가하는 앱들을 관리하는 쪽으로 이동시켰기 때문입니다.
저희 고객 중 한 곳은 투자 회사입니다. 포트폴리오 운영팀의 한 직원(코드를 단 한 줄도 작성해본 적 없는 사람)이 자신의 팀全体가 매일 사용하는 대시보드를 구축했습니다. 이 대시보드는 수십 개의 포트폴리오 회사에 걸친 가치 창출 작업을 추적합니다. 그녀는 Claude에 프롬프트를 입력하고 약 2개월에 걸쳐 반복 작업하며 구축했습니다. 모든 단일 코드 줄은 AI가 작성했습니다.
그리고 그 결과물은 훌륭합니다. 뷰는 정확하고, 워크플로는 팀의 실제 운영 방식에 맞으며, 도입은 즉시 이루어졌습니다. 그녀는 엔지니어가 개입하기 전에 올바른 제품을 스케치했습니다.
이는 우연이 아닙니다. 수십 년 동안 비즈니스 문제를 이해하는 사람은 거의 항상 그 문제를 해결할 소프트웨어를 구축할 수 있는 사람이 아니었습니다. 그 격차를 해소하는 것은 엄청난 노력이 필요했습니다: 그녀의 문제를 사양으로 바꾸는 프로덕트 매니저, 사양을 코드로 번역하는 엔지니어, 그리고 로드맵의 다른 모든 항목 뒤에 줄을 서는 과정이 필요했습니다. 아이디어에서 도구까지는 몇 달이 걸렸고, 최종적으로 출시된 것은 그녀가 의도한 바를 다른 사람이 해석한 결과물이었습니다.
그 격차는 이제 사라졌습니다. 구축할 수 있는 능력은 실제로 프로세스를 이해하고, 데이터가 무엇을 의미하는지 알며, 매일 워크플로 속에서 생활하는 사람들에게로 이동했습니다. 그녀는 첫 번째 시도에 올바른 것을 구축했습니다. 왜냐하면 그녀가 바로 그 근원이었기 때문입니다. 아무도 그녀를 중간에서 번역하거나, 약간 잘못 이해할 사람이 없었습니다. 이것이 시민 개발(Citizen Development)의 약속이며, 그녀는 그 약속을 실현했습니다.
하지만 우리는 그 내부를 살펴보았습니다.
전체 애플리케이션은 하나의 HTML 파일이었습니다. 540KB. 약 5,300줄. 마스터 데이터셋은 단일 라인에 80KB 크기의 데이터 블롭으로 파일 내부에 존재했습니다. 파일을 업데이트해야 할 때, AI는 앱이 로드될 때마다 값을 다시 쓰는 패치 기능을 덧붙였습니다. 작업을 저장한다는 것은 앱이 자신의 HTML을 다시 작성하고, 이를 노트북에 다운로드한 다음, 새 버전으로 공유 드라이브에 다시 업로드해야 함을 의미했습니다. 두 사람이 동시에 편집하면 마지막 저장이 우선 적용되고, 다른 사람의 편집 내용은 사라집니다.
어느 날, 저장 기능이 파일에서 마커를 찾다가 찾지 못했고, 가지고 있던 내용을 그대로 다시 썼습니다. 전체 540KB 애플리케이션이 7바이트로 잘렸습니다. 단 한 번의 조용한 쓰기 작업으로 그녀의 팀이 매일 사용하던 대시보드는 존재 자체가 사라졌고, 이를 감지하거나, 막거나, 되돌릴 수 있는 방법은 구축 방식에 전혀 설계되어 있지 않았습니다.
대부분의 리더는 이 이야기를 듣고 시민 개발을 차단해야 할 위험 요소로 결론 내립니다. 우리는 이것이 잘못된 교훈이라고 생각하며, 이에 따라 행동하는 회사들은 손해를 볼 것입니다. 올바른 교훈: 그녀는 자신의 업무를 훌륭하게 수행했습니다. 소프트웨어가 배송될 수 있는 길을 만든 사람은 아무도 없었습니다.
병목 지점이 이동했습니다
수십 년 동안 소프트웨어를 구축하는 것은 비용이 많이 드는 부분이었습니다. 느리고, 희소하며, 비용이 많이 들었고, 전체 소프트웨어 개발 라이프사이클(SDLC)은 이를 보호하기 위해 성장했습니다. 사양, 티켓, 스프린트, 코드 리뷰: 전통적인 SDLC의 모든 의식은 코드 작성이 병목 지점이었기 때문에 존재했습니다.
AI는 이 단계를 거의 0으로 붕괴시켰고, 병목 지점은 이동했습니다. 누구나 오후에 작동하는 앱을 구축할 수 있을 때, 비용이 많이 드는 작업은 더 이상 구축이 아닙니다. 그 다음이 중요합니다: 구축된 것이 정확하고 안전한지 확인하고, 라이브 상태가 된 후에는 증가하는 앱 함대를 관리하는 것입니다.
GIF
그리고 구축 속도는 느려지지 않고 있으며, 해결해야 할 두 가지 문제를 만들어냅니다:
첫째, 내부 품질. 비엔지니어가 빈 페이지에서 프롬프트한 에이전트는 오늘 작동하지만 영원히 유지 관리가 불가능한 해키한 소프트웨어로 수렴합니다. 540KB 파일은 이상치가 아닙니다. 이는 가드레일 없이 구축했을 때의 기본 출력물입니다.
둘째, 확산. 모든 팀은 자체 앱을 원하며, 중앙 IT 그룹이 수십 개의 앱을 직접 구축하고 운영할 수 없습니다. 가드레일이 없으면 각 앱은 빌더나 모델이 선택한 스택(다른 데이터베이스, 다른 인증 체계, 여기저기에 숨겨진 비밀) 위에 구축됩니다. 요청을 차단하면 멈추지 않고, 오프북(off the books)으로 이동합니다. 어느 쪽이든 앱 함대뿐만 아니라 그 아래에 있는 엉킨 인프라를 상속받게 되며, 그 어느 것도 IT가 합리적으로 보안을 유지하거나, 지원하거나, 설명할 수 없습니다.
따라서 모든 회사가 곧 직면하게 될 진짜 질문은 이것입니다: 비기술 직원이 실제 내부 소프트웨어를 출시하도록 허용하면서 그 함대를 상속받지 않는 방법은 무엇일까?
세 가지 기본 답변은 모두 실패합니다:
1) 잠가 버리기. 요청은 대기열에 쌓이고, 인내심은 바닥나며, 섀도우 앱은 어쨌든 구축됩니다. 이제는 그 어떤 것도 볼 수 없습니다. 볼 수 없는 것은 관리할 수 없습니다.
2) 무작정 허용하기. 구조 없이 비엔지니어를 AI 도구에 연결하고 데모를 축하합니다. 이것이 540KB 파일을 얻는 방법입니다. 그리고 사후에 코드 리뷰로 문제를 해결할 수 없습니다. 모노리스가 코드 리뷰에 나타날 때쯤이면 이미 모노리스입니다. 시작점에서 예방해야 합니다.
3) 모든 것을 검토하기. 모든 변경 사항에 사람의 승인을 받습니다. IT 팀은 얇고, 빌드 볼륨은 폭발적으로 증가하며, 이제 모든 배포는 리뷰어의 일정을 기다립니다. 리뷰는 도입을 죽이거나 도장을 찍는 형식이 됩니다. 두 결과 모두 목적을 무색하게 만듭니다.
따라서 해결책은 또 다른 정책 문서가 아니라 라이프사이클입니다: 자신을 개발자라고 부르지 않을 사람들을 위해 설계되고, 메모에 작성되는 대신 플랫폼에 내장된 가드레일을 갖춘 진정한 SDLC입니다. 첫 번째 평이한 언어 아이디어부터 관리되는 프로덕션까지 빌드를 운반하는 길이며, 빌더에게 엔지니어가 되라고 요구하지 않습니다. 사람은 의도를 제공하고, 플랫폼은 규율을 제공합니다.
모든 단계를 관통하는 하나의 원칙이 있습니다: AI는 노동을 수행하고, 결정적 코드는 가드레일을 설정하며, 인간은 예외 상황을 처리합니다. AI는 초안을 작성하고, 분류하고, 코드를 작성합니다. 코드는 무엇이 허용되는지 결정합니다. 사람은 판단이 실제로 필요한 곳에만 투입됩니다. 이 구분을 기억하십시오. 그것이 전체를 확장 가능하게 만드는 것입니다.
우리는 이것을 Citizen SDLC라고 부릅니다. 각각 관리되는 6단계입니다.
1단계
아이디어
사용자는 AI의 도움을 받아 평이한 언어로 앱을 설명합니다: 무엇을 하는지, 누가 사용하는지, 어떤 데이터를 다루는지, 누가 소유하는지. 몇 분이 걸리며 메모처럼 읽힙니다. 이는 다운스트림의 모든 것이 기반하는 브리핑 역할을 겸합니다. 이것이 운영 모델의 첫 번째 움직임입니다: AI가 횡설수설을 구조화된 아티팩트로 바꾸는 노동을 수행합니다.
실제로 어떻게 보이는지 살펴보겠습니다. 펀드 재무 부서의 누군가가 이렇게 입력합니다: "자본 출자 요청서(Capital Call Notice)용 트래커를 원합니다. 지금은 매주 금요일마다 수동으로 업데이트하고 이메일로 보내는 스프레드시트입니다." AI는 인입 분석가가 물어볼 질문을 합니다. 누가 더 봐야 하나요? 펀드 재무 및 IR 부서의 12명. 데이터는 현재 어디에 있나요? Box의 스프레드시트이며, 읽기 전용으로 충분합니다. 당신이 없을 때 누가 소유하나요? 그녀의 매니저. 횡설수설이 브리핑이 되었습니다: 목적, 사용자, 데이터 소스, 액세스 수준, 소유자, 심지어 앱 형태에 대한 첫 번째 추정까지. PRD라는 용어를 들어본 적 없는 사람이 작성한, 사실상의 PRD(Product Requirements Document)입니다.
GIF
아직 아무것도 존재하지 않습니다. 코드도, 액세스도, 인프라도 없습니다. 이는 의도적입니다: 회사는 앱이 존재하기 전에 앱에 대한 의견을 형성하며, 앱이 부하를 견디기 시작한 지 6개월 후에야 형성하지 않습니다.
2단계
프론트 도어
모든 요청은 하나의 구조화된 프론트 도어를 통과하며, 파일을 제출하는 동일한 동작이 요청을 곧바로 트리아지로 보냅니다. 브리핑은 요청, IT가 보는 티켓, 영구 기록, 그리고 누구나 검색할 수 있는 카탈로그의 항목이 동시에 됩니다. 복도에서 하는 요청도, 개인적인 부탁도, 섀도우 파이프라인도 없습니다. 볼 수 없는 것은 관리할 수 없고, 찾을 수 없는 것은 공유할 수 없습니다. 프론트 도어는 첫날부터 이 두 가지를 모두 가능하게 만듭니다.
이 단계는 섀도우 파이프라인을 죽이는 단계입니다. 프론트 도어를 건너뛴 빌드는 노트북의 프로토타입으로 존재할 수 있지만, 그곳에 머물러 있습니다. 프로토타입을 팀이 신뢰할 수 있는 소프트웨어로 바꾸는 모든 것(실제 스토리지, 회사 로그인, 배포 파이프라인, 실제 실행 환경)은 이 단계 이후에 존재합니다. 프론트 도어를 통과하지 않은 빌드에는 그 어떤 것도 도달하지 않습니다. 프론트 도어를 우회할 수는 있지만, 그렇게 하면 프로토타입 이상으로 갈 수 없습니다.
3단계
트리아지
AI는 두 가지 축을 따라 요청을 분류합니다. 형태(Shape): 어떤 종류의 앱인가요? 직원들이 실제로 구축하는 것을 역감사(reverse-audit)하면 거의 항상 짧은 목록으로 압축됩니다: 아티팩트 생성기, 워크플로 자동화, CRUD 앱, 대화형 대시보드. 형태를命名하면 필요한 아키텍처를 알 수 있으며, 다음 단계에 스탬프를 찍을 포장된 길을 제공합니다. 블래스트 반경(Blast radius): 이 빌드가 잘못될 경우 얼마나 큰 피해를 줄 수 있나요? 우리는 이를 네 가지 차원으로 평가합니다:
- 범위 및 기능: 무엇을 건드릴 수 있으며, 쓸 수 있는지 아니면 읽기만 가능한지?
- 되돌릴 수 있음 및 자율성: 루프에 사람이 개입되어 있으며, 작업을 취소할 수 있습니까?
- 노출: 누가 출력을 보며, 회사 외부로 얼마나 퍼져나갑니까?
- 데이터 민감도: 상호 작용하는 데이터의 기밀 수준은 어느 정도입니까?
하지만 이것을 신뢰할 수 있게 만드는 규칙이 있습니다: AI는 조언합니다. 코드가 결정합니다. 모델은 브리핑을 읽고 분류합니다. 그런 다음 IT가 작성한 정책 코드가 각 분류를 규칙과 비교하여 확인합니다. 자본 출자 요청서 트래커에서 어떻게 작동하는지 지켜보십시오. 형태: 대화형 대시보드. 블래스트 반경: 내부 펀드 데이터, 12명의 내부 사용자, 읽기 전용, 루프에 사람 개입, 기존 앱과 중복 없음. 모든 차원이 승인된 임계값 내에 있으므로 승인되며, 아무도 이에 대해 논쟁하지 않았습니다.
이제 한 가지 사실을 바꿔보겠습니다. 트래커가 LP 약정 데이터도 필요하다고 가정해 보겠습니다. 브리핑이 아무리 설득력 있어도 상관없습니다. 이 한 가지 변경으로 데이터 민감도 차원이 IT가 설정한 임계값을 초과하며, 요청은 사람에게 전달됩니다. 그 사이에 판단 호출은 발생하지 않았습니다. 규칙이 일치하거나 일치하지 않거나 둘 중 하나입니다.
세 가지 결과 경로:
- 승인됨. 모든 임계값 내에 있는 블래스트 반경, 완전한 브리핑, 높은 신뢰도. 저희 고객의 경우 약 10건 중 9건의 요청이 자동으로 이렇게 처리됩니다.
- 재사용. 이미 존재하는 앱과 중복되므로 요청자는 중복을 구축하는 대신 해당 앱의 소유자에게 라우팅됩니다. 중복은 병합되며, 곱해지지 않습니다.
- 에스컬레이션. 차원이 임계값을 초과하거나 신뢰도가 낮습니다. IT 및 보안팀의 담당자가 전체 요청을 컨텍스트로 받습니다.
GIF
열 번째 요청, 즉 예외적인 요청은 여전히 전체 브리핑과 함께 사람의 책상에 도착합니다. 나머지 아홉 개는 결코 그럴 필요가 없었습니다.
4단계
프로비저닝
여기 IT가 대량으로 '예'라고 말할 수 있게 하는 움직임이 있습니다: 프로비저닝은 IT가 출시되는 것에 대한 통제력을 잃는 것이 아니라 IT의 통제력이 업스트림으로 이동하는 것입니다. IT는 모든 앱을 사후에 검토하는 대신 포장된 길을 한 번 작성하고, 모든 앱이 그 길 위에서 탄생합니다. 한 사람이 승인하면 플랫폼은 앱의 형태에 맞는 길에서 앱을 스탬프합니다: 리포지토리, 회사 로그인, 배포 ID, 프라이빗 환경, 자체 데이터베이스. 이 모든 것은 IT가 소유하고 버전을 관리하는 코드형 인프라(Infrastructure-as-Code)로 정의됩니다. 몇 분 안에 프로비저닝됩니다.
이 순간은 높은 권한이 실행되는 유일한 순간이며, 사람이 그 앞에 있습니다. 모든 앱은 격리되고, 관리되며, 감사 가능하게 태어납니다: 자체 벽으로 둘러싸인 환경, 공개 주소 없음, 저장된 클라우드 비밀 없음, 0일부터 추가 전용 감사 추적. 보안 작업은 길에서 한 번 발생했습니다. 어떤 앱도 이를 반복할 필요가 없습니다.
길이 형태별로 작성되기 때문에 사람의 승인은 기본 자세이지 영구적인 세금이 아닙니다. 새로운 형태와 높은 블래스트 반경의 빌드는 사람의 게이트를 영구적으로 유지합니다. 그러나 특정 형태의 길이 충분한 빌드를 통해 입증되면, 해당 길의 낮은 블래스트 반경 요청은 자동으로 프로비저닝될 수 있습니다. 이는 한 단계 더 일찍 적용된 동일한 "사람의 판단을 꼬리 부분에만 사용하라"는 논리입니다: 초기에는 더 많은 것을 사람에게 라우팅하고, 패턴이 유지됨에 따라 라인이 자동화 쪽으로 이동합니다.
그리고 이 길은 인프라만큼 중요한 한 가지를 더 전달합니다: AI 규칙집입니다. 상속된 리포지토리는 코딩 에이전트에게 모든 세션에서 따를 지침 세트를 제공하며, 실제 실패에서 배운 안티패턴을 인코딩합니다. 1KB가 넘는 인라인 데이터 블롭을 사용하지 마십시오. 앱 로드 시 데이터를 다시 쓰는 함수를 추가하지 마십시오. 이것이 빌더에게 단일 모범 사례를 묻지 않고도 내부 품질 문제를 해결하는 방법입니다: 길이 에이전트가 이를 따르도록 만듭니다. 그 규칙들 각각은 뒤에 이야기가 있는 흉터입니다 (여러분은 그중 하나를 이미 읽었습니다).
5단계
빌드
빌더는 통제된 클라우드 워크스페이스 내에서 코딩 에이전트(Claude Code, Codex 등)에 프롬프트를 입력하며, 절대 자신의 노트북에서 하지 않습니다. 노트북의 터미널 에이전트는 거기에 있는 모든 것(메일, 동기화된 드라이브, 브라우저 쿠키, 캐시된 자격 증명)을 상속받습니다. 워크스페이스에서 에이전트는 프로젝트만 볼 수 있습니다. 그 외에는 아무것도 없습니다.
엔지니어가 일반적으로 가지고 다니는 모든 것은 대신 레일이 담당합니다: 저희 고객의 경우, 빌더가 끌 수 없는 4개 계층의 35개 가드레일이 있습니다.
병합 계층에는 AI 생성 코드에 특화된 드리프트 검사가 포함됩니다: 파일 크기 예산, 대규모 인라인 데이터 없음, 감사 로그 준수. 통과 또는 병합 불가입니다. 검사에 실패하면 빌더는 에이전트에게 수정을 요청하고 다시 푸시합니다.
사람은 일상적인 변경 사항을 검토하지 않습니다. 검사가 검토입니다. 일상적인 변경 사항은 리뷰어의 일정 속도가 아닌 CI 속도로 이동합니다. 사람에게 도달하는 것은 기계적으로 감지된 결과적인 꼬리 부분입니다: 파괴적인 스키마 변경, 새로운 종속성, 에이전트 자체 제약 조건에 대한 변경, 인프라와 관련된 모든 것. 이러한 것들은 사람을 기다립니다. 다른 것은 그렇지 않습니다. 그리고 새로운 문제가 어쨌든 빠져나갈 때마다 해결책은 더 많은 사람의 검토가 아니라 새로운 자동 검사입니다. 시스템은 회의를 추가하는 것이 아니라 교훈을 인코딩함으로써 더 엄격해집니다.
처음에 나온 대시보드를 기억하십니까. 드리프트 검사 중 두 가지는 첫 주에 작동했을 것입니다. 80KB 단일 라인 블롭은 첫 번째 커밋에서 CI를 실패했을 것이며, 어떤 실패 모드가 굳어지기 몇 달 전이었을 것입니다.
6단계
운영 및 변경
6개월 후, 자본 출자 요청서 트래커는 여전히 실행 중이며, 여기서 라이프사이클이 그 가치를 발휘합니다. IR 부서의 누군가가 3월 공지의 송금 마감일을 질문합니다. 감사 추적이 30초 만에 답변합니다: 누가 필드를 변경했는지, 언제, 그리고 이전에 무엇이었는지, 편집 자체와 동일한 트랜잭션에 기록됩니다. 아무도 이메일 체인에서 진실을 재구성하지 않습니다. 빌더가 팀을 옮길 때 소유권은 '어깨를 으쓱'하며 사라지는 대신 지정된 후임자에게 이전됩니다. 그리고 그녀가 회사를 완전히 떠나면 그녀의 로그인이 비활성화되고 그녀가 열었던 모든 문이 동시에 닫힙니다. 트래커도 포함됩니다. 다음 분기의 기능 요청은 첫 번째 커밋과 동일한 레일을 따릅니다.
거버넌스는 연간 감사가 아닌 신호에 기반하여 실행됩니다. 트래커의 사용량 메트릭은 두 개의 추가 팀이 이를 사용하고 있음을 보여주므로, 승격되고 투자됩니다. 4월 이후로 아무도 열지 않은 통화 대시보드는 메뉴에서 썩도록 방치되는 대신 보관 처리됩니다. 아무도 이를 애도하지 않습니다. 소유권은 첫날에 할당되므로, 어떤 것도 빌더 없이 주인 없이 남지 않습니다. 앱이 진화함에 따라 문서가 자동으로 재생성되므로 결코 낡지 않습니다. 사용되지 않는 앱은 실패이지 트로피가 아닙니다. 목표는 앱 개수가 결코 아닙니다: 잊혀진 소프트웨어의 묘지가 아니라, 직원들이 실제로 신뢰하는 살아있는 카탈로그입니다.
카탈로그가 10개 앱에서 200개로 성장함에 따라 중앙 팀은 더 이상 모든 것을 주시할 수 없으며, 감독은 앱을 소유한 팀으로向外 확장되어야 합니다. 이를 언제, 어느 정도까지 연방화할지는 판단의 문제이며, 포트폴리오가 성장함에 따라 달라집니다. 여기서 거버넌스는 한 번 설정하고 잊는 통제가 아니라 지속적으로 조정해야 하는 자세입니다.
모든 것을 유지하는 규칙
저희가 모든 고객에게 가르치는 한 가지 트리거가 있습니다. 이는 "이것에 전체 프로세스가 필요한가요?"라는 질문의 90%를 해결하기 때문입니다: 두 번째 소비자 규칙. 이것이 작동하는 이유는 위험 프로필이 변하는 순간이기 때문입니다.
자신의 노트북에서 자신을 위해 제한된 데이터 액세스로 분석을 구축하는 사람이 있습니까? 낮은 블래스트 반경, 가벼운 거버넌스. 그들이 스스로 실행하는 차트, 메모 및 스크립트는 배포 파이프라인이 필요하지 않습니다. 그러나 두 번째 사람이 작성자에게 새로 고침을 요청하는 대신 출력을 직접 사용하려는 순간이 오면? 블래스트 반경이 급증합니다: 더 넓은 범위, 더 멀리 이동하는 데이터, 다른 사람이 그것이 정확하다고 신뢰합니다. 이제는 소프트웨어이며, 명시적인 이벤트로 의도적으로 전체 라이프사이클로 업그레이드됩니다. 동일한 데이터 소스, 동일한 ID, 새로운 길.
이 하나의 규칙이 프로세스가 사람들을 압도하지 않는 이유입니다. 대부분의 빌드는 결코 선을 넘지 않습니다. 선을 넘는 것은 바로 그 의식을 치를 가치가 있는 것들입니다.
솔직히 말하는 부분
어떤 플랫폼도 첫 번째 빌더가 완벽한 코드를 작성하게 만들지 않습니다. 우리는 그렇게 주장하지 않습니다. 계층은 실수가 회사 전체의 사고가 아니라 하나의 작은 경계 내에서의 불편함이 되도록 존재합니다. 각 계층은 그 위의 계층이 할 수 없는 것을 정확히 커버합니다:
그리고 감사는 아무것도 막지 않지만, 모든 사고를 짧고, 설명 가능하며, 책임 소재를 명확하게 만듭니다. 이것이 나쁜 오후와 나쁜 분기의 차이입니다.
시민 개발은 전문 엔지니어링을 대체하기 위한 것이 아닙니다. 규제된 프로세스의 기록 시스템, 고객 또는 투자자 대면 시스템, 외부 사용자를 위한 앱, 다운타임에 금전적 패널티가 따르는 모든 것: 이러한 것들은 여전히 엔지니어링의 영역이며, 프론트 도어는 첫날부터 이를 해당 경로로 라우팅합니다. 이것이 대체하는 것은 병목 지점입니다. 공식 엔지니어링 프로젝트의 가치가 없었던 내부 도구의 긴 꼬리를 민주화하고, 로드맵 큐가 결코 제공할 수 없는 속도로 출시합니다. 경계가 없는 프레임워크는 슬로건에 불과합니다. 이 프레임워크는 자신이 무엇을 위한 것이 아닌지 알고 있습니다.
실제로 바뀌는 것
투자 회사에서 플랫폼을 통과한 첫 번째 앱은 그것을 동기 부여한 앱입니다: 처음 이야기의 대시보드를 레일 위에서 다시 만든 것입니다. 동일한 화면. 동일한 빌더. 이제는 실제 스토리지, 회사 로그인, 모든 편집 기록이 있습니다. 7바이트로 자신을 자를 수 없습니다. 왜냐하면 그것을 유발한 코드 클래스가 병합될 수 없기 때문입니다.
약 10건 중 9건의 요청이 이미 자동으로 해결되며, 그 비율은 계속 증가합니다. 비기술 빌더가 만드는 대부분의 것은 본질적으로 블래스트 반경이 낮습니다. 내부, 주로 읽기 전용, 소규모 대상 도구입니다. 각 형태의 길이 입증됨에 따라, 이러한 빌드 중 더 많은 것이 루프에 사람 없이도 안전하게 프로비저닝 및 배포될 수 있습니다. 인간의 주의는 계속해서 결과적인 꼬리 부분에 집중되고 다른 곳에서는 얇아질 것입니다.
'예'는 오늘 몇 분이 걸리며, 즉시로 향하고 있습니다. '아니오'는 내장되어 있기 때문입니다.
모든 회사는 곧 수백 명의 빌더를 갖게 될 것입니다. 대부분의 회사는 여전히 그것을 두려워해야 할지 기뻐해야 할지 결정 중입니다. 승리하는 회사는 가장 많은 빌더를 가진 회사가 아닐 것입니다. 가장 좋은 길을 가진 회사가 될 것입니다.
