[Info]Tags categorized posts and contents patterns..

[AJAX] Ajax Code E xamples.. [Book] About the book.. [CSS] CSS Code E xamples.. [DB] Sql Code E xamples.. [DEV] All development stor...

레이블이 디자인인 게시물을 표시합니다. 모든 게시물 표시
레이블이 디자인인 게시물을 표시합니다. 모든 게시물 표시

2017년 1월 20일 금요일

[Book] 심플은 정답이 아니다..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

심플은 정답이 아니다 - 6점
도널드 노먼 지음
이지현 외 옮김
교보문고

인지과학의 대부인 도널드 노먼 교수의 책으로 난 UX에도 관심있고 디자인에도 관심(관심만..)은 있지만 UI나 UX를 설계하는 업무가 주업은 아니기 때문에 이쪽에 대한 사전지식이 깊지 않은 가운데 읽었기 때문에 읽고 받아들이는 수준도 그리 높지는 않았다.(이쪽도 점점 관심을 더 깊게 가져야 해서...) 디자인(웹에 대한 얘기도 나오지만 전체적으로는 모든 분야를 다루고 있다.)에서 단순함을 추구하는 경향가운데 단순함과 복잡함을 어떻게 봐야하는지를 자세히 설명하고 있다. 웹사이트들에 대한 얘기도 좀 나오긴 하지만 전체적으로는 길이나 건물, 길거리등 다양한 사례를 들면서 설명하고 있어서 이해하기가 어렵지는 않고 설명이 좋아서인지 너무 당연하게 느껴질 정도이다.(평소에는 이렇게 생각하기 어렵겠지만.) 이 책을 읽으면서 왠지 Martin Odersky의 Simple or Complicated?이라는 글이 생각났다.

우리가 사용하는 제품들이 복잡하므로 "단순하게 만들어라"라는 해결책이 그럴듯해 보이지만 실제 단순한 제품에 대해서 사람들은 "핵심" 기능이 없다고 불평한다는 것이다. 여기서 사람들이 생각하는 단순함이란 좋아하는 모든 기능이 들어있으면서 버튼 하나로 조작할 수 있는 단순함을 의미하는데 이는 불가능하다고 보는 것이 맞다다. 사람들이 향샹된 기량과 쉬운 사용을 원한다고 이를 더 많은 기능, 단순한 디자인으로 생각해서는 안되고 사람들이 정말 원하는 것은 이해하기 쉬운 제품이다. 그래서 인간 중심 디자인의 핵심은 복잡한 도구를 최적화하고 이해가 쉽고 즐거운 제품으로 바꾸어 복잡함을 길들이는 것이다.

사람들은 단순함을 원하지만 많은 멋진 기능을 포기하고 싶어하지도 않는다. 그래서 너무 단순하면 금세 지루해지고 너무 복잡하면 혼란스러우므로 결국 사람들은 중간 수준의 적절한 복잡함을 원하게 된다. 단순함은 복잡함의 반대가 아니다. 복잡함은 세상의 모습이고, 단순함은 마음의 상태다. 그래서 기술을 길들이는 것은 물리적인 문제가 아니라 심리적인 문제이다.

아무리 똑똑하고 의도가 좋더라도 엔지니어와 프로그래머는 기계의 관점에서 바라볼 수밖에 없고 평범한 사용자들이 아니다. 엔지니어들이 기계에 더 높은 지능을 주려고 노력하고 있지만 지금 상황에서 신경써야 할 것은 지능이 아니라 매너이고 이 책임은 디자이너에게 있다. 그래서 당황스런 사용자 행동에 대해서 짜증을 내기 보다는 이런 반응을 유도한 자신의 사회성을 반성해야 한다. 인간중심 디자인과 사회적 디자인에는 그 사물을 이용하는 사람이 진정으로 필요로 하고 원하는 것을 고려해 그들에게 도움을 줘야 한다는 철학이 깔려 있다. 한때는 "디자인"이 외관을 가리키던 적이 있었지만 지금은 좋은 상호작용이 좋은 디자인의 중요한 요소중 하나가 되었다. 그래서 내가 가진 디자인 원칙 중 하나는 오류 메시지를 없애서 오류가 아니라 도움이 필요한 상황으로 간주하고 스스로 설명할 수 있게 하는 것이다.

