뒷담화 기록보관소

우연찮게 김창준님의 블로그에서 재미있는 퀴즈를 하나 발견했다. 개발자를 뽑는 어떤 회사의 채용 퀴즈인데, 시효는 이미 지난 문제지만 나 자신이 이런 종류에 필이 꽂히는 타입이라서 자세히 들여다보게 되었다.

퀴즈의 내용은 숫자를 입력 받아서 그에 해당하는 문자를 출력하는 것이고, 규칙은 엑셀과 같은 스프레드시트처럼 1은 A로, 2는 B로 변환하며, 26인 Z 다음부터는 AA, AB, … 에 해당된다. 프로그래밍 언어에는 제약이 없다. 필요하면 라이브러리를 동원해도 된다고 퀴즈 공고문에는 기재되어 있었다.

원래의 포스트에는 J언어로 아예 역함수까지 알짜배기로 짠 소스를 구경할 수 있었지만, 트랙백을 통해 다른 언어들로 시도된 내용을 보니 자바스크립트에 익숙한 입장에서 기왕이면 처음 발견했던 역함수 포함 J언어 버전과 격을 맞출 수 있는 코드를 구현해 보고픈 도전의식에 불타올라 버렸다.

<script>
function i2AB(n){return --n==-1?"":i2AB(Math.floor(n/26))+String.fromCharCode(65+n%26)}
function AB2i(s,p){p=p||0;return s==""?eval(p):AB2i(s.substr(1), "("+p+")*26+"+(s.charCodeAt(0)-64))}
</script>
<input id="num" value="65535">
<input type="button" value="1 to A" onclick="var n=document.getElementById('num');n.value=i2AB(parseInt(n.value))">
<input type="button" value="A to 1" onclick="var n=document.getElementById('num');n.value=AB2i(n.value)">

진지하게 Pure JS로 역함수까지 구현했다. 테스트는 바로 여기에서...

포스팅을 완성하고 나서 혹시나 싶어서 해당 회사 홈페이지에 들어갔더니 새로운 퀴즈가 걸려있다. 그건 다음 기회에...

P.S. 현재까지 출제된 모든 퀴즈가 수록된 좌표를 드디어 찾았다.

P.S. 하지만, 대부분의 철지난 퀴즈들은 이미지파일 소실로 확인 불가... -_-;

평소엔 잊고 있다가 누군가 언급하면 문득 '아, 그런 게 있었지!' 하며 떠올리는 사이트 중에 하나인 웹 아카이브. 오늘 평소에 자주 들르는 커뮤니티 사이트 자유게시판에서 누군가 언급하는 것을 보고선 예전에 한참 운영했던 개인 홈페이지의 모습을 오랜만에 다시 보니 촌스럽고 투박해도 새록새록 애환이 묻어나는 느낌이다.

그나마 예전 형태를 유지하는 모습들 중 가장 최근의 스냅샷 내용을 보니 참 그때는 나도 열정이 살아 숨쉬고 있었구나 하는 추억에 나도 모르게 사로잡히게 된다. 무식하면 용감하다고, 별로 잘 알지도 못하고 참 잘난 체도 많이 했고, 지금 보니 만감이 교차한다.

아마 그때처럼 다시 개인 홈페이지를 맨땅에 헤딩하듯 다시 운영하라고 하면 그때만큼은 절대 못할 것 같다. 그냥 알아서 집주인이 편의시설 대주는 입주형 블로거가 마음은 편하지. 띵가띵가~

굴림이냐 돋움이냐, 또는 11px이냐 12px이냐의 논란이 종지부를 찍을 줄 모르던 옛 시절이 아직도 기억에 생생한데, 벌써 하드웨어와 소프트웨어, 그리고 사람들의 인식은 세월을 훌쩍 넘어서 많은 변화를 겪었다. 이제는 2000년대 초 중반 스타일로 돋움 11px 글꼴로 설정된 블로그나 홈페이지는 뒤로 가기 버튼을 절로 찾을 정도가 되었다. 아니면 벌써 노안이 오고 있다거나. :-p

블로그는 읽기 편해야 한다. 내가 공들여 쓴 글들이 단지 눈이 아파서, 글꼴이 투박해서 폄하된다면 그 얼마나 속상한 일인가. 가독성이 뛰어나고 미려하며 눈에 착착 감기는 맛이 있는 글꼴을 되도록 설정하는 것이 필요하다. 여자들이 화장을 하는 이유와 근본적으로 다를 바가 없지 않겠나.

