글을 쓰려고 로그인하고 깜짝 놀랐다. 카르다노 프로젝트의 우로보로스 논문 해설을 1편만 쓰고 벌써 3개월이 지났다니.... 다사다난하게 살다보니 어쩔 수 없이 그랬지만 너무 찔리는 것도 사실이다. ㅠㅠ

회사에서 상반기에만 2번 뒤엎은 코드를 한번 더 뒤엎으며 엄청난 강행군을 했다. 하지만 뒤엎는 과정에서 얻은 것이 크다는 생각이 들며, 최근 들여다보는 블록체인 등의 주제들과도 많이 연관되는 것 같아 정리할 겸 글을 써본다.

모든 논리적 사고는 컴퓨터로 실행 가능하다

뜬금 없지만 요즘 하고 있는 생각이다.

모든 논리적 사고는 적당한 작업을 통해
컴퓨터 코드로 환원할 수 있고
그래서 결국 실행이 가능하다고 생각한다.

정확히는 사물을 이용하는 인과적인 논리로
한정지어야 하지만...
좀 없어보이기도 하고
사람들이 보통 논리적 사고라 하면
상식적인 인과를 떠올리므로 이렇게 설명해왔다.

인과과정을 쪼개보면,
전제와 조건에 의해 결과가 얻어지고
각 조건을 의식해 컴퓨터로 전제를 정의하면
각 조건에 관련된 모든 명제 및 그 결과는
프로그램으로 반드시 얻어질 수 밖에 없다.

예시.

'밤이 어두워지면 길을 밝혀야 한다'

--> '빛의 양이 적어지면 가로등을 켠다'

--> '집광 센서의 수치가 a 이하가 되면 가로등 스위치 값을 true로 바꾼다'

컴퓨터가 알 수 있는 "집광 센서 수치"의 감지가 전제되고
"a 이하"라는 조건이 세팅이 되면
가로등 스위치 on/off 결론까지 도달한다.

우리는 어떻게 해서든
컴퓨터한테 밤길을 밝히라고 시키는
그런 실행 가능한 시나리오를 만들 수 있다.

그러나 문제가 많이 있다.

논리적 사고는 실행 이전에 기술적 맥락에서 해석해야 했다

집광 센서는 어찌 구현하나?
가로등 스위치는 어찌 통제하나?
이것을 구현하는 소프트웨어는
어떤 기술로 만들어야 하나?

논리적 사고가 실행되기 위해서는
고난이도의 기술에 의해 해석되고
구현이 되어야 한다.

필자는 의료 솔루션을 개발하는데,

'환자가 이러면 이런 약은 금지해야 한다구요'

의사나 간호사가 위와 같이
가볍게 던진 것이 솔루션 내에 녹기까지
수도 없는 소프트웨어의 검증 작업이 필요해
개발자도 같이 녹아들어
사무실에 에밀레 종 소리가 울려퍼진다.

그러나 2018년에 이르러 글을 쓰는 지금
상황이 변했다는 생각이 들고 있다.

논리적 사고를 그 모형 그대로 해석하는,
혹은 최소한 그와 유사한 형태의 소프트웨어가
나타나고 있기 때문이다.

수많은 예시를 이미 보아왔지만,
필자가 개발하고 있는 것을 설명하며
또 얼마전 번역을 하며 인상 깊었던
리카르디안 컨트랙트도 소개하려한다.

참고로 머신러닝과는 다르다.
머신러닝은 통계적 방법론으로
'직관'의 영역을 넘어가려는 시도로
인과를 정확히 그대로 구현하는
소프트웨어 기존의 흐름과 분명히 다르다.

의사의 논리를 실행하는 Rule Engine

필자가 만들고 있는 부여잡고 고통받고 있는 Rule Engine을
정의도 건너뛰고 설명부터 하자면 다음을 구현한 것이다.

"의사가 정의한 논리대로 시스템이 움직이게 하는 것"

화면은 단순화 하면 다음과 같이 생겼다.

이런 모양을 만들어 놓고
어떤 의사가 이 프로그램을 사용하면,
환자가 20살 이하일 때 A약이 금지된다.

사업적인 감각이 있는 사람은
위 모양의 가치를 더욱 쉽게 알아보고들 한다.
사람을 많이 자를 수 있게 만들기 때문이다.

먼저 (1) 시스템 내에 숨어 들어간 것들이 드러나
훨씬 쉽게 검증 받을 수 있게 된다.

과거에는 저 논리를 검증하려면
운영 시스템에서 20살 이하 환자로 테스트를 해야 했다.
아니, 그 이전에 시스템 내에 저 규칙이 있는지도 모른다.
Rule engine이 있으면 훨씬 적은 개발자 인원으로도
시스템 검증을 할 수 있다.

그리고 (2) 개발을 안하는 사람도
충분히 알아볼 수 있게 된다.
즉, 논리적 사고를 찰떡 같이 받아들여서
의사와 개발자의 길고 슬펐던 싸움을 종결지을
실마리를 가져다준다.

이것이 핵심이다.

