프로그래머가 빠질 수 있는 흔한 착각 9가지

프로그래밍 언어는 특별하다
일과 후 술집에서 테이블을 내려친다. ‘긴 선언문’을 쓴다. 상사에게 이번에야말로 이 새로운 언어가 모든 것을 바꿀 것이며, 키보드가 저절로 엄청난 소프트웨어를 만들어내, 모든 프로젝트가 마감 기한 한 달 전에 끝날 것이라고 장담한다. 그러나 결국은 변수에 발목이 붙잡히고, ‘if(조건)’ 논리로 테스트를 하게 될 것이다.

프로그래머는 자신의 코드에서 구조(체계)를 들여다보고, 여기에서 비효율성을 모두 없애는 것을 꿈꾼다. 그래서 공중 누각인 ‘프레임워크’,’스캐폴딩’, ‘플랫폼’, ‘아키텍처’를 상상하고, 모든 것이 몇 줄의 멋진 명령으로 구현될 때까지 현재 당면한 문제만 해결할 정도로 힘을 쏟으면서 씨름을 한다. 그런데 유감스럽게도 다음 과업에는 적용되지 않는다.

결국에는 이 모든 것이 기만이고 언어적인 치장에 불과하다. 컴퓨터는 트랜지스터로 만들어진다. 제아무리 현명하게 코딩을 해도 모든 코드는 코드의 갈림길에서 왼쪽, 또는 오른쪽 가운데 하나를 선택하는 것에 불과하다. 그 중간의 길은 없다.

프레임워크가 점점 개선되고 있다
최근 React로 웹 애플리케이션을 개발한 이유가 혹시 앞서 Vue로 만든 페이지가 마음에 들지 않아서 아닌가? 또는 워드프레스 인터페이스가 꼴사납고 시대에 뒤떨어져, 템플릿 엔진으로 구축한 일부 정적 페이지로 루비(Ruby)를 포장하지 않았나? 아니면 더 작고, 더 새롭고, 더 ‘쿨’한 마코(Marko)나 글리머(Glimmer), 고스트(Ghost)로 모든 것을 다시 쓰지 않았나? 프로그래머는 항상 완벽한 프레임워크를 찾는다. 그러나 이렇게 프레임워크를 쫓는 것은 무지개를 쫓는 것과 같다.

랄프 왈도 에머슨은 1841년 ‘자신감’(Self-Reliance)이라는 책에서 프로그래머의 삶을 예측했다. 그는 “사회는 발전하지 않는다. 한쪽에서 무언가 얻지만, 다른 쪽에서 그만큼 빠르게 잃어버린다. 발전은 단조로운 반복이다. 주어지는 만큼 뺏기는 무언가가 있다”라고 말했다. 프로그래밍 프레임워크에 딱 들어맞는 이야기이다.

개발자는 기존 프레임워크의 문제를 해결하기 위해 새로운 프레임워크를 만든다. 그러면서 새로운 문제가 초래된다. 우리는 이런 일들을 계속해 보고 있다. 프레임워크에 서버 측면의 렌더링을 추가하면 서버가 느려진다. 모든 것을 클라이언트에 넘기면 클라이언트가 느려진다. 어쩌면 새로운 기능은 시간과 코드, 대역폭이 새롭게 절충된 무언가일 따름일지도 모른다. 

Null은 수용될 만하다
현대 언어 디자인에서 큰 문제 중 하나는 null 포인터 처리 방법을 파악하는 것이다. 때로는 필자가 쓴 자바 코드 중 절반 정도는 포인터가 null인지 확인하는 것과 관련이 있다는 생각까지 든다.

일부 언어는 물음표로 null 여부를 확인한다. 도움이 되는 방법이지만, 문제를 완전히 없애는 것은 아니다. 많은 최신 언어들이 null을 없애 null 검증 문제를 해결하려 시도했다. 모든 변수를 초기화하면 null이 존재할 수 없다. 그러면 null 테스트도 필요 없다. 문제가 해결된 것이다. 이제 쉬어도 될까?

그러나 새 코드 몇 줄 이내에서 기쁨이 사라진다. 데이터 구조에 정보가 없는 공백이 많기 때문이다. 사람들은 줄들을 공백 형태로 남겨 놓는다. 때론 데이터가 아직 가용하지 않은 경우도 있다. 그러면 요소가 비어 있는지 판단하기 위한 술어(Predicate)가 필요하다.

요소가 스트링인 경우, 길이가 0인지 테스트할 수 있다. 타입(Type) 정의에 오랜 시간을 투자하고 공을 들이면, 특정 문제에 대해 논리적으로 근거가 있는 무언가를 찾아낼 수 있게 될 것이다. 그러나 누군가 스펙을 바꾸기 전까지 해당되는 이야기이다. 이런 일이 몇 차례 반복되면, 빈 변수를 의미하는 단순한 단어 하나를 원하게 된다. 