망할 굴림과 돋움을 제쳐두고 최근 추세에 맞춰서 가장 접근성이 뛰어나고 가독성이 좋은 글꼴들을 나열해 보았다. 천생 공돌이인 내가 무슨 능력이 있겠는가. 입 소문으로 좋다고 회자되는 것들 중에 추려냈을 뿐이지.

1. 애플 산돌 고딕 네오
2. 나눔고딕
3. 맑은 고딕

사실 글꼴 전문가들은 이보다 더 좋은 해법을 찾을 지도 모르겠지만, 내 입장에서는 철저하게 비용 대비 효과 측면을 고려하지 않을 수 없다. 여기서 비용이란 진입장벽이고, 효과는 글꼴의 기능성, 즉 가독성과 미려함이다.

효과 측면에서의 위 글꼴들은 일단 현재로서는 내 느낌상 100점 만점 중에 못해도 80 내지 90점은 먹고 들어가는 글꼴들이다. 하지만 여기서 주목할 점은 3개의 글꼴 중 두 가지는 해당 하드웨어(OS 혹은 플랫폼)에서 기본 글꼴이라는 점이다. 따라서 진입장벽이 낮다.

나눔고딕은 조금 특수한 경우인데, 실질적으로 나눔고딕 글꼴을 별도로 설치한 사람들이 꽤 있다. 옛날옛적 윈도 기본 글꼴인 굴림과 돋움에 한이 맺혀서 적극적으로 추가 글꼴을 설치한 사람들 중에는 아마 가장 저변확대가 많이 되어있는 글꼴이 아닌가 싶다. 하지만 그 여부를 단정지어 생각할 수 없고, '기본'을 추구하는 입장에서는 조금 조심스러운 면이 없지 않다.

블로그 글꼴 적용하는 이야기를 하는 많은 곳에서는 웹 폰트를 적용하는 이야기를 많이 하고 있다. 물론 예전에는 그 자체가 불가능에 가깝거나 되더라도 매우 한정적이었기에 비교적 적용하기 쉬워진 현재에 와서는 많은 시도와 반영들을 하고 있겠지만, 아직은 웹 폰트 적용방식은 깔끔하고 가벼우며 스피디한 웹 환경을 추구하는 내 지향점과는 그다지 맞지 않는 듯 하여 일단 배제시키려고 한다.

font-family: "Apple SD Gothic Neo", "Malgun Gothic", Sans-Serif;

스타일 정의(CSS)에서 위와 같이 지정하면, 가장 먼저 명시한 글꼴을 우선 적용하고, 해당 글꼴을 적용할 수 없을 때에는 다음 순서의 글꼴을 차례로 시도하여 적용한다. 그 어느 것도 적용 가능한 글꼴이 없다면, 가장 마지막에 명시된 Sans-Serif를 적용하게 되는데, 이것은 획의 끝이 장식이 없는, 즉 고딕 계열의 기본 글꼴을 적용하라는 뜻이다. 망할 굴림이나 돋움을 명시하지 않아도, 이정도 만으로도 충분한 설정이 된다. 추후에라도 '망할' 굴림이나 돋움 대신 브라우저 기본 글꼴로 좀 더 나은 글꼴이 설정되는 날이 오면 자동으로 해당 글꼴로 대체되는 효과까지 있으니 일석이조.

iOS보다 PC계열 사용자가 훨씬 많을 텐데 굳이 애플글꼴을 먼저 명시한 이유는, 애플이 글꼴에 죽고 글꼴에 사는 원래 그런 환경이기 때문이다. 가장 최상의 환경을 가진 사용자들은 얼른 선택하고 빠져나가라는(^^) 뜻으로 제일 앞에 명시한 것이고, 어차피 적용 우선순위에 따라 어지간하면 Sans-Serif까지 가는 일은 드물 거라 생각하여 설정한 내용이다. 어차피 iOS도 윈도도 아닌 환경에 대해서는 어떤 글꼴이 쓰이는지 잘 알지도 못하고, 괜히 설레발을 치는 것 보다는 해당 브라우저 사용자가 설정한 기본 글꼴을 존중하는 것이 바람직하다는 이유도 있다.

