레베카 번개 후기 (was Re: Rebecca Wirfs-Brock 방한 기념 번개)

[June Kim]

어제 레베카를 호텔까지 바래다 드리고 집으로 돌아오니 밤 12시가 다되었더군요. 오늘 아침에 일어나서 잊기 전에 어제 있었던 일 후기를 쓰면 좋겠다 싶습니다.

일단 선물을 못한 것은 아쉽고요, 장정화님께서 맛있는 떡과 음료를 사다주시는 수고를 해주셔서 감사했습니다. 또 준비과정에서 관심 갖고 챙겨주셔서 고맙고요.

그리고 정말 촉박한 번개였음에도 많은 분들이 관심을 가져주시고 또 약속을 지키고 참석해주셔서 감사했고요, 편안하고 즐거운 분위기를 만들어주셔서 고맙습니다.

저는 모임 전에, 그리고 모임 중에 NOO 관련해서 어떤 이야기가 있었나에 초점을 맞춰서 후기를 적어볼까 합니다(유동민님도 오셨으면 좋았을텐데요). 그 외 부분은 어제 오셨던 다른 분들이 후기를 잘 써주실 수 있다고 믿고요.

참고로 NOO의 15 특성이 궁금한 분들은 지난번 NOO 공유회 발표를 위해 동민님이 준비해주신(그러나 발표는 못한 ㅠ) 도표를 참고하시면 좋습니다. http://miniway.blogspot.com/search/label/noo (Levels of Scale 경우 두 문을 서로 비교해 보시면 바로 느낌이 오실 듯)

호텔에서 레베카를 모시고 강남역으로 와서 저녁식사 대접을 했습니다. 마침 최승준님이 강남에 계셔서 같이 식사를 했고, 식사를 마쳐갈 때 쯤 신제용님이 합류를 했습니다. 저녁식사를 하면서 이런 저런 이야기를 했습니다.

레베카의 CACM 기사에 보면 NOO를 소프트웨어 설계에 적용해 보는 컬럼이 있었습니다. 근데 전 약간 의아해 했던 것이 15가지 특성(15 properties)을 설계에 적용하는 것에 대부분의 내용을 할애했다는 점이었죠.

제가 보기에 NOO에서 소프트웨어 설계에 적용할만한 부분은 크게 두 줄기가 있습니다. 하나는 조금 정적인 것으로 15가지 특성, 다른 하나는 동적인 것으로 생성적 절차(generative/unfolding sequence)입니다. 전자가 outcome에 가깝다면 후자는 process에 가깝죠. 물론 둘이 결국 통하고 나중에는 동등하게(15 특성이 process에도 적용됨) 설명되긴 합니다. 그리고 이 둘 중에는 비교적 후자가 SW 설계에 적용하기 좀 더 쉽고, 또 더 파워풀합니다(물론 이것은 초점의 문제이지 선택의 문제가 아니죠). 전자는 문제 공간의 기하학적 측면이 전제되어야 하는데, 이런 공간을 상정하는 것이 임의적일 수 있고 일관적으로 만들기가 쉽지 않기 때문에 15가지 특성의 적용은 after-thought 즉, 사후적 설명이 되기 쉽습니다. (하지만 효과적 적용도 가능한데, generative sequence를 중심으로 적용하고 보조적으로 15 propertise를 쓰면 가능)

다시 말해, 레베카는 더 간단하고 엘레강트한 적용 방법을 놔두고 왜 어렵고 잘 안들어맞는 듯 보이는 요소를 적용하려고 했냐 이런 의문이 제게 있었던 거죠.

그런데 그 이유가 흥미롭더군요. 이야기 해보니 레베카는 1권을 읽고, 2권은 스키밍(훑어보기)을 했답니다. 저랑 최승준님 및 NOO 스터디에서는 2권을 읽었습니다. 그리고 저는 1권을 스키밍과 발췌독을 했습니다. 그런데 1권이 정적인 요소(15 특성)를 핵심적으로 다루고, 2권이 과정적 요소(generative sequence)를 다룹니다. 그래서 레베카 입장에서는 2권에 대한 고민과 이해가 부족해서 그랬다는 생각이 들었죠. 그러면서 레베카가 우리 NOO 스터디 그룹을 매우 부러워 하더군요. 자기도 스터디 그룹 했는데 멤버가 자기 혼자였다고 하네요(결국 혼자 공부했다는...). 그래서 다음번에 NOO 관련해서 뭔가 하면 레베카도 참여해서 온라인을 통한 스터디 모임 같은 걸 공동 진행해 보기로 했습니다.

