'복잡도'에 해당되는 글 3건

  1. 2017.02.01 Regularization: 복잡도를 다스리는 법
  2. 2013.05.28 디버깅과 엔트로피
  3. 2013.04.10 더하기는 쉽고 빼기는 어렵다
Share           Pin It
개인적으로 전문용어가 어색하게 한글화되는 것을 별로 좋아하지 않는데, regularization도 그런 경우에 속합니다. 적당한 한글 용어를 찾기가 어렵습니다. 인터넷에 검색해보면 '규제화'라고 번역한 경우를 봤는데 페널티로 모델 복잡도를 제어하는 방식에는 유효하지만 다른 방식에는 조금 어색한 표현입니다. '일반화'는 그냥 generalization를 번역한 것 같지만 또 한편으론 학습오류와 테스트오류를 합친 generalization error를 줄인다는 의미처럼 보여서 나름 합당한 면이 있습니다. '정규화'라고 번역한 경우도 있는데 개발자들이 많이 사용하는 regular expression을 정규식이라고 부르니 정규화도 타당한 번역이지만 데이터를 정규 분포를 따르도록 만드는 normalization, 특히 N(0, 1) 분포로 만드는 standardization을 뜻하는 것 같은 느낌이 강합니다. 적당한 한글 용어가 뭔지는 모르겠지만 이번 글에서는 regularization을 다루려고 합니다.

Occam's Razor (오캄의 면도날)라는 유명한 관용구가 있습니다. 일반인들에게는 조디 포스터가 출연한 <콘택트>라는 영화에 언급되면서 유명해진 용어입니다 (물론 일반인들은 인식하지 못하고 놓쳤을 가능성이 높겠지만...). 어떤 현상을 설명하는 두개이상의 주장이 있다면 간단한 쪽을 선택하라, 즉 복잡한 것을 잘라내라는 의미입니다. 다른 많은 분야에서 유용한 원칙이듯이 기계학습에서도 매우 중요한 원칙입니다. 예를 들어, y = ax + b정도의 몇 개의 변수와 간단한 선형식으로 표현이 가능하다면 굳이 더 많은 변수와 다항식이나 log, exp 등의 복잡한 항을 추가하지 않는 것이 바람직합니다. 그렇지만 적은 변수와 간단한 수식으로 표현이 불가능하다면 더 많은 변수와 다양한 표현력을 가진 항을 추가해서 모델의 설명도를 높여야 합니다. 하지만 충분한 설명도를 가지는 모델을 더 이상의 개선없이 복잡하게 만드는 것은 지양해야 합니다.

이런 상황에서 보통 등장하는 이슈가 'bias vs variance', 'training error vs test error', 또는 'underfitting vs overfitting' 논쟁입니다. 세가지가 모두 다른 것을 나타내지만 또 결국 하나로 귀결합니다. 모델이 얼마나 심플하면서 설명력이 있는가의 이슈입니다. 보통 편차bias가 낮은 모델은 학습오류가 낮고 overfitting됐을 가능성이 높고, 역으로 분산variance가 낮은 모델은 학습오류는 다소 높더라도 테스트오류가 낮고 덜 overfitting된 경우입니다. Underfitting인 경우에는 학습오류과 테스트오류가 비슷하겠지만 둘다 일정 수준 이상으로 높을 가능성이 많고 특별한 경우가 아니면 평균과 분산 모두 높을 가능성이 있습니다. 어쨌든 기계학습에서 편차와 분산, 학습과 테스트 오류, 피팅(학습)의 정도를 따지는 것은 너무 복잡하지 않으면서 설명도가 좋은 (낮은 평균과 분산, 작은 학습 및 테스트 오류) 모델을 찾겠다는 의지(?)입니다. 비슷한 성능을 보이는 모델이라면 구조가 간단한 것이 일반적으로 generalization error가 더 적을 가능성이 큽니다. 그리고 그런 모델을 찾는 것이 오캄의 면도날이자 기계학습자들의 목표입니다.

이렇게 모델의 설명도를 유지하면서 모델의 복잡도를 줄이는 것이 regularization이라고 보면 됩니다. 아래에는 일반적인 복잡도를 다스리는 regularization 방식에 대해서 간단히 설명하려 합니다.

