neoevoke

[발번역] 고백 : 눈물 콧물 다 쏟은 스타트업 기업에서 실패하면 기분이 어떨까?

2011-12-20T11:51:51+09:00

비지니스인사이더 원문
http://www.businessinsider.com/boonsri-dickinson-what-to-do-if-your-startup-is-a-failure-2011-12

실리콘 벨리에는 시간을 들여서 열심히 일을 하면 돌려 받는다는 기정사실이 있다.

피, 땀, 눈물을 흘린 스타트업 기업에 어느날 실패했으니까 이제 그만해야한다고 깨닫는다면 기분이 어떨까?

Quora에 누군가 질문을 올렸다.

Mint.com의 창립자 Aaron Patzer가 대답했다.

먼저, 배경 설명부터 하겠다. 나는 몇년동안 Swift라는 것을 생각했다. 자기 부상 열차가 자동차를 대체할 것이고 최고의 생각, 발명, 프로그래밍, 물리학, 그리고 알고리즘 개발을 해서 이뤄낼 것이라고 생각했다. 수개월이 지나고, 자금을 준비하고, 기술적 개발을 고려하고 난 뒤 이 모든 실험은 경제적으로 가능하지 않다는 것을 알았다.

그래서 기본적으로 Patzer는 대체이동수단을 개발하는데 모든 시간을 쓰기만 하고, 회사를 키울 수 있는 가에 대해서는 생각을 하지 않았다고 말했다.

그 다음 Patzer가 그의 스타트업이 실패했음을 깨닫고, 이렇게 느꼈다고 한다.

첫째 : 실망감을 느낀다. 그리고 금새 혼돈에 빠지고 패닉에 빠진다. "ㅆㅂ 이제 뭘 하지?" 수년간 존나 멋진 많은 아이디어로 만든 회사의

둘째 : 배운 것에 대해 위안을 느낀다. 내가 주요 발명가로 일을 착수하는 동안 mint.com에서 엔지니어를 이끌기만하고 CEO로서 2008중순부터 2011중순까지 프로그래밍을 하지 않았다.Swift는 나에게 프로그래밍을 졸라 하게 만들었다. Grails & Groovy, JQuery, Google Maps 통합을 배웠고, 그래프 알고리즘과 교통흐름 패턴 시뮬레이션을 위한 확률 이론을 독학했고 다익스트라 알고리즘을 개선하기 위해 A*알고리즘을 가져왔다. 요약하자면 새로운 스킬을 익혔고 다음 스타트업에 적용될 것이다.

그럼에도 힘들지는 않았다고 결론짓는다.

내 여행은 여기까지 였다. 2년동안 놀았다. 내가 가진 돈 중에 수천만원을 쓰고 내가 받아보지 못한 기대 연봉은 억대로 미리 앞서갔다. 사랑을 희생시키고, 여가 시간을 희생시켰었다. 모든 것의 끌에는 돌아가서 탈출하고 싶었던 기업에 정진해야만 한다.

몇달전에 스타트업을 정리한 Chong Tee Kan은 이렇게 대답했다.

실패의 감각을 지배한 뒤 어떻게 되는가. 모든 부정적인 것들을 사람들은 나와 프로젝트에 대해 말한다. 모든 실수를 내가 만들었고 심지어 내 다른 실수와 스타트업 이전에 실패했던 실수조차도... 모든게 드러다고 내 머리속에 맴돈다. 자존심을 위축시킨다. 좋은점이라면 어두운 시기도 지나는 간다는 것이다.

거의 대부분이 동의하는 것이 있다면 이런 실패의 아픔에도 불구하고 그들은 돌아가서 다시 시도할 것이라는 것이다.

Objective-C ARC에 대한 이해[발번역]

2011-11-27T18:00:28+09:00

Objective-C에서 ARC에 대한 이해

원문 : http://longweekendmobile.com/2011/09/07/objc-automatic-reference-counting-in-xcode-explained/

