웹 기획, 복잡한 것에서 단순한 것으로

웹 서비스를 기획할 때마다 늘 처음엔 복잡했던 것이 기획의 후반부에 다가갈수록 점점 더 단순한 것으로 변화하는 것을 느낀다. 단순함으로 변신은 크게 세 가지 이유 때문이다.

첫째, 사람들이 서비스의 본질을 이해한다.
둘째, 사람들이 서비스가 너무 복잡하다고 투덜댄다.
셋째, 사람들이 사용자를 거론하기 시작한다.

이 세 가지 이유 때문에 처음에는 복잡했던 웹 서비스가 실제 구현 단계에 이르면 점점 더 단순해지기 마련이다. 그런데 이 과정에서 심각한 문제가 발생하기도 한다. 복잡함으로 인해 독창성이 있었던 웹 서비스가 단순해짐으로써 이해는 쉽게 되지만 남과 다를 바 없는 평범한 서비스가 되어 버리는 경우다. 이런 상황 또한 흔한 것이어서 간혹 기획자를 미치게 만든다. 거기에 '그건 구현이 안되요!'라는 불세출의 신공이 발휘되면 초기 웹 서비스가 공중 분해 되는 경우도 있다.

※ 단언 하건데 '그건 구현이 안되요' 신공에 대한 대응책은 단 한 가지, "그래 내가 할께!" 초식 외에는 없다. 그러나 이 초식을 구현할 경우 "이 회사가 니 회사냐?"라는 공격을 받고 주화입마에 빠질 수 있다.

기획자는 기획의 후반부에 이르러 이런 상황에 처하게 되었을 때 감사하는 마음을 일단 가져야 한다. 나는 오래 전에 vi 라는 유닉스 쉘에서 자주 사용하는 편집기를 배운 적이 있다. 이 편집기는 분명히 훌륭한 기능을 갖고 있었다. 그러나 내게는 단지 한 줄의 글을 쓰기 위해 수 십 가지 단축키를 외워야 겨우 사용할 수 있는 훌륭한 쓰레기로 보였다. vi를 개발한 사람의 역량에 대해 지금도 찬사를 보내지만 결코 친절한 편집기라고 부를 수 없었다. '편집' 메뉴를 클릭하는 단순한 행위조차 학습이라고 믿어 의심치 않는 일반인들에게 vi는 괴물과 같은 편집기일 뿐이다. 쓰레기는 좀 너무했고 그냥 일반인을 고통에 빠뜨리는 괴물 정도가 좋을 것 같다. 기획자는 자신의 기획이 너무 어렵다고 투덜대는 사람들이 주변에 있다는 자체에 감사해야 한다. 그들의 투덜거림은 대개 진실이고 그 투덜거림을 사라지게 만들지 못한다면 그 웹 서비스는 금방 얘기했던 '쓰레기' 혹은 '괴물'이 될 것이 분명하기 때문이다.

만약 기획자의 웹 서비스가 복잡하다고 투덜거리는 사람들이 개인적으로 기획자와 원한이 있거나 점심을 사 주지 않았다는 불만의 또 다른 표현을 그런 식으로 하는 것이 아님이 분명하다면 그 복잡함은 진실일 가능성이 있다. 그렇다면 분명히 '문제'가 발생했다는 말이다. 이 문제를 해결하는 방법은 싸움이나 설득, 혹은 포기가 아니다. 싸우는 건 무의미한 일이고 설득하는 건 시간 낭비고 포기하는 건 기획에 투입된 자원을 공중에 날려 버리는 일이다. 이 세 가지는 결코 문제를 해결하는 방법이 아니다. 문제를 해결하는 방법은 여러분도 나도 잘 알고 있듯 복잡한 웹 서비스를 단순하게 만드는것 외에는 없다. 복잡한 것을 단순하게 만드는 방법 중 내가 추천하고, 또한 지금도 실천하는 방법은 이렇다,

"복잡한 것은 뒤로 단순한 것은 앞으로"

사용자들에게는 단지 버튼 하나를 클릭하거나 두 세 가지 정도의 정보를 입력하는 정도만 요구해야 한다. 어떤 입력값이 존재하도록 만들고 나머지는 시스템이 알.아.서 해결해야 한다. 사용자가 백 가지 종류의 데이터를 입력하도록 요구하고 그 값을 기준으로 어떤 결과 값을 돌려 주는 시스템은 양돈장의 돼지도 할 수 있다. 그런 건 복잡한 시스템이 아니라 지저분한 시스템이다. 진정 복잡한 시스템은 사용자가 인지하지 못한 상태 즉 자연 상태의 입력값을 기준으로 그것을 검증하기 위한 몇 가지 또 다른 입력 값을 요구하고 나머지는 스스로 추론하고 예측하는 것이다. 추론과 예측을 통해 나온 값 즉 1차 분석 데이터를 사용자들이 어떻게 사용하는 지 추적한 후 또 다른 값을 추론하고 예측해야 한다. 그 과정이 무한대로 반복되어서는 안되고 일정한 시점에서 판단할 수 있는 값을 도출해야 한다. 그럴 수 있는 시스템을 기획할 수 있어야 비로소 복잡하고 단순한 시스템이라고 스스로 부를 수 있다.

즉 사용자는 아주 단순한 인터페이스나 입력 요청에 응하기만 하면 되고 그것에 대한 분석은 뒤에서 이뤄져야 한다. 인터페이스는 미려해야 하고 시스템은 복잡하고 성실하며 신뢰할 수 있도록 동작해야 한다. 마치 호수 위에 고아하게 떠 있는 백조가 수면 아래에서 가라 앉지 않기 위해 미친 듯 물질을 하는 것과 마찬가지다.

만약 누군가 기획자의 생각이 너무 복잡하다고 말한다면 그건 시스템 자체에 대한 비난이 아니라 사용자에게 너무 많은 것을 요구하고 있다고 해석하는 게 맞다. 그것은 분명한 문제이며 반드시 해결해야 하는 과제가 생겼음을 의미한다. 물론 주변 사람들이 복잡하다고 이야기하는 게 거짓일 수도 있다. 프로그래밍을 모르는 사람에게 컴파일러의 작동 원리를 이해시키려 시도하면 대부분의 사람들은 구역질을 하거나 '복잡하다'고 투덜대기 마련이다. 그런 경우 컴파일러의 작동 원리를 설명하는 것보다 "이것은 자동차의 엔진과 같다"고 말하는 게 낫다. 설령 그게 적절치 못한 비유라도 관계 없다. 그들에게 필요한 건 진실한 이해가 아니라 '일단 이해는 한 것 같다'는 느낌이기 때문이다.

가장 바람직한 관계는 모르는 건 굳이 알려 하지 말고 아는 것에 대해 논의하려는 태도를 모두가 견지하는 것이다. 그러나 이런 관계는 현실에 존재하지 않는다.