마지막으로, 글꼴의 크기도 좀 편안하게 읽으려면 11이나 12px같이 깨알 같은 촘촘함보다는 살짝 넉넉함이 묻어나며 너무 방만하지 않을 정도의 타협점을 여러모로 시도하다 결국 찾은 내 나름대로 적당하다고 생각한 크기가 15px이었다. 노안이 좀 더 심하게 온다면 여기서 더 커질 지도 모른다. :-p

보통 SQL의 Where절을 구성할 때에는 다음과 같은 빈번한 형태에서 벗어나기 힘들다.

WHERE col1=val1 AND col2=val2 AND …

천편일률적 형태이긴 하지만, 실제로 이런 형태로 대부분의 문제는 해결되기 마련이다. 하지만 SQL이 아닌 일반 프로그래밍 언어에서 많이 사용하는 if문에서처럼 조건문을 Where절로 구현하려면 어떻게 해야 할까?

이산 수학(Discrete Mathematics)에서는 참과 거짓을 다루는 명제와 조건명제에 대한 이야기가 나온다. 명제는 참인지 거짓인지를 명확하게 판별할 수 있는 문장이나 수식을 말하며, p, q, r 등으로 표현한다. 함축(조건명제)은 두 개의 명제가 다음과 같은 관계를 가질 때 성립된다. 각 행의 내용은 동일한 의미를 가지며, 첫 번째 내용은 예시 문장이다.

• "날씨가 화창하다" → "소풍을 간다"
• p → q
• if p then q

위의 내용은 진리표(Truth Table)에 의해 다음 수식과 논리적으로 동치(Logical Equivalent)한다.

~p ∨ q

한글로 된 최초 명제의 예시로 치환하면(의미적으로) 다음과 같다.

"날씨가 나쁘거나 소풍을 간다"

날씨가 화창하다면 소풍을 가는지의 여부에 따라 참 거짓이 판별이 나는 것이고, 날씨가 나쁘면 소풍 여부는 상관이 없게 된다.

SQL 이야기로 돌아와서, 무조건 어떤 수식을 검사해야 하는 것이 아닌, 특정 조건에 따라 검사를 하거나 하지 않는 여부가 달라지는 복합적인 조건이 있다면 대개는 SQL을 동적으로 생성하는 외부 프로그래밍 언어 레벨이나 조건별 지시자를 이용하는 쿼리 프레임워크 레벨에서 if문과 같은 기능을 이용하여 복잡하게 구성하려고 하는 시도를 많이 보게 된다.

WHERE 1=1 (if condition1 = value1 then) AND A=B (end if)

위에서 설명한 명제의 함축을 이용하면 SQL 내에서 논리적 수식 만으로도 이러한 의미를 동일하게 구사할 수 있다.

WHERE (condition1 <> value1 OR A = B)

OR가 들어가니 성능에 영향을 줄까 걱정을 할 수도 있지만, OR 연산자의 앞부분이 참이면 뒷부분은 실제 평가를 하지 않고 넘어가는 쿼리 옵티마이저의 특성을 생각하면 결론적인 성능차이는 걱정할 수준이 되지 못한다.

HTML 폼 입력란에서 엔터키 막느라 바쁜 양반들이 많다. 그나마 2000년대 초중반에는 몇 안 되는 개발자 커뮤니티 사이트 게시판에서 꼼수의 일종으로 조금씩 퍼지더니, 바야흐로 블로그 홍수시대에 와서는 온통 바이블이라도 되는 양 예제 코드랍시고 퍼 나르고들 계신다.

어디 한두 개라면 조용히 댓글 훈수라도 시도해 보겠건만, 검색엔진에서 수두룩하게 쏟아 나오는 결과 페이지들의 규모를 보니 이미 틀렸다.

심지어는 엔터키를 이미 가로챈 상황에서 역으로 엔터키 누르면 submit 되게 하는 방법이라 소개하는 웃지 못 할 블로그 내용도 있을 정도니 심각한 일이 아닐 수 없다.

form에 input type=text가 1개만 있으면 엔터누르면 서밋이 된다고???

얼마 전 우연찮게 재미있는 블로그 내용을 하나 발견했다. 블로그 주인장의 호기심과 댓글 릴레이 덕분에 실제로 새로운 사실을 알게 된 계기가 되었지만, 결국 온전한 폼이라면 어떻게든 submit이 되는 것이 원래 당연한 것 아닌가 하는 의견을 덧칠하고 싶다.