1. Early stopping
모델이 복잡해지기 전에 막겠다는 것입니다. 즉, 모델을 만드는 초기 단계부터 계속 검증하면서 모델이 급격하게 복잡해지는 것을 막는 것입니다. 기계학습에서 보통 전체 데이터를 학습데이터 training data와 테스트데이터 test data로 나눠서, 학습데이터로 모델을 학습시키고 테스트 데이터로 학습된 모델을 평가합니다. 하지만 early stopping에서는 전체 데이터를 학습데이터, 검증데이터 validation data, 테스트데이터로 나눕니다. 학습데이터로 모델을 학습시킨 후에 검증데이터로 모델이 너무 복잡한지를 계속 체크하면서 검증데이터의 분산을 낮게 유지시킵니다. 그렇게 학습 및 검증된 모델을 최종적으로 테스트데이터로 모델의 예측력을 평가합니다. 하지만 이 방법의 문제라면 학습, 검증, 평가 데이터로 3등분(보통 7:2:1정도)해야 하기 때문에 데이터량이 조금더 많아야 합니다. 데이터량이 많아서 3등분하더라도 어떻게 나뉘느냐에 따라서 최종 모델의 예측력에 편차가 생길 수 있습니다. 어쨌든 모델을 만드는 초기부터 다양한 반례를 들어가면서 모델이 한쪽으로 치우치지 않도록 만드는 방법입니다.

2. Noisy input
Early stopping에서는 데이터를 3등분할만큼 충분해야 한다는 조건이 있습니다. 하지만 정답이 있는 데이터는 늘 부족합니다. 기계학습 발전 방향의 한축은 부족한 데이터를 극복하는 거였습니다. Bootstrap으로 랜덤 샘플링으로 cross-validation하는 것도 방법이지만, 가용한 데이터에 일부러 노이즈를 줘서 다양한 데이터로 뻥튀기하는 방법도 있습니다. 정답(Y)가 있는 데이터(X)에 약간의 노이즈를 붙여서 X'를 만들었을 때, 노이즈가 크지 않다면 X'의 답은 여전히 Y입니다. 이미지 데이터가 인풋이라면 이미지의 전체 중에서 일부만 crop한다거나 상하좌우로 뒤틀리게 만든다거나 역전 및 회전시킬 수도 있고, 이미지 전체에 랜덤 노이지를 추가할 수 있습니다. 이미지 데이터가 조금 손상됐지만 여전히 그 이미지가 가리키는 객체에는 변함이 없습니다. 이렇게 다양하고 풍성한 noisy 학습데이터(인풋스페이스)로 학습을 시키면 더 전체 데이터로 학습시키는 것과 비슷한 효과를 주게 됩니다. 신생아를 해롭지 않은 세균에 노출시켜서 면역력을 키우는 것과 같은 원리입니다. 하지만 오답 또는 오분류되는 샘플이 뻥튀기됐다면...
 
3. drop-out
복잡한 모델에서 일부 파라메터를 의도적으로 제거하는 방법도 있습니다. 변수가 100개인데, 학습할 때마다 일부 변수의 학습데이터에 null값을 준다거나 일부 모델 파라메터를 0으로 강제하는 방식입니다. 즉, 특정 변수나 일부 파라메터가 없더라도 모델 전체의 설명력은 떨어지지 않도록 학습시키는 것입니다. 인공망에서 일부 은닉층의 몇몇 노드를 불용화해서 다른 남은 노드들만으로도 괜찮은 결과를 만들어내도록 의도적으로 모델을 불구로 만드는 것입니다. (좋은 비유는 아니지만) 100명이 해야할 일을 일부러 평소에 가끔 90명에게 주고 훈련시켜서 갑작스레 몇 명의 결원이 발생해도 시스템은 정상적으로 작동하게 만드는 것과 비슷합니다. 단점이라면 여러 drop-out 조건에서 모델을 학습시켜야 하므로 학습에 소요되는 회수/시간이 늘어난다는 점입니다. 적당히 작은 모델이면 큰 문제가 아니지만 수백 수천대의 컴퓨터를 이용해서 며칠동안 학습시켜야하는 크고 복잡한 모델이라면 모델링 비용이 만만치가 않을 것입니다.