ARC는 메모리 관리를 위한 무거운 짐을 없애준다. 릴리즈를 덜 해서 메모리가 세거나 많이해서 죽이는 버그를 찾느라 고생하는 일은 말도 마라!

이렇게 멋지지만, ARC도 조금은 신경 써줘야 한다.

ARC에 대해서 설명해줄테니 읽어보고 빨리 배우시길

Objective-C에서 ARC에 대한 이해
뭐가 바꼈나?
레퍼런스 카운트되는 메모리(기존방식) : 훝어보기
Automatic Reference Counting이 동작하는 원리
프로젝트에 ARC켜기
ARC 때문에 강제되는 새 룰
ARC 수식어(Qualifiers) - Declared Properties
ARC 수식어 - 일반 변수
ARC로 기존 프로젝트 마이그레이션 하기
ARC 컴파일 사용하지 않는 코드 포함하기
그럼에도 불구하고 ARC를 써야하나?

뭐가 바꼈나?

ARC 이전에 사람들은 retain/release/autorelease 를 오브젝트에 수동으로 때리면서 필요한동안 남겨놓으라고 지시 했었다.

하지만 retain 하는 것을 까먹거나 release를 많이 하면 앱이 죽거나 메모리가 세는 문제가 발생한다

Xcode 4.2에서부터 문법을 사용한다고 하기만 하면 애플의 새로운 LLVM Compiler가 수동으로 메모리 관리를 하느라

진흙길에서 고생하던 것을 언제 객체가 해제되어야 하는지 알아서 해준다. 애플 문서는 ARC를 이렇게 설명한다.

Automatic Reference Counting(ARC)는 컴파일러 수준에서 코코아 어플리케이션들의 객체의 일생(메모리관리)을 관리해주는 과정을 단순화 시켜주는 기능이다.

이 기능은 메모리 관리를 대부분 쉽게 해주긴 하지만, 다른 객체의 참조를 관리하는 클래스에서는 여전히 어떤 책임을 져야한다.

첨부터 시작해보자

레퍼런스 카운트되는 메모리(기존방식) : 훝어보기

수동으로 관리하는 참조의 숫자를 세는 방법은 iOS에서 다음과 같이 동작한다 : 객체를 만들 때 alloc/init ( 혹은 비슷한 명령어)를 사용하고, retainCount가 1로 리턴한다.

그 뜻은 객체의 주인이라는 것이다.

NSObject *obj = [[NSObject alloc] init];

// do some stuff

[obj release];

객체에게 alloc/init을 하는것(소유권을 갖는 일)과 release를 하는 것(소유권을 놔주는) 사이에 당신이 원하던 일을 안전하게 객체게 해제된다는 걱정 없이 할 수 있다.

비슷하게 autorelease pool에 객체를 넣을 때도 당신의 객체는 더 이상 필요가 없기 전까지 잘 있을 것이다.

-(NSObject*) someMethod {

NSObject *obj = [[[NSObject alloc] init] autorelease];

return obj; // will be deallocated by autorelease pool later

}

Automatic Reference Counting이 동작하는 원리

대부분의 iOS를 처음 접하는 프로그래머들은 reference counted memory 때문에 고생을 한다. ARC는 컴파일을 하기 이전에 retain/release/autorelease 문을 당신의 코드에 자동으로 삽입하는 과정이다

이것은 Garbage Collection과는 다르다. Reference counted memory가 사라지는 것은 아니고 그것이 자동화 되는 것이기 때문이다. 간단하다고 단순히 생각할 수도 있겠지만 Objective-C의 소스파일을 컴파일 하기 전에 전처리를 통해 구현되어야하는 많은 기능을 생각해보라.

ARC를 사용하면 당신의 코드는 이렇게 짜면 된다.

NSObject *obj = [[NSObject alloc] init];

// do some stuff

ARC 전처리기는 자동으로 이렇게 바꿀 것이다

NSObject *obj = [[NSObject alloc] init];