복잡함을 단순하게 만드는 가장 좋은 방법은 핵심 문제에 대한 개념을 새로 세우는 것이다. 디자인적 사고란 가장 먼저 진짜 문제가 무엇인지를 규정하는 것이다. 나는 이를 두고 "클라이언트가 해결해 달라고 하는 문제는 절대로 해결하지 마라"고 바꾸어 말한다. 클라이언트는 증상에만 반응하기 때문이다. 모든 과정에서 가장 어려운 일이기도 하면서 디자이너가 가장 먼저 해야 할 일은 정말로 해결되어야 하는 문제가 무엇인지를 찾는 것이다.

2016년 10월 31일 월요일

[EP] 개발자를 위한 ‘共感(공감)’ 세미나 12회 발표자료 : 혼자서 프로젝트 수행하기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

지난 7일 교보타워에서 공감 세미나가 있었다. 오랜만에 참석하는 공감세미나이긴 하는데 이번에는 KSUG쪽 세션을 맡아서 발표자로 참석을 하게 되었다. 처음에는 첫 세션을 맡았지만 낮에 갔다와야 할 곳이 생겨서 마지막 세션으로 바꾸었지만...

이번 세션은 그냥 사석에서 얘기를 나누다가 프로젝트 할때 아이콘 폰트는 뭐 쓰고 프레임웍은 뭐 쓰고 이런 얘기를 나누다가 fupfin님이 그걸 발표해도 괜찮겠다고 해서 시작되었다.(그때는 농담인줄 알았지만...) 잉여력을 발휘해서 학습 겸 개인 프로젝트를 많이 하는 편인데 그럴때 사용할만한 도구들을 소개하는 발표였다.


혼자서 프로젝트 수행하기 from Outsider

나는 네이밍을 잘 못하는 편인데 특히 이런 발표나 글 같은 경우 내용은 채우겠는데 제목짓는 건 참 어렵다. 나름 고민해서 지은 제목이긴 하지만 개인 프로젝트를 하면서 도움이 될만한 도구들의 소개가 위주인데 제목에서는 잘 안타난것 같아서 아쉽다. 처음에 발표하기로 하고 이런 저런 유용한 도구를 소개하는 것도 괜찮겠다고 생각은 했지만 막상 발표준비를 하다보니 발표시간만큼의 분량이 잘 생각나지 않았다. 상황별로 누가 물어보면 뭐 쓰면 좋겠다 라고 대답해 줄 수 있겠지만 막상 처음부터 생각하니까 "내가 무슨 도구를 쓰더라", "이 도구는 다들 알고 있는 것 아닌가?"하는 생각이 많았다. 그래서 처음부터 기획하고 디자인하고 서비스하는 과정에서 내가 사용하거나 참고할 만한 도구를 위주로 자료를 만들었다. 이런 도구를 설명하는 발표는 해당 도구나 서비스를 아느냐 모르냐의 차이일뿐 어떤 사전지식이나 내공(?)이 필요한건 아니라서 꽤 유용하다고 생각하지만 자칫하면 다들 하는 너무 쉬운 것만 말할 수도 있어서 조심스럽기도 하다. 다행히 끝나고 몰랐던게 많았다고 해주신 분들이 계셔서 다행이었다.

추가적으로 기존에는 발표자료를 만들때 그림을 많이 넣는 편이다. 이전에는 거의 전 페이지에 이미지를 넣어서 만들었는데(이미지 찾는데 시간이 엄청 걸린다.) 최근에는 발표내용을 전달하는데 얼마나 유효한가에 대해서 좀 의문이 들었다. 발표자료 만드는 스킬을 좀 더 올리고 싶은데 적절한 상황에서 이미지를 활용하는 것은 전달에 도움이 되지만 그냥 습관적으로 이미지를 넣어서 만드는 경우도 많은 것 같아서 이번에는 이미지를 좀 자제하고(스샷이 많았지만) 텍스트를 넣으려고 했다.(발표자료 만드는건 역시 어렵;;;)

2016년 5월 4일 수요일

[Book] 디자이너가 아닌 사람들을 위한 디자인북..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

디자이너가 아닌 사람들을 위한 디자인북 - 6점
로빈 윌리엄스 지음
윤재웅 옮김
고려원북스

일단 책에 대한 얘기를 잠시하면 어딘가에서 누가 괜찮다고 하는 얘기를 듣고 6개월정도 전에 샀는데 오늘 리뷰를 쓸려고 들어가보니 그사이에 절판이 되고 몇일 전에 개정판이 나왔다. (읽지도 않았는데 개정판이 나온것 보다야 낫지만 ㅠㅠ)