4. 복잡도 패널티
가장 많이 사용하는 방법으로 복잡도에 페널티를 주는 것입니다. 즉, 모델이 복잡해질수록 페널티가 커져서 목적식 loss function이 다시 커지도록 만드는 것입니다. 학습 효과가 페널티 때문에 다시 커지지 않는 범위까지 학습을 시키는 것입니다. 기계학습을 공부하면 L1 regularization과 L2 regularization이라는 용어가 종종 등장하는데, 이것이 모델 복잡도에 대한 페널티를 부여하는 것입니다. 회귀분석 regression에서 L1은 계수의 절대값의 합을 페널티로 제공하는 Lasso regression이고 L2는 계수의 제곱의 합을 페널티로 부여하는 ridge regression이 있습니다. 이런 shrinkage 방식으로 모델을 단순하게 만듭니다. 새로운 변수나 파라메터가 추가될수록 페널티가 커지기 때문에 무제한 늘리지 않는 선에서 모델 복잡도를 결정하게 됩니다. 참고로, 보통의 경우 미분가능 등의 이유로 제곱항을 많이 사용하지만, regression에서 절대값을 사용한 lasso는 때론 feature selection이라는 부가 효과도 있습니다. 

5. Pruning 및 feature selection
이걸 regularization이라고 부르는 것이 맞을지는 살짝 고민되지만, 불필요한 복잡한 가지나 변수 등을 쳐냄으로써 모델의 복잡도를 관리하는 것이니 포함합니다. Pruning은 보통 decision tree에서 많이 사용하는 방식입니다. 즉, decision tree를 100% 분류하도록 leaf node까지 모두 만들면 tree가 매우 커고 복잡해집니다. 그래서 오분류가 별로 크지 않는 선에서 중간 node로 합쳐서 아래쪽의 가지들을 쳐내는 방식입니다. 다른 모델에서도 feature selection 방식을 통해서 불필요한 또는 덜 중요한 변수들을 제거해서 모델을 만듦으로써 모델의 설명도를 어느정도 유지하면서 심플하게 만드는 것입니다.

6. Ensemble 
이건 regularization 방식은 아니지만, 복잡도를 다루는 한 방식이기 때문에 함께 적습니다. 위에서는 모두 복잡도를 줄이는 방식을 설명했는데, 앙상블은 오히려 복잡도를 더 증가시키는 방식입니다. 복잡도를 증가시켜서 복잡도를 낮춘다는 좀 아이러니한 방식입니다. 앙상블은 여러 모델을 만들어 합쳐서 하나의 큰 모델을 만드는 방식입니다. 배깅 bagging이나 부스팅 boosting도 큰 틀에서 앙상블이라 볼 수 있습니다. 앙상블은 개별 모델은 복잡해서 특수한 케이스에 대해서 틀릴 수도 있지만 여러/많은 모델들이 합의해서 결론을 짓기 때문에 틀릴 가능성을 낮추는 것입니다. 개인은 틀려도 집단은 틀리지 않는 일종의 집단지성입니다. 실제 decision tree를 배깅한 random forrest가 classification에서 state-of-the-art가 된 것은 우연이 아닙니다. 그리고 요즘 가장 핫한 deep learning도 매우 많은 선형/비선형 regression을 스태킹 및 앙상블한 것입니다. 모델의 복잡도를 잡는다는 것은 예상치 못한 실패를 막겠다는 것인데, 일부가 실패하더라도 더 많은 나머지가 실패하지 않으리라는 믿음이 앙상블을 만듭니다. 개별 모델의 복잡도는 잡는 것이 아니라 많은 모델을 이용함으로써 개별 모델의 복잡도를 무시하는 것입니다. 하지만, 앙상블의 개별 모델 및 전체 모델도 위에서 설명한 다양한 방식으로 regularization합니다. Deep learning에서도 모델의 강건성 robustness를 높이기 위해서 drop-out하면서 학습시키거나 의도적으로 노이즈를 준 adversarial sample을 이용해서 학습시키는 등의 regularization에 대한 여러 연구가 있습니다.

또 다른 방법들이 더 있겠죠...

Regularization이 모델을 깔금하게 만들면서 일반 오류 (학습오류 + 테스트오류)를 줄이는 좋은 방법입니다. 하지만 이것도 data-poor 시대의 유물이기도 합니다. 최적화 문제에서 가능한 모든 공간을 빠른 시간 내에 탐색할 수 있다면 -- 현실적으로 불가능하지만 -- 복잡한 최적화 알고리즘이 필요없습니다. 학습데이터가 표본 샘플이 아니라 전체 population이라면 오버피팅되는 것에 문제가 없습니다. 어차피 테스트할 샘플도 이미 학습데이터에 포함됐을 것입니다. 앞서 일부러 노이즈 데이터를 만들어내서 모델의 강건성을 높인다고 했듯이 전체 스페이스를 커버할 수 있는 데이터가 있다면 regularization이 필요없습니다. 데이터 디멘즌과 사이즈가 다르면 경험적 직관과 달라질 수 있습니다. 그럼에도 generalization error를 최소화하도록 모델을 regularize하는 것이 여전히 필요합니다.

