Graha 는 쓸데없는 짓거리를 한 걸까?

1. 노코드(No-code) ~ 로우코드(Low-code)

눈이 번쩍 뜨인다.

분명히 Graha 를 개발하기 이전에 업무용 프로그램을 개발하기 위한 생산성 도구를 검색한 적이 있다.

당시에는 없었는데, 열심히 찾지 않았던 탓일까?

2. 아직은 아닌 것 같다.

노코드(No-code) 란 마우스를 까닥거려서 그정도로 할 수 있는 수준의 웹페이지나 휴대전화용 응용프로그램을 만드는 것을 의미하는 것 같다.

이런 방식은 직관적이고 쉬워 보이지만, 정형화되지 않은 컨텐츠와 어울리지 않는다.

3. 왜 이런 이야기가 나올까?

코로나 팬데믹은 전산시스템에 대한 수요를 폭발적으로 증가시켰다.

이런 일들이 대세적 경향인지에 대해서는 논란의 여지가 있겠다.

이에 따라 실무에 바로 투입할 수 있는 프로그래머의 수요도 폭발적으로 증가했다.

정규교육과정을 거쳤다고 하더라도, 최상위 1% 정도를 제외하면, 5년정도의 실무경력을 쌓은 다음에야, 실무에 즉시 투입할 수 있는 프로그래머가 된다.

5년의 기간을 단축시키는 여러가지 방법이 있겠지만, 코딩의 양을 줄이는 것도 한 가지 방법이 되겠다.

이런 이야기가 나오는 이유는 생산자와 소비자의 경계가 허물어지고 있는 추세의 반영일 수도 있다.

4. 가까운 미래에 그렇게 될 수도 있을까?

가까운 미래는 아닐 것 같다.

Graha 의 개발경험을 돌이켜 보면, 코드의 양은 줄일 수 있지만, (sql 과 같은) 기술에 대한 이해는 더 높아져야 한다.

생산성이란 확장성(+호환성)과 맞바꾸는 성격이기도 하다.

5. 노코드(No-code) 의 미래는?

프로토타이핑 내지 비전문가나 숙련도가 낮거나 퇴역한 프로그래머를 위한 맞춤형 도구 수준이라면 누군가에게 효용이 있을 가능성도 있다.

사용법을 익히는데 많은 노력이 필요하다면, WYSIWYG 방식의 HTML 에디터나, 비슷한 시기에 유행했던 Windows 응용프로그램을 만들기 위한 프로그래밍 개발도구들의 경험을 참조할 수 있겠다.

부정적인 느낌이 강하지만, 프로그래머가 아닌 일반인들이 Microsoft Excel 의 수식을 능숙하게 사용하는 것을 보면, 예단하기는 힘들다.

웹페이지를 만드는 새로운 접근이 필요하다.

아이디어만 있는 사람들에게 그것을 구현하는 것은 비용의 문제도 있겠지만, 구현 과정에서 배제되면서 발생하게 되는 다른 문제점도 있을 수 있다.

6. 로우코드(Low-code) 의 미래는?

C 언어에서 구조체와 포인터를 사용하면, 객체지향을 흉내낼수 있다.

이에 대해서는 C로 구현한 알고리즘 을 참고하라.

C 언어는 Java에 비해 할수 있는 일도 많다.

어셈블리어 와 초창기 C 언어의 관계도 유사하다.

새로운 프로그래밍 언어(Java) 들은 한계가 분명해 보였지만, 결과는 모두가 알고 있는 바와 같다.

많은 프로그래밍 언어들이 등장했었고, 그 중의 극히 일부는 초창기의 평가에도 불구하고 대단히 큰 성공을 거두었고, 다른 일부는 그 나름대로 쓰임이 있고, 또 다른 일부는 극히 일부분의 사람들에게만 알려졌다.

로우코드(Low-code) 의 미래는 제반 환경과 산업계의 요구에 따라 달라질 수 있고, 일단 수 많은 시도들이 있고, 그 중의 극히 일부라도 성공을 거두게 된다면, 현재가 추억이 될 수도 있을 것이다.

로우코드(Low-code) 혹은 다른 것이라고 하더라도, 생산성을 1000% 정도로 개선하거나, 비숙련자도 쉽게 접근할 수 있도록 하는 것은 불가능하다.

7. Graha 의 미래는?

Graha 는 데이타베이스 기반의 웹프로그램에 특화된 로우코드(Low-code) 라이브러리의 일종이다.

Graha 의 목표는 설계서를 작성하듯이 프로그램을 개발하는 것이다.

처음에는 노코드(No-code) 를 구상했지만, UI를 감당할 수 없다는 것을 깨닫고, 로우코드(Low-code)로 전향했다.

유사한 프로그램이 있었다면, 시작조차 하지 않았을 것이지만, 눈에 띄는 로우코드(Low-code) 프로그램이 등장한다고 해도, 시위를 떠난 화살을 멈춰 세울수는 없을 것 같다.

8. 마치며

프로그램 개발의 생산성이 시장의 수요에 뒤쳐지는 현상은 하루 이틀의 이야기가 아니다.

생산성의 문제는 숙련된 프로그래머의 숫자를 늘려서 해결할 수 있을 것처럼 보이지만, 소프트웨어의 규모 내지 완성도 와 복잡도 내지 결합도의 관계를 감안하면 전술적 변화를 동반해야 한다.

전술적 변화란 방법론, 디자인 패턴, 그리고 생산성 높은 프로그래밍 언어 내지 생산성 도구 등을 포괄하고, 숙련된 프로그래머들의 숫자도 늘어나야 한다.

2000년 이후의 전술적 변화란 더 개방적이고 투명하고 협력적인 방향으로 나아가고 있다.

2000년 정도로 시간을 되돌리면, 웹이라는 새로운 환경이 Java 와 같은 새로운 프로그래밍 언어들의 토양이 되었지만, 지금은 (프로그래머를 확보하기 어려운) 소규모 회사나 스타트업이, 새로운 개발도구 등을 지지할 가능성은 있겠다.