컴퓨터와 협업해 도움받게 되는 다른 산업/학문 분야를
개발자들은 보통 도메인이라 부른다.
개발자들은 도메인의 지식을 해석해
컴퓨터 코드에 담기 위해 일생을 바친다.

도메인 유저는 말 한마디 못알아 먹는
개발자에게 화내고,
개발자들은 입만 열면 말이 바뀌는
도메인 유저를 보며 고구마를 먹은듯 답답해한다.

그래서 의료 IT 분야에서는
의료지식을 공부한 개발자와
프로그래밍을 공부한 의사 중
누가 더 좋은 시스템을 만드는 지
닭과 달걀의 병맛 논쟁이 나오곤 한다.

도메인의 유저들이 가진 풍부한 지식들은
원래 복잡한 컴퓨터 속 구조에 가려져 있었는데,
Rule Engine과 같은 형태로 수면 위에서
다룰 수 있게 되었다.

이제는 약간의 '컴퓨터 감각'이 있는 사람은
아무런 개발도 배우지 않고 위와 같은 도식만으로
시스템 전반의 그것도 가장 중요한 영역을 기획할 수 있다.

그리고 이와 비슷한 플랫폼이
산업들마다 전방위적으로 나타나고 있다.

이 흐름은 단순하게 해석할 수 없다.
사회 구조에 지대한 영향을 끼치리라 본다.

이제 도메인의 논리가 시스템에 녹을 것이므로
개발자가 무조건 잘 먹고 잘 살게 될까?

미국의 경우를 보면 반쯤 그런 것 같지만,
그것보다 '의사'와 '개발자'라는 영역이
정의하기가 갈수록 어려워진다는 것에
집중할 필요가 있다.

더 전개하면 주제가 복잡해지므로
이쯤에서 다음 예시를 들겠다.

실행 가능한 계약 - 리카르디안 컨트랙트

리카르디안 컨트랙트를 소개합니다

EOSYS 집필진의 번역 알바?를 하면서 흥미롭게 읽은 글이다.

지금까지의 논리를 감안하면
아주 간단한 문제에 의해 제시된 것이다.

이더리움의 smart contract와 같은 것이
현실세계의 계약을 다루는데
그것을 개발자만이 읽을 수 있다는 점,
도메인 유저는 명확한 판단을 못한다는 점이 문제다.

해당 smart contract가 문제가 있어
'내가 이해하고 있던 그 계약대로'
실행해주지 않는다면
아주 큰 문제가 발생한다.

보통의 계약과는 달리
자동화된 계약은 컴퓨터를 이용하기 때문에
수십~수만 건의 계약들이 순식간에 실행되고
문제 발견 시 개발자가 해석해야하고..
결국 이미 늦었을 수 있기 때문이다.

그러므로 계약을 실행하기 이전에
그리고 계약을 실행 후 문제가 있을 때
사람이 행정적/법적으로 그 계약을 해석해야한다.

이는 다시 도메인 유저와 개발자의 문제로 돌아온다.

도메인 유저가 만든 계약은
이더리움이나 EOS 등등에 Solidity, c++로 바뀌어
올라가 있기 때문일 것이다.

아무리 계약을 문서화해서 잘 갖춰놓아도,
결국 찰떡 같이 못 알아듣는 개발자는
답답한 도메인 유저를 욕하며
똥을 싸놓게 된다.

리카르디안 컨트랙트는

"읽을 수 있는 계약으로 컴퓨터를 실행시키자"

라는 아이디어를 구현하는 것이다.

약간의 조사를 해본 결과,
그 구현 형태가 기술적으로 표준이 있지는 않다.

그 중 원 글의 링크에 있는 동영상이 직관적이다.

{{signer}} 혹은 {{voter}}가 향후 컴퓨터로 실행할 때 참조하는
일종의 script 형식으로 만들었다는 것을 알 수 있다.

이것을 읽은 투표 관련 공무원(블록체인 정부기관이 생길 것이므로)은
한결 부담을 덜고,
무엇보다 최종 도장을 찍을 수 있는 확신을 가지게 된다.

원 글에서 보면 알 수 있듯이
결국 법적인 문제를 판가름 할 수 있느냐에
리카르디안 컨트랙트의 가치가 달린다.

흡수된 도메인 논리, 자동화된 개발 과정

자본주의 하에 발전하는 IT 기술 앞에서
장밋빛 미래를 볼 수 있는 노동자 계급은 없다.

도메인 유저는 자기 논리를 흡수당했고,
점점 자기가 내는 결론보다 정확한
소프트웨어 서비스를 발견할 것이다.

개발자는 자기가 개발하던 코드가 패턴화 되었고,
점점 자기가 만드는 속도보다 빠르게 도메인 논리를 구현하는
소프트웨어를 마주하게 될 것이다.

이 상황에서
Rule Engine, 리카르디안 컨트랙트, 언리얼 엔진, 노코드 플랫폼
과 같은 것을 만드는 것이 어떤 의미를 가지는 것일까.

내 스스로 만들어 놓은 작품의 아름다움에 경이를 느끼면서도
계속해서 내가 나아갈 길에 갈피를 못잡는 상황이
2018년 여름에도 이어지니 아이러니하게 느껴질 따름이다.