// do some stuff

[obj release]; // **Added by ARC**

아래의 그림(애플 문서에서 발췌)은 retain과 release 논리를 쓰고 . 이것은 노련한 Objective-C coder들에게는 맞지 않겠지만 Objective-C를 처음 접하는 사람들에게는 해당될 것이다. 그들이 팝업을 띄우면 메모리 문제가 생길 것이다.

http://developer.apple.com/library/mac/#releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_7.html

프로젝트에 ARC켜기

ARC를 켜기 위해서는 간단히 Xcode 프로젝트 Build Setting에 있는 Objective-C Automatic Reference Counting이라는 옵션을 YES로 바꾸기만 하면 된다. 그러면 뒤에서는 -fobjc-arc 라는 컴파일러 flag를 켜는 것이다.

ARC 때문에 강제되는 새 룰

ARC를 켜서 컴파일 할 때는 몇가지 지켜야할 룰이 있다.

1. Alloc/Init

위에서 설명했듯이 오브젝트 생성은 끝난다. 하지만 retain/release/autorelease 는 쓰면 안된다. 간접적으로 selector에서 간접적으로 호출 하는 것도 할 수 없다. @selector(retain) 과 @selector(release) 사용이 금지된다.

2. Dealloc Methods

일반적으로 이것을 위해 존재하는 것이다. dealloc을 강제로 부르면 안된다. 하지만 custom한 dealloc 메소드는 만들 수 있고 필요하면 인스턴스를 해제할 수 있지만 [super dealloc]은 호출하지 말라. 이것은 컴파일러가 해줄 것이기 때문이다.

3. Properties의 선언

ARC 이전에는 컴파일러에게 public properties는 assign/retain/copy 파라메터로 메모리 관리를 해왔다. 이 파라메터들은 더 이상 ARC에서는 사용되지 않는다. 대신에 이 properties가 얼마나 많이 사용되는지 알려주기 위한

weak과 strong 파라메터가 생겼다.

4. C 구조의 Object 포인터

이것 역시 하면 안된다. 이 문서는 struct대신에 class로 저장하기를 권장한다. ARC에게 모르는 것이라고 하는 것 보다 말이 된다. 이것 때문에 골치 아플 수도 있다. 하지만 ARC 설정을 file 마다 따로 할 수 있다. "ARC를 사용하지 않는 코드 포함하기" 편을 봐라

5. id 와 void*의 형변환

id 와 void*의 형변환은 Core Foundation의 C 라이브러리와 Foundation Kit의 Objective-C 라이브러리 사이에서 자주 쓰인다. 이것은 Toll Free Bridging으로 알려져 있다.

ARC에서는 CF 객체가 메모리 관리를 위해 제어권을 갖는지 필요없는지 컴파일러에게 힌트/수식어를 줘야된다. 이 수식어(qualifier)는 __bridge, __bridge_retain 그리고 __bridge_tranfer를 포함한다. 그리고 CFRetain, CFRelease를 여전히 호출해야 된다.

이것은 심화과정 주제이며 CF objects가 뭔지 모르면 걱정안해도 된다.

6. NSAutoReleasePool을 대체할 @autoreleasepool

ARC 컴파일 코드는 NSAutoReleasePool 객체를 사용하면 안된다. 대신 @autoreleasepool{} block을 사용해라. ARC를 사용하는 프로젝트의 main.m은 좋은 예제이다.

int main(int argc, char *argv[])

