LLM 시대, 로우코드는 어떤 의미가 있을까?

ChatGPT 3.5 출시 이후, Copilot, Cursor 같은 AI 코딩 도구가 개발자 손에 들어오면서 많은 질문이 생겼습니다. 그중 생각해볼만한 질문은 바로 이것입니다.

“이제 운영툴 같은 건 다 AI가 대신 짜줄 수 없을까?”

초기 boilerplate 세팅, 버튼 하나 추가, 컬럼 노출 조건 변경 같은 요청들을 진행하면 LLM이 금방 코드로 만들어줄 수 있습니다. 실제로 많은 개발자가 이런 작은 단위의 작업을 맡겨 본 경험이 있을 것입니다.

LLM 코딩에 대한 일부 연구에서 개발 속도를 약 55% 향상시킨 긍정적 효과가 보고된 반면(GitHub Copilot 연구), 또 다른 무작위 실험에서는 숙련된 개발자의 작업을 오히려 19% 늦추는 결과도 확인되는 등(METR 연구) 연구에 따라 상반된 결과가 나오고 있기도 합니다.

운영툴 변경의 실제 비용

운영툴을 직접 개발해본 사람이라면 압니다. 문제는 코드 몇 줄이 아니라, 그 코드가 얽혀 있는 맥락입니다.

예를 들어, “승인 버튼을 임원도 보이게 해달라”는 요청이 들어왔다고 해봅시다. 코드로만 보면 아주 간단합니다.

// routes/orders.js
router.post("/orders/:id/approve", async (req, res) => {
  const orderId = req.params.id;
  await db.run("UPDATE orders SET status='APPROVED' WHERE id=?", [orderId]);
  res.json({ ok: true });
});

이 정도라면 LLM에게 물어봐도 금방 똑같은 코드를 짜줄 겁니다.

하지만 실제 운영 환경은 여기서 끝나지 않습니다.

• 권한 체크: 누가 버튼을 눌렀는지, 눌러도 되는 권한이 있는지
• 감사 로그: 누가 언제 승인했는지 기록이 남는지
• UI 조건: 버튼이 어떤 상황에서만 노출되는지

심지어 구현 위치도 흩어져 있습니다.

• 권한 체크는 /middleware/permissions.js
• 감사 로그는 /middleware/audit.js
• 버튼 노출 조건은 /client/components/ApprovalList.vue

결국 버튼 하나 수정하려 해도 여러 파일과 레이어를 건드려야 합니다. LLM이 코드를 대신 써줄 수는 있지만, 이 사이드이펙트와 맥락 전체를 관리하는 책임은 여전히 개발자 몫입니다.

LLM이 주는 도움과 한계

이럴때 LLM은 도움이 됩니다.

• 단순 CRUD 코드
• 반복적인 테스트 코드
• 포맷팅이나 문법 오류 수정

이런 작업들은 AI가 빠르게 처리해줍니다. 하지만 운영툴의 문제는 속도뿐 아니라 일관성과 정책에 대한 것도 있습니다.

• DB 트랜잭션 처리: 롤백 조건은 제대로 되어 있는가?
• 권한 체크: 기존 권한 시스템과 일관되게 적용되는가?
• 감사 로그: 모든 기록 체계가 유지되는가?
• UI 조건: 버튼과 컬럼 노출이 기존 규칙과 충돌하지 않는가?

결국 LLM이 코드를 짜주더라도, 검토해야 할 범위는 줄지 않는다는 게 핵심입니다.

로우코드(Low code)의 역할: 검토 범위 줄이기

같은 요청을 로우코드 스펙으로 표현하면 이렇게 해볼 수 있습니다.

actions:
- name: approve
  type: http
  log: 승인처리 id={{id}} actor_email={{email}}
  roles:
    edit:
      - 임원
      - 개발팀장

이 단순한 스펙 정의 안에는 이미 세 가지가 포함돼 있습니다.