어제 모임 중에서는 NOO의 alternative repitition과 levels of scale이야기가 나왔죠. 설계를 하는 사람이 macro view와 micro view를 모두 가지고 진행해야 하는데(교차적으로 하건, 동시 진행하건) 앞의 두 특성이 유사성이 있다는 이야기가 나왔습니다. 특히 LoS 경우, 레베카는 CRC 카드, Diagramming, Code의 세 레벨(앞에서부터 고차원/추상적)로 생각하고 작업해야 좋은 설계가 나올 수 있다고 말하며, 그 레벨 구분이 흐릿해져서 뭉쳐버리거나 혹은 뭔가가 빠지면 문제라고 보는데, LoS와 대응되는 부분들이 있습니다. 통상 LoS는 즉물적으로 해석하면 객체나 클래스의 크기라는 차원에서 생각하기가 쉬운데, 어제는 추상성의 차원에서 생각해 본 것이었죠.

그런데 이것 역시, 결과로서의 LoS보다, 과정으로서의(transformational) LoS로 보면 더 흥미로운 점들이 있습니다. 이 부분은 어제 언급되지 않았습니다.

결과적으로 참 흥미로운 시간이었고, 레베카도 생각해볼 수 있는 질문들을 해줘서 고맙다고 하시네요. 저는 개인적으로 다음 NOO 스터디의 동료를 얻을 수 있게 돼서 뜻깊었습니다. ㅎㅎ

2010/3/11 Min <min...@gmail.com>

지금 남은 일의 분량을 봐서는 시간에 맞추기가 힘들 것 같습니다. 6 시가 넘어서 취소가 안되네요, 

한분 저대신 참석하셔도 될 것 같습니다.

NOO 와 XP 의 연결은 정말 궁금한데 말이죠 ㅠㅠ

2010/3/11 Chungha Yun <chu...@gmail.com>

빠른 답변 감사드립니다.

저는 알렉산더라고 하시길래..알렉산더 대왕인줄 알았다는;;;ㅠㅠ (아..이 무지함;;)

출발하기 전까지 열심히 찾아봐야겠네요~

2010년 3월 11일 오후 5:37, 이평섭 <pyon...@gmail.com>님의 말:

Nature of Order 입니다.

2010/3/11 Chungha Yun <chu...@gmail.com>

혹시 NOO가 머의 약자 인가요?

제 구글링 실력이 딸려서;;ㅠㅠ 갈챠주세요~

2010/3/10 June Kim <june...@gmail.com>

참고로 주제는 알렉산더, NOO, 애자일 실천법, 한국의 애자일 실천과 커뮤니티, 트렌드 등이 될 것 같습니다. 편안한 자리가 되었으면 하시더군요.

2010/3/10 June Kim <june...@gmail.com>

2010/3/10 June Kim <june...@gmail.com>

http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock

레베카 워프스 브락이라는 분이 계십니다. 매우 친 애자일적인 분이고(애자일 진영의 분들과도 친합니다) 소프트웨어 설계쪽으로 나름 유명하신 분입니다. 저는 그분의 최초의 책인 DOOS를 20세기에 봤고 큰 인상을 받았습니다. 2002년에는 DOOS를 좀 더 업데이트해서 Object Design이란 책을 내셨죠. 참고로 DOOS는 제가 전산학 분야 저에게 가장 큰 영향을 준 서적 목록에 꼽는 책 중 하나입니다. http://xper.org/wiki/seminar/_b1_e8_c3_a2_c1_d8_c0_c7_bc_ad_b0_a1 (10년 전에 만든 목록인데 감회가 새롭습니다)

레베카의 객체 설계 철학은 소위 스몰토크 학파와 맥을 같이 하는 편입니다. 그녀의 남편인 알렌 워프스 브락은 텍트로닉스에서(레베카도 여기 출신) 워드 커닝햄과 같이 일하기도 했고, 초기 스몰토크 구현에 참여했던 역사적 인물 중 하나이기도 합니다. 레베카의 설계 철학은 책임 주도 개발(Responsibility Driven Design)으로 불립니다.

레베카는 국내에 두어번 방문을 하신 것 같습니다만 이제까지 공개된 자리에서 뵐 기회는 없었죠.

그런데 이번 목요일 저녁에 어쩌면 가능할 수도 있겠습니다. 아직 확정된 것은 아닙니다만 이야기가 오가는 중입니다.

