Heart’s Develop Inside

MS가 Windows Vista 의 다운그레이드를 제공하기로 했다는 기사가 나온지도 꽤 되었다.

Windows XP 때에도 98, ME, 2000 에서 넘어가는 과도기에 다운그레이드가 제공되는 일은 없었는데,
얼마나 사람들이 답답해했으면 하위 버전 다운그레이드를 제공할까…

하긴… 개발자인 나도 잠깐 써보고 ‘별로…’ 라는 생각이 들었으니…

MS-DOS에서부터 UNIX 체제처럼 유저별 권한을 복잡하게 지정하고 권한별로 기능을 막았으면 사람들이 썼을까?
일단 무엇보다도 ‘유저가 쓰기 편하게’ 를 목표로 바뀌어 온 MS의 OS 인데…
그런 의미에서 XP -> Vista는 개발자나 일반 사용자나 정말 쓰기 쉽지 않다. 아니, 쉽지 않다기보다 쓰다보면 슬슬 짜증난다. UAC, IE7 프로텍트 모드, A/X 지원 등등…
MS가 UAC를 넣은 이유가 이해가 안가는 것도 아니지만, 뭐 할 때마다 ‘확인’ 선택하는게 나도 짜증나는데 일반 사용자들은 오죽할까?

자체적으로 리소스도 엄청 먹어대고(OS 깔끔하게 돌리려고 컴퓨터 바꿔야 될 정도), 어플리케이션 호환성도 아직 해결된 것 같지 않다. 특히 게임에 대한 호환성이 떨어진다는 이야기가 많이 나돌고 있고, 실제로 사촌동생 PC에 ‘메이플 스토리’ 를 호환모드 없이 실행해 보니 실행은 되지만 곧 다운되어 Win XP SP2 호환으로 설정해야 했다.
호환성 모드로 해결해야 된다는 건 미봉책이지, 해결된 건 아니다.

그나마 희소식은, 비스타 SP1이 클로즈 베타로 돌고 있다고 하는데, 이걸로 사람들의 외면을 받고 있는 비스타가 XP를 밀어낼 수 있을지…
어찌됐던 비스타는 호환성이 가장 문제이고, 편의성 떨어지는 게 두 번째이다. 이거 두 개는 XP에서 비스타로 업그레이드 하는 데 엄청난 장애로 남아서 MS를 괴롭힐 듯…

조엘이 엄선한 소프트웨어 블로그 베스트 29선 - 조엘 스폴스키 지음, 강유.허영주.김기영 옮김/에이콘출판

‘조엘이 엄선한 블로그 베스트 29선’ 이라는 책 중에 1~10번 까지의 내용을 읽고 인상깊은 포스트에 대해서만 제 생각을 적어 봅니다.

각 포스트는 원문 링크를 달아 두지만, 한글은 당연히 아닙니다 ^^;; (그리고 전 한글 번역서를 읽고 있겠죠? ^^;;)

<1> 스타일은 언어 요소다.(켄 아놀드)

요약하자면 “코딩 컨벤션을 아예 컴파일 체크에 포함시키자” 라는 것

소스를 버전 관리 시스템에 넣어 관리해 본 사람이라면 쌍수를 들고 환영할 것 같다.

작업 하나 하고 나면 commit 대상 파일 리스트 중 상당수가 내용변화 없는 포매팅 변화, 빈 칸-탭-엔터 추가 등에 의한 변경 감지이다.

commit 리스트에서 삭제하기 위해 revert를 해 주는 작업도 한두번이지, 여러 번 하면 정말 짜증나기 일쑤…

게다가 같이 쓰는 코드를 commit 해 놨는데 상대가 자신의 코드 컨벤션에 맞게 리포매팅을 해서 다시 commit 한다면

분명 언젠가 둘 중 하나는 머리에서 김이 날 것이다.

하지만 띄어쓰기 하나하나에 에러를 내뱉는 리눅스 셸 프로그래밍을 해 본 사람이라면 이것도 편하지만은 않다는 것을 알고 있을 것이다.

