‘자동화’가 역효과를 일으키는 6가지 이유

AI와 로우코드 도구가 알아서 기업 인프라를 운영하고, 사람 직원은 수영장에서 느긋하게 쉬는 모습을 상상해 본 적 있는가? 만약 웹 앱의 한 섹션을 다시 디자인하기로 한다면, ‘수영장을 떠나지 않은 채’ 몇 가지 명령어만 입력하면 된다. 필요한 코드가 완벽하게 생성돼 실행되고, 모든 부분이 제대로 돌아간다! 

달콤한 상상이지만, 현실은 찬물을 끼얹는다. 아직은 사람의 개입 없이 원활하게 실행되는 도구가 없다. 물론 가끔은 잘 된다. 코드 완성이 정확하게 되거나, 자동화된 시퀀스가 서버 부하 매개변수를 즉석에서 조정한다. 하지만 실패했을 때의 결과는 단순히 불편한 정도에 그칠 수도 있고, 재해 수준으로 심각할 수도 있다. 

자동화는 많은 부분에서 유용하지만, 반대로 많은 부분에서 일을 망치기도 한다. 자동화가 잘못된 길로 갈 수 있는 6가지 방법을 소개한다. 
 

 

가비지 수집

이론적으로 메모리 할당은 사람이 걱정할 필요가 없는 문제다. 오늘날 대부분의 언어에는 메모리 조각을 할당하고, 메모리 조각에 포함된 데이터가 더 이상 필요하지 않을 때 이를 정리하는 계층이 있다. 따라서 개발자는 시간을 절약해 더 중요한 일에 집중할 수 있다.

가비지 수집은 자동으로 이뤄지기 때문에, 메모리 누수는 이제 과거의 일이라고 생각할 수 있다. 확실히 예전보다 줄어들기는 했다. 하지만 더 이상 사용되지 않는 객체가 회수되지 않고 계속 누적될 수 있다. 더 큰 문제는 개발자가 메모리 누수를 더 이상 자신이 신경 써야 할 일이 아니라, 가비지 수집기가 해야 할 일이라고 생각한다는 점이다. 따라서 잘못 할당된 데이터를 찾는 대신, 그냥 클라우드 서버의 RAM 용량을 늘린다. 이미 정리됐어야 할 데이터 구조로 채워진 클라우드 RAM이 얼마나 될까?

자동화된 메모리 관리에는 다른 문제도 있다. 객체 할당은 코드에서 시간을 많이 잡아먹는 요인이다. 똑똑한 개발자는 프로그램 시작 시 하나의 객체를 할당한 다음, 이 객체를 계속 재사용하면 코드가 더 빠르게 실행된다는 사실을 안다. 즉, 가비지 수집기가 아무 작업도 하지 않도록 설정하는 셈이다.
 

인터프리터 코드

다양한 스크립팅 언어가 코딩의 문턱을 낮추면서 이제는 코드 몇 줄만 입력하면 쉽게 코딩할 수 있다. 상대적으로 단순한 접근 방식 덕분에 전업 개발자뿐만 아니라 관련 분야(예 : 데이터 과학 등)에서도 많은 팬이 생겼다. 파이썬이 현재 가장 많이 배우는 프로그래밍 언어가 된 것에는 그만한 이유가 있다. 

하지만 인터프리터 언어를 사용하기 쉽게 해주는 자동화는 비효율성과 보안 문제를 야기할 수도 있다. 인터프리터 언어는 일반적으로 속도가 느리다(때로는 심하게 느릴 때도 있다). 자동화된 메모리 관리, 짧은 최적화 시간, 느린 런타임 해석 속도가 결합되면 코드의 속도가 현저히 느려질 수 있다.

성능이 뛰어난 JIT(Just-In-Time) 컴파일러를 활용하면 개선할 수 있다. 파이썬 개발자는 자바 기반 JIT 컴파일러가 내장된 자이썬(Jython)을 쓸 수 있다. PHP와 파이썬에도 자체 JIT 컴파일러(파이파이(PyPy), 넘바(Numba), 피스톤(Pyston) 등)가 있지만 인터프리터가 할 수 있는 일에는 여전히 한계가 있다.

일각에서는 인터프리터 코드의 보안이 취약하다고 주장한다. 컴파일러는 코드를 검토하는 데 많은 시간을 할애하는 반면, 인터프리터는 그 반대 방향, 즉 ‘제시간에’ 결과를 내놓는 데 주력하기 때문이다. 또 인터프리터 언어에서 널리 사용되는 동적 타이핑은 주입 공격 또는 기타 공격을 실행하기 쉽게 만들 수 있다. 물론 컴파일된 코드도 취약할 수 있다. 모든 개발자는 어떤 언어를 사용하든 방심하지 말아야 한다.
 

인공지능

인공지능은 자동화보다 훨씬 더 큰 주제다. AI는 모두의 기대를 뛰어넘는 모습을 보여주지만, 처음의 ‘신기함’이 사라지면 AI가 내놓는 결과물은 단조롭고 반복적으로 느껴지는 경우가 많다. 대규모 언어 모델(LLM)은 기본적으로 학습 세트의 방대한 평균치이기 때문에 당연한 현상이다.

때때로 AI는 역효과를 일으키기도 한다. AI 시스템은 문법적으로 완벽한 문장과 잘 구성된 단락을 쏟아내다가 갑자기 환각을 일으켜 멋대로 지어낸 이야기를 사실처럼 출력한다. 설상가상으로 AI는 실존하는 개인에 대한 중상, 명예훼손, 험담을 쏟아 내 소송 위험에 처하기도 한다. AI의 가장 적절한 용도는 이 자동화된 천재성을 통제할 수 있는, 더 똑똑하고 민첩한 인간을 위한 비서 정도다.
 