평가를 하자면 나쁘지도 않지만 나한테는 뭐 크게 좋지도 않았다. 이 책의 첫장에는 상당히 인상적인 이야기로 시작하고 있다. 조슈아 나무 이야기라는 건데 식물도감에서 죠슈아나무라는 특이한 모양의 나무가 소개되어 있어서 이런 나무가 우리 동네에는 없을꺼라고 생각했는데 동네에 나가보니 곳곳에 죠슈아 나무가 있었고 삼십년동안 살면서도 기억에 없었는데 이름을 알고 구별할 수 있게 되자 알아볼 수 있게 되었다는 이야기이다. 실제로 살다보면 이러한 일은 상당히 많이 있다.

하지만 나에겐 이 이야기가 가장 인상적인 내용이었다. 이 책은 디자인의 원리를 배치, 정렬, 반복, 대비 4가지로 설명하고 있고 그에대한 상세한 내용을 예시를 들어서 설명하고 있다. 뒷부분은 색상과 폰트에대한 얘기로 폰트부분에 대해서 꽤 많은 내용을 참고하고 있다. 전에도 디자인원리는 좀 찾아본적이 있기 때문인지 크게 인상적이지는 않았지만 디자인에 대한 기초가 아예 없다면 설명은 쉽게 해놨기 때문에 볼만할 것 같다. 제목대로 디자이너가 아닌 사람들을 대상으로 하고 있기 때문에 쉽게 설명하고 있는데 나한텐 좀 너무 쉬웠던 것 같다. 중요한 내용이지만 어느정도는 알기에 새로 배우거나 하는 느낌은 없었고 이런거 안다고 디자인이 되는게 아니라.. ㅠㅠ

디자인 책의 번역서에서 아쉬운 부분은 보통 예시가 영문을 기준으로 되어 있다는 것이다. 어설프게 예시를 갈아치우는것 보다는 낫지만 한글과 영문은 차이가 크기때문에 아쉬운 편인데 이 책에는 한글에 대한 설명이 많이 나와있다. 원서에 그렇게 되어 있지는 않을것 같은데 따로 설명이 없기 때문에 역자가 추가한것인지 어떤지는 모르지만 영문부분설명 뒤에 한글폰트를 쓸때 어떤 특징들이 있는지를 꽤 자세히 설명하고 있다. 이부분은 상당히 도움이 되는 부분이라고 생각한다. 그리고 이 책의 대부분의 예제는 명함, 광고 같은 인쇄물에 집중하고 있다. 기본적인 원리야 동일하겠지만 웹이나 어플리케이션만 주로 만지는 나한테는 인쇄물에 집중되어 있는건 좀 아쉬운 부분이다.(물론 이는 내가 책에대한 사전조사가 부족했기 때문이겠지만.)



2016년 3월 3일 목요일

[EP]켄트 벡(Kent Beck) 초청 세미나 #1..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

지난 4일 애자일컨설팅과 (주)STA컨설팅의 주최로 켄트 벡(Kent Beck)의 초청 세미나가 한국과학기술회관에서 있었습니다. 켄트벡은 XP(Extreme Programming)와 TDD(Test Driven Development)로 유명하신 분으로 한국에는 처음 오신 것으로 알고 있습니다.

켄트벡의 유명세가 있는데 초반에 반응이 좀 뜸하길래 회사 분위기도 살피고 여유있게 있다가 보니 허락받고 신청하니까 대기자로 들어가서 하마터면 못 갈뻔했습니다. 흔치않은 기회였는데... 대기자가 너무 많아서 1일에 추가 세미나로 200명을 더 개최하고 2일전에 대기자차례가 돌아와서 참여하게 되었습니다. 지원은 받기 힘든 상황이라 약간 세기는 했지만 과감히 자비로 비용을 부담하고 갔다왔습니다.

사용자 삽입 이미지

세미나는 켄트벡이 최근에 연구중이라는 "Responsive Design: Wehn, How, and What(반응적 설계: 언제, 어떻게, 무엇을)"에 대해서 진행되었습니다. 말자체로 살짝 느껴지기는 하지만 좀 생소하기는 한 말입니다. Responsive Design.... 켄트벡의 수준이 높기도 하고 그전에 들리는 얘기로도 켄트벡의 세미나는 약간 추상적인 얘기도 많이하고 공부해놓고 가야된다고 해서 어느정도 이해를 할 수 있을지 가기전에 좀 고민되기도 했습니다.