목요일 저녁 미팅이 확정되었습니다. 현재 신청자 숫자로 보아, 강남 토즈점 25명 부스를 선택하게 되겠군요. 인원이 충분히 못오면 회비가 커지는 약점이 있긴 합니다.

기대가 되네요.

간단한 선물 같은 거 해주면 좋을 것 같은데, 혹시 도와주실 분?

 

일단 아이디어는 번개이고, 가능하신 분들과 모여서 우리가 레베카에게 궁금한 것 물어보고, 또 레베카는 우리에게 궁금한 것 물어보고 스낵도 먹고 하면서 좀 편안한 시간을 가졌으면 하는데(레베카가 우리나라에서 일주일 동안 강의만 하다가 간다고 하니, 얼마나 강의에 치여있겠습니까), 장소나 방식 등등에 대해 아이디어 있으신 분?

--
한국 XP 사용자 모임(http://xper.org) 메일링 리스트에 가입하셨기에 이 메시지를 보내드립니다. Google 그룹스 "xper" 그룹
이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오.
xp...@googlegroups.com
이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오.
xper+uns...@googlegroups.com
추가 옵션을 보려면 http://groups.google.com/group/xper?hl=ko?hl=ko의 그
룹을 방문하십시오.

--
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com

--
한국 XP 사용자 모임(http://xper.org) 메일링 리스트에 가입하셨기에 이 메시지를 보내드립니다. Google 그룹스 "xper" 그룹
이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오.
xp...@googlegroups.com
이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오.
xper+uns...@googlegroups.com
추가 옵션을 보려면 http://groups.google.com/group/xper?hl=ko?hl=ko의 그
룹을 방문하십시오.

--
한국 XP 사용자 모임(http://xper.org) 메일링 리스트에 가입하셨기에 이 메시지를 보내드립니다. Google 그룹스 "xper" 그룹
이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오.
xp...@googlegroups.com
이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오.
xper+uns...@googlegroups.com
추가 옵션을 보려면 http://groups.google.com/group/xper?hl=ko?hl=ko의 그
룹을 방문하십시오.

--
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com

--
한국 XP 사용자 모임(http://xper.org) 메일링 리스트에 가입하셨기에 이 메시지를 보내드립니다. Google 그룹스 "xper" 그룹
이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오.
xp...@googlegroups.com
이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오.
xper+uns...@googlegroups.com
추가 옵션을 보려면 http://groups.google.com/group/xper?hl=ko?hl=ko의 그
룹을 방문하십시오.

--
한국 XP 사용자 모임(http://xper.org) 메일링 리스트에 가입하셨기에 이 메시지를 보내드립니다. Google 그룹스 "xper" 그룹
이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오.
xp...@googlegroups.com
이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오.
xper+uns...@googlegroups.com
추가 옵션을 보려면 http://groups.google.com/group/xper?hl=ko?hl=ko의 그
룹을 방문하십시오.

[hellena Jang]

먼저 김창준님께 레베카 아줌마와 뜻깊은 시간을 가질 기회를 주셔서 너무 감사드립니다.

 

프로그래밍이나 아키텍트에 관해 잘 모르는 저로써는 가기전에

알렉산더와 NOO를 찾아보고 간 것이 도움이 많이 되었습니다.

(물론, 창준님의 뛰어나신 번역 및 추가 설명들이 아니였으면, 알아듣기 힘들었을 것입니다. ^^* )

 

가장 인상깊은 부분은 매크로뷰와 마이크로뷰 부분이였습니다.

전문가(많은 경험과 경력, 노하우를 가진자)와 초보자(그렇지 못한자)의

가장 큰 차이가 될 수 있다는 생각도 들었습니다.

 

또 개인적으로 신선했던 부분은,

프로그래밍을 하지 않는 유일한 참석자가 저 혼자였다는 것과,

쉬는시간에 제가 레베카 아줌마께 프로그래밍을 하지 않는 유일한 참석자인

저에게 왜 그 자리에 참석했냐고 물었냐고 다시 질문을 했을 때,

프로그래밍과 아키텍트 등에 관한 대화가 대부분이여서

제가 지루하거나 소외될까봐 걱정하셨다더군요~ (배려심에 감사했습니다.)

 

저는 프로그래밍을 하지 않지만, 개발자가 아니지만,

우리 회사, 조직, 구성원이 모두 발전하고, 행복해 지길 바라며,

그러기 위한 방법으로 애자일을 배우고 싶다고 하였습니다.

 

쉬는시간에 덧붙여 레베카 아줌마께 추가 설명으로

나는 기획자 겸 마케터인데, 개발자들이 며칠 밤새며 개발을 할 때,

같은 조직원으로써 도울일이 없었다... 개발자들이 불쌍했다...(죄송합니다.)

그래서 애자일을 통해서 발전하고 나아지고 싶다고 얘기했습니다.

 

레베카 아줌마도 웃으시며 공감하시더라구요^^*

 

비록 중요한 선약으로 끝까지 함께하지는 못했지만,

경험하기 힘든 경험을 할 수 있어 감사한 시간이였습니다.

 

 

 

 

 

 

 

2010년 3월 12일 오전 8:13, June Kim <june...@gmail.com>님의 말:

[Chungha Yun]

어제 NOO 관련 내용을 들을때에도 신선한 충격이었는데.. 이렇게 자세하게 설명해 주시니 정말 감사드립니다.

NOO에 대한 내용은 어제 처음 접했는데 새롭게 공부할 내용이 생겼네요. 책 사서 읽어봐야 겠습니다. 

장정화님이 준비해주신 떡을 와이프 주려고 하나 챙겨왔는데 (남았길래ㅋㅋ) 깜빡하고 가방에서 안꺼내서

회사에까지 가져왔네요..@@

xper 모임이 좋은 점은 모임에 매번 나가지 못해도 다른 모임과는 다르게 그닥 소외받지는 않는다는 것입니다.

예전에는 일때문에 참석못한 적이 많았었는데, 이제는 제 미래를 위해서라도 꼭 참석하도록 하겠습니다.

근데 참석하셨던 분들이 모두 영어를 잘하시는듯..ㅠㅠ 2차 충격;;;ㄷㄷㄷ

2010년 3월 12일 오전 8:46, hellena Jang <jang.h...@gmail.com>님의 말:

[이평섭]

레베카님께 질문하였던 것 중에 '가장 크게 실패하였던 경험은, 그 때로 다시 돌아간다면, 어떻게 하겠느냐'에 대한 이야기...

실패가 없어서, 이제 까지 일을 하고 있다는 ^^

실수는 있엇다는 이야기에서, 처음 일을 시작한 회사에서 개발할 때의 경험을 이야기해 주었습니다.
코볼로 작업 중이었고, 회사는 개발자를 레벨로 관리하였는데, 자신은 레벨2 이었다고 합니다.
파일에 데이터를 기록하지 않고, 코드에 기록하는 실수를 한 것 그리고, 다시 돌아간다면, 그렇게 하지 않겠다는 것이었죠.
레벨4의 선임자와 관련된 이야기도 있었는데,기억이 나지 않구요. 아비엠 스타일의 회사였다는 이야기로 재미있어 했습니다.

실패와 실수라는 생각의 차이가 긍정적이라는 생각이 듭니다. 실패는 없어도, 실수는 있다. 실수는 돌이킬 수 있다.
또 레베카님도 수십년전에 일을 처음 시작할 때는 그랬구나 하는 생각과,
지금의 모습으로 자신을 변화시키는 과정의 터닝포인트에 대해서 궁금해지네요.
마지막에 질문할 껄 그랬나 봅니다.

자리마련하여 주신 김창준님, 장정화님과 신제용님께 감사드리며, 좋은 하루 되시구요.

2010년 3월 12일 오전 9:21, Chungha Yun <chu...@gmail.com>님의 말:

[Seung Joon Choi]

벌써 기억이 가물가물한데, 저는 후반부에 나온 다음 사람에게 인수인계(?) 진행완료 혹은 진행중인 경험과 지식을 다음 사람에게 전달할 때 어떻게 하느냐의 질문에 대한 (맞나요?) 레베카의 답변에서

창준님의 역할극 제안에 흔쾌히 상호작용해줬던 부분도 인상적이었는데요.

결국 문서로만 전달하고 땡이 아니라, 그 문서에 대한 비평도 들어가며, 대면을 통해, 그리고 비공시적인 채널을 통해 사람들을 만나고 소통하는 것을 해왔고 해야한다는 이야기를 들었을 때

시간이 좀 더 있었더라면, 그리고 청중이 NOO와 패턴에 대한 맥락에 관심있어 한다는 확신이 있었다면,

그런 '암묵지'자체를 어떻게 사람들에게 전달하고 알리느냐 (역시 비공식적인 채널일 수 있겠죠) 하는 것을 질문하고 싶었습니다.

거기에 더하여 혹시 알렉산더의 '패턴'(디자인 패턴이 아니라)을 그런 다큐먼테이션에 응용해 본 적이 있는지도 궁금했구요.

창준님의 코멘트 중

그런데 이것 역시, 결과로서의 LoS보다, 과정으로서의(transformational) LoS로 보면 더 흥미로운 점들이 있습니다. 이 부분은 어제 언급되지 않았습니다.

은 중요한 내용이라고 생각합니다. 결과로 15 props 보다는 과정이 흥미로운데 공감합니다. 하지만 이 역시도 결과로써 after-thought를 하는 것이 연습이 되어 다음을 진행할 때 '과정으로 15 props를 생각'하는데 도움을 줄 것이기 때문에 아마도 주변에서 레베카에게 좋은 질문을 던져준다면(너무 전문가의 경지로 존경하기만 하지 않고, 혼자 공부하도록 외롭게 하지 않는다면) 많은 사람들에게 더 좋은 영감을 불어 넣어주시지 않을까 기대합니다. 역시 alternating repetition 속에 발전이 있는 것이 겠죠.

특히 LoS 경우, 레베카는 CRC 카드, Diagramming, Code의 세 레벨(앞에서부터 고차원/추상적)로 생각하고 작업해야 좋은 설계가 나올 수 있다고 말하며, 그 레벨 구분이 흐릿해져서 뭉쳐버리거나 혹은 뭔가가 빠지면 문제라고 보는데, LoS와 대응되는 부분들이 있습니다.

질문할 때 사실 저는 제용님의 말씀을 듣고 LoS(레벨 오브 스케일)를 바로 떠올려서 확인하려고 했기 때문에, 좋은 질문은 아니었을지도 모르겠습니다만, 처음 나온 이야기가 alternating repetition이었다는데 약간 놀랐습니다. 그리고 창준님의 도해로 부터 아하!가 있었죠. 사실 NOO 2권에 보면 15 props의 상관관계와 때로는 비슷한 요소가 15안에서 나타나는 것에 대한 표가 있음이 기억났습니다.

이 질문의 맥락이 아키텍트는 추상적인것 부터 구체적인 것 까지 다 인식하고 염두에 두어야 할 수 있다는 맥락이었죠? (가물가물)

CRC 카드, Diagramming, Code의 세가지 스케일 레벨이 있을 때(그리고 어떤 구조라고 비슷한 양상이 나타나죠) 그 레벨의 구분을 적절히 유지하는 것이 그 구조를 더 살아있게 만드는, 즉 sweet point 같이 sweet scale이 있다는 점에 매우 공감합니다. 알렉산더는 NOO에서 프랙탈(fractal)이라는 용어를 쓰지 않고 있죠. 대신 15 props안에 fractal과 개념과 관련이 있는 것이 반복적으로 나옵니다.

micro와 macro를 오가는 과정중에 있는 것(저는 -scopic을 이야기할 때 trans-scopic 혹은 transcopic이라고 부릅니다)은 중요합니다.

어떤 전문가들이라도 아마 이 것을 자연스럽게, 부지불식간에 하고 있지 않을까요.

어떤 현상을 관찰할 때, 예를 들어 풍경이라고 하면 내가 그 것을 재인하는 능력이 400 x 400 픽셀의 한정된 메모리 안에서만 이루어진다고 합시다. 그리고 두 가지 경우를 생각해 봅니다.

첫번째 경우

1. 멀리서라면 각각의 1픽셀에 대한 샘플링은 작은 정보만 들어가면 됩니다. (실제로는 연속적으로 보이는 더 많은 데이터를 샘플링하여 1픽셀을 표현하는 것이죠). 하지만 여기서 그 샘플링을 제대로 못해내면 그림은 큰 손상을 받습니다. 
2. 아까보다는 가까이 가서 보면 그림의 크기는 작아지지만, 1픽셀을 위해 샘플링 해야할 정보는 충분해 집니다. 샘플링하기가 쉬워지는 편입니다.
3. 아주 가까이 가서 보면 그림의 크기는 매우 작아지고, 샘플링 해야할 정보가 매우 많이 있습니다. 충분히 무시해도 같은 결과를 낼 수 있는 정보들이 있을 수 있는 레벨인 것이죠.

두번째 경우는 앞에서와는 같은데 앞뒤로 가면서 관찰 대상과의 거리를 변화시키는 것이 아니라 거리는 고정하고 샘플링 하는 영역의 크기를 변화시키는 방법을 취합니다.

1. 400x400 영역을 5x5씩으로 쪼개어서 관찰하고 샘플링해서 5x5를 채울 색을 만들어 냅니다. 이런 영역이 80x80개가 생깁니다
2. 400x400 영역을 20x20씩 쪼개어서 색을 칠하고 20x20개의 영역으로 전체 그림을 표현합니다
3. 400x400 영역을 50x50씩 쪼개면  8x8개의 영역으로 전체 그림이 표현되겠죠

그런데 각각의 단계를 시간에 따라서 중첩하면서(cross fade) 보면 1x1씩 샘플링한 정도는 아니더라도 각각의 관찰단계만 놓고 보았을때 보다 원래 풍경(현상)에 가까운 이미지가 보이는 것을 느낄 수 있습니다. computer graphics에서의 subpixel sampling이라던가 anti aliasing 기법들과도 연관이 있을 것이라고 짐작해 봅니다.

제가 위에 '느낄 수 있다'고 표현한 것은 인식의 주체가 '사람'이기 때문입니다. 그리고 그 것이 중요한 부분이라고 생각하구요.

CRC, Diagram, Code는 결국 하나의 현상을 표현하는 3가지 단계 아닐까요?

좀 딱딱하게 표현하긴 했지만 일상생활에서 위와 같은 일을 실천해 보는 것(다양한 레벨로 관찰/생각해 보고 그 사이를 오고 가는 것)이 재밌는 생각을 하는데 큰 도움이 된다고 믿습니다.

한 가지가 더 인사이트가 있었는데, 글을 적다보니 까먹었습니다. 글을 적기 시작하기 전에 인사이트들만 키워드로 적어놓고 시작할 것을 그랬나봐요. 매번 실수하네요. ㅎㅎ 

[Seung Joon Choi]

까먹었던 내용은 생각이 안나고 다른 내용이 생각나네요.

애자일 팀에서 실수가 있었을 때 어떻게 할 것이냐에 대한 레베카의 질문에 제가 생각한 답변은

'선택과 책임'이었습니다. 어떤 선택을 하고 어떻게 책임을 질 수 있느냐가 중요한 부분인데, 레베카도 관련한 이야기를 좀 해주었던 것 같은데 정확히 기억은 안나네요.

이럴 바에야 차라리, 커뮤니티가 할 수 있는 일이라는 것이 늘 그렇듯, 우리가 모았던 질문의 목록을 문서화 시키고, 레베카의 답들도 기억나는데로 기입해 놓고, 질문하지 못했던 내용들에 대해서는 스스로 다양한 대답하려는 시도를 해보는 것이 어떨까요?

그리고 이를 통해 좋은 질문들의 목록이 만들어진다면, 다음에 또 다른 전문가를 모실 때 같은 질문을 던져보는 것도 의미있는 요소가 될 수 있을 것 같습니다. 하나의 질문에 대한 다양한 현답을 얻을 수 있는 가능성이 있겠죠.

[Seung Joon Choi]

생각 안났던 것이 났습니다.

공던지기에 대한 것이었군요. 저도 수업에서 공을 꼭 사용해봐야 겠다는 생각을 해봤습니다. 언플러그드 컴퓨터 사이언스와도 맥락이 닿는 부분이지 않을까요.

사람(오브젝트)들이 이미 역할을 가지고 있고, 서로 공(메시지? 창준님은 프로그램 카운트라고?)을 던져 보면서 테스트 해보는 것이었던가요? 그럼 바로 설계에 대해 뭔가를 알 수 있게 될 것 같습니다.

공은 고무공이면 되겠죠. ㅎㅎ

[Jooyung Han]

http://en.m.wikipedia.org/wiki/Koosh_ball?wasRedirected=true

Koosh ball

이번 교육에서는 Koosh Ball 이란걸 이용했습니다.  고무냄새 진하게 나는 것이라 레베카 교육 중에 졸릴 때 쓸ㄲ 싶었답니다 :)

프로그램 카운터라 볼수도 있고 토큰이라 볼수도 있고. 멀티쓰레드인 경우엔 공 두 개를 동시에 사용하기도 한답니다. 물론 권장사항은 아니겠죠. 공두개가 한사람한테 가서 얼굴 맞는 경우도 있었다는 군요 ㅋ

단순 고무공도 좋겠지만 나름 새로운 느낌을 주는 쿠쉬볼도 재밌었습니다. 

Sent from my iPod

--