|
경영진은 로우코드(low code) 툴이라는 개념을 좋아한다. 이들에게 코드가 적다는 것은 일이 적다는 의미이고, 일이 적다는 것은 더 신속한 프로젝트, 더 빠른 만족, 더 가벼운 예산, 궁극적으로는 더 두둑한 보너스를 의미하기 때문이다. 좋아하지 않을 사람이 누가 있겠는가?
하지만 개발자들은 싫어한다. 이들도 로우코드의 이론적인 장밋빛 약속은 좋아한다(일이 줄어드는 것을 원하지 않는 사람이 누가 있겠는가?). 그러나 더 쉬운 개발이라는 달콤한 이야기와 마감이 다가오는 상황에서 툴이 약속한 기능을 제대로 실행하지 않을 때 마주하는 현실 사이에는 큰 간격이 존재한다는 사실을 잘 안다.
물론 로우코드 솔루션에는 장점이 있다. 시간과 노력을 덜 들이면서 작동하는 무언가를 얻을 수 있는 로우코드의 기능은 프로그래머에게도 반갑다. 개발자는 로우코드 툴이 검색, 정렬을 비롯해 테이블 데이터를 다루는 메커니즘을 곧잘 생산할 수 있다는 사실을 알고, 적절한 경우에 기꺼이 로우코드 툴을 사용한다.
그러나 개발자는 코너에 몰려 모든 주변 조건과 씨름하고 툴이 알아서 처리하지 못하는 부분을 일일이 찾아 손봐야 하는 상황을 두려워하기도 한다. 결함에 대처해야 하고 문서화되지 않은 기능을 조작해야 하고 작업 방식이 다소 다른 요청을 만족시킬 방법을 알아내야 한다.
개발자는 홍보 문구의 귀가 솔깃한 약속과 로우코드 툴을 사용한 작업이 스택을 직접 쓰는 방식, 즉 하이 코드 방식보다 더 느리고 짜증스러운 경우가 많다는 현실 사이에 갇힌다.
프로그래머의 시간을 절약해준다고 호언장담하는 로우코드 툴에 정작 프로그래머들이 좌절하는 9가지 이유는 다음과 같다.
1. 유지보수가 어렵다
로우코드 솔루션을 다룰 때 가장 까다로운 부분은 일반적으로 몇 년 이후에 발생한다. 기존 시스템이 원활하게 잘 돌아간다 해도 사람들은 수정과 개선을 요청한다. 이렇게 요청되는 부가 기능의 상당수는 기존 로우코드 솔루션의 아키텍처 구조를 벗어나므로 손쉽게 추가할 방법이 없다. 소스코드가 있다면 내부로 파고들어 일부분을 다시 구축할 수도 있겠지만 소스코드가 없다. 해당 기능이 필요하게 될 것을 최초 설계자가 알았더라면 다르게 설계했을 수도 있고, 시작부터 전혀 다른 프레임워크를 선택했을 수도 있다. 하지만 이미 지나간 일이고 지금은 이러지도, 저러지도 못하는 상황이다.
2. 천편일률적인 결과
체인 음식점에서 밥을 먹는 사람들은 뻔한 메뉴에 익숙하다. 놀랄 만한 무언가는 당연히 없다. 비즈니스 모델은 표준 메뉴, 표준 설계를 통한 비용 절감과 일관적인 경험에 의존하지만 재미는 없다.
로우코드 툴 역시 이와 같은 틀에 박힌 느낌이다. 어느 정도 경험을 가진 유능한 개발자라면 클릭 몇 번만 하면 기반 툴을 파악할 수 있다. 다양한 구성 옵션과 스플래시 스크린, 맞춤 CSS 스킨으로 무장한다 해도 근저의 메커니즘이 뻔히 드러난다. 항상 똑 같은 것을 원하는 일부 사용자에게는 편안하게 느껴질 수 있지만 참신함은 기대할 수 없다.
3. 딱 맞는 곳이 없는 원 사이즈
제품 제조업체는 “모두에게 맞는 원 사이즈” 상품을 좋아한다. 제조 공정이 훨씬 더 단순하기 때문이다. 그러나 고객은 많은 경우 이러한 상품을 싫어하고 “아무에게도 안 맞는 원 사이즈”라며 불평한다.
로우코드 제품은 동일한 방식으로 손쉽게 사용할 수 있다. 그러나 바꾸고 맞춤 설정하고 코딩할 부분이 많지 않으므로 그냥 그대로 사용해야 한다. 할 수 있는 일을 하지만 그뿐이고, 최종적으로 누구도 행복하지 않다.
4. 차라리 코딩이 구성보다 쉬울 때가 있다
개발자가 흔히 저지르는 전략적 실수는 소프트웨어 구성 작업을 최소한으로 줄이는 것이다. 회사내 회계 부서가 코드 라인당 비용 따위의 기준을 계산해서일 수도 있고, 경영진이 항상 새 코드 생성 비용과 완성된 제품을 구입하는 비용을 비교해서일 수도 있다. 어느 경우든 코더는 플랫폼이나 툴의 구성 파일 매개변수를 조정하는 작업을 사소한 일로 치부한다.
로우코드 옵션 역시 비슷한 경향이 있다. 즉, 알고리즘을 지정하고 데이터베이스를 연결하고 매개변수를 입력하는 동안에는 코딩을 하는 것이 아니다. 이런 작업은 하찮은 구성 작업일 뿐이며, 모두가 알다시피 구성은 간단한 작업이라서 나중에 시끄러운 바에서도 스마트폰으로 해도 된다. 그러나 현실은 구성을 정말 제대로 하기 위해서는 며칠, 또는 몇 주가 걸릴 수도 있다는 것이다. 심지어 실제 코드를 쓰는 힘든 “작업”보다 구성에 더 많은 시간이 걸린다 해도 개발업체는 고객이 구성을 “작업”으로 간주하기를 원치 않는다.
5. 눈 가리고 비행하기
개발자는 오랜 기간에 걸쳐 만들어진 정교한 디버깅 툴을 사용해 소프트웨어를 임의의 지점에서 손쉽게 멈추고 데이터 구조와 알고리즘 상태를 세부적으로 살펴보면서 현재 일어나는 일을 파악할 수 있다. 로우코드 툴은 이런 모든 부분을 의도적으로 숨기고, 그것이 개발자에게도 이익이라고 생각한다.
로우코드의 각 부분이 예상한 대로 작동만 한다면 아무런 문제가 없다. 그러나 어딘가 잘못되는 경우가 많은데, 이럴 때는 블랙박스 안에서 무슨 일이 일어나는지 알 수 없는 상태로 막히게 된다. 계기판 없이 비행기를 조종하면서 상황을 파악하기 위해 애쓰는 것과 같다.
6. 가끔 데이터를 정리하기 위해 함수 하나를 삽입해야 할 때
소프트웨어 코딩을 해본 사람은 누구나 알겠지만 작업의 절반은 문제를 걸러내면서 데이터 흐름을 지속시키기 위한 부가적인 연결 코드를 작성하는 일이다. 날짜가 ISO 8601 형식인 경우도 있고 현지에서 주로 사용하는 형식인 경우도 있다. 숫자가 문자열이어야 하는 부분에서 정수로 되어 있거나 그 반대로 되어 있기도 하다.
로우코드 제품은 필터 또는 스위치를 통해 이 작업을 일부 처리하는데, 이 정도로 충분한 경우도 많다. 문제는 충분하지 않을 때다. 로우코드 제품은 진퇴양난에 빠진 상황이다. 일부 제품은 실험적으로 개발자가 임의의 코드 블록을 삽입하도록 허용하기도 했지만 누군가가 이를 악용할 방법을 찾아내서 심각한 보안 결함을 일으킬 수 있다. 실제로 드루팔(Drupal)은 잠재적인 보안 결함을 없애는 동시에 캐시 성능을 높이기 위해 PHP 코드를 이곳저곳에 포함할 수 있는 옵션을 제거했다.
7. 로우코드는 비효율적인 경우가 많다
로우코드 툴은 무엇을 해야 하는지 알고 알아서 척척 해낸다고 주장한다. 그러나 이렇게 개발자의 마음을 읽기 위해서는 일반적인 기준을 벗어나는 모든 구성과 상황을 처리하는 방대한 양의 코드가 필요하다.
개발자가 직접 코드를 썼다면 예를 들어 CSV 파일로만 데이터를 저장하면 된다는 것을 알 수 있다. 그러나 로우코드 기반의 회사는 모든 만일의 사태에 대비해 계획해야 하며, 이는 JSON, YAML, XML(버전 1.0과 1.1 모두)을 다뤄야 한다는 것을 의미한다. 현업에서는 수십 가지의 형식이 사용되므로 로우코드를 판매하는 업체는 이런 형식을 모두 처리할 수 있는 툴을 만들어야 한다. 즉, 기능 표가 있다면 모든 칸에 체크 표시가 된 툴이 필요하다.
그 결과로 나온 엔지니어링은 방탄 전함 드레드노트(Dreadnought)만큼이나 인상적이다. 물론 움직임 역시 거대한 1차대전 전함 수준으로 둔하다.
결국 모든 것이 더 느리고 덜 효율적이다. 기한이 촉박하지 않고 데이터 집합이 그렇게 크지 않다면 스택에 더 많은 컴퓨팅 성능을 욱여넣어 이 무거움을 숨길 수 있다. 그러나 온갖 부가적인 코드로 인한 비용은 언젠가는 청구될 수밖에 없다.
8. 경험의 필요성
주요 오픈소스 플랫폼의 상당수는 학교에서 가르치는 인기있는 언어로 만들어진다. 자바, 자바스크립트, 파이썬, PHP와 같은 주요 언어로 만들어진 스택을 해체하고 다시 구축할 수 있는 인재는 풍부하다.
로우코드를 가르치는 곳은 거의 없다. 애초에 지도가 필요없는 개념이기 때문이다. 로우코드를 지지하는 사람들은 로우코드 툴이 보편적인 언어로 작성되는 경우가 많다는 점을 강조하지만 개발자에게 진짜 문제는 그게 아니다. 문제는 로우코드 프레임워크 안에 기본적으로 포함되는 부가적인 구조다. 이 구조는 로우코드를 구입하는 이유이기도 하지만 팀이 플랫폼을 수정하거나 확장하려는 경우 따로 배우느라 시간이 소비되는 이유도 된다.
9. 종속성
로우코드 플랫폼을 시작하는 것은 폭력 조직에 들어가는 것과 비슷하다. 들어가기는 쉽지만 나오기는 어렵다. 일의 양을 줄이고 거인의 어께 위에 올라서게 되지만 그 대가로 거인에게 종속된다. 거인이 움직이면 함께 움직여야 하며 거인이 멈추거나 쓰러지면 곤란한 상황에 처하게 된다. editor@itworld.co.kr
원문보기:
http://www.itworld.co.kr/news/131434#csidxc99cb701a62f53a8d448844e7f5fa3f
|
