Low Code Platform 6편) 로우코드 도입 사전 Checklist

 

로우코드 도입을 검토하는 조직이 가장 먼저 해야 할 일은

플랫폼 비교가 아니라 질문 정리다.

어떤 질문을 먼저 던지느냐에 따라

성공적인 도입이 될 수도, “또 하나의 툴 실험”으로 끝날 수도 있다.

---

▶ 어디에 쓸 것인가: 대상 업무 정의

첫 번째 질문은 단순하다.

"이 플랫폼을 어디에 쓸 것인가"

 

여기에 답하지 못한 상태에서 “요즘 다 쓴다니까” 수준으로 들어가면 실패 확률이 매우 높다.

• 코어 시스템을 대체할 것인가
• 주변 업무 시스템을 만들 것인가
• 내부용 앱 위주인가, 대외 서비스도 포함인가
• PoC 차원의 실험인가, 전사 전략의 일부인가

이 질문에 답을 먼저 정리해야 한다.

 

일반적으로는 주변 업무, 내부 행정·포털, 빠르게 바뀌는 프로세스부터 시작하는 것이 안전하다.

다음은 App을 선택하는데 있어서 중요도를 선택하는 기준 예시이다.

 

Governance: the missing but critical link in no-code/low-code development

---

▶ 누가 만들고, 누가 운영할 것인가

두 번째 질문은 역할에 대한 것이다.

• 개발 주체는 IT 부서인가, 현업 부서인가, 혼합 모델인가
• 아키텍처와 표준을 정하는 조직(거버넌스)은 누구인가
• 운영·유지보수는 누가 책임지는가

이 부분이 흐릿하면 시간이 지날수록 시스템이 흩어지고 중복된다.

엔터프라이즈 환경에서는 보통 다음과 같은 모델이 많이 쓰인다.

• 중앙의 Center of Excellence(CoE) 또는 IT 아키텍처 팀이 표준·가이드·템플릿을 만든다.
• 개발은 IT 부서와 각 실무팀이 협력하여 수행한다.
• 운영은 IT 부서에서 담당하되, 경미한 변경은 실무팀이 직접 수행할 수 있게 한다.

---

▶ 기존 IT 체계와 어떻게 연결할 것인가

세 번째 질문은 통합이다.

• 기존 ERP, CRM, 레거시 시스템과의 연계 범위
• 인증·SSO, 권한 체계와의 연계
• 데이터 거버넌스 정책과의 정합성

로우코드로 만든 앱이

“섬처럼 따로 노는 시스템”이 되면 곤란하다.

플랫폼 도입과 동시에

• 공통 통합 방식(API, 메시지, DB 접근 등)을 정하고
• 인증·권한 방식(SSO, Role 기반 등)을 표준화해야 한다.

---

▶ 장기 유지보수 관점에서의 설계

네 번째 질문은 시간에 대한 것이다.

• 3년 뒤에도 유지될 시스템인가, 1년짜리 실험인가
• 담당자가 바뀌어도 유지 가능한 구조인가
• 여러 팀이 함께 만들어도 이해 가능한 아키텍처인가

로우코드는 빠르게 만들 수 있지만, 그렇다고

“빨리 만들었으니 빨리 버려도 된다”는 뜻은 아니다.

 

초기 설계 단계에서부터

• 모듈 구조
• 네이밍 규칙
• 재사용 가능한 컴포넌트
• 공통 라이브러리

를 고민하는 것이 중요하다.

---

▶ 조직 문화와 기대치 관리

마지막으로 중요한 것은 기대치 관리다.

• 로우코드가 들어오면 모든 개발이 쉬워질 것이라는 과도한 기대
• 반대로 “이건 가벼운 툴일 뿐”이라는 과소 평가

둘 다 위험하다.

 

로우코드는 적절한 문제에 써야 최고의 효과가 나온다.

이 연재에서 정리했던 것처럼,

• 코어 시스템은 그대로 두고
• 변화가 잦고, 현장과 밀착된 영역에
• 빠르게 설계하고 구현하고 개선하는 도구로

위치를 잡아야 한다.

---

▶ 로우코드를 도입할 때 가장 중요한 것은 다음 두가지 질문에 대한 답이다.

 

"어떤 문제를 풀기위해 도입하는가"

&

"누가 책임지고 설계/운영할 것인가"

 

플랫폼 및 기능 비교는 그 이후의 테스크이다.