Regularization를 뜻하는 가장 좋은 한글 용어가 뭔지는 여전히 모르겠으나 현재 문제가 변수 한두개로 해결되는 선형 문제가 아니라면 이 부분에 대해서 미리 공부해두는 것이 좋습니다. 

===
B: https://brunch.co.kr/@jejugrapher
F: https://www.facebook.com/unexperienced

댓글을 달아 주세요

디버깅과 엔트로피

Gos&Op 2013.05.28 09:41 |
Share           Pin It

얼마 전에 내가 담당하는 (다양한 서비스 로그를 분석해서 순위 데이터 제공) 서비스에 문제가 있는 것을 파악하고 급하게 수정 작업을 진행했다. 적당히 테스트해보니 문제가 해결된 것같아서 그대로 커밋을 해버렸다. 다음날 실 서비스를 확인하는 별다른 문제가 눈에 띄지도 않고 데이터도 정상적으로 나오고 있어서 전날 버그수정이 제대로 이뤄졌다고 생각했다. 그런데 2주 정도가 지난 후에 조금 다른 문제가 계속 발생하고 있음을 깨달았다. 처음에는 다른 곳 (데이터 가공에서 변수에 따른 가중치 산정)에 문제가 있는 것같아서 또 급하게 수정했다. 그 다음날 서비스는 정상적이지만 조금 이상하다는 것을 느꼈다. 그래서 다시 테스트런을 하고 소스코드를 면밀히 검토하니 2주 전에 수정할 때 프로그램에 또 다른 간단한 버그가 심어졌음을 발견했다.

그 순간 깨달았다. 버그 수정이 또 다른 버그를 양산한다는 것을… 열역학에 따르면 자연상태에서 엔트로피는 증가할 수 밖에 없다. 프로그램 버그, 즉 프로그램 복잡도도 그런 것같다. 프로그램에 문제가 있어서 코드를 수정하거나 기능 추가를 위해서 새로운 코드를 삽입할수록 코드는 복잡해지고 미처 깨닫지 못한 새로운 버그가 심겨지는 것같다. 그래서 많은 개발자들이 새로운 이터레이션에서 기존 코드를 수정보완하기 보다는 처음부터 새롭게 프로그램을 짜는 것같다. 특히 다른 사람이 만들어놓은 코드라면 대략적인 로직만 이해하고 처음부터 다시 시작하는 경우가 많다. 그래도 생길 버그가 안 생기는 것도 아니다.

열역학에서 엔트로피를 증가시키지 않기 위해서는 외부에서 에너지가 꾸준히 공급되어야 한다. 프로그램 버그도 그런 것같다. 그 프로그램이 더 이상 복잡해지지 않고 버그 프리가 되기 위해서는 프로그래머 혼자서 밤을 새가면서 그 코드를 면밀히 검토한다고 해결되지 않는다. 심플한 경우라면 가능하겠지만, 몇천 몇만 라인이 넘어가는 프로그램인 경우 자신이 짠 코드에서 버그를 찾아내는 것이 여간 어려운 것이 아니다. 그렇기 때문에 두명이서 한조를 이뤄서 코딩을 하는 것을 권장하는 경우도 있다. 두 사람이 서로 의논해서 로직을 정한 후에 (때론 합의된 로직이 없어도 된다) 한명은 컴퓨터 앞에서 해당 로직을 구현하고, 또 다른 한명은 그저 등 뒤에서 프로그래맹되는 것을 지켜보면서 잘못된 것이 있는지 확인하는 그런 페어링을 추천하기도 한다.