켄트벡 소개 : 내가 보는 켄트벡(김창준)

세미나는 애자일 컨설팅의 김창준님이 켄트벡을 간단히 소개하는 시간으로 시작되었습니다.
먼저 동양과 서양 사람들의 생각하는 방식의 차이가 있다는 얘기를 하셨는데 강아지, 소, 풀 3가지중에서 다른 것을 하나 고르라고 하면 동양사람들은 맥락적인 행위로 판단을 하고 서양사람들은 존재론적으로 생각하기 때문에 동양사람들은 강아지를 고르고 서양사람들은 풀을 고른다는 얘기였습니다. (저는 강아지를 고르게 되더군요. 흠....)

켄트벡이 스스로 꼽은 자신의 키워드는 아래 3가지였습니다.

  • 개발자가 작성하는 TEST
  • 패턴
  • XP (Extreme Programming)
TEST는 에릭감마와 같이 만든 소위 xUnit이라고 말하는 테스트 유닛으로 대표되고 최근에는 개발자들에세 테스트프레임워크의 지원이 언어를 선택하는 기준중 하나가 되어가는 분위기라고 합니다. 김창준님은 켄트벡이 GoF보다 더 패턴의 선구자라고 생각하고 있으며 크리스토퍼 알렉산더의 책을 보고 87년 UI패턴에 대한 논문을 썼으며 GoF의 패턴책은 어려운 감이 있는데 켄트벡의 책은 이해하기가 쉬운 편이라 서로 보완적인 관계에 있다고 생각한다고 하였습니다. 마지막으로 XP는 1판과 2판이 책의 내용이 상당히 다른데 1판은 선언문 같은 느낌이 있으면 커뮤니티에서도 "니가 틀렸다"라는 식의 대응을 많이 하였으나 2판부터는 친근해지고 겸손해 졌으며 "내가 잘못한 것 같은데 어떻게 하면 더 잘할수 있을까?"의 식으로 대응하는 경우가 많아졌다고 합니다.

켄트벡을 소개하는 김창준님
켄트벡을 소개하는 김창준님
등록하면서 받은 물건들
등록하면서 받은 물건들

김창준님이 본 Kent Beck는 2가지였습니다.
단순성에 대한 집착 : 터무니 없이 단순한 생각에서 멍청할 정도로 극단적으로 적용합니다.
인간적 성숙을 위한 노력 : 이부분은 XP책의 2판부터 나타나기 시작했으면 "책임감 있는 개발"이란 말을 많이하기 시작했다고 합니다.

마지막으로 세미나를 열린 괄호와 닫힌 괄호에 비교하셨습니다. 닫힌 괄호는 단편(?)적인 지식을 쌓는 것이고 열린 괄호는 명확히 지식적으로 얻은 것은 없는 것 같지만 무언가 해봐야 겠다는 생각이 들게 되는 세미나인데 켄트벡의 세미나는 이런 에너지와 실험으로 이어지는 열린괄호에 가깝다는 것이었습니다.
(30분정도의 짧은 시간이었지만 생각해 봄직한 말들이었습니다. 김창준님은 2년전 P-Camp때 처음 뵈었었는데 그때도 느꼈지만 참 말씀 잘하시더군요.... 부럽;;; ㅎ)

오전 세션
켄트벡의 오션세션이 이어졌습니다.
반응적 설계(Responsive Design)은 책으로 나올 예정인데 "Structured Design"이란 책을 보고 많은 영감을 받았고 여기서 기본적인 내용을 잡았다고 합니다. 이 책의 저자들과 얘기해서 기본적인 것을 바탕으로 내용을 업데이트하고 켄트벡의 생각을 넣어서 새로 만드려고 하는 것이 Responsive Design의 시작이라고 합니다.

디자인이 왜 중요한가 하면 여러가지 증상(Symptom)들이 근본적으로 디자인인 경우가 많습니다. 예를 들어서 테스트하기가 어려워서 더 복잡한 것을 해결할 수 있는 테스트툴을 만들수 있지만 표면적인 증상만 보지 말고 한걸음 물러나서 디자인을 보게 되면 근본적으로는 디자인의 문제인 경우가 많습니다. "어떤 디자인이면 이 문제를 해결할 수 있을까?"라는 고민을 하게 되면 쉽게 증상을 해결할 수 있는 경우가 많습니다. 또한 팀작업의 경우에도 같은 파일의 수정에 대한 문제같은 경우 팀웍의 문제일 수도 있지만 왜 같은 파일을 수정해야 되게 되었는가에 대한 고민을 할 필요가 있습니다. 쉽지 않고 어려운 문제지만 할 필요가 있습니다.

