서문

1회와 2회에서는 EUC와 카미 엑셀이 단기적으로는 현장을 구하면서도 장기적으로는 조직에 부정적 유산을 남긴 역사를 확인했다. 이번 글에서는 시점을 현재로 옮겨 현대 시민 개발 플랫폼인 RPA와 노코드·로우코드의 빛과 그림자를 살펴본다.

이들은 카미 엑셀의 재연이자, 규모와 의존도의 관점에서 더 큰 위험을 품고 있다. 다음 편에서 생성 AI의 충격을 생각하기 위해서도, 먼저 이 특성을 정확히 파악해야 한다.

시리즈 전체

빛──왜 받아들여졌는가

즉효성

코드를 작성하지 않아도 GUI 조작만으로 간단한 자동화나 앱이 금세 완성된다. 일일 전표 입력이나 정형 처리를 며칠 만에 대체하는 효과는 현장에 엄청나다.

가시화의 설득력

플로차트나 화면 설계를 눈으로 확인할 수 있는 형태로 보여 줄 수 있으니, 전문지식이 없는 사람도 이해하기 쉽다. 경영진에게는 “움직이는 그림”으로 성과가 보이는 것이 큰 안심감을 주어 도입을 밀어붙이는 결정 요인이 된다.

시민이 내딛는 첫걸음

입력 폼이나 간단한 워크플로처럼 제한된 용도라면 비엔지니어도 직접 만들 수 있다. 이 수준에서는 “누구나 할 수 있다”는 감각이 살아나고, 조직 전체에 시민 개발의 저변을 넓히는 입구가 된다.

그림자 (1)──실무에서 마주치는 “전문가의 벽”

겉보기에는 “누구나 다룰 수 있다”처럼 보이지만, 실무에 본격적으로 적용하려 하면 결국 프로그래밍과 동등한 사고방식과 시스템 엔지니어링 시각이 요구된다.

  • 제어 구조의 필연성
    고객 조건마다 처리를 나누려면 조건 분기(If/Else)가 필요하다. 수백 건의 데이터를 다루려면 반복(ForEach)이 필수다. 외부 시스템의 응답 지연이나 오류에 대비하려면 예외 처리(Try/Catch)가 꼭 들어간다. GUI로 배치할 수 있을 뿐 본질적으로는 프로그래밍이다.

  • 데이터 구조의 이해
    JSON과 배열을 펼치고, 계층을 매핑하고, 날짜와 숫자의 형식을 맞추는 작업은 업무 연계에 필수다. 단순히 표 형태로 바꾸는 것으로 끝나지 않으며, 데이터 구조를 이해하지 못하면 곧바로 무너진다.

  • 시스템 간 연계의 복잡성
    API 인증 만료 관리, 복수 시스템을 가로지르는 일관성 유지, 레이트 리밋 회피 등 기존 소프트웨어 공학과 동일한 과제가 그대로 등장한다. GUI가 가려 줄 뿐 난이도는 오히려 높다.

  • 운영과 품질 요구사항
    모니터링, 로그 수집, 테스트·본운영 환경의 차이 관리, 배포 시 롤백 등 운영 설계가 빠지면 곧 혼란이 찾아온다. 코드를 기준으로 관리하지 못하는 만큼 관찰 가능성도 떨어지기 쉽다.

이런 벽 앞에서 시민 개발자가 혼자 실무를 버틸 시스템을 구축·유지하기는 어렵고, 결국 전문 기술자에게 기대게 된다. 전문가 조직의 용량 문제는 해결되지 않은 채 말이다.

그림자 (2)──벤더 락인과 이식의 어려움

카미 엑셀에는 아직 구제책이 있었다. 어디까지나 하나의 파일이었기 때문이다. 표 형식 데이터는 CSV로 내보낼 수 있었고, 함수와 매크로는 Excel에 묶여 있었지만 부분적으로라도 호환되는 스프레드시트 소프트웨어가 존재했으며, 코드나 수식을 읽어낼 수도 있었다.
반면 RPA와 노코드·로우코드의 산출물은 대부분 플랫폼 고유의 UI와 설정 파일 안에 갇힌다.

  • 다른 제품으로의 이동은 사실상 “처음부터 다시 만들기”에 가깝다.
  • SaaS의 서비스 종료나 사양 변경은 이용자가 통제할 수 없고, 축적한 자산이 하룻밤 사이에 무가치해질 수 있다.
  • PaaS 위에서 구축하면 그 클라우드 생태계에 묶여 다른 환경으로 옮기기가 극도로 어렵다.
  • 코드를 쓰지 않고 UI로 로직을 정의하면 문제 지점을 찾아내거나 검색하기 힘들어진다.
  • 도구 설계에 따라서는 구성요소를 더블클릭해야만 내부 처리를 확인할 수 있는 등 가독성을 떨어뜨리는 구조도 흔하다.

이처럼 스프레드시트 파일 하나로 끝났던 카미 엑셀과 비교해도, 의존도와 부채화 위험은 훨씬 크다.

그림자 (3)──경영진을 현혹하는 “가시화 편향”

기술자의 눈에는 “실무에서 마주치는 ‘전문가의 벽’”에 결국 부딪힌다는 것이 명백하다. 그러나 경영진은 GUI로 그린 흐름도나 화면을 보여 주면 “이 정도면 누구나 쓰겠지”라고 생각하기 쉽다.

왜일까. 경영진에게 시스템은 대개 블랙박스이고, 그 위에 화살표로 연결된 업무 프로세스나 입력 폼이 늘어서 있으면 내부의 복잡성을 이해한 것 같은 착각을 하기 때문이다. 하지만 실제로 그 뒤에서 벌어지는 것은 프로그램과 똑같은 제어 로직과 오류 처리이며, 실무에 적용해 버틸 구조로 만들려면 엔지니어링 지식이 필수다.

이 “경영진의 안도감”과 “기술자의 우려” 사이의 격차가, 도입을 가속하면서도 장차의 부채를 키우는 온상이 된다.

카미 엑셀 2.0의 시대로

정리해 보면 RPA와 노코드·로우코드는 카미 엑셀과 동일한 패턴을 되풀이한다. 즉효성으로 현장을 구하고, 가시화로 경영진을 설득하며, 결국 블랙박스화와 개인 의존으로 조직에 짐을 남긴다.

단, 결정적으로 다른 점은 그 영향 범위다. 카미 엑셀은 파일 단위로 끝났지만 현대 시민 개발은 클라우드와 전사 업무에 얽혀 조직 전체를 묶어 버리는 부채가 될 수 있다. 게다가 Excel보다 훨씬 강한 락인 구조까지 지니고 있다. 이것이 바로 “카미 엑셀 2.0”이라 부를 만한 상황을 부른다.

요약

  • RPA와 노코드·로우코드는 즉효성과 가시화의 설득력으로 현장과 경영진 모두에게 받아들여졌다.
  • 그러나 실무를 버티려면 제어 구조·데이터 구조·시스템 연계·운영 설계 같은 소프트웨어 공학 지식이 필수이고, 시민 개발자만으로는 구축·유지가 어렵다.
  • 플랫폼 고유 UI는 이식을 극도로 힘들게 만들며 벤더 락인을 강화한다.
  • 경영진의 “가시화 편향”은 이러한 위험을 과소평가하게 만든다.

결국 현대 시민 개발은 카미 엑셀보다 강력하면서도, 실상은 카미 엑셀보다 더 위험하다. 다음 편에서는 여기에 생성 AI가 더해지면 무엇이 벌어지는지 살펴본다.

다음 글: 생성 AI가 시민 개발에 미치는 영향 4/7