이 방법론이 효과가 있다는 얘기는 자주 듣지만, 막상 내가 그렇게 프로그래밍을 해야 한다면 절대 못할 것같다. 익숙해지면 생산성이 향상되겠지만 익숙해지는 과정이 너무 길 것같다. 내가 짠 소스코드가 나 아닌 다른 사람에게 공개된다는 것은 마치 내 속살을 그대로 보여주는 것과 같을 거다. 많은 대중 앞에서 강연을 할 때도 그렇고 이렇게 불특정 다수를 향해서 생각을 글로 표현할 때도 대중 앞에서 발가벗겨지는 기분을 느낀다. 대중강연이나 블로깅의 경우 그래도 적당히 수위조절이 가능하기 때문에 완전히 발가벗겨지는 것같지는 않지만, 업무에서 발생하는 프로그램의 경우는 자의적으로 감출 수가 없기 때문에 더 어렵다. 완벽하고 심플한 프로그래밍이 가능했다면 커플을 이뤄서 코딩을 할 필요조차 없을지도 모른다. 커플코딩뿐만 아니라, 이제껏 담당하던 서비스를 타인에게 이관할 때도 비슷한 경험을 한다.

그래도 혼자서 코딩을 하다보면 버그가 버그를 부르게 되고 프로그램은 복잡해지기 때문에 엔트로피를 감소시키듯이 코딩에서도 외부의 에너지가 필요한 것같다. 처음에 조금은 불편하겠지만, 타인의 눈을 통해서 내 코드가 면밀히 까발려지고 테스팅이 된다면 결과적으로 더 만족할만한 결과물이 나올 것이다. 이를 잘 알지만 막상 실천은 어렵다.

(2013.05.24 작성 / 2013.05.28 공개)

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

나름 업계의 트렌드에 빠삭하다고 자부하기 때문에 새로운 서비스가 소개되면 일단 가입부터하는 버릇이 생겼다. 잘못된 자만심은 늘 불행의 씨앗이다. 그냥 기다렸다가 한번 정리가 된 서비스에 가입해서 사용하면 될 것인데, 일단 가입부터 해서 한두번 사용해보고 재미없어서 그냥 묵히는 경우가 많다. 초기 테스트를 위해서 소개된 웬만한 기능들은 다 활성화시키고, 가용한 친구들은 다 추가시키거나 친구요청이 들어오면 아무런 가이드도 없이 그냥 수용하는 경우가 많다. 트위터를 처음 사용할 때 조금 유명세를 탄 이후에 들어오는 대부분의 팔로잉을 맞팔로잉했고, 페이스북은 게임을 한다고 게임친구들을 마구잡이로 추가했고, 구글+도 친구요청이 오면 다 추가했다. 그렇게 막무가내로 친구나 기능을 추가하다보면 당연힌 사용빈도나 연결빈도가 낮은 기능/친구들이 생겨나고, 그렇게 될수록 서비스에 대한 흥미도 떨어진다. 그런데 막상 한번 활성화된 기능이나 추가된 친구를 제거하는 것은 어렵다. 더하기는 참 쉽다.

다행히 트위터는 4000명이 넘어선 순간부터 무분별한 맞팔로잉은 자제하고 있고, 페이스북은 더 친밀한 관계 유지를 위해서 게임친구들을 모두 제거했다. 구글+은 단순히 블로그글을 발행하는 이상의 활동을 하지 않기 때문에 여전히 계속 추가하고는 있고, Quora나 Pinterest 등도 큰 활용성이 없기 때문에 아직은 그냥 추가하고 있다. 그 외의 서비스들도 비슷한 경향이다. 지난 대선을 지나면서 트위터에서 나랑 맞지 않는 일부는 제외시켰지만, 여전히 4000명 가량의 팔로잉이 유지되고 있어서 혼란스럽고 줄려야겠다는 압박을 받는다. 페이스북도 2000명이 넘던 친구들을 200명으로 줄였지만 또 어느 샌가 500명을 바라보고 있다. 숫자의 압박을 받을 때마다 불필요한 연결을 끊어야겠다고 마음을 먹지만, 막상 실행에 옮기기가 너무 힘들다. 누구를 남기고 누구를 추가할 것인가?는 참 어려운 문제다. 빼기는 참 어렵다.

더하기는 쉽고 빼기는 어렵기 때문에 생각했던 전략이 초기화다. 물론 아직 한번도 실행에 옮긴 적은 없지만, 처음부터 다시 시작하면 깔끔해질 것같다. 트위터에서 모든 팔로잉을 정리한 후에, 다시 넣기를 하면 적어도 지금처럼 4000명을 팔로잉하는 일은 없을 것같다. 추가 여부를 판단하는 것이 어렵고 아리쏭해서 또 넣기도 하겠지만 지금보다는 깔끔한 목록이 만들어질 것같다. 페이스북에서는 그나마 쉬웠다. 오프라인에서의 관계가 있는 경우만 페이스북 친구로 남겼다. 실제로 오프라인에서 만났거나 학교나 회사 등으로 연결되어 잠정적으로 만날 수 있는 사람들만 페이스북 친구로 남겼다. 물론 한 열명정도는 전혀 일면식도 없는 경우거나 오프라인 관계가 없지만 친구로 등록된 경우도 있다. 매번 그들의 글을 보면 그냥 정리하고 싶은 충동을 느끼지만, 또 앞날이 어떻게 될지 모르니 그냥 남겨놓곤 한다.

