[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...

2016년 3월 29일 화요일

[JSP]JSTL 비교 연산자..

뜻하지 않게 업무가 바뻐졌다.. 모바일쪽은 원래 하던 일도 아닌데 모바일 웹도 개발 범위로 넘어왔다.. 그나마 App 이 아니라서 다행이라는 생각도 들긴한다..

오랫만에 내 포스팅인데 JSTL[자바서버 페이지 표준 태그 라이브러리(JavaServer Pages Standard Tag Library, 약칭 JSTL)] 비교연산자를 간단히 정리 하려고 한다..

JSTL 테그를 그렇게 많이 안쓰기도 하고, 대부분 if ~ else, for 에 해당하는 <c:if test=""></if> 내지는 <c:forEach>정도만 쓰게 되는데 오늘 소스에서 비교연산자 eq 가 자주 출몰해서 검색을 좀 해봤더니 평소 안보던 것도 몇 개가 있더라..

참..!! 원래는 카테고리를 [JSTL] 로 만들까 했었다.. 근데 결국에는 JSP 내에서 주로 쓰는 것이고, 파생된 개념이기 때문에 JSP 카테고리 내에 쓰기로 마음 먹었다.. 그렇게 되면, AJAXjQuery 카테고리도 좀 그럴 수도 있지만 패수하자.. ㅋㅋ.. 너무 복잡해지자낫..

우선 우리가 보통 사용하는 것이 ==, !=, <, >, <=, >= 이정도인데.. 이것이 JSTL 로 가면 아래처럼 바뀐다..


  • == is JSTL eq 
  • !=  is JSTL ne
  • <   is JSTL lt
  • >   is JSTL gt
  • <= is JSTL le
  • >= is JSTL ge

오른쪽 부분이 JSTL 로 변경 된 것.. 나도 그렇지만 모르는 사람들은 대부분 위처럼만 얘기하면 분명히 이해가 안간다.. 계속 쓰던 사람이라면 모를까.. 그래서 간략하게 쓰임새를 보자.. 단, 주로 쓰고 대표적인 eqne 로 예제를 올린다.. 

eq..

1
2
3
4
//eq ==
<c:if test="${null eq testData}">내용</c:if> // null
<c:if test="${0 eq testData}">내용</c:if> // 숫자
<c:if test="${'0' eq testData}">내용</c:if> // 문자

ne..
1
2
3
4
//ne !=
<c:if test="${null ne testData}">내용</c:if> // null
<c:if test="${0 ne testData}">내용</c:if> // 숫자
<c:if test="${'0' ne testData}">내용</c:if> // 문자

상당히 간단하다고 생각 든다.. 물론 나만 그럴 수도 있긴하지만, 그래도 어려운 로직이 아니고 단순한 패턴이기 때문에 조금이라도 개발을 하시던 분이거나 이제 입문하셨다고 해도 충분히 "아~~~" 이럴 것이라고 생각된다..

다음에는 기회가 되면, 기타 연산도 포스팅 할까 싶기도 한데 우선은 내가 쓰다가 올리면 좋겠다는 것을 위주로 포스팅 하기 때문에.. 기약없는 나중을.. 후후..



[JS]JavaScript.next에 대해서..

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

그 전에도 수시로 논의가 오갔지만 5월 초에 JSConf.us 2011이후로 JavaScript.next()에 대한 논의가 해외 프론트앤드 개발자 사이에서 엄청나게 활발해 졌습니다. 여기서 JS.next()라는 것은 차세대 자바스크립트를 의미합니다. 이 논의의 발단은 JSConf에서 Brendan Eich의 발표가 그 시작점이었던것 같습니다. 물론 대부분의 논의는 JavaScript가 어떤 언어가 되어야 하고 어떤 문법을 추가해야 하는가에 대한 구체적인 논의이지만 이 순간이 JavaScript가 크게 변화는 시작점에 포함되어 있다는 판단하에 앞으로의 상황추이를 좀 쉽게 보기 위해서 현재의 상황을 좀 이해하고 넘어가야 할 것 같아서 관련 정보들을 찾아보았습니다.

JavaScript의 역사
JS.next에 대해서 이야기 하기전에 자바스크립트의 역사를 좀 집고 넘어가야할 필요가 있을 듯 합니다. JavaScript는 Netscape에서 Brendan Eich(Mozilla의 공동설립자로 현재는 CTO로 있습니다.)가 90년대 초에 웹페이지를 다이나믹하게 하기 위해서 만들었으며 처음에는 Mocha라고 불렀으며 그 뒤에는 LiveScript라고 명명되었습니다. 이후 Netscape Navigator에 자바기술을 넣기 위해서 Sun Microsystem와 함께 하면서 1995년에 JavaScript라는 이름으로 최종 확정됩니다.

Netscape가 JavaScript를 Ecma International에 제출하게 되고 1996년 11월에 ECMA-262를 위한 스펙을 제정하는 작업에 들어갔으며 1997년 7월에 첫번째 에디션이 받아들여졌습니다. 1996년 Netscape 3.0에서 1.1이 적용된 뒤 1997년 Netscape 4.0에서 1.2가 릴리즈되었습니다. 이때 Microsoft는 1996년에 Internet Explorer 3.0를 발표하면서 JavaScript에 기반을 두었지만 트레이드마크를 피하기 위해서 JScript라고 이름을 지어서 같이 발표했습니다. JScript는 JavaScript의 방언정도이고 이후로 ECMAScript가 표준화 되면서 JavaScript도 ECMAScript의 Netscape 방언이 되었으며 그 외방언으로는 ActionScript가 있습니다.

이후 Netscape와 Internet Explorer의 브라우저 전쟁이 나면서 지금에서는 이상하게 들리겠지만 Microsoft는 당시에 JavaScript가 인기를 얻을 수 있도록 하기 위해서 JScript를 JavaScript와 최대로 호환성을 이룰수 있도록 노력하였습니다. 이 브라우저 전쟁의 중심에는 DOM 개발이 있었고 DOM Level 0은 Netscape에서 개발했으며 그 유용성이 좀 의심스럽기는 하지만 현대적 브라우저가 모두 지원하고 있는데 Microsoft도 이를 카피해서 Internet Explorer 3에 적용했습니다. document.images[0]같이 사용하는 것인 DOM Level 0입니다

W3C는 1994년에 설립되었고 ECMAScript를 통해서 JavaScript의 표준화를 돕고 있었으며 1998년 DOM Level 1을 위한 recommendation이 발표되고 2000년에 DOM Level 2가 발표되어 지금의 getElementById()와 이벤트 모델을 가지게 되었습니다. 하지만 이는 너무 늦은 시기였습니다. Microsoft가 브라우저 전쟁에서 이긴 후에 비호환성 정책을 취하게 되고 IE6이 지배적인 브라우저가 되면서 웹의 혁신은 끝이 나게 됩니다. 이는 웹 2.0의 시대가 올 때 까지 계속 됩니다.

또한 SpiderMonkey는 Netscape에서 Brendan Eich가 C로 구현한 JavaScript의 첫번째 인터프리터였으며 지금도 파이어폭스와 Adobe의 제품들에서 사용되고 있습니다. 1999년 말에 ECMA-262 Edition 3가 발표되면서 정규표현식과 try/catch를 통한 예외처리등이 추가되었고 현재의 대부분의 브라우저는 이 Edition 3를 지원하고 있습니다.

하지만 이 시점 이후로 ECMAScript의 개발인 이상한 짓을 하기 시작합니다. 임베디드 장비를 위한 컴팩트 버전도 발표하고 XML을 위한 ECMAScript로 E4X도 발표하게 됩니다. Edition 3출시 이후 ECMAScript 4에 대한 작업도 바로 시작되었는데 2003년에 중간보고서를 발표하면서 ActionScript, JScript.NET이 이 당시의 일부를 구현하고 있습니다. 2005년 ES4에 대한 작업이 다시 시작하며 2008년에 완료를 목표로 하고 있었지만 클래스기반의 객체지향, 다중메서드, 오퍼레이터 오버로딩, 타입 애노테이션, Strict 모드, 제너레이터등 작성해야할 피쳐리스트들이 2007년에도 2페이지가 넘었습니다.

이때 Douglas Crockford는 Ajax Experience 컨퍼런스에서 ES4 제안의 복잡성에 대해서 지적을 하기도 했으며 2007년 말 ES4가 완성될 수 없는 작업이라는 것이 명백해지기 시작했습니다. 그렇게 기대되던 ECMAScript 4와 JavaScript 2는 그렇게 그 생명을 다하게 됩니다. 이 과정에서 ECMAScript Edition 3의 마이너 패치를 위한 ECMAScript 3.1을 위한 워킹그룹도 진행이 되었으며 ECMAScript 4를 작업하는 워킹그룹과 별도로 진행이 되었지만 두 그룹의 분쟁은 어쩔 수 없는 것이었습니다. 

결국 협의 끝에 이 두그룹의 작업을 합치는 것으로 결정을 하게 되고 2008년 가을에 Brendan Eich는 Harmony 프로젝트를 발표하게 됩니다. 이 프로젝트는 파벌들을 다시 합시고 새로운 ECMAScript 표준을 계속 개발하는 작업을 돕기 위한 프로젝트입니다. 비록 ES4가 많은 부분에서 잘못되었지만 이미 많은 개발자들이 오픈소스 라이브러리를 ES4기반으로 만들었기 때문에 ES4를 완전히 버릴 수는 없었습니다.(물론 한때 열심히 전파되던 ES4의 특징들은 다 잊어버려도 됩니다.)

2009년에 "차후 ECMAScript 에디션에 대한 작업은 이전에 발표했던 ECMAScript Harmony 프로젝트의 일부로써 계속 됩니다.(Work on future ECMAScript editions continues as part of the previously announced ECMAScript Harmony project.)"라는 말과 함께 ECMA-262의 5번째 Edition이 승인되었습니다. ES5는 ES4처럼 급진적이고 혁신적이지 않았습니다. 배열메서드, Native JSON, String.trim, Date등이 추가되었으면 언어에 Function.prototype.bind, Updated object model, Strict mode, Constants, Getters/Setters등이 추가되었습니다.

Brendan Eich의 발표
이것이 현재까지의 상황이고 이 상황에 기반해서 Brendan Eich가 발표가 있었습니다. CoffeeScript를 만든 Jeremy Ashkenas와 Brendan이 JSConf에서 만나서 의기투합이 되어 Jeremy가 자신의 세션인 "CoffeeScript as a JS/next"에 첫 15분을 Brendan Eich를 위해서 양보해서 발표가 이루어지게 됩니다. Brendan의 발표자료는 Slideshare에 올려져 있고 자신의 블로그를 통해서 발표한 내용해 대해서 자세히 코멘트를 달았습니다.

Brendan의 얘기로는 JavaScript 개발자들이 미래를 두려워 하는 것처럼 보이게 된 것이 웹브라우더 벤더사들과 Ecma TC39(ECMAScript 3.1과 ECMAScript 4에 대한 커밋 책임을 가진 곳입니다.)가 그렇게 만들어 놨다는 것입니다. 그래서 JSConf를 통해서 JS 개발자들이 그들이 할 수 있는 가장 좋은 일을 할 수 있도록 독려하고자 했으며 그것은 모질라의 ES토론에 글을 쓰고 CoffeeScript를 사용하는 것과 같이 직접 행동하는 것입니다.

웹브라우져 경쟁이 뜨거워졌고 벤더사들은 개발자들이 팬이면서 지원자가 되기를 바랬지만 결과적으로 JS 해커들에게 커다란 힘을 안겨주었습니다. TC39의 멤버들이 커미터로써의 입장에서만 귀를 기울이면서 JS 커뮤니티보다는 업체들을 더 존중했기 때문에 이제 JS 개발자들이 목소리를 낼 수 있게 된 것은 아주 중요합니다.  물론 커뮤니티는 한 목소리를 낼 수 없지만 각 커뮤니티들은 자신들만의 방법으로 Prototype.js나 JQuery같은 결과물을 만들어냈습니다.

커뮤니티가 중요한 이유는 커뮤니티들은 JavaScript가 가진 가혹한 테스트에 직면해 있기 때문에 경쟁적이고 시간압받을 받으며 작업하는 커미터들보다 나은 장점을 가지고 있습니다. Andrew Dupont(prototype.js의 메인 커미터중 하나입니다.)이 JSConf에서 현재 어떻게 JavaScript 표준이 커뮤니티-프로젝트 라이브러리 방법을 통해서 시작되었는지를 얘기했다고 합니다. 이러한 사실상(de facto)의 표준은 러프(rough)하지만 진짜이고 JS가 그렇게 했습니다. 개발자들은 이길 때까지 사용자 테스트를 하고 이터레이션을 돌 것입니다. Harmony의 목표는 사실상의(de facto) 표준을 문서화 하는 것에 대해서 얘기하고 있습니다. 여기서 Harmony의 프로세스는 구현자들(implementors)이 어떻게 HTML5와 Web API 표준을 만드가를 돕는 것입니다.

TC39는 기존을 것을 사용해서 발전시킬수 있는 것(pave the cowpaths - 소의 통로를 포장한다.)대신에 새로 발명하는 것을 피해야 합니다. TC39는 발명을 더욱 더 하고자 하는 유혹에 빠졌습니다. 이 작업은 아마 완료되지 않을 것입니다.  TC39의 개발자들과 구현자들은 다른 것에서 좀더 배우고 어느정도 타협을 해야합니다.
Harmony의 목표는 좋지만 개발자들은 스스로 라이브러리 코드에서 무엇을 할수 있는지를 보여주거나 CoffeeScript같은 JS에 기반한 다른 언어 도달했습니다.

Harmony는 JavaScript가 더 나은 JavaScript가 되는 것을 도와주려고 하고 JS.next로써 표준화 될수 있도록 하기 위해서 입니다. 이것은 중요하고 큰 작업입니다. 이미 스펙으로써 하나의 오픈소스 언어(Single-open-source-as-spec)가 시작되었습니다.

JS.Next, ES.next
Brendan은 이 발표해서 현재 이슈되고 있는 가장 중요한 주제로 Tranpiler(Transcompiler)를 얘기했습니다. Tranpiler는 프로그리밍 언어의 소스코드를 다른 언어의 소스코드로 바꾸어주는 특수한 컴파일러를 의미하고 CoffeeScript가 그 중 하나인데 마침 이 JSConf에서 구글의  Allex Russel과 Peter Hallam은 Traceur을 발표했습니다. Traceur은 Hormony스러운 Tranpiler입니다.(Tracuer에 대한 더 자세한 내용은 Rhio.kim님의 자바스크립트. 그 다음 구글 Traceur에서 보실 수 있습니다.)

표준제정에 대한 관계가 복잡해서 완전히 다 파악할 수는 없었지만 분위기 상으로는 Brendan도 TC39나 ECMAScript 4와 무관하다고 할 수 없을텐데 JavaScript의 창시자가 직접 JavaScript의 표준은 커뮤니티가 주도해야 하며 지금보다 더욱 적극적으로 참여하라고 말한 것입니다. 현업 개발자들이 가장 좋은 안을 제시하고 만들어 내면 Harmony에서 그걸 표준문서화 해내겠다라는 의미정도로 받아들여집니다.그 때문에 엄청나게 많은 논의가 시작된 것입니다.

이 논의에는 프로토타입기반의 JavaScript에 OO의 특성이 어느정도 수준으로 들어와야 하냐부터 CoffeeScript나 Traceur같은 Tranpiler들이 JS.next이냐에 대한 다양한 논의부터 function이 너무 길어서 fn으로 하자는 중요도가 낮은 문제들까지 아주 다양합니다. 이 상황에서 JavaScript의 지존과도 같은 Douglas CrockfordES-discuss에서 현업개발자들이 아닌 언어 디자이너와 비평가들은 언어를 개선하기 위한 시도도 하지 말라라고 하면서 이 분위기를 더욱 고조시킵니다.

개인적으로는 어떻게 흘러갈지 모르기 때문에 뭔가 불투명한 것 같지만 이런 흐름의 미래는 아주 흥분되고 기대되는 일입니다. 최근 1,2년 사이에 JavaScript에 정말 많은 변화가 이루졌다고 생각하고 있는데 본격적인건 이제부터 시작인것 같습니다.

그런 면에서 Jeremy Ashkenas는 말은 아주 의미심장합니다.

"JavaScript는 전문가들에게 맡겨두기에는 너무나도 중요합니다."
"JavaScript is too important to be left to the experts."

[참고링크]
- Wikipedia
- History of JavaScript: Part 1
- History of JavaScript: Part 2
- History of JavaScript: Part 3
- History of JavaScript: Part 7
- ECMAScript Harmony



[Tool]Eclipse에서 메서드 정의로 이동시 인터페이스(Interface)가 아닌 구상(Implementation) 클래스의 정의로 이동하기..

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

이클립스에서 메서드의 정의롤 보기 위해서 해당 메서드에서 F3을 누르거나 Ctrl + 클릭을 하면 해당 메서드가 정의된 곳으로 이동하게 됩니다.(소스를 읽을때 꼭 필요한 편리한 기능입니다.) 하지만 일반적으로 클래스를 정의할때 커플링을 줄이고 테스트용도로 DI를 하기 위해서 Interface를 쓰게 되는데 이럴경우 Interface로 선언이 되어 있기 때문에 정의로 이동해도 인터페이스의 정의로 이동합니다. 로직을 보려고 정의(Declaration)로 이동한 것인데 인터페이스에는 로직이 없기 때문에 프로젝트뷰에서 다시 구상(Implementaion) 클래스를 열어서 봐야합니다.

이런 불편함은 아래와 같은 방법으로 해결할 수 있습니다.

이클립스에서 튤팁을 연 모습

이클립스 버전이 3.6 Helios이상이라면 Ctrl + 클릭으로 이동할 때 바로 클릭하지 않고 메서드위에 마우스를 올리면 위와 같은 튤팁메뉴가 나와서 인터페이스의 선언부로 이동할 것인지 구상클래스의 선언으로 이동할 것인지를 선택할 수 있습니다.(이전 버전에 위처럼 사용할 수 있는 플러그인이 따로 있는것 같습니다.)

인터페이스 계층창을 연 화면

메서드 위에서 Ctrl + T를 클릭하면 위 화면처럼 해당 인터페이스를 구현한 클래스의 계층 구조를 모두 볼 수 있고 여기서 원하는 구상클래스를 선택해 주면 됩니다. 앞에서 설명한 방법도 구상클래스가 1개일때는 바로 이동하지만 구상클래스가 여러개일때는 Ctrl + T를 누른 튤팁과 동일한 튤팁이 나오고 여기서는 필터링 기능도 있기 때문에 많은 클래스 내에서도 쉽게 찾을 수 있습니다.(오랜만에 본격적 자바코딩을 하니 몰랐던게 많군요 ㅎ)



[Tool]Eclipse에서 계속해서 오류날때 워크스페이스 Clean하기..

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

이클립스를 사용해서 개발을 하던 도중 파일을 저장할때마다 오류를 뿜어내며(저장은 되었지만) 기타 다른 동작을 할때도 크래쉬 오류가 계속 나왔습니다.(그냥 뭔가 액션만 취했다 하면 오류얼럿이 튀어나왔습니다. ㅠㅠ) 한참 검색을 하다보니 워크스페이스를 클린하면 된다는 정보를 얻었습니다.(오류로그(워크스페이스내 .metadata/.log)를 보아도 일반적인 java오류와 비슷한 메시지였기 때문에 검색하기도 쉽지 않더군요.)

결론부터 말하자면 이클립스는 파일저장이나 플러그인 추가등의 관련 모든 정보를 workspace내에 저장하는데 워크스페이스를 clean해주면 되고 이클립스를 실행할 때 -clean 파라미터를 붙혀서 워크스페이스를 정리할 수 있습니다. 이클립스 문서를 보면 다음과 같이 나와 있습니다.

Cleans cached data used by the OSGi framework and Eclipse runtime. Try to run Eclipse once with this option if you observe startup errors after install, update, or using a shared configuration.

-clean 옵션을 사용시 한번만 동작하며(이클립스를 킨 이후에 계속 유지할 필요는 없다는 의미입니다.) 아래와 같은 2가지 방법으로 사용할 수 있습니다.

  • 이클립스 설치 디렉토리에 있는 eclipse.ini 파일의 최상단에 다음과 같이 -clean을 추가합니다.
    -clean
    -startup
    plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar

  • Eclipse 바로가기를 수정해서 eclipse.exe -clean 같은 형태로 실행시 옵션을 주도록 수정합니다.

하지만 저의 경우 이렇게 하고나니 약간 괜찮은것 같더니만 다시금 비슷한 오류가 나는 상황이 되어버렸습니다.(대부분 clean만으로 해결이 된다는데 저는 안되더군요 ㅡㅡ;) 이런 경우에는 Workspace를 완전히 새로 생성합니다.

간단한 개발환경이라면 새로구성하면 되고 그렇지 않다면 이클립스의 설정파일 내보내기(File > Export > Preferences > "To preference file"을 통해서 백업한 뒤에 다시 가져옵니다. 필요하다면 프로젝트도 임포트하면 됩니다. 이렇게 하면 워크스페이스를 새로 구성한 것이기 때문에 완전하게 clean이 됩니다.(좀더 두고봐야겠지만 괜찮아진 듯 하군요. ㅎ)



[Book] 똑바로 일하라(REWORK) - 성과는 일벌레를 좋아하지 않는다..

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

똑바로 일하라 - 8점
제이슨 프라이드 & 데이비드 하이네마이어 핸슨 지음
정성묵 옮김
21세기북스(북이십일)

원서의 제목인 REWORK으로 더 잘 알고 있던 책을 번역서가 나와서 이번에 읽었습니다. 이 책은 37signals를 설립한 Jason Fried와 37Signals에서 일하고 있는 David Heinemeier Hansson가 지은 책입니다. 국내에서는 37signals가 많이 알려져 있는 편은 아닌듯 하지만 제가 개인적으로 좋아하는 회사이기도 하고  프로젝트 관리를 위한 Basecamp, 협업을 위한 그룹챗 Campfire, 조직내 커뮤니케이션을 위한 Backpack, 정보관리도구인 Highrise등을 판매하며 많은 돈을 벌고 있는 대표적은 웹2.0 회사중 하나입니다. 책에 나온대로 규모는 10~20명정도인듯 합니다.

물론 37signals에는 회사보다 더 유명한 Rails를 만들어서 Ruby on Rails라는 새로운 세계를 만든 David Heinemeier Hansson(이 책의 저자이기도 하고 보통은 DHH라는 닉을 사용합니다)가 있고 prototype.js를 만들어서 JavaScript 프레임워크의 시작점과 같은 역할을 한 Sam Stephenson이 근무하고 있으며 그외 Ruby on Rails쪽 커미터들이 포진하고 있는 회사입니다. 비록 숫자는 큰 기업에서 일개 팀정도의 규모이지만 개개인을 보면 포스가 후덜덜할 정도입니다. 왠지 관리도 필요없이 내비두면 금새 서비스하나씩 만들어올 것 같은 느낌이랄까요? ㅎ

REWORK이나 똑바로 일하라 라는 제목대로 일하는 방식에 대해서 조언을 해주는 형태의 책이라고 할 수 있고 스타트업 회사들을 타겟으로 하고 있습니다. 벤처나 이제 막 시작한 스타트업들이 어떻게 회사를 운영하고 일을 해야하는지에 대해서 자신들의 노하우를 공유해주는 것입니다. 많은 열정있는 개발자들이 꼭 회사는 아니더라도 자신만의 서비스 혹은 애플리케이션을 꿈꾸고 그러면서도 어떤 조직내에서 생활을 하면서 REWORK이 말하고 있는 것들은 충분히 꼽씹어 볼만한 내용들이 많이 있습니다.

물론 평소에 이런 부분에 관심이 있었다면 REWORK이 말하고 있는 것중에 깜짝 놀랄만한 새로운 것이나 그동안 전혀 몰랐던 것 같은 것은 많지 않습니다. 그럼에도 이 책은 각 챕터에서 얘기하고자 하는 핵심을 삽화처럼 만들어 놓았기 때문에 핵심이 쉽게 각인이 되면서 글이 많지 않아서 금방 읽을 수 있었고 애자일스러운 회사답게 기존의 관습이나 관료주의류의 형식들은 깨고 실리적이고 효율적으로 움직일 수 있도록 조언해 주고 있으며 장황하게 설명하기 않고 간단한 예시와 함께 핵심만 전달하고 있어서 아주 명쾌합니다. 실제 37signals로 성공사례를 몸소 보여준 입장에서 하는 말이기 때문에 더 와닿는 것 같습니다.

개인적으로 회사에 속해서 업무를 하면서 부딪히는 것들이나 제가 생각하는 부분과 REWORK에서 말하고 있는 것들이 상당히 일맥상통하는 데다가 혼자 막연히 생각하던 것을 명쾌하게 정리해 주니까 속이 다 시원하게 느껴지는 것 같습니다. 단순히 동의를 얻어서 좋은 것이 아니라 핵심을 찌르는 부분들이 많기 때문에 글을 간결하지만 많은 생각을 할 수 있게 합니다. 관료주의가 팽배한 국내 회사들이 꼭 들어보아야 할 얘기들이 많이 있다고 생각합니다.(물론 이 책 한권보고 생각이 바뀔정도라면 애초에 걱정도 안했겠지만요. ㅎ)

이 책에서 인상 깊게 느낀 부분들은 약간 정리해 보았습니다.(책 발췌)

일중독자들은 늦게까지 남아 일하지 않는 사람들에게 위에서 시키는 일만 하는 사람이라고 비난하며 죄책감을 심어주고 사기를 떨어뜨린다. 그 결과 의자에 엉덩이만 붙이고 보자는 태도가 만연해진다.

사업가 말고 스타터라고 부르자.... 그저 괜찮은 아이디어 하나, 한 줄기 자신감, 그리고 뭔가를 시작할 추진력만 있으면 된다.

가상 쉽고도 단순한 방법은 '자기자신이 사용하고 싶은 것을 만드는 것이다. 하나의 제품이나 서비스를 만들려면 매일 수백가지의 세세한 결정을 내려야 한다. 그런데 그 제품이나 서비스가 남이 사용할 것이라면 모든 결정을 암흑속에서 내려야 한다.

중요한 것은 생각이나 말이 아니라 행동이다
핵심을 찾아내라.

한번 내린 결정을 영원히 이어갈 필요는 없다! 문제가 있으면 나중에 바로잡으면 된다.

사업의 핵심은 변하지 않는 것들이다. 사람들이 오늘도 원하고 앞으로 10년 후에도 변함없이 원할 것들, 바로 이런 것에 투자해야 한다.

대게는 흡족한 마음이 들기 훨씬 전에 내놓는게 안전하다. 제품에 꼭 필요한 기능을 장착했으면 주저하지 말고 출시하라

야근을 하는건 해야할 일이 많기 때문이 아니다. 평소에 일을 제대로 하지 못하기 때문이다. 그 원인은 바로 방해다. 최악의 방해요소는 바로 회의다.

'아이팟 킬러'나 '차세대 포켓몬'을 겨냥한다면 이미 진 것이다. 경쟁자에게 리드를 허용하는 셈이다. 애플의 비전으로 애플을 이길 수는 없다.... 나의 판을 짜야 한다.

열정이 생긴다고 해서 반드기 그 아이디어가 정말로 가치 있는 아이디어인 것은 아니다.

문화는 창출하는 것이 아니다. 그냥 생기는 것이다.

우리에게 정말 필요한 것은 일의 양이 아니라 질이다.

소신을 지켜서 성공사례를 만들어 내었다는 것은 상당히 고무적인 일이라고 생각합니다. 물론 REWORK은 단순히 이렇게 하면 성공할 수 있다 같은 수준의 내용이 아니라 "이렇게 일해야 한다"가 더 핵심이라고 생각하고 있습니다. 그 성공은 이런 것들이 막연히 이상적인 말들이 아닌 실제로 그렇다는 것을 보여준 증거라고 생각합니다. 개인적으로는 책에 내용과 부합되게 심플한 느낌으로 인상적인 원서의 임팩트가 번역서의 표지나 제목에서 느껴지지 않는것 같아 약간 아쉬워하고 있습니다만 간만에 좋은 영감을 주는 책을 읽은 것 같습니다.