{

@autoreleasepool {

return UIApplicationMain(argc, argv, nil, NSStringFromClass([ExampleAppDelegate class]));

}

7. 기타등등

Zone 기반 메모리 관리는 이제 그만(분명히 런타임도 물론 아니다)

NSAllocateBoject나 NSDeallocateObject도 쓸 수 없다.

ARC 수식어(Qualifiers) - Declared Properties

프로그래머들은 변수나 상수를 만들 때 전역으로 할 것인지 지역으로 정의할 것인지 결정을 내려왔다. 마찬가지로 우리의 properties가 다른 객체와 어떤 관계인지 결정을 내려야 한다. 우리는 strong/weak 수식어를 통해 컴파일러에게 관계를 알려줘야 한다.

Strong References

strong reference는 객체가 deallocated되면 함께 멈추는 객체에 쓴다. 다른말로 소유 관계다. 이전에 이렇게 사용하던 것들을

// Non-ARC Compliant Declaration

@property(retain) NSObject *obj;

ARC에서는 아래와 같이 클래스 인스턴스의 레퍼런스 객체 소유관계를 확실히 한다.(예를들어 소유자가 해제되기 전까지 해제되지 않는다)

// ARC Compliant Declaration

@property(strong) NSObject *obj;

Weak References

weak reference 는 객체가 해제 되더라도 멈추지 않는 객체에 쓴다. 다른 말로 소유 관계가 아닌 것이다. 예전에 이렇게 쓰던 것들을

// Non-ARC Compliant Declaration

@property(assign) NSObject *parentObj;

ARC에서는 아래와 같이 객체를 소유하지는 않지만 참조한다고 확실히 한다.(예를 들어 자식이 부모를 소유하지 않을 때 weak reference를 쓴다)

// ARC Compliant Declaration

@property(weak) NSObject *parentObj;

ARC 수식어 - 일반 변수

변수 수식어

위의 예제들은 properties가 어떻게 관리 되어야 하는지 선언하는 것이었다. 일반 변수에 대해서는 아래와 같은 것들이 있다.

__strong

__weak

__unsafe_unretained

__autoreleasing

일반적으로 이러한 추가적인 qualifier들은 매우 자주 필요한 것은 아니다. 마이그레이션 툴을 사용했을 때 처음 볼 것이다. 하지만 새 프로젝트에서는 필요도 없고 대부분 properties선언에서 strong/weak를 쓸 것이다.

__strong - default 이며 타이핑 할 필요도 없다. 이 말은 어떤 객체가 alloc/init으로 생성되면 현재 scope의 일생동안 retain된다. 이 current scope 는 보통 변수가 선언되는 brace를 뜻한다. for block이나 if block같이

__weak - 이것은 언제든지 파괴될 수 있다는 뜻이다. 이것은 다른 strongly reference객체가 있을 때만 사용된다. 파괴되면 __weak 변수는 nil이 된다.

__unsafe_unretained - 이것은 __weak과 같지만 object가 해제 되어도 pointer가 nil로 되지 않는다. 대신 pointer가 여전히 메달려 있다.(하지만 유효하지는 않다)

__autoreleasing - method에서 반환하기 전에 객체에 autorelease를 호출하는 것과 햇갈리지 않으면서 오브젝트를 참조(reference)로 넘길 때 사용된다. 예를 들면 NSError objects를 참조방식으로 넘길 때 [myObject performOperationWithError:&tmp]; 쓴다.

Source: LLVM Clang Objective-C Automatic Reference Counting Documentation
http://clang.llvm.org/docs/AutomaticReferenceCounting.html#ownership

NB: 우리는 @property 선언에서 ARC가 활성화 되어 있는데 strong대신 retain을 써도 컴파일러가 warning을 내지 않는 것을 발견했다. 하지만 미래에도 명확히 하기 위해 strong으로 써라.

ARC로 기존 프로젝트 마이그레이션 하기

Xcode 4.2에는 기존 코드를 ARC로 변환하기 위한 conversion tool을 제공한다. 그리고 자동으로 마이그레이션 못하는 코드를 수동으로 변환하는데 도움을 준다.

1. non-ARC 프로젝트를 열어서 Edit>Refactor>Convert to Objective-C ARC. 를 눌러라

2. 변환하고 싶은 build targets과 파일을 선택하라.

3. 미리 검사하기를 누르고 Next를 클릭

nb : next를 누르면 LLVM 컴파일러가 프로젝트를 분석할 것이다. 만약 프로젝트에 어떤 에러가 있으면 다음 과정으로 갈 수 없다. Xcode 새 버젼에서 처음 열었으면 Clean한번 해줘라.

4. 제안된 변화를 검사하고 포함할지 제외할지 고른다음 save 눌러라

NB : 어떤 파일은 마이그레이션 안되는 것을 알아야 한다, 모든 파일(라이브러리 포함)이 마이그레이션 될 필요는 없다. ARC는 개별 파일에 각각 설정할 수 있기 때문에 compile time에 제외하는 방법은 아래에서 설명한다.

5. 마이그레이션 툴이 자동으로 컴파일러 옵션을 켜준다. build setting에서 확인해봐라(검색어 : reference counting)

ARC 컴파일 사용하지 않는 코드 포함하기

애플 문서에서는 "ARC 방식은 수동 reference counting 코드를 파일 단위로 조절한다. 어떤 파일은 수동으로 하고 싶으면 그렇게 할 수 있다"고 한다

이 말은 어떤 파일은 ARC를 사용하고 어떤 파일은 사용하지 않을 수 있다는 말이다. 컴파일 타임에 ARC에서 제외시키는 절차를 설명한다.

이글을 쓰는 시점에에도 많은 유명한 라이브러리들이 ARC 준비가 안되어 있다. 아래 절차를 따라 해보자.

1. Xcode project tree를 클릭

2. Target을 클릭

3. Build Phases tab을 선택

4. Compile Sources section을 확장

5. ARC에서 제외하고 싶은 하나 또는 더 많은 파일을 선택

6. 엔터키를 한 번친다.

7. -fno-objc-arc 를 타이핑

8. 엔티키를 다시 친다.

9. 각각 파일은 이제 -fno-objc-arc 컴파일러 옵션이 켜졌고 ARC에서 제외될 것이다.

그럼에도 불구하고 ARC를 써야하나?

Objective-C를 처음 접한다면 써야한다. reference counted memory에 대한 걱정 없이 처음부터 배운다면 그것보다 좋은 것은 없다. 기존의 라이브러리를 사용하기 시작할 때 ARC pre-compilation을 확실히 제외하는 방법에 익숙해 지지 않으면 고통이…

ARC없이 행복하게 코딩하고 있었다면 아마 "난 필요없어!"라고 생각할 것이다. 지금까지 당신한테는 맞을 수도 있겠다. 대부분의 유명한 라이브러리들이 ARC로 변환되지 않았고 Core Foundation classes들도 ARC와 잘 동작하지 않는다. CF 클래스를 사용할때는 확실히 한계가 존재하고 toll free bridging을 동작하게 하려면 migrating code인 extra qualifiers들이 붙는다.

내가 보고 읽은 바로는 ARC는 바로 사용가능하다. 하지만 익숙해지기 전까지는 새 프로젝트에서만 사용하자. ARC가 iOS 4.0 에서 하위 호완성을 가지지만 weak reference는 iOS 5.0에서만 지원된다. 아마 다른 이유로 아직 모두 마이그레이션 안된 것 같다. (더 자세히 보려면 이 글 끝에 Resources 를 보시오)

어떤 초기 보고서는 ARC가 당신의 프로젝트를 더 빨리 만들 수 있다고 주장한다. 아마도 autorelease에 더 적은 신뢰로말이다. 하지만 retain/release를 더 잘 사용해서 할 수도 있다. 하지만 요점은 이것이다. ARC는 당신의 코드에서 효율적인 접근을 자동으로 선택해준다는 것.

현재 ARC로 옮기는 것은 조금은 힘들다. 긴 주말 뒤에 새 프로젝트를 시작할 때 이것은 애플의 새 추천 접근 방법이다. 그러니까 미래의 디자인 결정을 할 때 ARC 기반으로 하고 수동 reference counting을 하지 않게 될 것이다.

수영 - 500m

2011-07-30T11:31:04+09:00

계속 연습 하다보니 이제 500m정도는 할 수 있다
시간은 15분 정도 걸리는듯...

아마도 천천히 하면 더 길게도 가능할지도...
이제 속도를 올려야지~~

1. 호흡할 때 왼팔 굽혀지는 문제
2. 힘들어지면 발차기 할 때 발이 벌어지는 문제

발차기4+자유형10+자유형10=1시간

기본으로 돌아가자

2011-07-28T00:48:09+09:00

어느 운동, 아니 어느 분야에서나 기본은 중요하다.

스노보드를 예로 들면
많은 사람들은 획일화된 턴 자세를 신경 쓰겠지만 그보다 더 중요한 것은
변화하는 눈 상태에 따라 발목, 무릎, 허리, 팔, 어깨, 고개가 어떻게 잘 움직이느냐 하는 것이다.
눈 상태가 다르고, 슬로프마다 기울기가 다르고, 뭐 하여튼 기타 등등
물론 획일화된 턴 자세 연습이 필요없다는 것은 아니다.
그 경지까지 오르려면 턴 자세를 잡고난 다음에 턴 자세에서 변형을 가해서
자신에게 알맞는 턴의 자세가 나오게 되는 것이다.

프로그래밍을 예로 들면
어떤 사람들은 언어, OS 등이 중요하다고 생각하지만
고수들은 변화하는 환경에 어떻게 적응해서 새로운 언어, 새로운 플랫폼에 어떻게 적용할 것인지 벌써 알고 있다.

수영을 하다가...
진도가 점점 거꾸로 나가길래...
ㅜㅜ

거꾸로 나가는 진도이지만 실력은 점점 좋아지고 있음을 느낀다.

수영 원포인트

2011-07-27T00:25:28+09:00

회사의 고수분(사실은 중급실력이라고...하지만 나에게는 고수 +_+)이 원포인트를 해주셨다.

하악.

내가 수영을 못하는 이유는 어깨가 유연하지 못해서 ㅜㅜ
어깨 스트레칭을 막 하구 수영을 했더니
훨씬 잘되는 것이었다. ㅜㅜ

엉엉...

매일 스트레칭 열심히 해야겠다.

수영

2011-07-26T08:43:41+09:00

열심히 배우고 있따 ㅋㅋ

호흡할 때 머리 위치 수정했다.

팔저을 때 반대쪽 팔이 굽혀져 있는거 펴고...
발차기 가라앉는거랑...
고개 더 넣는거...
더 고쳐야함...

자전거

2011-07-24T23:03:13+09:00

행주산성 찍고 옴.

54km
쉬어가면서 4~5시간
중간에 Bike Computer 베터리가 나가서 기록은 못하고...

갈 때는 평속이 25정도...
올 때는 평속이 20정도...였는데도 힘들었다.

체력을 많이 길러야겠다.
첫 라이딩인데 너무 무리한 것은 아닐런지 ㅋㅋ

수영 - 자유형 적절한 호흡 동작

2011-07-23T22:26:04+09:00

자유형 숨쉬기를 할 때
최소로 고개를 내밀면서 숨을 쉬려고 하는데 자꾸 물을 먹는다.
고개를 많이 들면 물 안먹고 잘 쉴 수 있지만 아무래도 손실을 보니까...

스노보드 탈 때 너비스턴,카빙턴에서 몸을 얼마나 적절히 기울여야 하는지 몰라서 넘어지는 것과 비슷한 것 같다.

물 조금만 더 먹다보면 언젠가는... ㅜㅜ

자유형 30분 - 300m정도..

수영 5일째

2011-07-19T09:34:20+09:00

강사님이 팔접기 올라오다가 만다고 목요일에 가르쳐주신다고 한다.
사람이 꽤 많아졌다. 2레인에 23명 정도...

물이 차가워졌다. 물이 원래 소금물맛이었는데 염도가 내려갔고 수온도 내려갔다.

74.4kg / 쉬어가며 400m
74.4kg / 저녁 추가 연습 1시간 반 500m

자유형 팔꺽기 설명
http://blog.naver.com/PostList.nhn?blogId=shezgone85&categoryNo=15

수영 4일째

2011-07-16T21:34:04+09:00

머리를 물 밑으로 더 넣어야 다리가 뜬다.

그리고 동생한테 T자누르기 라는 기술을 배웠다.
그걸 하면 발이 더 높이 뜬다고 한다.

75.5kg / 쉬어가며 200m

수영 3일째

2011-07-15T08:41:13+09:00

강습 1시간 받았는데
확실히 많이 나아졌다고 혼자 생각하고 있음
수영 강사 선생님 좋음 ㅋㅋ
이상하게 별로 힘들지는 않음

조언 : 발차기를 좀 더 높게

74.5kg / 쉬어가며 250m쯤?

수영 이틀째

2011-07-14T22:03:46+09:00

이제는 다행히 죽을 것 같이 힘들지는 않다

75kg / 100m 쉬고 50m 쉬고 50m

수영 시작

2011-07-14T00:56:02+09:00

회사에 트라이애슬론 동호회에 가입하고 스포츠센터 1년 회원권에 가입했다.
10월에 대회가 있는데 수영 1.5km, 자전거 40km, 달리기 10km 의 올림픽 코스에 도전하기로 했다.

체력 운동은 안한지 1년은 다 되어가서 몸이 어떤 상태인가 테스트해봤다.
절...to the..망.......

100미터 했는데 숨이 차다.
내일부터 아침 7시까지 어떻게 가지?

롤링이 없고, 고개를 팔에붙여야하고, 고개를 너무 들지말고
10여가지 지적 받음 ㅋㅋ

74kg / 쉬어가면서 100m

[펌]칭찬의 역효과

2011-06-06T11:17:25+09:00

의료 웹 사이트 링크

2010-10-18T00:48:41+09:00

몇시간 하지도 않았는데 공부할 것이 이렇게 많다니 ㄷㄷㄷ

소셜 미디어와 의료 환경의 변화
http://www.koreahealthlog.com/1698

꼭 읽어야 하는 책 - 닥터스 씽킹 Doctor's Thinking
http://www.aladin.co.kr/shop/wproduct.aspx?ISBN=8973378791
하버드 의대 교수가 들려주는 의사들이 어떻게 사고하는지 잘 설명한 책

기술보다 하이터치가 의료에 더 중요하다
http://health20.kr/1134
이것이 바로 닥터스 씽킹에서 중요하다고 하는 것이다.

의료 포털 비타민 MD
http://www.koreahealthlog.com/1249

미국 간호사들은 모두 인터넷으로 갔다.
http://blogs.kormedi.com/5754
미국 간호사 4명중 3명은 온라인 상담에 적극적이고 건강 의료 웹사이트를 추천한다고 한다.

groupon 의 사례
치과를 개업하면서 80% 할인한 가격에 진단을 해주겠다는 소셜 네트워크를 기반한 공동구매

페이스북과 트위터가 의료를 어떻게 바꿀까?
http://health20.kr/1291

웹 2.0의 시대, 병원 홈페이지는 어떻게 바뀌어야 할까?
http://health20.kr/1187
내 생각엔 이젠 병원앱은 어떻게 바뀌어야 할까로 제목도 바껴야 할듯

MIT 에서 준비하는 소셜 미디어 의학
http://health20.kr/1121

의료분야 트위터 이용 사례
http://webscience.creation.net/6

환자와 소통하는 제네럴 닥터 블로그
http://gedoc.tistory.com

외국인 환자 유입 경로 분석
http://stoo.asiae.co.kr/news/stview.htm?idxno=2010042011133033896

하이컨셉 하이터치 블로그 운영자 의사출신 25년차 프로그래머 인터뷰
http://www.koreahealthlog.com/742?category=3