해외의 경우도 크게 다를 바가 없는 모양이다. 오죽하면 이런 글이 나올 정도니까.

The Enter Key should Submit Forms, Stop Suppressing it

jQuery팀 멤버가 하는 얘기니까 단순 헛소리라고 매도하려면 꽤 단단하게 논리 무장을 준비해야 하지 않을까?

다시 원점으로 돌아와서, 엔터키 이벤트 처리하느라 바쁘신 많은 웹 개발자분들에게 이런 이야기를 하고자 한다.

엔터키를 누르면 submit되는 것이 당연하다.

정상적으로 만든 폼이라면, TextArea 같은 특수한 입력 객체를 제외하면 엔터키로 submit되는 것이 당연하고, 그렇게 되어야만 한다. 원래 안 된다고? 그건 폼을 잘못 만들어서 그렇다. 아직도 A 태그로 만든 링크버튼으로 submit 호출하는 것이 정상적이라고 생각하는 착각에 갇혀있지 않기를 바랄 뿐이다.

폼 검사(Form Validation)는 onsubmit 이벤트 핸들러로 처리한다.

입력값 검증은 원래 onsubmit 이벤트 핸들러로 하는 것이다. 아직도 많은 사람들이 가짜 submit 버튼(A 태그 등의)에 달려있는 onclick 이벤트 핸들러로 폼 검사를 하고 있는데, 그런 건 안했으면 좋겠다.

스크립트에 너무 의존하지 마라.

폼 검사, Ajax 등 스크립트 기반 기능은 기본적인 마크업 내용의 편의성을 증대시키는데 사용되어야 하는 것이지, 필수가 되어서는 바람직하지 않다. 바람직한 웹 개발에서는 클라이언트 브라우저의 스크립트에 의한 폼 검사를 거치지 않아도 서버 측에서 입력 값에 대한 오류처리를 충분히 해야 하며, 적절한 UI를 제공해야 한다. 스크립트는 점진적 향상(Progressive Enhancement)에 있어서 하나의 측면일 뿐이다.

개발자는 보통 에디터 글꼴에 민감하다. 코딩 작업의 효율은 에디터 글꼴에 많은 영향을 받는다.

코딩에 적합한 글꼴은 우선 고정폭 글꼴이어야 한다. 가변폭 글꼴은 일관된 패턴 흐름을 제대로 살리지 못할 때가 많다.. 또한 글자 하나 혹은 구두점 하나의 변화에도 큰 차이를 나타내는 코딩의 특성상 그 차이를 극명하게 표현하는 고정폭 여부는 매우 중요하다.

또한 가독성이 뛰어나야 한다. 미려함 보다는 기능성이 중요하다. 척 보고 한눈에 알아볼 수 있어야 한다.

Fixedsys는 고정 폭이라는 특성과 함께 윈도 플랫폼이라면 기본으로 설치되어 있어서 접근성이 뛰어나다. 게다가 영문 기본이 다른 글꼴에 비해 굵직해서, 주석이나 메시지 내용으로 주로 쓰이는 한글보다 코드 내용에 집중할 수 있는 장점이 있다.

자체적으로 한글을 지원하지 않아서 보기 싫은 굴림체가 적용된다거나 역슬래시가 쓸데없이 원화표시로 대체된다는 단점을 제외하면 지금 막 윈도를 재설치 했거나 다른 자리에서 한동안 작업해야 하는 특별한 상황일 때 최상은 아니지만 최선으로서 급한 대로 설정하기 편한 점은 꽤 만족스럽다.

그런데 한가지 문제는 윈도7의 경우 Fixedsys가 설정가능 글꼴목록에 표시되지 않는 것이다. 따라서 Fixedsys를 사용하려면 윈도 설정을 한가지 변경해줘야 한다. 다음은 윈도7에서 Fixedsys를 사용할 수 있도록 하는 방법이다.

제어판 – 모양 및 개인 설정 – 글꼴 순으로 잦아들어가거나 혹은 윈도 키 + R 키로 'control fonts' 명령을 실행하면 글꼴 확인 및 설정 화면을 호출할 수 있다.

