노코드·로우코드와 맞춤 개발, 어떤 기준으로 골라야 합니까?

만드는 비용은 낮아졌고, 운영 책임은 그대로입니다

노코드·로우코드 도구에 더해, 요즘은 원하는 화면을 문장으로 설명하면 앱을 만들어 주는 AI 앱 빌더까지 쓰입니다. 현업 담당자가 개발 부서를 거치지 않고 직접 업무 도구를 만드는 것을 시민 개발(citizen development) 이라고 부르는데, 애플리케이션 보안 분야의 국제 비영리 단체인 OWASP는 이 분야의 보안 위험 목록에서 로우코드·노코드 같은 업무 혁신 플랫폼과 함께 AI 보조 코딩과 AI 에이전트까지 다루고 있습니다. 만드는 방법이 다양해진 만큼 위험의 출처도 넓어졌다는 뜻입니다.

만드는 비용은 분명 낮아졌습니다. 그러나 누가 고치고, 누가 권한을 관리하고, 만든 사람이 떠나면 누가 이어받는가라는 질문은 어떤 도구로 만들든 그대로 남습니다. 선택 기준은 이 질문에서 출발해야 합니다.

AI 앱 빌더에는 한 가지 고려가 더 붙습니다. 화면을 설명하면 코드까지 만들어 주지만, 그 코드를 읽고 검토한 사람이 없는 상태로 운영에 들어가기 쉽습니다. OWASP 목록의 첫 항목이 맹목적 신뢰(Blind Trust) 인 것도 같은 이유입니다. 「잘 돌아간다」는 것과 「권한과 데이터가 올바르게 다뤄진다」는 것은 다른 확인이 필요합니다.

두 방식의 강점과 한계

비용을 비교할 때는 초기 비용만 보지 말고 과금 단위를 보셔야 합니다. 노코드 플랫폼은 사용자 수, 앱 수, 실행 횟수, 외부 연결 기능처럼 플랫폼마다 다른 단위로 과금할 수 있어, 사용자가 늘면 비용 구조가 달라집니다. 3년 뒤 사용자 수를 가정해 두 방식의 누적 비용 구조를 같은 표에 놓고 비교해 보시기 바랍니다.

옮기는 비용도 함께 봐야 합니다. 노코드로 만든 도구는 그 플랫폼 안에서만 동작하므로, 요금 정책이 바뀌거나 회사 표준 도구가 바뀌면 데이터는 내보낼 수 있어도 화면과 자동화 규칙은 새로 만들어야 하는 경우가 생깁니다. 처음 고를 때 데이터를 표준 형식으로 내보낼 수 있는지만큼은 확인해 두시기 바랍니다.

무엇으로 가르는가 — 사용 범위와 민감도

판단은 두 축으로 하면 빠릅니다. 누가 쓰는가(사내 일부인가, 외부 고객이나 전사인가)와 무엇을 담는가(단순한 기록인가, 개인정보·돈·핵심 업무 규칙인가)입니다.

여기에 하나를 더 봅니다. 다른 시스템과 얼마나 깊게 연결되는가입니다. 회계·ERP·그룹웨어와 데이터를 주고받아야 하고, 실패했을 때 다시 처리하는 규칙까지 필요하다면 노코드의 연결 기능만으로는 한계가 드러나기 쉽습니다.

「사내 일부 · 민감하거나 복잡함」 칸, 즉 소수가 쓰지만 민감한 데이터를 다루는 경우가 가장 애매합니다. 이때는 노코드를 금지하기보다 어떤 데이터에 어떤 계정으로 연결하는지를 정보보안 담당이 함께 승인하는 절차를 두는 편이 현실적입니다. 반대로 외부 고객이 쓰는 화면은 장애가 곧 고객 불편이 되므로, 단순한 기능이라도 운영과 장애 대응을 누가 맡는지부터 정하고 시작하셔야 합니다.

노코드에서 자주 생기는 보안 함정

OWASP 목록은 노코드 환경의 위험을 구체적으로 짚고 있습니다. 실무에서 먼저 점검할 항목은 다음과 같습니다.

• 만든 사람의 계정으로 데이터에 연결 — 앱을 쓰는 모든 사람이 만든 사람의 권한으로 데이터에 접근하게 됩니다(계정 사칭 위험)
• 과도한 연결 범위와 오래 남는 토큰 — 「모든 데이터 읽기·쓰기」 권한으로 연결한 뒤 담당자가 부서를 옮겨도 연결이 살아 있습니다
• 누가 무엇을 만들었는지 목록이 없음 — 앱과 자동화가 늘어나도 소유자와 용도를 아무도 모릅니다
• 기록이 남지 않음 — 사고가 나도 누가 언제 무엇을 했는지 추적할 수 없습니다

대응은 어렵지 않습니다. 데이터 연결은 개인 계정 대신 전용 서비스 계정과 최소 권한으로 만들고, 앱마다 소유자를 지정해 목록으로 관리하며, 퇴사·부서 이동 때 소유권을 넘기는 절차를 둡니다. OWASP도 공유 연결을 점검하고 각 앱이 필요로 하는 범위로 권한을 줄이며, 토큰을 주기적으로 재인증하도록 권고합니다.

회사 차원에서 노코드를 허용한다면 개별 앱을 검사하는 것보다 규칙을 먼저 정하는 편이 효율적입니다. 쓸 수 있는 플랫폼, 연결해도 되는 데이터 원천, 새 앱을 등록하는 절차, 쓰지 않는 앱과 연결을 정리하는 점검 주기를 한 장으로 정해 두면 현업의 속도를 해치지 않으면서 관리 공백을 줄일 수 있습니다.

둘을 섞어 쓰는 방식

둘 중 하나만 고를 필요는 없습니다. 핵심 데이터와 규칙은 맞춤 시스템에 두고, 그 시스템이 제공하는 연동 창구(API)를 통해 노코드로 화면이나 보고서를 만드는 방식이 있습니다. 이렇게 하면 기록의 원본과 권한 통제는 한 곳에 남고, 현업은 자주 바뀌는 화면을 직접 고칠 수 있습니다. 노코드 쪽에는 조회와 입력에 필요한 최소 권한만 열어 주면, 앱이 늘어나도 데이터가 여러 곳으로 흩어지지 않습니다.

노코드를 시제품으로 쓰는 방법도 있습니다. 노코드로 먼저 만들어 몇 달 써 보면 실제로 필요한 기능과 필요 없는 기능이 드러나고, 그 결과를 요구사항으로 정리해 맞춤 개발로 옮기면 처음부터 설계할 때보다 범위를 정확하게 잡을 수 있습니다. 이때 시제품이 그대로 운영 도구로 굳지 않도록, 언제까지 쓰고 무엇이 확인되면 옮길지를 처음에 정해 두는 편이 좋습니다.

참고 자료

• OWASP Citizen Development Top 10
• OWASP CD-SEC-03: Authorization Misuse