소프트웨어 개발과 수학의 거리. 그 가까움에 대해서

 소프트웨어 개발은 기계적인 절차를 다룬다. 즉 Universal Turing Machine과 동치인 이 컴퓨터에 대해 그 작동 메카니즘을 실제로 활용해서 반영하고, 그 과정을 수없이 반복함으로써 체득하는 과정이다.

 

 그것은 수학적 증명의 절차를 따라가는 것과 유사하기도 하며, 계산 절차를 진행하는 것을 관리 감독하는 것과 같다. 그리고 여러가지 관점에서 소프트웨어 개발은 수학적 사고와 매우 깊은 연관이 있다고 생각한다.

 

 기존 글에서 필자는 수 계산의 본질이 상태와 전환이라는, 즉 어떤 저장값과 그 저장값을 바꾸는 과정이라고 주장했다. 그리고 그 주장은 소프트웨어도 마찬가지다. 다만, 수는 대칭 체계에 기반하여 이 상태/전환을 설계하여 숫자화하고 이용하고 있고, 소프트웨어는 이 수학 체계를 그대로 이어 받아서 사용하는 점이 현재의 모양새이다. 그러나 그 본질로 들어가면 이 둘은 다르지 않다. 밑 바닥의 중간 기초가 달라보이고 서로 차용하지만, 그 근간은 수학의 상태와 전환, 그리고 튜링 머신의 보편성이 그대로 서로 이어지면서 둘은 다를 것이 없다. 수리 논리 관점에서는 차이가 없다는 말이다.

 

1. 수학의 계산과 증명을 뜯어보면, 대칭 체계하에서 상태와 전환에 대한 기초 틀을 만들고, 그것을 반복 사용하는 것으로 통칭할 수 있다. 숫자 체계도 마찬가지고 공리를 통한 증명도 마찬가지다. 기본이 되는 재료(상태와 전환의 묶음)를 만들고 이를 반복한다.

 

2. 컴퓨터는 1번에 대비해서 실제 제한된 시간안에 특정 연산을 수행하기 위한 명령을 내리기 위해서 더 추가적인 기교가 들어가 있다. 우선 조건 및 분기, 반복, 함수처리 같은 연산 보조 기능이 함께한다. 그러나 이는 역시 단순한 반복이나 반복의 반복 등을 쉽게 나타낼 뿐이지, 1번과 본질적으로 다르지는 않다.

 

 컴퓨터로 행하는 일련의 작업은, 어떤 메모리 상의 값이 존재하고 이것을 변환하는 과정에 불과하다. 따라서 컴퓨터 상에서 행해지는 모든 연산도 이 관점에서 바라보게 될 수 있다.

 

 추상화하면, 가장 본질적인 질문은 상태 2가지가 서로 같은가 다른가, 어떤 과정을 거치고 그 과정의 패턴이 어떤가에 대한 문제로 좁혀진다. 다만 이 과정의 문제는 단순하게 혹은 복잡하게도 나타낼 수 있는데, 그 과정이 중요한 경우는 현실에서 소요되는 시간이라던가 거치는 상태가 어떤것이다라는 가에 따라서 달라지고, 그 반복의 효율이 달라지기 때문이다. 이런 부차적인 것들도 소프트웨어 개발에서는 중요하다. 동일한 출력을 내는 문제에서 서로 다른 과정을 거치는데, 이 과정을 최적화하는 작업을 소프트웨어개발에서는 튜닝이라고 한다. 수학에서는 이 과정을 단순화라고 하는데 오히려 지향하는 바가 조금씩 다르다. 수학은 짧게 직관적으로 설명하면 되고, 소프트웨어에서는 복잡하더라도 빠른 과정을 찾는다. 이 둘은 좀 차이가 있다.

 

3. 수학과 소프트웨어 개발 모두 무한의 문제를 가지고 있다. 어쩌면 당연하다.

 

 소프트웨어 개발시 나타나는 dead lock(데드락)이나 freezing문제는 무한 문제의 대표 케이스이다. 당연하게도 오류이고 피해야 하는 것이라고 생각하는 것처럼 수학에서도 그렇다. 가장 유명한 문제는 1을 0으로 나누는 문제이다.

 

 1을 0으로 나누면 수학에서는 무한대로 칭한다. 나눗셈은 사칙 연산 중에서도 가장 복잡한 양상을 띄는데(빼기나 더하기, 곱하기는 어떤 진법이나 소수를 포함하더라도 로직이 단순하다.), 예를 들면 소프트웨어로 이 문제를 풀려면 아래와 같다.

 