Fixedsys는 사용할 수 있는 다른 글꼴과는 달리 희미한 상태로 보이고 있을 것이다. 이는 글꼴 자체가 설치는 됐지만 사용할 수 있도록 활성화되지 않았다는 뜻이다. 글꼴을 사용하려면 이렇게 비활성화 상태를 사용가능 상태로 만들어주어야 한다.

글꼴설정화면에서 Fixedsys를 클릭하여 선택한 후, 상단의 메뉴 혹은 마우스 우클릭 팝업 메뉴에서 '표시'를 선택하면 해당 글꼴이 진하게 표시된다.

이로써 설정은 끝났다. 이제부터는 메모장을 비롯하여 각종 에디터에서 사용글꼴 설정화면에서 Fixedsys를 사용할 수 있다.

어제(2014. 9. 30) 서울 양재동에서 한국 인터넷 진흥원에서 주관하는 인터넷 이용환경 개선 가이드라인 설명회가 있어서 오랜만의 서울 나들이를 겸해서 출장으로 다녀왔다. 참가비가 따로 없는 행사임에도 경품들이 군침이 흐를 만한 것들이 좀 있어서 은근한 기대감을 떨치기는 힘들었었다.

평소에도 나름 관심을 가지고 적극적으로 공부하던 분야라서 그런지, 개인적으로는 설명회 자체에서 나오는 이야기들은 이미 알고 있는 내용을 머리 속에서 다시 정리하고, 흔히 말하는 국내 웹을 선도한다는 업체와 조직들의 생각들과 동향들을 파악하는데 더 의의가 있었다고 볼 수 있었다. 물론 몇몇 놓치고 있던 내용이나 막연하게만 알고 있던 것을 확실하게 개념 정립할 수 있는 기회가 된 부분도 있기는 했다.

HTML5 이야기가 워낙 요새 핫 이슈라서 이젠 완전히 HTML5 세상이 되나 싶기도 했지만, 아직 권고안 확정도 되지 않은 상태라는 걸 처음 알게 되고선 살짝 멘붕이 오기도 했다. 너무 분위기에 휩쓸려서 경거망동을 하는 우를 범하지는 않아야 하니 말이다.

새로운 웹 표준(후보)에 따라서 발 빠르게 대응하는 국내 업체들도 꽤 있다는 것을 전시장 입구에 설치된 홍보 부스들에서도 분위기를 읽을 수 있었다. ActiveX를 대체하는 기술에 대한 수요를 충족시키기 위해서 다들 열심이구나 하는 생각과 함께, 또 다른 한편으로는 어느 시점에서나 경제논리에 따라서 움직이는 것이 업계의 본능이기에, 이제 HTML5가 경제논리를 결정하는 요소가 됐구나 감상을 하게 되었다.

다만 조금 답답하게 느꼈던 점은, 그간 수많은 사용자들이 그렇게 울부짖어도 꼼짝도 하지 않던 국내 웹 환경에 영향력이 큰 업계와 조직들이 대통령의 말 한마디에 그렇게나 발에 땀이 나도록 뭔가 움직임을 보이려 노력한다는 것이 착잡하게 다가왔다는 것이다. 뭔가를 바꾸고 개선하려면 엉뚱한 곳에서 삽질하지 말고 청와대 신문고나 두들기는 것이 더 빠를 지도 모르겠다.

참가자 등록하고 받은 응모번호가 95번이었는데, 96번과 94번이 경품에 당첨되었다. 분해서 잠이 오질 않았다.

늘어나는 이삿짐

철새처럼 직장을 자주 옮겨 다니지 않고 한 직장에서 오랜 기간 있다 보니 개인 짐이 알게 모르게 많이 쌓여버렸다. 엊그제만 해도 라면박스 두 개 정도는 되는 크기의 포장용 박스 안에 잔뜩 들어가있던 서류며 책이며 업무바인더 등을 죄다 헤집어가며 살릴 건 살리고 버릴 건 과감히 분리 수거했다. 큰 박스가 총 3개가 있었는데, 겨우 두 박스는 처분했고, 마지막 남은 박스 하나가 사무실 내 책상 곁에 웅크리고 있는데, 쳐다볼 때마다 압박감이 장난이 아니다.

계기가 없었다면 정리하지도 않은 채 잊어먹고 살고 있었을 텐데, 짐이 들어있는 박스가 보관되어 있는 창고를 청소해야 하니 짐을 찾아가지 않으면 전부 버리겠다는 청소 담당자의 으름장에 겁먹고 박스들을 내 책상 앞에 꾸역꾸역 갖다 놓은 것에서부터 발단된 일이다. 아마도 청소가 아니었다면, 부서 이동 등으로 사무실을 옮길 때가 되어야 이런 기회가 찾아왔을 테지만 말이다.