컴퓨터가 사람의 선택을 포착할 수 있다
성별을 판별해 적합한 대명사를 선택하도록 코딩하는 문제는 프로그래머들에게 아주 큰 ‘지뢰밭’이다. 컴퓨터는 고정된 목록과 잘 정의된 메뉴를 처리하는데, 사람들은 계속 규칙을 바꾼다. 남성과 여성이 아닌, 다른 젠더를 선택할 수 있게 해달라는 요구가 등장한다.

컴퓨터 사이언티스트는 이 문제를 제대로 풀지 못한다. 또 하나의 ‘우회로’ 계층만 추가시킬 뿐이다. 이 경우, 사람이 자신의 선택값을 입력할 수 있는 빈 스트링 필드이다. 그런데 예측불허인 누군가가 대명사에 “his majesty(폐하)”라는 표현을 사용한다. 누군가는 웃고, 누군가는 기분 나빠 할 것이다. 그러나 고정 목록으로 돌아갈 경우 다시 몇몇 선택값이 배제될 수 있다. 

이런 디자인 실패가 반복된다. 모든 사람들이 이름과 성을 입력하도록 강요하면, 누군가는 이름 하나만 입력할 것이다. 또 자신이 유니코드 문자 스트링으로 지칭되는 것을 원하지 않는 사람도 있을 것이다. 누군가 이름 스트링에 새 이모지를 선택했는데, 이모지가 최종 목록 중 하나에 들지 못한 경우도 있을 수 있겠다. 제아무리 컴퓨터에 유연함, 사람들의 변덕에 대해 가르쳐도, 사람들은 언제나 코드를 무용지물로 만드는 새로운 논리 폭탄을 만들어낸다.

유니코드는 ‘유니버셜 커뮤니케이션(보편적인 소통)’을 상징한다
자주 만나 사람들의 커뮤니케이션에 대해 정의하며, 여기에 반드시 포함시킬 기호, 그림 문자(이모지) 리스트를 결정하려 노력하는 성실한 위원회가 있다. 그런데 이들은 특정 이모지를 없애는 결정도 하며, 이는 일부 사람들의 마음을 상하게 만든다.

각종 밈(Meme)이 폭증하는 것이 이런 프로세스가 얼마나 헛된 프로세스인지 알려준다. 세상이 이모지의 종류에 제한이 있다고 판단하면, 문화를 상징하는 사진과 텍스트를 혼합해 사용할 것이다. 이 경우, 이모지 리스트가 소용이 있을까?

그리고 이모지 폰트 문제가 있다. 누군가는 귀엽다고 생각하는 폰트를 다른 사람은 싫어할 수 있다. 귀여운 이모지를 선택하면, 사용자의 스마트폰은 여러 다양한 브랜드의 스마트폰을 가진 친구에게 유니코드 바이트를 전송한다. 그런데 폰트가 달라 보기 싫은 이모지로 바뀔 수 있다. 이런 식의 문제가 발생하는 것이다.

사람의 언어는 일관적이다
개발자가 대응하는 방법들 중 하나는 텍스트 필드 형태를 만들어, 사람들이 원하는 것을 입력할 수 있도록 만드는 것이다. 개방형 주해 항목은 인간을 위해 만들어지며, 알고리즘으로 해석되는 경우가 드물기 때문에 문제가 되지 않는다.

진짜 문제는 텍스트 구조화 필드에 존재한다. 필자의 내비게이션은 내가 성인의 이름을 딴 도로명으로 안내할 때, “turn onto Street Johns Road(스트리트 존 로드로 진입)”이라고 말한다. 그러나 도로명에 어퍼스트로피가 붙을 경우 루프에 빠지곤 한다. 애석하게도 현실에서는 “St. John’s Road”가 “Saint Johns,” “St. Johns,” “Saint John’s,” 심지어 복수형인 “Saint Johns.”로 표시되는 경우가 흔하다. 미국 우정국은 추가 문자가 없는 규정된 주소 목록을 갖고 있으며, 임의의 주소들을 이런 규정된 형태로 바꾸는 정교한 알고리즘을 만들어 대처하고 있다.

시간이란 일관된 존재다
시간이 일정한 속도로 계속 흐른다고 생각할 것이다. 실제 그렇다. 그러나 컴퓨터는 그렇지 않다. 사람의 행동이 이와 관련된 규칙을 엉망으로 만들며, 이것이 프로그래머의 삶을 힘들게 만든다. 하루는 24시간이라고 생각할 것이다. 그러나 항상 그럴 것이라고 가정해 코드를 쓰는 것은 좋지 않다. 누군가 비행기로 미국 동부에서 서부로 이동했다고 가정하자. 이 사람의 하루는 27시간이다.

표준 시간대는 시작에 불과하다. 써머 타임 시간은 시간을 가감한다. 그것도 매년 바뀌는 주말에 그렇게 된다. 예를 들어, 2000년 미국에서 써머 타임 시간이 변경된 시기는 4월이었다. 올해는 3월 두 번째 일요일에 시간이 변경되었다. 또 유럽은 3월 마지막 일요일에 ‘써머 타임’으로 변경된다.