디자인 공부는 아래의 3가지의 초점을 맞추어서 합니다.

Introspectively : 자기반성적으로 내면을 봅니다. 나는 어떻게 하는지... 어떤걸 해보았는지...
Empirically : 경험적으로 잘된 것과 잘안된 것은 인식해야 합니다.
Quantitatively : 정량성

SW에 대해서 생각하기에 적합한 시기인지에 대해서 생각해 볼 필요가 있습니다. 현재 SW 디자인에서 큰 변화가 일어나고 있습니다. 기존에 적용되었던 것이 이제 통하지 않고 있기 때문에 차세대 SW 디자인에 대한 스킬이 필요한 때입니다.

디자인 스킬은 큰 변화가 왔을 때 큰 능력을 발휘합니다.

현재 큰 변화로는

  • 무어의 법칙의 종료 : 여태는 SW개발자가 HW성능향상에 중독되어 HW가 향상되기를 기다리면 퍼포먼스문제가 해결되었으나 이제는 그렇지 않습니다.
  • Scale : 스케일이 점점 커지고 있어서 디자인으로 해결해야 합니다.
  • Cloud : 클라우드로의 이동이 이루어지고 있어서 쉬웠던 것들이 어려워지고 어려웠던 것들이 쉬워지고 있습니다.
  • PC-Client : 과거에는 모든 것이 Server에 들어가고 Client는 조악했지만 이제는 상황이 바뀌었습니다.
켄트벡이 개발을 배울때는 마감일에 모든 기능이 완료되면 되는 분위기였습니다. 초기 설계에 70%정도를 투자하지만 실제 사용되는 것은 10%정도에 불과하고 이런 상황은 지금도 꽤 있습니다. 50주짜리 프로젝트면 다 만들어서 50째주에 한번에 모두 Delivery하는데 이것은 좋지 않다. 기능의 꾸준한 흐름(Steady flow of Features)을 유지하면 변경이 용이하고 피드백이 가능합니다.(당연한 얘기이겠지만 이런 부분은 애자일에서 얘기하는 것들과 일맥상통한 부분이죠.) 시간이 지나면 디자인은 달라지게 마련이고 SW에서 제약사항들은 한꺼번에 해결하는 것이 불가능합니다.

강연하는 켄트벡강연하는 켄트벡

효율성
디자인은 효율적이어야 합니다. 효율성은 작은 Scale로 볼수도 있고 큰 Scale로 볼 수도 있습니다. 공장으로 본다면 공장전체는 효율적이지만 기계단위 별로는 효율적일 때도있고 아닐때도 있을 수 있습니다. 효율성외에 초기에 얼마만큼의 디자인 비용이 드는가에 대해서도 고려해야 합니다. 그리고 또하나의 큰 비용은 변화에 대한 비용이기 때문에 이에 대한 부분을 줄이려고 노력해야 합니다. 반응적 설계는 변화에 대한 비용을 줄일 수 있습니다.

설계는 모든 환벽한 정보에 기반해서 하지 않기 때문에 실수에 대한 비용도 있습니다. 또한 현재 하는 일때문에 하지 못하는 것에 대한 기회비용도 있습니다. 프로젝트 초기에는 해당프로젝트의 가능성을 잘 모르기 때문에 기회비용이 클 수 있는데 초기투자를 줄여서 프로젝트가 진행되면서 확실해 졌을때 더 많이 투자함으로써 기회비용을 줄일 수 있습니다. 반응적 설계는 효율은 높이고 비용은 줄이는 것입니다.

디자인할 때는 아래 3가지의 균형이 중요합니다.

  • Latency (지연)
  • Throughput (처리량)
  • Variance (변화)
처리량은 높지만 지연율이 많을 수 있습니다.

어떤 부분에 너무 깊게 관여되어 있으면 시야가 좁아지기 때문에 한걸음 물러나서 큰그림을 봐야합니다.

글이 길어져서 글을 나누어야 겠습니다.