데이터베이스 쿼리

데이터베이스는 모든 정보를 체계적으로 정리된 테이블에 보관하고 언제든 원할 때 질문에 답해주는, 자동화된 도구의 원조라고 할 수 있다. 오라클은 (데이터베이스의) 모든 것이 얼마나 자동화됐는지 강조하기 위해 데이터베이스에 ‘자율’이라는 이름표까지 붙였다. 오늘날의 기업은 대규모 데이터베이스의 마법 없이는 돌아가지 않는다. 

하지만 개발팀은 데이터베이스의 한계를 금방 알게 된다. 고급 쿼리 엔진의 강력함이 별 효용성이 없는 때가 있다. 간단한 SQL 쿼리 작성은 특별히 어려운 일이 아니지만, 복잡한 쿼리를 효율적으로 작성하기는 매우 어려울 수 있다. 

여유가 있는 팀이라면 원활한 운영을 위해 전문 데이터베이스 관리자를 채용할 수 있다. 전문 데이터베이스 관리자는 매개변수를 조정하고 스래싱 없이 인덱스를 처리할 만한 RAM을 확보한다. 2개 이상의 절로 구성된 SQL 쿼리를 생성해야 할 때도 시스템에 과부하를 주지 않도록 하는 방법을 안다.
 

로우코드 플랫폼 자동화

일부 엔터프라이즈 도구, 포털, 웹 애플리케이션은 프로그래밍이 거의 또는 전혀 없어도 즉석에서 자체적으로 조정할 수 있을 만큼 정교해졌다. 영업팀은 이 기능을 ‘로우코드’나 ‘노코드’라고 부른다. 자동화 수준이 꽤 매끄럽기 때문에 틀린 표현은 아니지만, 여전히 몇 가지 문제점이 있다.

가장 큰 문제는 모든 상황에 적용될 수 있는 만능 솔루션이 없다는 점이다. 기업마다 조금씩 다르기 때문에 데이터 웨어하우스, 처리 파이프라인, 인터페이스 역시 달라야 한다. 하지만 로우코드와 노코드 옵션은 하나의 일반화된 시스템을 제공한다. 사용자 정의가 가능한 부분은 대체로 피상적인 정도에 그친다.

이 일반화된 코드는 모든 상황에서 사용 가능해야 하므로 많은 경우 속도가 훨씬 더 느리다. 데이터를 포맷하고 다시 포맷하기 전에 지속적으로 데이터를 확인해야 한다. 자동으로 연결되는 모든 글루 코드는 새로운 데이터가 수신될 때마다 실행돼야 한다. 그 결과 하드웨어 비용이 증가하고 때로는 모든 작업 속도가 느려진다. 

많은 팀이 인프라 구축을 위한 프로젝트 인력을 구하는 것보다 더 쉽고 더 저렴하다는 이유로 느린 자동화라도 사용한다. 하지만 이는 적합하지도 않을 뿐만 아니라 더 느리고 비용도 더 많이 드는 뭔가를 억지로 계속 사용한다는 것을 의미한다.
 

워크플로우 자동화(RPA)

로우코드 및 노코드 개발의 사촌 격인 RPA, 즉 로봇 프로세스 자동화가 있다. RPA 도구는 문서 처리 같은 일반적인 사무 작업에 AI를 적용하는 데 유용하기 때문에 사무실 환경에서 주로 사용된다. 하지만 안타깝게도 이 도구는 AI와 로우코드의 잠재적인 문제점을 모두 갖고 있다.

RPA의 가장 큰 장점은 레거시 인프라에 최신 인터페이스를 적용하는 동시에 약간의 통합도 가미할 수 있다는 것이다. 기존 코드를 변경하지 않고도 겉모습을 빠르게 개선할 수 있다는 이야기다. 물론 기존 코드를 최신 표준으로 업데이트하거나 재작성하지 않기 때문에, 내부는 펀치 카드 시대에 쓰이던 데이터 구조와 알고리즘이 가득 차게 된다는 의미이기도 하다. 즉, RPA는 간신히 실행되는 코드 위에 기술이라는 포장 테이프를 덕지덕지 붙이는 것과 같다.

진짜 위험은 사람이 안심하고 잠들 수 있을 정도로 소프트웨어가 원활하게 작동할 때 발생한다. 자동화는 수작업으로 이뤄지던 단계를 처리한다. 수작업으로 할 때는 송장이나 주문에 문제가 있을 때 인간 담당자가 알아차릴 시간이 있다. 자동화되면 관리자가 로그인해서 ‘모두 승인’ 버튼을 클릭하기만 하면 된다. 기존 업무 절차의 견제와 균형이 약화되면서 기만과 실수가 누적되기 시작한다. 마지막으로 남은 한 사람(물론 파트타임 직원)은 너무 늦기 전에 무슨 일이 일어나는지 파악하기 위한 도구도, 식견도 없다. 
 

제로 자동화

자동화를 추가하는 것보다 더 나쁜 것은 아무것도 하지 않는 것이다. 기술 부채는 절대 해결되지 않는다. 소프트웨어 인프라가 너무 오래되면 더 이상 업그레이드할 가치도 없어진다. 인프라가 서서히 노후화되면, 사무실의 모든 사람도 노후화된다. 기업은 과거에 항상 해오던 방식에 고착되기 마련이다. 

소프트웨어 자동화의 실패에 불만을 제기하고 주의를 기울이는 것도 좋지만, 그 함정을 인지하고 전략적으로 계획하는 것이 가장 좋다. 즉, 단점을 고려해 (단점을) 피하거나 더 나은 해결책을 찾아야 한다. 진전보다 더 나쁜 유일한 것은 아예 진전하지 않는 것이다.
editor@itworld.co.kr