핀터레스트도 한번 정리했던 적이 있다. 몇 가지 주제에 관심이 있어서 이런 저런 모든 사람들 -- 정확히 말해서, 보드 Board들 --을 팔로잉했는데, 어차피 사진이 올라오는 보드만 계속 사진이 올라오고 나머지는 별로 업데이트도 되지 않기 때문에 불필요한 보드가 많아져서 그냥 모두 제거하고 새롭게 관심보드를 빌딩했던 기억도 있다. 그렇게 가끔 한번씩 초기화에 가까운 빼기를 한 후에 다시 더하기를 하는 것은 그냥 많이 채워진 가운데 하나둘을 제거하는 것보다는 더 쉬웠다. 빼기가 어려울 때는 다 빼고 다시 시작하는 것도 좋은 전략이다.

포털 회사를 다니다 보니 많은 사람들을 만족시켜줘야 하기 때문에 이런 저런 다양한 서비스를 제공해주고 있다. 많이 사용되는 서비스들은 깔끔하고 리뉴얼도 잘 되는데, 그냥 구색을 맞추기 위해서 만들어진 서비스들이나 이미 경쟁사에 밀린 서비스는 업데이트도 잘 안 이뤄지고 아주 오래전 디자인/서비스가 그대로 인 것들이 많다. 그런데 막상 그런 서비스를 종료시키는 것은 참 어렵다. 그래서 서비스 종료 결정을 빨리 내리지 못하고 차일피일 미루면서 운영비용만 가중시키는 것을 종종 본다. 각 서비스에 담당자들이 있기 때문에 그들 입장에서는 자신의 서비스가 종료되는 것에 반감을 드러내는 경우도 있고, 또 혹시나 모르는 고객들의 불만도 고려되기 때문에 어떤 서비스를 남기고 어떤 서비스를 버릴지를 결정하는 것이 어렵다. 수십 수백 가지 서비스를 동시에 관리다보면 그런 일이 자주 발생한다. 이런 경우에도 제로베이스에서 검토해보면 어떨까?라는 생각이 든다. 100개에서 10개를 빼는 것이 아니라, 0에서 90개를 더하는 방식이다. 그러면 좀더 쉽게 서비스가 정리될 것같다.

서비스 뿐만 아니라, 현재 대한민국의 포털 탑화면에 노출되는 수많은 정보들도 그렇다. 모든 것들이 꼭 필요한 것이 아닌데, 예전부터 노출되던 것이라서 과감히 뺄 수가 없거나 아니면 새롭게 추가된 기능/서비스이기 때문에 잘 노출시켜줘야 한다는 논리다. 매년 주기적으로 메인화면의 리뉴얼이 진행되지만 정보의 위치가 바뀔 뿐 제거되는 것은 거의 없다. 사실 리뉴얼될 때마다 새로운 정보/기능들이 더 추가될 뿐이다. 그렇게 시간이 흐를수록 서비스의 질은 떨어지고 고객들은 혼란에 빠진다. 그렇기 때문에 처음부터 백지 화면에서 시작해서 꼭 필요한 것만 남기는 식으로 정보/기능을 추가하면 조금 더 깔끔한 첫페이지가 만들어지지 않을까? 최근에 야후의 탑화면이 간단해졌는데 (물론 다른 서비스들에 비해서는 복잡하지만), 어쩌면 그들이 했던 것이 이런 제로베이스에서 시작한 것이 아닐까?라는 생각을 해본다.

더하기는 쉽고 빼기는 어렵기 때문에 어려운 빼기에 골몰할 것이 아니라, 0에서 시작하는 더하기 전략을 택하는 것이 좋을 것같다. 그렇게 더해가다보면 또 복잡해진다. 그러면 그때 다시 0으로 만들어서 또 더해나가면 된다. 뺄 수 없으면 다시 시작하자.

뺄 수 없으면 파괴하라.

(2013.04.08 작성 / 2013.04.10 공개)

댓글을 달아 주세요