• roles → 권한 관리
• log → 로그 자동 기록
• UI 노출 → 버튼 정의에서 일관 관리

로우코드는 반복적이고 공통적인 문제를 시스템이 대신 책임지도록 만드는 도구입니다. 여기서 중요한 건 단순히 코드를 줄인다는 게 아니라, 개발자가 검토해야 할 범위를 줄여준다는 점입니다.

로우코드는 SaaS다

로우코드를 도입한다는 건 사실상 다른 SaaS를 도입하는 것과 같습니다.

• AWS를 쓴다고 해서 서버 운영을 대충 하는 게 아니듯
• Slack을 쓴다고 해서 협업을 소홀히 하는 게 아니듯
• 로우코드를 쓴다고 해서 운영툴을 허술하게 만든다는 게 아닙니다.

오히려 로우코드는 권한, 로그, UI 조건 같은 운영툴의 공통 문제를 SaaS 수준에서 해결하는 선택입니다.

많은 개발자가 “보안이나 권한은 직접 구현해야 안전하다”라고 생각합니다. 하지만 실제로는 반대가 도움이 되는 경우도 많습니다.

• 코드 중심 접근: 개발자가 매번 권한 체크 로직을 짜다 보니 누락·불일치 리스크 발생
• 로우코드 접근: roles 정의를 통해 시스템 차원에서 일관성 향상

LLM과 로우코드: 역할의 차이

여기서 LLM과 로우코드의 차이가 명확해집니다.

• LLM: 코드를 대신 작성해주는 도구. 즉, 속도 향상.
• 로우코드: 반복적 요소(권한, 로그, UI 조건)를 아예 시스템이 내장. 즉, 검토 범위 축소.

LLM은 코드 작성 자체를 빠르게 해주지만, 로우코드는 코드가 얽힌 맥락을 줄여주는 가드레일이 됩니다.

코드와 로우코드의 보완 관계

물론 로우코드만으로 모든 걸 해결할 수는 없습니다. 실제로는 두 방식을 병행하는 게 가장 현실적입니다.

• 로우코드: 반복적 요청, 단순한 UI/권한/로그 처리
• 코드: 복잡한 비즈니스 로직, 고도의 최적화가 필요한 부분

Git 워크플로우 안에 로우코드 스펙을 포함할 수도 있습니다. 즉, 코드 리뷰·배포 프로세스와 충돌 없이 관리할 수 있다는 뜻입니다.

두 방식은 경쟁 관계가 아니라, 각자의 장단점을 활용하는 보완 관계입니다.

언제 로우코드를, 언제 코드를?

실무에서는 이런 질문과 비교표로 판단해볼 수 있습니다.

• 보안·권한 이슈인가? → 로우코드 권한 체계로 흡수 가능한가?
• UI 조건/노출 조정인가? → 스펙 수정으로 충분한가?
• 단기 대응 vs 장기 로직인가? → 단기는 로우코드, 장기는 코드로.
• 운영팀/PM도 리뷰해야 하는가? → YAML 기반 로우코드는 협업에 유리하다.

코드 vs 로우코드 비교 표

로우코드는 여전히 의미가 있을까?

정리하면 이렇습니다.

• LLM은 코드를 빨리 짜주지만, 운영툴 변경의 본질적 문제—검토와 책임—을 해결하지 못합니다.
• 로우코드는 반복적이고 공통적인 운영 문제를 SaaS 차원에서 흡수하여, 개발자가 검토해야 할 범위를 줄여줍니다.

따라서 로우코드를 도입한다는 건 곧 “반복적 운영 문제는 시스템이 대신 처리하게 하고, 개발자는 본질적인 서비스 가치와 문제 해결에 집중한다”는 선택입니다.

LLM 시대에도 로우코드가 여전히 의미 있는 이유는 바로 여기에 있습니다. 궁극적으로 중요한 건, 지금 개발자의 시간을 어디에 쓸 것인가입니다.