날이 가면 갈수록 애물단지 짐이 늘어나는 주요 원인은 아마도 '놔두면 언젠가는 써먹을 곳이 있겠지'라는 생각이 영향을 주지 않았나 싶다. 사실 버리면서도 꽤 독한 마음을 먹어야 할 순간이 수시로 있었는데, 머리를 차갑게 하고 이성적으로 생각해보면, 꽤 오랜 시간이 흘러 나중이 되더라도 써먹어야 할 순간에 과연 써먹을 만한 가치를 계속 가지고 있을까 하는 판단에 통과하는 경우는 사실 많지 않다.

시스템 관리에도 이삿짐은 있다

지난주에 사내에서 굴러다니던 동영상 스트리밍 시스템 하나를 치우는 결재를 상신했다. 2008년도에 도입했던 장비와 소프트웨어가 세트로 구성된 시스템인데, 구입금액만 8천만 원을 상회하는 엄청 비싼 시스템이었는데, 결국 한두 해도 제대로 못써먹고 애물단지로 전락해버린 시스템이다.

어떻게든 살려보려고 이모저모 살펴봤지만, 기본적으로 ActiveX 기반으로 구축됐고, 실시간 촬영 및 송출장비가 Windows XP 기반의 맞춤형 장비로 되어 있어서 요새 같은 시절에 뭘 어찌 건드려볼 만한 성질의 것이 아니었다. 참고로, 현재 내가 근무하는 이곳의 업무시스템은 타도 ActiveX를 목표로 멀티 플랫폼, 멀티 브라우저를 지향하는 웹 표준 방식으로 구현되어 있어서, 시대를 역행하는 짓이 바람직하지 않게 된 배경도 있다.

하드웨어를 포함한 유형 시스템 만의 문제는 아니다. 업무규칙을 구현한 응용프로그램 같은 소프트웨어 구성요소 또한 시간이 지나면서 쓰지 않고 방치된 경우를 흔하게 접할 수 있다. 실제로 내 주변에서 겪었거나 현재진행형으로 겪고 있는 운영환경을 살펴보면 원활하고 효율적인 운영관리를 위해 정리할 필요가 있는 시스템 관리상의 구성요소들은 몇 가지가 있다.

하드웨어 및 인프라 시스템

위에서 설명한 동영상 스트리밍 서버 말고도 사실 내가 근무하는 부서에서 관리하는 시스템 중에 노후화 되어 활용도가 극히 떨어지는 시스템이 있다. 주로 용도에 더 이상 부합되지 못할 정도로 낙후되어 단순한 업그레이드나 부품교체 만으로는 감당이 되지 않는 경우가 대부분이다.

일반적인 시설이나 장비에 있어서도 각 회사나 조직은 이런 경우를 대비하여 내구년수나 감가상각을 관리하게 된다. 사실 일반적인 장비들에 비해 정보관련 기기들의 수명주기는 상당히 짧게 마련이다.

보통 관리를 평소에 잘 한 경우라면 실제 내구년수보다 훨씬 장기간 운영이 가능할 수도 있으나, 대체로 못써먹겠다고 판단을 하는 근거는 따로 있다. 시대가 바뀌어 표준이나 규격과 멀어진 펌웨어(혹은 운영체제 등)의 노후화로 지속적 지원이 불가능해 지는 경우도 더러 있다.

비싼 돈을 들여서 장만한 시스템일수록, 치우려고 할 때 최종 의사결정을 경영진에게서 얻어내는 과정에서 주요 걸림돌은 대안의 제시다. 손쉽게 추가로 돈을 들여서 새로운 시스템으로 교체하는 것을 허락 받는다면 제일 행복한 경우라고 볼 수 있겠으나, 보통 경영진은 이렇게 들어가는 돈을 제일 탐탁잖게 여기기 마련이다. 그냥 대형 폐기물 스티커 가격이 더럽게 비싼 경우라고 이해하고 적절히 행동하는 것이 필요하다.

데이터베이스