나누는 값 0을 계속 더해서 몇번 만에 1에 도달할지 구하는 함수를 짜서 실행하면 된다. 이 나누는 값이 0이 아니라 잘 나누어 떨어질때는 이 함수가 잘 작동하는데, 0일때는 이 함수가 끝나지 않는다. 즉 무한의 시간이 걸린다.

 

function getDiv(number target, number val) {

  number i=0;

  number total;

 

  for(total과 target이 동일해질때까지) {

    total = total + val;

    i = i +1;

  }

 

  return i;

}

 

 이 함수의 존재야말로 수학과 소프트웨어 개발이 겪는 어려움이 같다는 것을 알 수 있는 대표적인 사례다. 소프트웨어 개발자는 따라서 이 함수를 버그로 간주하고 예외처리하여 계산하지 않도록 함수를 설계한다. 수학자들도 오랫동안 그렇게 해왔다. 본능적으로 0으로 나누는 것은 성립되지 않다고 간주해왔다. 하지만 전체적인 수학 체계에서는 0으로 나누는 현상이 예외일 수 없다. 대칭적인 체계에서 그것은 수학 체계 안으로 들어와야 하며, 칸토어는 이것을 해결하기 위해 고군분투한 셈이다.

 

 위의 0으로 나누는 문제는 직관적이고 곧바로 우회로를 적용할 수 있는 단순한 형태이다. 그러나 소프트웨어 개발처럼 복잡한 논리를 처리하다보면 무한의 문제는 수시로 잠재해있다. 데드 락은 그렇게 나타난다. 쉬운 형태의 데드 락도 있지만 어려운 형태의 데드 락도 있다. 그리고 더 재미있는 현상도 있다.

 

4. 어떤 것은 같은 결과값을 구하는데 무한의 시간이 걸리는데, 어떤 경로로는 그렇지 않을 수 있다.

 

 놀라운 일이다. 어떤 값을 구하는데 원래 무한의 시간이 걸리는데, 그것을 우회하는 전환 과정이 존재한다. 예를 들면 이렇다.

 

 ㅇ1/3=(0.333....) 에 3을 곱한 값은 무엇인가?

 

인간의 분수 계산 방식에서는 1/3에 3을 곱하면 분모3과 곱하려는 값3이 일치하므로 1로 곧바로 결과값을 나타낼 수 있게 된다. 그런데 재미있게도 이 문제에 무한을 끼워넣을 수 있다. 바로 1/3에 대한 것이다.

 

 1/3은 10진수 소수 체계에서는 0.3 + 0.03 + 0.003 + ... 로 나타낼 수 있다. "상태"와 "전환"이 본질인 수학이나 소프트웨어 개발에서는 특정 상태로 이동하기 위해서는 이런 무한의 과정이 필요하다. 무리수나 초월수 등의 값들이 잘 알려져있고, 아예 따라서 이 과정을 생략하고 sqrt(2)=루트2나 pi같은 상수로 나타내기 한다. 여하튼 이 상태에 다다르기 위해서는 무한의 시간이 필요하다.

 

즉 마치 1/3 * 3을 구하기 위해서는 아래와 같은 두개의 함수가 존재하는데 B는 끝나지 않는다.

 

 function A() {

   return 1;

}

 

function B() {

   a=0.33333...(0.3+0.03...)

   return a*3;

}

 