(’띄어쓰기가 잘못되었다’ 라고 에러로 친절하게 알려주지 않기 때문에 한참을 고생한 기억이 난다.)

컴파일 체크에 코딩 컨벤션을 포함시키는 것은 기발한 아이디어인 것 같긴 하다.

하지만 이를 사람에게 전적으로 위임하는 것은 그 나름의 불편을 초래할 수도 있으니까, 컴파일러 표준에 전처리로 표준 스타일의 리포매팅을 하도록 한다면 사람의 실수도 어느 정도 줄일 수 있지 않을까?

아니면 적어도 에러 메시지를 ‘스타일에 의거해서 …. 가 잘못되었다’라고 가르쳐주고 라인번호, 컬럼번호 정도는 알려줘야 될 듯…

<3> 프로그래머 아웃소싱의 단점(마이클 빈)

골치아픈 개발, 그냥 사람 쓰고 편하게 편하게 갈 수 있으면 다 그렇게 해 왔겠지…

국내에서 A/S 센터 아웃소싱 하는 H/W(PMP, MP3 등)회사들… A/S때문에 소비자들에게 이미지 안좋아지고 있다.

자신의 회사처럼 열과 성의를 다하지 않으니까… 그렇게 할 이유가 별로 없고…

무엇보다도 개발은 발전, 혁신이 필요한 것인데… 아웃소싱 인력에게 그런 걸 바라는 것은 무리가 아닐까?

<5> ICSOC04 강연 한 토막(애덤 보스워드) - 원문 포스트 사라짐

KISS(Keep It Simple, Stupid:간단하고 알기 쉽게 만드는 편이 좋다) 원칙이 갖는 유용성과 인터넷 컴퓨팅에 미친 영향에 대해 언급하고 있다.

상당히 긴 내용이지만 요약한다면 이렇게 되지 않을까 싶다.

어렵고 추상적이며 빡빡한 시스템은 스스로 붕괴하고 사람들이 찾지 않는 기술이 될 것이며, 쉬우면서 유연성 있고 자연스러운 시스템은 많은 사람들에 의해 애용될 것이다.

정말 중요한 것은 ‘기술’ 자체가 아닌 ‘기술’에 의해 처리되는 ‘컨텐츠’이기 때문이다.

<7> 비정상적으로 행동하는 애플리케이션을 막지 않는 이유는?(레이먼드 첸)

‘윈도우 호환성을 위한 몇 가지 트릭이 윈도우에 숨겨져 있고, 이는 버전이 넘어갈 때마다 계속 유지되어 오고 있다’고 한다.

(조엘은 예로 DOS->Windows로 OS 흐름이 넘어갈 때, ‘치명적인 버그’ 로 호환되지 않는 심시티를 위해 MS에서 손수 OS에서 패치한 것을 들었다.)

생각해 보면 당연한 이유인 것 같다.

현재 사람들이 Windows Vista로 마음 놓고 갈아타지 않으려는 이유, 과거 Windows 2000이 SP2 이전까지 찬밥 신세였던 이유는

OS의 결함이 아니라 기존 프로그램과의 호환성이 엉망이었기 때문이다.

그리고 그게 설령 프로그램 제작사의 잘못이더라도 사용자 눈에는 그렇게 보이지 않는다는 것이다.

OS가 컴퓨터의 메인 애플리케이션임은 맞지만, 내가 쓰고 있는 프로그램이 돌아가지 않는다면 활용가치는 뚝 떨어지는 것이니까…

<8> 환상적인 사용자 인터페이스(케빈 쳉, 톰 치)

Winamp가 이렇게 나왔다면 이미 옛날에 역사의 뒤안길로 사라졌겠지…

UI의 기준은 전적으로 사용할 유저에게 맞춰야 한다는 것을 제대로 보여주는 카툰인 것 같다.

<10> EA : 휴먼 스토리(ea_spouse) - 이 글은 2004년 11월에 쓰여졌고, 지금과는 다를 수 있다.

국내 IT 개발 사회(사실 IT 외의 많은 분야 포함)의 고질적인 문제인 야근…