내가 직장에 몸담고 있는 동안 업무시스템에 사용되는 데이터베이스는 총 두 번에 걸쳐서 전면 재설계와 재 구축을 동반한 개편이 있었다. 초창기의 잔재는 이제 거의 찾아보기 힘들지만, 두 번째 데이터 모델의 잔재들은 아직도 DBMS에 담겨있는 테이블 목록에서 심심찮게 발견되곤 한다.

쓰지 않는 테이블이 남아있어도 당장 현재 운영 중인 시스템에 영향을 끼치진 않는다. 그래서인지 많은 사람들이 '굳이 놔둬도 큰 문제가 없는데 나중에 필요할 상황이 혹시 생기면 어쩌려고 함부로 지우려고 하느냐'고 말하며 무사안일을 추구하게 마련이다.

하지만, 데이터 품질관리를 철저히 하기 위해 각종 스키마와 데이터 모델을 표현하는 문서화를 현행화하기 위해 팔을 걷어붙이자마자 당면하는 과제는 쓰지도 않는 무수히 많은 쓰레기 더미를 마주하게 되는 상황에 맞닥뜨리는 것이다.

꼭 거창한 이유가 아니더라도, DB 접속 프로그램으로 테이블 목록에서 나한테 필요한 테이블을 찾기 위해 쓰지도 않을 테이블들의 산더미 속에서 대상 테이블을 매번 찾아내는데 쌓이는 스트레스 또한 티끌 모아 태산인 점을 간과해서는 안 된다.

참고할 점은, 비단 테이블뿐 아니라 DBMS에서 관리되는 요소인 뷰(View)와 트리거 및 내장 프로그램 객체(프로시저 등) 또한 테이블이 갖는 똑 같은 문제를 가지고 있다.

응용 프로그램

대규모 신규구축 사업 등을 통해 한꺼번에 개발을 하는 경우에는 업무용 응용프로그램 또한 각 단위 시스템 별로 해당 관련 업무부서의 과잉의욕을 충족시키려고 별의별 메뉴와 화면, 기능들을 잔뜩 만들기 쉽다. 하지만 구축단계가 끝나고 운영관리 단계로 이행되면서 기존 예상과는 다르게 업무환경이 변했거나 여러 가지 이유로 구축 시 만들었던 일부 응용 프로그램들은 찬밥신세가 되기 마련이다.

우리 회사에서도 프로그램 소스를 관리하는 저장소를 뒤져보면 버전 1.0에서 단 한번도 수정은커녕 활용되지도 않고 고이 모셔져 있는 소스들을 꽤 많이 발견할 수 있다. 그럼에도 불구하고 삭제도 하지 않고 계속 받들어 모시는 이유는 역시 '언젠가는 필요할지 몰라서'라는 이유 때문이다. 내 책상 옆에 모셔져 있는 짐 꾸러미 박스가 생각난다.

제일 좋은 것은 새로운 버전을 만들거나 더 이상 활용도가 없어졌을 때 등, 평소에 미리미리 적시에 판단해서 정리를 했어야 하는데, 무에 그리 바쁜지 '나중에 정리해야지' 하며 방치하고 있다가 결국 꾸역꾸역 쌓인 결과물들인 셈이다.

데이터베이스와 더불어 응용 프로그램들은 정리를 할 때에는 반드시 백업 대책을 잘 마련하고 시행해야 한다. 아무 대책도 없이 무작정 삭제해버린 후에 정말로 그 '만약'이라는 사태가 벌어져서 땅을 치고 후회하지 않으려면 말이다.

의외의 결론

경영진의 입장에서는 지금까지 언급한 유형과 무형의 자원에 더하여 인적자원 또한 고려대상이 될 수도 있다. 기술의 시류를 타지 못하고 퇴물이 되어버린 유지관리 업무 종사자들의 이야기다. 나 또한 언젠간 퇴물이 될 위험에서 언제까지나 열외일 수는 없는 노릇이니 은근히 겁나는 의외의 결론에 도달해 버렸다.

하드웨어는 계속 써먹기 위해서 지속적으로 업그레이드를 하고 부품을 교체한다. 소프트웨어와 응용 프로그램은 업무환경과 표준규약의 변화에 맞춰서 시시때때로 수정보완과 패치를 하여 지속적인 운영을 유지해 나간다. 치킨 집 차릴 목돈을 모아놓지 않았다면 끊임없이 공부해야 한다는 슬픈 이야기다.