만약에 무한의 문제를 존재하지 않는것처럼 치부해버리면 이 함수 A와 B를 제대로 비교할 수 없고 분석할 수 없다. 이 두 과정의 다름은 분석할 수 없는 것이 된다. 그러나 칸토어는 이를 그냥 내버려두지 않았다. 무한을 이해하면 이 두 함수의 차이를 더 자세히 이해할 수 있고, 따라서 무한이 실제한다는 것을 알 수 있다. 두 함수 모두 1/3 * 3을 구하는 과정인데, 한쪽은 무한의 과정을 거쳐야 가능하고, 사실은 실제로 그 무한의 과정을 거칠 수 있다고 가정하면 그 결과값이 1이라는 것을 알 수 있다.

 

 바로 이것이 수학적 논리 전개의 힘이라고 할 수 있다. 다만 칸토어는 상태에 대한 무한만을 다루었다. 과정에 대한 무한을 다루지 않았다. 과정에 대한 무한은 튜링이 그것을 처리하기는 했는데, 아직 완전히 구분되어 이해되지는 못하고 있다.

 

 

 그러면 과정에 대한 무한을 이해하면 어떻게 될까? 소프트웨어 개발이 혁신될 수 있다. 막연히 무한의 상황을 회피해야하고 버그로 간주하는 것이 아니라 소프트웨어 개발 전체에 안전장치가 마련된다거나, 해당 무한의 과정을 유한한 과정으로 자동으로 변환하는 방법이 생길 수도 있겠다. 그리고 이 과정은 그대로 수학에 재반영될 수 있다.

 

 그렇게 소프트웨어 개발에 대한 체득화된 경험은 수학에서도 여러가지 기여를 할 수 있는 잠재력을 지니는 셈이다. 소프트웨어의 다양한 최적화 방법이 수학의 증명에서도 사용될 수 있다.

 

5. 골드바흐의 추측이 있다. 2보다 큰 모든 정수는 세 소수의 합으로 나타낼 수 있다는 추측이다.

 

 아직 제대로 증명되지 않았는데, 이 증명을 하는 재미있는 방법이 있다. 즉 1부터 수를 증가해가면서 세 소수의 합으로 나타내는지 확인하는 함수를 짜서 하나씩 검사하는데, 이 검사 과정이 무한한 시간이 걸려도 끝나지 않는다면, 골드바흐의 추측이 참이다.

 

 그러면 앞서의 4와 연결지어 보자. 이 과정은 무한의 시간이 소요되는데 과연 유한한 시간안에 끝나는 함수로 변환해서 만들 수 있을까?

 

 이 질문은 1/3 * 3과 동치이다. 만약에 해당 상태를 특정해서 실제 구하지 않고 진행하는 방법을 찾으면 유한한 시간안에 값을 구할 수 있다. 만약에 골드바흐의 추측을 구하는 튜링 머신의 원천적인 절차를 유한하게 바꾸는 기계적인 방법이 있다면 어떨까?

 

 우리는 수학적인 단순한 증명이 아닌, 무언가 기계적인 매우 복잡한 변환 방법을 통해서 이 증명을 해낼 수 있을지 모른다. 인간이 이해하지 못하는 증명 방법이 아닐 수도 있다(이를 테면 1억가지의 경우의 수로 나누어서 하나하나 증명한 후 그 증명을 합치는 그런 일이다. 사람은 이런 소위 노가다 같은 방법에 익숙하지 않다. 그러나 그것은 논리적으로 성립한다)

 

 이런 일들은 수학자들의 몫이라기 보다는 소프트웨어 개발을 이해하는 이들의 수학적 마인드로 달성될 수 있다. 역시 '과정'이라는 소프트웨어 코드 들의 상호 변환에 대한 이해하에 이런 것들이 가능할테다. 그리고 이미 튜링은 어떤 함수가 유한시간안에 끝날지 무한시간안에나 끝날지 검사하는 함수를 상정함으로써 이 문제에 도전했다. 결과적으로는 완전히 알 수 없지만, 부분적으로는 알 수도 있겠다.

 

 

6. 그래서 수학과 소프트웨어 개발은 상당히 친하다. 달리 말하면 튜링머신에 대한 탐구는 현대 수학이 어려워하는 문제를 풀어낼 수 있다. AI가 코딩을 할 수 있는 세상에서 이러한 추상적인 접근법들이 수학에 돌파구를 마련할 수 있다. 그리고 그것은 소프트웨어 개발의 어떤 혁명을 이뤄낼 수 있다. 기계어 수준의 자동 튜닝이라던가, 절차 최적화를 기계가 자동으로 할 수 있는것 아니겠는가?

 

7. 소수(prime number)에 법칙성을 발견하면 압축을 어마어마하게 할 수 있는 것도 같은 이슈이다.

 

소프트웨어 개발과 수학은 이렇게 너무나 가까이 있는 것들이 수두룩 하다. 둘다 기계를 다루기 때문이다. 이 이야기가 많은 소프트웨어 개발자들에게 영감을 불러일으키면 좋겠다.