컴퓨터 과학의 방대한 분야들 중에서도 특히 소프트웨어의 기초 지식에 관련해 공부할 때에 국내의 많은 서적과 온라인 자료상에서 흔히 발견하는 잘못된 표기로 "알고리즘"이라는 용어가 있습니다. 물론 제대로 알고 계시는 분들도 있습니다만 이 용어의 올바른 표기법은 "알고리듬"입니다. 비록 언뜻 보기에 양자의 표기는 초성 하나에서만 차이가 있고 대략 서로 비슷해 보이지만, 사실 이렇게 만연된 "알고리즘"이라는 그릇된 표기의 이면에는 보기보다 상당히 커다란 문제점이 도사리고 있습니다. 필자는 국어국문학에 전문적 지식을 갖고 있거나 해당 학계에 종사하는 사람이 아니면서도 이 문제의식에 대해 깊이 공감하기 때문에 여기에 간단하게 공유해 보고자 합니다...
소위 Integrated Development Environment(IDE), 즉 통합 개발 환경이라고 불리우는 도구들은 모두 그 자체에 코드 에디터를 내장하고 있습니다. 그럼에도 IDE를 사용하는 대부분의 개발자들이 이와는 별개의 텍스트 에디터를 설치해 두고 종종 사용하곤 합니다. 개발 도구의 발달사를 보자면, 텍스트 에디터는 범용 운영체제들이 등장할 때부터 함께 존재했으며 IDE가 보편화된 지금에 와서도 대체가 불가능한 유틸리티입니다. 텍스트 에디터는 가볍고, 빠르고, 개발 과정에서 반복되는 특정 조작들에 대해 실수를 줄여줄 수 있는 옵션들을 보유하고 있습니다.
개발자마다 개발 플랫폼 및 개인적 선호에 따라 다양한 텍스트 에디터를 사용하게 됩니다. 그런데 국내 뿐만 아니라 국제적으로도 상당히 잘 알려진 텍스트 에디터들 중에 한국의 개발자가 제작한 것이 있는데 바로 아크로에디트입니다. 아크로에디트는 위에서 말한 텍스트 에디터의 특징들을 매우 잘 살리고 있는 프리웨어입니다. 필자가 이 에디터를 처음 알게 된 것이 2002년경이니까 무려 15년을 넘겼을 뿐만 아니라, 지금도 꾸준히 업데이트되고 있는 당당한 현역입니다.
아크로에디트를 국내 개발자가 사용하다 보면, 일정 시간 후에 거의 반드시 찾아보게 되는 설정 옵션이 있으니 에디터의 글꼴 설정입니다. 대개의 경우 코드는 영문으로, 주석 및 데이터의 일부는 한글로 작성하는 수가 많다 보니 영문과 국문이 섞인 텍스트가 좀 더 눈에 잘 들어오게 할 수 없을까 궁리하게 되는 단계입니다. 그러나 아크로에디트 내에서는 한 가지 글꼴만 선택할 수 있기 때문에 영문과 국문의 글꼴을 달리 설정할 수 있는 방법이 없습니다.
만약 아크로에디트에서 글꼴을 영문 폰트, 가령 Consolas로 선택한다면 한글은 바탕 글꼴로 표시됩니다. 따라서 한글의 표시 글꼴을 제어하고 싶다면 애초에 맑은 고딕과 같은 국문 폰트로 선택해 두어야 하는데 이렇게 되면 반대로 영문의 표시 글꼴에 제약이 발생하는 것입니다. 그렇다면 영문을 Consolas로 표시하면서도 국문의 글꼴은 굴림체로 보길 원할 경우 어떻게 해야 할까요?...
이미 빠르게 자취를 감추고 있습니다만 불과 오륙년 전만 해도 웹에서 어도브 플래시라는 플러그인을 마주치는 것은 빈번한 일상이었습니다. 2000년대 초반부터 광범위하게 설치된 그 플러그인은, 마치 웹 브라우저에서 ActiveX가 갖는 브라우저 제약과 보안상의 취약성을 대부분 해결하면서도 기능적으로는 대등한 상위 호환의 기술처럼 잘못 알려져 있었습니다. 그런데 플래시보다 훨씬 이전에 매우 비슷한 첫인상으로 먼저 등장했던 기술이 있으니 바로 자바 애플릿이라는 것입니다. 자바 애플릿은 브라우저상에서 웹 페이지와 일체가 되어 구동되는 작은 프로그램이었고 플래시와 마찬가지로 넷스케이프를 비롯한 대부분의 브라우저에서 지원되었기 때문에, 이것을 사용해 개발자들은 브라우저 기반의 미니 게임을 만들고 웹 디자이너들은 애니메이션을 만드는 풍경이 유행하기도 했습니다.
지금은, 특히 국내에서는, 주로 웹 사이트 개발환경으로 널리 설치되는 JDK라는 키트의 본래 얼굴이 그러했다는 것을 기억하는 분들이라면 분명 중년의 개발자들일 것입니다. 이 JDK가 시대와 함께 여러 가지 부침을 겪으면서도 지평을 넓혀가며 살아남아, 바야흐로 세계 수십억 개 이상의 호스트에서 구동되는 프로그램들을 생산하는 도구가 되었습니다. 그런데 JDK의 최근 버전들에 와서는 개발자들조차 설치 자체에서 어려움을 겪는 경우가 늘어나고 있습니다. 그 주된 원인은 설치에 필요한 계정 권한의 제약에서 발생합니다.
특히 윈도 운영체제상에서 JDK를 설치하려다가 실패 메시지에 맞닥뜨리거나 영원히 끝나지 않는 프로그레스 바를 보며 의아해 하는 일이 많습니다. 사실 개발 플랫폼을 구성하는 과정 자체가 난관이 되는 일은 흔하지만, JDK를 다뤄보기도 전에 설치라는 첫 관문에서 막히는 데다가 과거에는 일어나지 않았던 문제이기 때문에 당황하기도 합니다.
개발자가 JDK 설치시에 이러한 현상이 일어난다면 어떻게 해결하는 게 좋을까요? 그 원인이 계정 권한에 관련되었다면, 더 많은 권한을 달라고 계정 관리자에게 요구해야 할까요?...
인터넷이 태동하던 무렵에 존재하지도 않던, 그리고 이메일과 FTP가 쓰이고 나서도 한참 후에야 나타난 프로토콜이 있습니다. 이 프로토콜이 현재에 이르러서는 FTP가 하던 역할의 대부분을 대체했을 뿐만 아니라, 지구상의 인터넷 사용자들이 가장 빈번하게 사용하고 또한 그들 중 대부분이 이름을 기억하는 존재가 되었습니다. 어쩌면 PC 앞에서 일하거나 활동하는 시간 내내 그 이름을 보고 있을 가능성이 높습니다. 그것의 이름은 HTTP입니다.
우리가 브라우저를 통해 포털이나 검색 엔진 사이트에 들어갈 때에, 상단의 주소줄 맨 왼쪽에 항상 들어가 있는 문자열이 바로 이 프로토콜을 의미합니다. 그런데 어느 순간부터 유명 사이트들에 접근할 때에는, 이 프로토콜의 뒤에 "s"라는 한 글자가 더 붙곤 합니다. 즉 HTTPS라는 이름이 HTTP보다 점차 더 많이 쓰이는 추세입니다. 그 "s"라는 글자는 Secure, SSL, 또는 TLS를 의미합니다.
보안성을 의미하는 한 글자가 더 붙어있는 만큼, HTTPS는 이전에 HTTP를 통해 주고받던 내용을 암호화함으로써 당사자들이 아니면 해독할 수 없게끔 만듭니다. 다만 사용자 본인이라 해도 브라우저만을 통해서는 해독된 모든 통신 내용을 파악할 수 없습니다. 브라우저에 표현되지 않는, HTTPS가 실어나르는 모든 정보를 해독해서 보려면 별도의 도구가 필요합니다.
피들러(Fiddler)는 바로 그러한 용도로 널리 사용되는 유틸리티입니다. 이러한 프로그램을 통해서 어느 호스트가 언제 무슨 내용을 보냈는지에 대한 원시 데이터를 분석할 수 있습니다. 그런데 전술했다시피 점점 더 많은 인터네트워킹이 HTTPS를 사용하고 있기 때문에, 피들러를 보고 있노라면 알 수 없고 필요도 없는 많은 트래픽이 눈에 들어오게 됩니다. 그러므로 내가 띄운 브라우저에서 접근하고 있는 웹 사이트들의 응답만 보려면 필터링이 필요해집니다. 매번 필터링하기보다는, 애초에 꼭 필요한 대상만 분석되도록 설정할 수는 없을까요?...
관계형 데이터베이스의 물리적 설계는 논리적 설계에서는 존재하지 않던 새로운 제약들 위에서 이뤄집니다. 물론 여기서 말하는 제약은 not null이나 chkeck와 같은 SQL상의 제약을 가리키는 것은 아닙니다. 그보다는 DBMS가 파일 시스템을 관계대수적 집합으로 추상화시킬 때에 발생하는 현실적인 장벽들이라고 할 수 있습니다.
대표적인 제약들 중의 하나로서, 테이블을 구성하는 열들간에 순서라는 개념이 발생한다는 점을 들 수 있습니다. 이는 애트리뷰트가 컬럼으로 실체화되면서 집합이 순서집합으로 협소해지는 과정입니다. 즉 {X}로부터 {X, <=}로 질적 탈바꿈이 일어납니다. 그러므로 DBMS의 입장에서 열의 순서는 본질적으로 고정된 것이며, 이 순서를 변경한다는 의미는 기존의 테이블이 사라지고 새로운 테이블이 생성된다는 것과 동일합니다.
이렇게 DBMS가 받아들이기 싫어하는 변화이더라도 가끔은 그것을 수행해야한 할 때가 있습니다. 그러한 경우의 상당수는 인간의 관점에서 중요한 열을 더 앞쪽에 두고 싶기 때문에, 그리고 그 열이 중요하다는 것을 나중에 발견하기 때문에 발생하는 경향이 있습니다. 그런데 만약 DBMS가 제공하는 도구가 그것을 거부한다면 어떻게 해야 할까요?
상용 DBMS로서 널리 사용되는 SQL Server를 예로 들면, 기본적으로 제공되는 SQL Server Management Studio(SSMS)에서 이러한 명령을 거부하게끔 설정되어 있습니다. 이는 "내부적으로 기존 테이블을 삭제하고 새로운 테이블을 만드는 작업이라서 위험합니다. 권장하지 않습니다"라는 의미입니다. 위험을 감수하고 이를 수행하도록 하려면 SSMS의 설정을 변경해야 합니다...