소프트웨어 제작의 문턱이 낮아지고 있다
오랫동안 소프트웨어 개발은 전문 개발자의 영역으로 여겨졌다. 요구사항을 정리하고, 개발팀에 요청하고, 우선순위를 기다리고, 몇 주나 몇 달 뒤에 결과물을 확인하는 방식이 일반적이었다. 하지만 업무 현장의 문제는 그렇게 천천히 움직이지 않는다. 영업팀은 고객 후속 관리용 작은 앱이 필요하고, 인사팀은 온보딩 체크리스트를 자동화하고 싶어 한다. 재무팀은 승인 흐름을 추적하고, 공장 관리자는 현장 점검 데이터를 모바일로 받고 싶어 한다.
로우코드와 노코드는 이 간격을 줄인다. 로우코드는 최소한의 코드와 시각적 구성 요소로 앱을 만드는 방식이고, 노코드는 코딩을 거의 하지 않고 드래그 앤드 드롭, 템플릿, 워크플로 설정만으로 앱과 자동화를 만드는 방식이다. 여기에 AI 보조 개발이 결합되면 사용자는 자연어로 "고객 불만 접수 양식을 만들고, 담당자에게 알림을 보내며, 처리 상태를 대시보드로 보여줘"라고 지시할 수 있다. AI는 화면 초안, 데이터 필드, 업무 흐름, 일부 코드까지 생성한다.
이 변화의 핵심은 개발자가 사라진다는 뜻이 아니다. 소프트웨어를 만드는 사람이 넓어진다는 뜻이다. IT 민주화는 IT 자원과 지식, 도구를 더 많은 사람에게 개방하고, 디지털 솔루션의 책임을 IT 부서만이 아니라 비즈니스 오너와 함께 나누는 흐름이다1. 현업 전문가는 문제의 맥락을 가장 잘 안다. 따라서 적절한 도구와 안전장치가 주어지면 작은 업무 문제를 직접 소프트웨어로 바꿀 수 있다.
AI 생성 이미지
도구는 역량을 대체하지 않고 증폭한다
로우코드, 노코드, AI 보조 개발은 진입장벽을 낮춘다. 그러나 이것만으로 성과가 보장되지는 않는다. 좋은 플랫폼을 도입했는데도 앱이 방치되거나, 비슷한 자동화가 부서마다 중복되거나, 중요한 데이터가 잘못 연결되는 일이 생길 수 있다. 이유는 단순하다. 도구는 조직의 역량을 대신하지 않는다. 기존의 협업 방식, 데이터 품질, 보안 습관, 업무 정의 능력을 더 크게 드러낸다.
AI 보조 소프트웨어 개발에 관한 DORA의 2025년 보고서도 AI를 '증폭기'로 설명한다. AI는 조직이 이미 잘하는 것을 더 빠르게 만들지만, 약한 구조도 함께 확대한다2. 요구사항이 불분명하면 AI가 만든 결과도 불분명하다. 테스트 문화가 약하면 자동 생성된 코드의 결함이 그대로 운영으로 넘어간다. 데이터 소유권이 모호하면 시민 개발자가 만든 앱은 편리하지만 위험한 도구가 된다.
따라서 로우코드 전략은 "누구나 앱을 만들 수 있다"에서 멈추면 안 된다. 더 중요한 질문은 "누가 어떤 범위에서, 어떤 데이터로, 어떤 승인 절차를 거쳐, 어떤 책임을 지고 만들 것인가"이다. 민주화는 무질서가 아니다. 좋은 민주화는 접근성을 높이면서도 책임의 경계를 분명히 한다.
시민 개발자는 현장의 병목을 푼다
시민 개발자는 전문 개발자는 아니지만, 승인된 플랫폼을 활용해 업무용 앱과 자동화를 만드는 현업 사용자다. 예를 들어 인사 담당자가 신규 입사자 제출 서류를 자동으로 확인하는 앱을 만들 수 있다. 영업 운영 담당자는 계약 갱신일이 다가온 고객을 자동으로 표시하는 대시보드를 만들 수 있다. 품질 관리자는 공장 점검 결과를 모바일 양식으로 받고, 이상 항목을 즉시 담당자에게 전달하는 흐름을 구성할 수 있다.
이런 앱은 대규모 핵심 시스템이 아니다. 하지만 현장에서는 매우 중요하다. 엑셀 파일, 이메일, 메신저, 수기 확인으로 이어지던 반복 업무를 줄이고, 업무 상태를 한눈에 보이게 만든다. 작은 자동화가 쌓이면 IT 대기열도 줄어든다. 개발팀은 단순 양식, 알림, 승인 흐름 요청에 매달리는 대신 핵심 시스템 설계, 데이터 통합, 보안 아키텍처 같은 고부가 업무에 집중할 수 있다.
시민 개발의 효과는 속도만이 아니다. 문제를 가장 잘 아는 사람이 해결책을 직접 설계하면서 제품 소유권이 강해진다. 현업은 더 이상 "IT가 만들어주지 않는다"고 불평만 하지 않는다. 대신 자신이 원하는 결과, 필요한 데이터, 사용자 흐름, 운영 책임을 함께 정의해야 한다. 이때 비즈니스 부서는 기술 소비자에서 디지털 솔루션의 공동 책임자로 바뀐다.
성공은 플랫폼이 아니라 운영 모델에서 갈린다
시민 개발 프로그램은 단순한 툴 도입 프로젝트가 아니다. 조직 차원의 운영 모델이다. 먼저 경영진, IT, 현업이 목표를 공유해야 한다. 왜 시민 개발을 하는가. IT 비용을 줄이기 위해서인가, 업무 속도를 높이기 위해서인가, 현장 혁신을 확산하기 위해서인가. 목표가 불명확하면 각 부서는 플랫폼을 제각각 사용하고, 나중에는 관리하기 어려운 앱 더미만 남는다.
딜로이트는 시민 개발 성공 조건으로 조직 정렬, 인재 성장 경로, 통합 거버넌스, 일관된 과제 접수·평가 방식, 적절한 파트너십을 제시한다3. 여기서 중요한 점은 시민 개발자를 아무나 많이 늘리는 것이 아니라, 역할과 수준을 구분하는 것이다. 모든 현업 직원이 앱 제작자가 될 필요는 없다. 어떤 사람은 자동화 아이디어를 내는 사용자이고, 어떤 사람은 간단한 워크플로를 만드는 제작자이며, 어떤 사람은 부서 내 챔피언으로 동료를 돕는다.
변화 전파자도 필요하다. 새로운 도구가 들어오면 기대와 불안이 동시에 생긴다. "내 일이 대체되는 것 아닌가", "IT 승인 없이 만들어도 되는가", "문제가 생기면 누가 책임지는가" 같은 질문이 나온다. 현장 챔피언은 이런 혼란을 줄인다. 이들은 업무 언어와 기술 언어를 모두 이해하고, 작은 성공 사례를 주변으로 확산시킨다.
또 하나의 핵심은 CoE, 즉 전문 지원 조직이다. 시민 개발 CoE는 플랫폼 사용 기준, 교육 자료, 템플릿, 보안 가이드, 승인 절차, 재사용 가능한 컴포넌트를 제공한다. 중앙에서 모든 것을 통제하기보다, 현업이 안전하게 움직일 수 있는 포장도로를 깔아주는 역할이다.
빠른 개발에는 빠른 위험도 따라온다
로우코드와 노코드의 장점은 빠른 제작이다. 그러나 빠른 제작은 빠른 위험을 낳을 수 있다. 고객 정보가 들어간 앱이 권한 설정 없이 공유될 수 있다. 여러 부서가 비슷한 데이터를 각자 복사해 쓰면서 숫자가 달라질 수 있다. 만든 사람이 퇴사한 뒤 앱의 구조를 아무도 모를 수 있다. 작은 내부 앱이 어느 날 핵심 업무에 쓰이기 시작했는데 백업, 모니터링, 장애 대응 체계가 없을 수도 있다.
이것이 그림자 IT의 문제다. 그림자 IT는 공식 IT 관리 밖에서 만들어지고 사용되는 시스템이다. 처음에는 빠르고 유용해 보인다. 하지만 보안 취약점, 컴플라이언스 위반, 데이터 무결성 훼손, 중복 시스템, 운영 책임 공백으로 이어질 수 있다. 특히 AI 보조 기능이 결합되면 사용자는 더 쉽게 앱을 만들지만, 자신이 만든 로직이 어떤 데이터를 읽고 어디로 전송하는지 충분히 이해하지 못할 수 있다.
따라서 거버넌스는 나중에 붙이는 장식이 아니다. 시작 단계부터 설계해야 한다. 첫째, 앱의 위험 등급을 나눈다. 개인 생산성 도구, 부서 내부 앱, 고객 데이터 처리 앱, 핵심 운영 앱은 같은 기준으로 관리할 수 없다. 둘째, 데이터 접근 기준을 정한다. 어떤 데이터는 조회만 가능하고, 어떤 데이터는 마스킹해야 하며, 어떤 데이터는 시민 개발 앱에서 사용할 수 없도록 해야 한다. 셋째, 배포 승인 절차를 둔다. 모든 앱을 무겁게 심사할 필요는 없지만, 일정 수준 이상의 사용자 수나 민감 데이터를 다루는 앱은 IT와 보안 검토를 받아야 한다.
넷째, 모니터링과 수명주기 관리를 해야 한다. 누가 만들었는지, 누가 사용하는지, 어떤 데이터와 연결되어 있는지, 마지막으로 업데이트된 시점이 언제인지 기록해야 한다. 사용되지 않는 앱은 정리하고, 중요도가 높아진 앱은 전문 개발팀이 재설계하거나 기업 표준 시스템으로 승격할 수 있어야 한다. 시민 개발은 임시방편이 아니라 성장 경로를 가져야 한다.
IT 부서는 코딩 대행자에서 거버넌스 파트너로 이동한다
이 변화 속에서 전문 개발자와 IT 부서의 역할은 줄어들지 않는다. 오히려 더 중요해진다. 다만 역할의 중심이 바뀐다. 과거 IT는 현업의 요청을 받아 기능을 대신 만들어주는 조직으로 보이기 쉬웠다. 앞으로 IT는 플랫폼 선정자, 아키텍처 설계자, 시스템 통합자, 데이터·보안 관리자, 품질 검증자, 시민 개발자 교육자로 움직여야 한다.
전문 개발자는 시민 개발자가 만들기 어려운 영역을 맡는다. 복잡한 시스템 연동, 대규모 트랜잭션 처리, 성능 최적화, 보안 설계, API 표준화, 데이터 모델링은 여전히 전문성이 필요하다. 동시에 현업이 안전하게 활용할 수 있는 표준 커넥터, 재사용 가능한 컴포넌트, 승인된 템플릿을 제공해야 한다. 개발자는 모든 앱을 직접 만드는 사람이 아니라, 더 많은 사람이 좋은 앱을 만들 수 있도록 기반을 설계하는 사람이 된다.
현업도 책임을 져야 한다. 자신이 만든 앱의 업무 목적, 사용자, 데이터 의미, 운영 규칙을 설명할 수 있어야 한다. "도구가 만들어줬다"는 말은 책임 면제가 될 수 없다. AI가 코드를 생성했든, 노코드 플랫폼이 화면을 만들었든, 그 앱이 업무에 영향을 준다면 사람이 검토하고 승인해야 한다.
소프트웨어는 더 많은 사람의 언어가 된다
로우코드, 노코드, AI 보조 개발이 만드는 가장 큰 변화는 소프트웨어가 조직의 공통 언어가 된다는 점이다. 과거에는 현업이 문제를 문서로 설명하고 개발자가 시스템으로 번역했다. 이제는 현업이 직접 프로토타입을 만들고, 개발자와 함께 개선하며, 데이터와 프로세스를 더 구체적으로 논의할 수 있다. 추상적인 요구사항보다 작동하는 초안이 대화를 빠르게 만든다.
물론 모든 앱을 시민 개발로 만들 수는 없다. 고객에게 직접 노출되는 핵심 서비스, 금융 거래, 의료 데이터 처리, 대규모 공급망 시스템은 높은 수준의 엔지니어링과 통제가 필요하다. 그러나 모든 문제를 전문 개발팀의 대기열에 올릴 필요도 없다. 중요한 것은 구분이다. 작은 문제는 현업이 빠르게 해결하고, 커지는 문제는 IT와 함께 확장하며, 핵심 문제가 되면 전문 시스템으로 승격한다.
앞으로 경쟁력 있는 조직은 개발자를 더 많이 고용한 조직만이 아니다. 문제를 소프트웨어로 표현할 수 있는 사람이 많은 조직이다. 현업은 문제의 맥락을 알고, IT는 안전한 기술 기반을 제공하며, AI는 제작 속도를 높인다. 이 세 가지가 맞물릴 때 시민 개발은 그림자 IT가 아니라 조직 전체의 디지털 실행력이 된다.
참고
1IT democratization: Benefits and challenges
2DORA | State of AI-assisted Software Development 2025
3Accelerate software development utilizing citizen developers
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.