이것이 끝이 아니다.  애리조나는 써머 타임 시간을 사용하지 않는다. 그러나 애리조나에 위치한 나바호 네이션(Navajo Nation) 지역은 독립 자치 구역이기 때문에 써머 타임 시간이 있고, 이를 스스로 결정할 수 있다. 그리고 실제 그렇게 하고 있다.

아직 끝나지 않았다. 나바호 네이션 내부의 호피 네이션(Hopi Nation)은 나바호와 다른 방식을 추구하기 때문에 써머 타임 시간을 사용하지 않을 수 있다.

슬프게도 또 있다. 나바호에 속한 호피 네이션 내부에 작은 땅은 또 다를 수 있다. 정확한 지리 좌표를 사용하기 훨씬 더 어려워, 애리조나만 기준으로 정확히 시간을 추적하기 힘든 지역이다. 이런 주가 애리조나만 있는 것이 아니다. 인디애나도 이렇다.

파일이란 일관된 존재다
단순히 데이터를 저장하는 것이 컴퓨터가 꽤나 잘 할 수 있는 일로 보인다. 그렇다면 우리는 비트에 수 많은 논리적, 형식적, 철자적, 숫자적, 기타 형태의 불일치가 가득한 경우에도 비트를 복구할 수 있어야 한다. 그렇지만 유감스럽게도 그렇게 할 수 없다.

맥에 파일 시스템을 확인해 문제점을 고치라고 명령할 때마다 필자의 맥은 자신이 성실하게 수행한 ‘승인 권한 오류’ 목록을 제시한다. 내가 승인 권한을 주지 않았는데, 소프트웨어는 내 파일 시스템에 접근할 권한을 변경하는 권한을 어떻게 획득한 것일까? 

이는 파일 시스템이 사용자(전기를 공급하는 사람)와 머신(전기가 절대적으로 필요한) 간 맹약을 존중하지 않는 일부 사례일 뿐이다. 노련한 프로그래머들은 아마 파일에 포함될 것으로 예상되는 내용이 포함되지 않는 상황을 수백 가지를 언급할 수 있을 것이다.

데이터베이스 회사는 데이터를 일관되게 쓸 수 있도록 만드는 서비스를 제공하며 값비싼 대가를 지불 받는다. 그렇지만 이런 경우에도 문제가 발생한다. 결국 컨설턴트가 투입돼 잘못된 테이블을 고치곤 한다.

우리가 통제한다
우리는 우리가 만든 명령이 컴퓨터에게 할 일을 알려 준다고 생각한다. 이런 자부심은 대부분 사실에 근거를 두고 있지만, 그렇지 않은 경우도 있다.

어떤 경우일까? 분명히 프로그래밍 지식이 없는 일반적인 얼간이들에게는 해당되지 않을 것이다. 논리와 수학의 마법사인 우리 개발자에게 해당되는 이야기는 아닐 것이다. 그렇지 않은가? 

틀렸다. 우리 모두 힘이 없다. 어쩌면 우리는 머신이 무엇을 주든 받아들이는 ‘거지’에 불과하다. 일단 운영체제가 힘을 갖고 있다. 다시 말해, 우리가 원하는 것을 연산할지 말지 결정하는 것은 우리의 코드다.

좋다. 리눅스 배포판을 만들어, 우리가 테스트한 코드만 설치했다고 가정하자. 이 경우, 우리가 통제를 할 수 있을까?

아니다. BIOS가 컴퓨터에 대한 1차적인 권리를 갖고 있으며, 은밀하게 코드를 살짝, 또는 이보다 많이 변경할 수 있다. 클라우드를 이용하는 경우, 하이퍼바이저가 우리보다 더 큰 힘을 갖고 있다.

BIOS를 맞춤화한 부트 로더로 교체했다고 가정하자. 이 경우에도 머신 깊숙이 숨겨진 수 많은 펌웨어를 고려해야 한다. 디스크 드라이브, 네트워크 카드, 비디오 카드 모두 펌웨어에 가장 먼저 귀를 기울인다. 

여기에 그치지 않는다. CPU에도 누군가 명령을 할 수 있는 '숨겨진 갓 모드'가 있을 수 있다. 이에 대한 설명한 자료를 찾으려 노력하지는 말자. 그런 자료는 없기 때문이다. 이는 평판 높은, 공식 출하된 칩에도 해당될 수 있는 문제다. 누군가 숨은 의도를 갖고 추가로 칩을 숨겨 장착했을 수 있다.

작은 USB 플래시 드라이브에도 직접 결정을 내리는 코드가 내장된 ‘빌트-인(내장)’ 프로세서가 있다. 이런 임베디드 프로세스에 악성코드가 은닉해 있을 수도 있다. 책상 및 머신의 트랜지스터 구성요소 중 당신이 마음 놓고 부리는 요소는 단 하나도 없다는 의미다.

*Peter Wayner는 오픈소스 소프트웨어, 자율주행 차량, 개인정보 보호 강화, 디지털 트랜잭션, 스테가노그래피(steganography) 등 다양한 주제에 관한 16권 이상의 책을 저술한 저자다. ciokr@idg.co.kr