설마 EA라는 미국 대형 게임 회사에서 국내에서나 가능한 일이라고 생각한 ‘월화수목금금금’ 야근을 아무일 없이(즉, 보상 없이) 시키고,

그 과정 또한 국내와 비슷하며, 그로 인한 이직률이 50%에 달했다는 점에 놀랐다.

불공평하고 반인륜적인 혹사, 그리고 반대하는 사람들은 시장논리에 의하여 버려지는, 사회적 강자와 사회적 약자와의 싸움.

‘너 나가면 다른 사람으로 채우면 된다’는 사람과 부품을 동일시하는 마인드.

이런 회사가 망해야 본보기가 될텐데… 망하기는 커녕 스포츠 시리즈 매년 나와 주니 왠지 기분이 착잡하다.

게다가… 글 아래의 리플이 주루룩 달린 것이 왠지 불안하다.

(EA만 그런 게 아니다라고 말하고 있는게 아닐까 해서… 웃긴건 리플에 국내 S모사도 나온다.)

@ IT 프로젝트 현실

신입 사원 때 이 그림을 접했을 때는 크게 공감가는 부분이 없었는데, 기업 상대의 솔루션 회사에서 일하면서 2년이 되어가는 지금 시점에 이 그림을 다시 우연히 보니까 완전 공감이 간다.

슬픈 것은 이 그림의 원본이 영어로 되어 있다는 점이랄까?

결국 인프라나 시스템이 잘 갖춰져 있는 외국 또한 이런 현실에서 벗어나지 못하고 있다는 이야기일 것이다.

그림의 내용에 덧이어, 개발자의 입장에서 최근 느끼는 가장 큰 문제는 구현이 완료되고 클라이언트 측에서 테스트를 수행하는 안정화 기간에서야 클라이언트 측이 시스템에 대한 이해를 하고, 마음에 안 드는 부분, 빠진 부분을 막 요구하기 시작한다는 점이다.

안정화 기간의 의미는 최종 테스트를 수행하고 에러 발생시에 에러를 수정하는 검수 이전 단계인데, 마치 2차 요구사항 반영 시기같은 상황이 일어난다.

결과적으로 프로젝트 후반기 일정이 완전히 무너지고 검수는 늦어진다.

왜 이런 비효율적인 프로세스가 관습적으로 내려오는 것일까?

내가 생각하는 가장 큰 이유는 시스템 도입 기업(일명 갑)에서 애초에 시스템에 대한 이해와 관심이 크지 않은 상태에서 인터뷰를 수행하고, 구현 이후 안정화 기간에서야 실제로 돌아가는 모습을 보고 ‘이거 불편하고 저거 잘못됐네, 이건 좀 넣어줘야겠다’ 식으로 실시간으로 오더를 내려버리는 것으로 보인다.

안타깝게도 안정화 기간이 검수 이전에 이루어지기 때문에 파워 게임에서 갑이 칼자루를 쥐고 있기에 개발 측에서 이를 거부할 수 있는 경우는 별로 없어 보인다.(검수 이후에 유지보수 기간에도 거부하기 쉽지 않긴 하지만… 영업 측에서 잘 풀어야되는 문제이긴 하다)

설계, 프로토타입 및 구현된 프로그램을 수시로 보여 주며 프로세스 진행 중간중간에 수시로 인터뷰하고 계속적으로 수정하는 방법이 그나마 선택할 수 있는 방법이 되지 않을까 생각되지만, 그렇게 협조를 잘 해줄 클라이언트가 있을지는 조금 미지수랄까…
사실 기술적으로도 쉽지 않은 문제이기도 하고, 일정 산정에 클라이언트 인터뷰가 곳곳에 추가된다면 불안정한 일정이 도출될 문제도 있을 것이다.

이렇게 아무리 고민해도 뚜렷한 방안은 없다. 하긴, 그러니까 SI 프로젝트가 몇 년씩이나 시행되어 왔지만 이런 문제가 전혀 해결되고 있지 않고 있겠지.

결국은 그 놈의 ‘손님은 왕이다’ 정신이 문제

이 글은 스프링노트에서 작성되었습니다.