2019.10.30

'그 전제는 틀렸다'··· 프로그래머들의 흔한 착각 리스트업

Peter Wayner | InfoWorld
프로그래머들이 가지는 자부심에는 근거가 있다. 데이터베이스에 접근해 현실을 변화시킬 힘을 갖고 있는 이는 프로그래머밖에 없다. 세상이 돌아가는데 컴퓨터가 더 많이 개입될수록 프로그래머의 힘도 커진다.

그렇지만 교만은 패망의 지름길이다. 프로그래머는 분명히 힘을 갖고 있지만, 절대적인 힘과는 거리가 멀다. 또 공허한 때도 많다. 완벽한 코드란 없다는 점을 감안하면, 어쩌면 항상 공허할지 모른다. 또 컴퓨터가 실수를 저지르기 때문에 한계를 정해 놓아야 하는 때도 있다. 컴퓨터는 오류에 빠지기 쉽다. 우리는 이런 경험을 너무 많이 해서 아주 잘 알고 있다.

그렇지만 프로그래머들이 옳지 않은 가정을 설정함으로써 초래되는 문제들도 많다. 때론 맞지만, 항상 맞는 것은 아니기 때문에 이런 일이 일어난다. 이와 관련, 마크 트웨인은 “우리가 곤경에 빠지는 것 무언가를 몰라서가 아니다. 무언가를 확실히 알고 있다라는 우리의 착각과 오판,자만 때문이다”라는 명언을 남겼다.

프로그래머들이 맞다고 종종 확신하지만, 사실은 빈번히 그렇지 않은 ‘착각’들을 이야기한다.
 
ⓒ Image Credit : Getty Images Bank



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.



2019.10.30

'그 전제는 틀렸다'··· 프로그래머들의 흔한 착각 리스트업

Peter Wayner | InfoWorld
프로그래머들이 가지는 자부심에는 근거가 있다. 데이터베이스에 접근해 현실을 변화시킬 힘을 갖고 있는 이는 프로그래머밖에 없다. 세상이 돌아가는데 컴퓨터가 더 많이 개입될수록 프로그래머의 힘도 커진다.

그렇지만 교만은 패망의 지름길이다. 프로그래머는 분명히 힘을 갖고 있지만, 절대적인 힘과는 거리가 멀다. 또 공허한 때도 많다. 완벽한 코드란 없다는 점을 감안하면, 어쩌면 항상 공허할지 모른다. 또 컴퓨터가 실수를 저지르기 때문에 한계를 정해 놓아야 하는 때도 있다. 컴퓨터는 오류에 빠지기 쉽다. 우리는 이런 경험을 너무 많이 해서 아주 잘 알고 있다.

그렇지만 프로그래머들이 옳지 않은 가정을 설정함으로써 초래되는 문제들도 많다. 때론 맞지만, 항상 맞는 것은 아니기 때문에 이런 일이 일어난다. 이와 관련, 마크 트웨인은 “우리가 곤경에 빠지는 것 무언가를 몰라서가 아니다. 무언가를 확실히 알고 있다라는 우리의 착각과 오판,자만 때문이다”라는 명언을 남겼다.

프로그래머들이 맞다고 종종 확신하지만, 사실은 빈번히 그렇지 않은 ‘착각’들을 이야기한다.
 
ⓒ Image Credit : Getty Images Bank



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.

X