이 책은 에디슨 위슬리 반 버논 시리즈의 여러 책 중의 한 권이다. 특히, 아키텍처 설계와 관련해서 관심을 가지다가 알게 되었고 번역 제안을 받아 진행하게 되었다. 쉽지 않은 과정이었지만, 몇 가지 알게 된 것, 느낀 것 그리고 번역에 대한 나의 짧은 생각을 적어 보려 한다. 

 

반 버논은 도메인 주도 설계(Domain Driven Design, DDD)가 도입되는데 큰 기여를 하고 있다. 특히, 도메인 주도 설계 구현(Implementing DDD)으로 유명하다. 나는 DDD가 요구사항과 구현 사이의 간극을 드라마틱하게 줄여주는 실천법이라고 생각한다. 이를 통해 확보한 요구 사항의 명확한 이해를 기반으로 효과적인 소프트웨어 설계를 수행할 수 있다. 흥미롭게도 비지니스 전문가와 개발자들이 함께 일하는 애자일 원칙과도 맞닿아 있다. 또한 이 책은 반 버논 시리즈의 두 번째 역서이다. 하나는 API 설계 원칙이다. 반 버논의 추천사를 보아도 두 책의 저자들이 상호 보완적으로 글을 썼다고 한다. 이 책에서는 웹 API 설계 원칙의 정렬-정의-설계-구체(Align-Define-Design-Refine) 단계 개념을 패턴에 적용하기도 했다.

 

반버논의 추천사에서 보면 유기적 구체(organic refinement)는 소프트웨어와 관련된 모든 개념이 무생물이 생물체의 측면을 '특성화'한다는 아이디어를 언급한다. 소프트웨어는 구체적인 시나리오를 통해 모델을 논의하거나 아키텍처를 설계하고 단위 테스트와 도메인 모델을 작성함으로써 살아 움직이기 시작한다. 마찬가지로, 건축가이자 패턴 개념을 만든 크리스토퍼 알렉산더는 "Nature of Order"에서 인간 배아(Embryo)의 예를 들며, 분화(Differentiation)에 대해 이야기한다. 이는 유기적 구체와 매우 유사하며 유기적이며 발전하고 성장하는 프로세스를 강조한다. 이러한 관점에서 소프트웨어의 진화는 생물의 발전에 대한 이해와 유사한 맥락에서 이해할 수 있다. 생명체가 환경과 상호작용하면서 성장하고 변화하는 것처럼, 소프트웨어도 사용자와 시스템 사이의 상호작용 속에서 점진적으로 발전하는 것이라 이해할 수 있다.

 

이 책에서 언급하는 패턴의 경우도, 이러한 유기적 구체 혹은 분화 과정에서 발견되는 반복적인 내용들을 잡아 내어 패턴의 커뮤니티에서 키워내고 리뷰하여 만들어 내는 과정을 거친다. 그러므로, 패턴, 유기적 구체, 분화와 같은 것을 이해하고 소프트웨어 구조를 설계할 때 분화의 관점 그리고 소프트웨어가 발전 성장하는 과정에서 패턴을 적용해가는 것이 필요하다는 관점에서 이 책에 접근하는 것을 권한다.

 

개별 언어는 독특한 여러 특징을 가진다. 이로 인해, 각 언어에 내재한 작은 뉘앙스 차이를 다른 언어로 옮기는 일은 매우 어렵다고 생각한다. 이 책에서는 "force"라는 어찌 보면 ""이라고 단순하게 번역할 수 있는 단어의 번역에 고민을 오래 하였다. 소프트웨어 설계에서 "force"는 설계 결정에 영향을 미치는 다양한 요인을 의미한다. 특히 이 책에서는 패턴의 문제-해결 짝과 이후에 상세 설명에서 패턴과 관련된 여러 "중요한 요구 사항"을 가리키는 용어로 등장한다. 이는 서로 상충되는 경우가 많다. 다른 아키텍처 책에서도 이 "force"를 언급하지만 이 책에서 더 자주 언급되어 시간을 들여 고민을 하였다.

 

이 책에서는 한글과 원어를 여러 번 병기하였다. 그 이유는 소프트웨어 개발이나 소프트웨어 개발과 관련된 도메인의 중심이 여전히 미국에 있기 때문이다. 따라서 영어로 쓴 원서나 관련 논문, 인터넷 글을 읽을 기회가 많으므로 원어 용어에 익숙해져야 한다. 따라서 이 책에서도 병기를 충분히 했다. 여러분도 책을 보면서 소프트웨어 아키텍처와 소프트웨어 개발에 관련된 원어 용어에 익숙해졌으면 한다.

 

번역 중 저자들과의 몇 번의 소통이 있었다. 올라프 짐머만과의 몇차례 이메일을 통해서 사소한 오탈자 뿐 아니라 그들이 생각하는 용어 정의와 같은 부분에 대해서도 의견을 나눌 수 있었다. 이러한 과정은 나에게 새로운 경험이었고, 책에 담긴 내용을 조금 더 깊게 이해하는데 도움이 되었다.

 

책의 번역을 마무리하면서 소프트웨어 개발, 설계에 대해 다시금 돌아보며 좋은 학습의 기회였고, 저자와 연락하며 짧지만 전문가들과 이야기 나눌 수 있어서 좋았다. 번역이라는 작업에 대해서도 내 생각을 정리하는 것은 나름 의미가 있었다

문제 해결 방법은 여러가지가 있을 수 있다. 혼자서 열심히 고민하여 문제 해결 하는 방식도 있지만, 팀으로서 협력하는 것은 매우 효과적이다. 하지만, 현실은 늘 항상 들어 맞는 정답은 없다. 그래도, 성공적인 팀-협업적(Collaborative)으로 일하는 팀이 문제를 효과적으로 해결한다.

 

여기서는 김창준님의 함께 자라기[1]에서 이야기하는 소프트 스킬, 협력적 추상화, 그리고 전문가를 어떻게 팀으로 데려와 성공할 수 있는가의 측면에서 살펴 보자

하드 스킬(Hard Skill) vs 소프트 스킬(Soft Skill)

우리는 많은 경우, 특정 도메인에서 일을 한다. 전자 상거래, 소셜 미디어, 멀티미디어 등 여러 가지가 있을 수 있다. 이렇게 한 분야에서 일을 하다 보면 그 분야, 즉 도메인 지식(Domain Knowledge)가 증가한다. 뿐 만 아니라, 개발자라면 컴퓨터 언어, 자료 구조, 알고리즘과 같은 개발과 관련돈 공통된 지식도 증가하게 된다. 이러한 것은 우리가 문제를 해갈 하기 위한 기술 하드 스킬(Hard Skill)이라고 할 수 있다.

 

우리가 혼자서 일한다고 하면 이 하드 스킬만 키우면 문제 없다. 하지만, 우리가 여러 사람들과 일하게 되면 여러가지 다른 기술이 필요해 진다. 즉, 사회 생활을 하는데 도움이 되는 자본과 기술이 필요하다고 한다. 좀 더 구체적으로 이야기 하면 커뮤니케이션과 협업 능력과 같은 소프트 스킬(Soft Skill)이 중요하다. 숙련된 프로그래머/개발자들에게 이야기 들어 보면 이러한 소프트 스킬을 높이는 것도 강조하는 사람이 많다는 것을 알게 된다.

 

이 부분은 뒤에서 문제를 해결하는데 기본이 되는 것이라고 할 수 있다.

협력을 통한 추상화(Collaborative Abstraction)

대니얼 슈와르츠[2]의 연구에서는 한 명이 문제를 푸는 것 보다 두 사람이 문제를 푸는 차이에 대해서 설명하면서 두 사람이 문제를 푸는 경우가 문제 해결에서 추상화를 통해서 새로운 것을 발견하도록 도와 준다고 한다. 이는 둘이서 협력(Pair-work)하면서 다른 시각(perspective)를 받아 들이고, 이를 연결하기 위한 추상화 필요하다고 설명한다.

 

이러한 추상화는 단순히 서로를 이해하게 하기 위한 것 뿐 아니라 문제를 바라 보는 단계를 높인다. [1]에서 언급하듯이 전산학의 소프트웨어 공학나 많은 학문이 그렇듯이 이 추상화를 거쳐서 발전하게 되었다. 그러므로, 우리는 이러한 추상화를 더욱 일어나게 하기 위해서 협업을 해야 한다. 

전문가와 일하는 방법 (How to bring experts)

우리가 특정 분야의 문제를 해결하려면 전문가를 데리고 하는 것이 유리할 것이라는 것은 예측하기 쉽다. 하지만, 여기에는 함정이 있다. 울리의 연구[3]를 보면 전문가와 일하되, 협력적으로 조율(Coordination)하고 통합(Integrate)하라고 가이드 한다. 

 

그의 연구에서는 전문가 혹은 비전문가 팀이 협업을 하는지 하지 않는지를 나누어 비교 연구하였다. 즉, 다음과 같이 그룹을 나누었다.

1. 전문가 협업 개입

2. 전문가 비협업 개입

3. 비전문가 협업 개입

4. 비전문가 비협업 개입

 

어느 팀의 성과가 가장 좋았을까? 그렇다 전문가 협업이 가장 좋았다. 그렇다면, 꼴지팀은 어디였을까? 전문가 비협업이었다는 것이 매우 흥미롭다. [1]에서는 전문가를 데리고 오더라도, 정보를 공유하고 협력을 잘하기 위한 명시적인 도움이 필요하고 소셜 스킬이 뛰어난 제너럴리스트가 있으면 도움이 된다고 조언한다.

 

참고 문헌

[1] 김창준, "함께 자라기- 애자일로 가는 길", 인사이트 · 2018년

[2] D. L. Schwartz, "The emergence of abstract representations in dyad problem solving", The journal of the learning sciences, 1995

[3] A. W. Woolley, et al. "Bringing in the experts: How team composition and collaborative planning jointly shape analytic effectiveness." Small Group Research 39.3 (2008): 352-371.

1만 시간의 재발견[1]으로 알려진 안데르스 에릭슨은 의도적인 수련(Deliberate Practice)으로도 알려져 있다. 자신의 전문성을 키우기 위해 의도적으로 따로 연습하는 방법이라고 볼 수 있다. 개발자 혹은 자신의 전문성을 키우고 싶은 사람으로서 수련하는 방법의 좋은 예로 김창준님의 Facebook 포스트[2]를 보고, 조금 더 추상화 부분을 정리해 보았다. 그리고, 최근 그릿[3]을 읽으면서 알게 된 부분도 같이 붙여 메타인지를 해보자.

 

김창준님개발자의 의도적 수련 활동:

 
관찰하고/책 읽고/비디오 보고,  시도하기: 매우 일반적일 수 있지만 시도하는 것은 조금 더 발전된 부분이다.
* 새로운 도구, 기술, 코드, 기법을 시도해 보고 그 결과를 관찰, 분석해 보기
* 개발 관련된 저널과 잡지, 책을 읽기, 개발 관련해 인터넷을 훑어보기, 관련된 비디오를 보기 등
* 개발 관련 세미나, 워크숍, 교육과정, 컨퍼런스 등에 참석하기
* 다른 동료 혹은 회사 밖의 사람의 코드나 작업물를 구경하거나, 다른 동료(개발자 외에도 QA 담당자라든지)가 일하는 방식을 주의 깊게 관찰해서 새로운 아이디어를 얻기
피드백 찾기(Feedback-seeking): 피드백을 받는 것은 쉽지 않다. 그래서, 그 부분을 찾고 다르게 일해 본다.
* (회사 내외의) 다른 개발자나 도메인 전문가의 의견을 묻기, 남에게 배우기 위해 네트워킹하기, 새로운 도구, 기술 등에 대해 동료와 이야기하기
* 나의 고객(내게 일을 주는 사람 -- 기획자, 운영자, 다른 개발자 등)에게 다가가서 피드백을 달라고 하기, 그 고객들의 니즈에 대해 묻기 등
 
페어 워킹: 다른 사람과 함께 할 것을 찾아 보거나 같이 하면서 배운다. 
* 어디에 개선이 필요한지 다른 직원들과 브레인스토밍 하기
* 사석에서 친구랑, 혹은 배우자나 다른 사람과 개발 일에 대해 이야기하며 새 아이디어를 얻기
* 다른 사람의 업무에 대해 배우기 위해 그 사람을 도와주기
 
회고: 자신의 상태를 점검해 보고 새롭게 해본다.
* 현재 코드의 상태를 점검해서 어디가 장차 문제가 될 수 있는지 확인하기, 코드 품질을 확인해서 개선할 방법을 찾기 등
* 내가 조금전, 오늘 혹은 이번주에 했던 일들을 복기하며 반성해 보고 실수한 것은 무엇인지, 다음에는 어떻게 하면 좋을지 생각하고, 다음을 위한 행동 계획 짜기
 
의도적 수련: 진정한 의도적 수련으로 보인다. 많은 사람들이 하지 못하는 부분이다.
* 이미 개발한 프로그램을 더 잘 만들 요량으로 다른 방법으로 처음부터 다시 개발해 보기
* 이미 개발했고, 기능상 문제가 없지만 리팩터링 등을 통해 코드 구조를 더 개선하거나, 성능상 문제가 없으나 자신만의 더 나은 성능기준을 목표로 개선하기
* 반복되는 작업을 자동화해서 거기에 드는 시간과 노력, 실수여지를 줄이기
 

Grit의 내용

그릿[3]에서는 최고가 되고 싶으면 '의식적인 연습(deliberate practice)' 수천, 수만 시간동안 하면 된다. 그러면서, 전문가들의 연습 방법에 대해 다음과 같이 설명하고 있다.

  1. 도전적인 목표를 설정하고 전체 기술 중에서 아주 일부분에 집중한다. 이미 잘하는 부분 보다는 뚜렷한 약점을 개선하려고 노력한다. 아직 도달하지 못한 과제에 도전하는 것이다.
  2. 도전적인 목표 설정 뒤에는 목표에 도달하기 위해 온전히 집중하고 비상한 노력을 한다. 음악가 같은 경우는 혼자 연습하는 시간이 다른 음악가와 함께 연주하는 시간보다 많다.
  3. 가능한 빠른 피드백을 받고 싶어 한다. 부정적인 내용이 많다. 자신이 잘한 부분 보다 틀린 부분에 관심이 많은 것이다.

이 내용을 조금 더 구체화한 것이 김창준님의 방법이라고 할 수 있겠다.

 

결론은?

앞에서 이야기 한것 처럼 그릿에서 의도적 수련에 대해 정리하고 있다. 개발자의 입장에서는 김창준님의 구체적인 수련 방법을 참고하면 큰 도움이 될 수 있다. 다른 업무를 한다면? 추상적인 것을 통해서 자신의 업무를 대입해보는 것도 좋겠다.

 

 

참고 문헌

[1] 안데르스 에릭슨, "1만 시간의 재발견" 노력은 왜 우리를 배신하는가

[2] 김창준, "개발자의 의도적 수련," https://www.facebook.com/cjunekim/posts/5465539236807932

[3] 앤절라 더크워스, "그릿 GRIT", 비즈니스북스, 2016년 10월

'Technical Leadership' 카테고리의 다른 글

협업적 문제 해결 방법 - 함께 자라기  (0) 2023.07.10
살리고 글쓰기  (4) 2023.03.12
책 읽기: 효과와 효율  (2) 2023.03.05
다니엘 핑크: 후회의 재발견  (0) 2023.02.25
ChatGPT에 대한 짧은 생각  (0) 2023.02.16

애자일 학습을 하면서 기존의 방법을 통해 느끼는 대한 안티패턴을 공유해 봅니다.

 

. 회사의 업무처럼 한다.

저는 회사에서 업무를 할 때, 미리 계획을 세우고 진행합니다. 물론 계획이 필요 없다는 것은 아닙니다. 하지만, 상황이 바뀌더라도 기존에는 그 계획대로 하려는 경향이 있었습니다. 애자일 학습에서도 제가 하려는 활동을 잘 하려고 그렇게 했던 경향이 있습니다.

애자일 해지기 위해서는 상황에 대응(adaptation)하기 위해서 협업을 강조하고 피드백을 중요하게 생각합니다. 그러므로, 빠르게 실패하는 것을 권장하며 실패를 통해서 피드백을 받고 배움을 얻는 것을 중요하게 생각합니다. 이를 위해서 같이 하는 사람들과의 회고 및 추가 활동을 통해서 더 배워야 합니다. 지속적이고 의도적인 연습 및 실행을 통해서 성장을 꾀해야 합니다.

그러므로, 애자일 학습을 하는 동안에는  기존에 하던 것과 같은 방법 혹은 그렇게 하지 못해서 그와 완전히 반대로 한다거나 하기 보다는 애자일하게 하던 방법과 하지 않던 방법을 섞어서 하는 것을 좋습니다. 이러한 학습에서도 업무에 어려움을 반영하여 내 실재 문제를 해결하거나, 배운 것을 업무에 적용해 보는 것도 좋습니다.

 

. 혼자 하려고 한다.

새로운 것을 배울 때 저는 우선 관련된 강의나 책을 먼저 찾았습니다. 특히, 책을 읽고 전문성을 높여서 문제를 해결하려고 했습니다.

하지만, 애자일 학습에서는 책만 읽는 것을 것을 권하지는 않습니다. 애자일적인 접근 방법으로 협력을 탐색해야 한다는 측면에서는 자신이 가지고 있지 않은 그것을 얻기 위해 책을 읽는 방법만 있는 것이 아니기 때문입니다. 것을 잘하는 사람을 찾고, 그 활동을 같이 하기도 하고, 같이하면서 배우고, 배운 것을 연습하는 것을 권합니다. 저도 최근에 새롭게 배운 동기 면담의 경우, 다른 분들과 자주 연습하려고 하고 있습니다.

 

. 중요하다는 것의 관점

최근에 코칭을 받고 있습니다. 애자일 학습을 하시는 분들께서 중요하다고 이야기 해주시는 내용 중에 하나입니다. 또한, 본인에게 중요한 문제를 가지고 코칭 받으라고 합니다.

그런데, 이 중요한 문제의 관점이 달라 졌습니다. 제가 느끼는 감정의 문제, 회사 업무에서의 문제들 중에서 여러 고민을 하고 고르고 골라 코칭을 받았습니다. 하지만, 정작 그 코칭을 통해서 어떻게 도움이 될까라는 문제로 돌아가 보면 선정한 문제가 중요한 문제인가에 대해 다시 질문할 수 밖에 없었습니다. 왜냐하면, 이미 코칭 받았던 문제들이 1년 아니 3~4년에 한 번 발생하는 문제 그리고 분기 혹은 많아야 한달에 한번 있을까 말까 하는 문제였거든요.

코칭 내용을 선정하는 가이드 중에서, 시간적 스펙트럼이 매주, 매일, 매시간에 나를 괴롭히고 있는 것이 무엇인지 묻습니다. 문제가 더 중요한 문제일 수 있다는 것입니다. 즉, 내, 수면, 음식, 건강의 문제, 내 평상시의 루틴한 업무와 관련된 문제가 더 중요할 수 있다는 것입니다. 집중력의 문제, 음주로 인한 에너지 문제, 혹은 음식의 자제가 되지 않아 어려운 다이어트 문제, 아침에 일어났을 때의 에너지 문제가 중요할 수도 있다는 것입니다.

 

. 피드백을 구하지 않는다.

애자일 학습을 하면서 멘토링 그리고 코칭의 기회가 많았습니다. 이 것이 자체로 이미 좋은 피드백이지만 애자일의 측면에서 우리가 학습하는 것들에 대해서 피드백을 찾아야 합니다(Feedback-seeking). 물론 기존에 애자일로 업무를 하는 사람들이 많기 때문에 회고를 가지면서 피드백을 찾는 것이 어느 정도 몸에 배어 있어 보입니다. 하지만, 이 피드백을 통해서 Action Plan이 나오고, 이를 추적하여 개선하는 것까지가 피드백 구하기라고 생각됩니다. 최근에 좋은 모임에 대한 번개에 대해서 진행할 , 쌓기 게임을 하였습니다. 우리 팀은 서로 경쟁해 보면서 누가 잘하는지 비교하기 바빴는데, 잘하시는 분들은 팀원들이 다른 사람 하는 것을 관찰하고 피드백 하던 것을 보았습니다. 우리가 업무에 적용해 본다면 어떨까요

최근에, AC2에서 디버거 활용하여 디버깅을 하신 세션을 공유한 세션을 듣고 나의 생각이 있어 적어 봅니다저는 개발자이고 싶은 관리자(^.^)이기 때문에 사례의 경우 동료들의 같이 하는 고민으로 이해 해주시면 됩니다. Android Phone Framework System Service 주로 개발하는 저와 동료들의 경우도, 요사이 디버깅은 로그 베이스일 밖에 없다는 생각이 들었습니다. 디버깅을 10번한다면, 9 이상이지요. 이유는 번개 때에 지나가듯 이야기 해주시는 부분에 있다고 생각했습니다. 그래서, 빠르게 생각을 정리해 보았습니다.

 

제가 생각하기에 디버거가 예전 같이 많이 사용되지 않는 것은 리눅스와 같은 우선 멀티프로세스(Multi-process) 상황이기 때문이란 생각이 들었습니다. 주로, 디버거로 확인 가능한 것은 하나의 프로세스에서 관련된 심볼(High level language machine language 연결 시켜주는 정보) 읽어와서 보여주며 실행하여야 하기 때문이라고 생각됩니다. 우리가 담당하지 않는 다른 프로세스로 넘어가게 되면 확인이 어려워 집니다. 상황에서 타이밍 이슈가 있는 부분이라면, 로그와 같은 디버깅 코드를 추가하면서 문제가 사라지는 경우도 발생하게 됩니다. 것은 번개에서 언급되었던 것으로 기억합니다. 실재로 동료들과 이야기 나눠 봐도 디버거를 아예 모르는 분도 계시고 경력이 많은 분도 실재 기기에서는  Watchdog 같은 제약도 많아 로그 기반으로 접근한다고 하네요.

 

디버거로 가능한 것들은 어떤 것들일까요? 우선 디버거가 있으면 1. 원하는 코드 부분에서 멈추게 있습니다. 그것만 가능한 것이 아니고 2. 멈춘 후에, 상황에서의 변수들의 값을 확인할 있습니다. 그리고, 3. 함수를 불렸을 , 어떤 함수에서 호출한 것인지(call stack) 있습니다. 그리고 4. Call stack 따라 호출한 시점으로 변수의 (물론 호출하여 관련 변수들이 변경되었다면 최신 상태) 확인해 있습니다. 세션에서도 설명하셨지만, 5. 원하는 코드가 특정 변수의 상태일 멈추게하는 것과 같은 고급 스킬도 가능합니다. 세션에서도 시연을 시도하셨죠.

 

다시 돌아와 디버거를 언제 써야 할까요? 10번에 1번이 될까 말까 하는 기술을 알아 두는 것은 좋을까요? 세션에서 공유해주신 사례에 적절하다고 생각됩니다. 저도 이쪽 도메인을 몰라서 이상한 이야기일 있습니다. 제생각에 방법을 모르셨다면, 사용하시는 Framework 뒤지고 로그를 넣어가며 확인하셔야 했을 가능성이 있어 보입니다. , 우리가 사용하는 모듈의 복잡성이 높은 부분에서 필요한 부분을 적응적으로 찾아 봐야할 때가 디버거를 사용을 고민해야 하는 아닌가 조심스럽게 추측해 봅니다. 저의 요즘 화두인 탐색이 필요하겠다는 생각을 잠시 했습니다. 망치를 쓰는 법을 알았으니, 망치를 쓰는 것이 좋겠다 싶은 곳을 탐색도 하고 연습도 해야죠. 그리고, 여기 저기 망치질을 하고 다니는 아닌가 고민해야 하겠네요.

"살리고 글쓰기" AC2 과정을 들으면서 알게된 글쓰기 방법으로 기존에 내가 글을 쓰던 방법과는 상당히 다른 부분이 있다. 내가 사용하던 예전 글쓰기는 기존 책의 구조와 비슷하게 개론에서 시작하여 각론으로 나아가는 글쓰기 방법이었다. 하지만 살리고 글쓰기는 애자일하게 글을 쓰는 방식으로 반복적(Iterative)으로 그리고 생성적으로 글을 쓴다.

 

예전의 방식이라면 어떤 주제를 적을 것인지 생각하고 이야기할 생각의 가지들을 만들어 부분들을 채워 갔을 것이다. , 내가 이야기하려는 주제가 생각이 나더라도 전체적인 구조와 각론이 정해질 때까지 정리되지 않으면 글을 쓰기 시작하지 못하고 시간이 많이 걸렸다. 살리고 글쓰기를 , 장점은 글감을 적고, 문장을 만들고, 거기서 글을 만들어 간다. 이렇게 반복적으로 글을 쓰는 것이다. 이렇게 작게 시작하므로 언제나, 어디서나, 낮은 에너지로 글을 있다. 글도, 핸드폰과과 랩탑 컴퓨터를 이용하여 썼다. 책상에서 버스에서 거실의 소파에서 반복적으로 글을 썼다.

 

살리고 글쓰기는 반복적으로 글을 쓰기도 하지만, 생성적(generative)으로 글을 쓴다. 앞에서 언급한 것과 같이 우선 하고 싶은 말에서 시작한다. , 글감이 있다면 글을 쓰기를 시작할 있다. 단어에서 문장이 나오고, 거기에서 센터를 찾아 자연스럽게 나무가 가지를 뻗듯이 글을 펼쳐보는 것처럼 발전 시킨다. 이를 반복적으로 적용하여 글을 쓰면서, 새롭게 떠오르는 센터를 기준으로 계속 글을 써간다. 그러면서, 글이 어떻게 전체적으로 변하고 있는지 살피면서 계속해서 글을 써간다. 인공물이 아닌 자연에서 관찰되는 자연물과 같이 만들어 지도록 생성적으로 글을 쓴다. 글은 "살리고 글쓰기" 배우고 배운 내용을 정리하고 연습하는 관점에서 발견한 센터들을 기준으로 반복적으로 생성적으로 글을 것이다.

 

나는 예전의 방법으로 글의 구조 잡는데 에너지를 쓰고 나서, 정작 글쓰기를 시작하지 못하는 경우가 너무 많았다. 살리고 글쓰기와 비교하여, 기존의 글쓰기는 글감이 있다고 하더라도 예상하는 글의 뼈대가 보일 때까지 충분한 고민을 하여야 하기 때문이다.  또한, 이러한 뼈대를 위한 구조나 로직을 먼저 생각하다 보면,  쓰려고 하는 글의 중요한 부분의 발견을 놓칠 수도 있다. 살리고 글쓰기의 경우는 이와 상반된 장점이 있다. 글을 , 적은 에너지로 시작할 있다. 또한, 글을 쓰면서 전체와 센터를 고민하게 되므로 새로운 발견, 창발적인 주제를 발견할 수도 있다. 이렇게 낮은 에너지 진입 장벽과 새로운 주제 발견이 글감과 관련된 글을 확률을 높여 준다.

 

살리고 글쓰기를 다른 장점은 글감을 적고 시작하고, 거기서 자연스럽게 발전되어 나가는 것이다. , 여러 가지 방법을 사용할 있을 것으로 생각이 들었다. 하나는 생각의 흐름데로 써본다는 것이다. 말하기에 대비하여 글쓰기의 장점은 뱉어 생각을 이리 저리 정리하여 다듬을 있다는 것이다. 글의 살을 붙이는 다른 여러 가지 방법이 있다. 글감에 대해서 시간 순으로 써본다거나, 생각하는 주제 주변을 탐색하거나, 글감의 구조에 대해 살펴 있다. 애자일적으로 접근하는 방법을 생각해 보면, 글감에 대해서 추상과 구체를 왔다갔다하는 방법 또한 좋은 방법이다. , 추상적으로 설명하다가, 나의 경험과 같은 , 구체로 들어가면 된다. 이렇게 하여 글을 적다 보면 하고 싶은 글감에 살이 많이 붙는 것을 느낄 있다.

 

물론 기존 글쓰기 방법을 살리고 글쓰기에서 사용하는 방법을 배재할 필요까지는 없어 보인다. 기존 글쓰기에서 좋은 점들을 적용하는 것도 글을 좋게 만드는 좋은 방법들이다. 살리기 글쓰기를 알려주신 김창준님이 설명해 주신 내용 몇가지를 살펴 보자. 우선 해외 대학에서 글쓰기에 대해 가르치는 하나로 아키데믹 라이팅(Academic Writing) 있다. 여기에도 여러 가지가 있지만, 창준님이 예로 들어 주신 것은 글을 문단(paragraph) 구조화하는 것이다. 문단을 나누어 글을 쓰면, 글이 단정하고 명료해 진다. 다른 하나는 글을 쓰고 소리 내어 읽어 보는 것이다. 예전에 유시민 작가의 글쓰기에 대한 책을 적이 있다. 여기에도 똑같이 언급되었는데, 글도 말이기 때문에 소리내어 읽어 보면서 정리하면 좋아 진다. 이렇듯 기존의 글쓰기에 좋은 방법도 살리고 글쓰기에 적용할 있다.

 

살리고 글쓰기를 알게 되고 얻은 가장 것은 생각을 글로 조금 쉽게 펼쳐 나갈 있겠구나 하는 것이다. 하지만, 살리고 글쓰기의 방법을 배웠다고 바로 몸에 익혀지는 것은 아닐 것이다. 이제 시작이고, 수련이 필요한 것이다. 연습을 하면서, 빼먹지 않았으면 하는 것은 피드백을 받는 것일 것이다. , 이제 시작이다.

책을 읽는 다면 처음 부터 끝까지 눈으로 읽고 이해하는 것이 일반적이라고 생각 있다. 하지만, 공부나 연구를 업으로 하다 보니, 여러 다양한 방법들을 알게 되었. 다른 많은 일들이 그렇듯이 이 것도 효과와 효율에 대해 이야기 해볼 수 있겠다. 효과와 효율, 비슷하면서도 다른 말이다. 효과는 어떤 일을 하고 원하는 "목표" 얻게 되는 것을 의미하고 효율은 어떤 일을 , "비용" 얼마나 되느냐라고  있다. 나름 내가 알고 있는 방법이 있다고 자부했지만, 최근에 알게 방법을 포함하여 내가 사용했던 방법들을 포함하여 정리해 보자.

 

최근에 AC2를 통해 알게 된 효과적으로 읽는 방법은 내가 학위를 논문을 빠르게 읽는 방법과 유사했다. 조건은 분야를 알아서 중요한 부분만 읽는 것과 비슷했다. 선행 과정으로 필요한 것은 글의 전체 구조를 보고 중요한 부분 찾아 후에 부분을 파악하는 것이다. 많은 논문은 구조가 비슷해서 것이 쉽게 적용된다. 책의 경우는 목차를 보고 어떤 부분을 읽을 것인지 결정을 한다. 책을 읽으며 내용을 파악할 때에도 가정(가추법/귀추법 abduction) 하고 확인하여 읽는 부분도 최소화 하는 것이 필요하다. 또한, 마인드풀(mindful)하게 책을 읽어야 한다. , 내가 책의 내용을 어떻게 사용할 것인지 계속 생각하면서 읽는 것이 효과를 높이는 방법이다.

 

논문을 읽는 경우도 내가 저작할 활용하기 위해서 논문이 다루는 문제가 무엇인지 그리고 어떤 새로운 방법으로 풀었는지를 나의 언어로 작성을 해두어야 했다. 논문을 읽을 수록 점점 읽기 쉬워졌는데, 하루에 10편도 넘게 읽을 있는 경우도 생겼다. 논문을 읽을 , 지도 교수는 사람이 기존과 다른 "새로운 아이디어(novel idea)" 무엇인지 것을 어떻게 증명해 보였는지 " 문장"으로 정리할 것을 요구했다. 처음에는 부분을 논문에서 발췌했더니  "재구성(rephrase)"라도 해서 나의 말로 바꾸어야 한다고 강조하셨다. 부분이 되기 시작하면서 논문 읽는 능력이 늘어 나기 시작하고, 기존 알고 있던 다른 연구와 유사한 경우는 정말 30분도 안되서 정리가 되곤 했다. 그리고는 그 것들이 내가 쓰는 논문의 참고 문헌에 기반이 되기도 했다.

 

효율에 대해서 조금 생각해 보면, 책을 읽을 사용하는 에너지에 대해 생각해 있다언제인가 책이 많아져 정리해야 , 책을 스캔하여 있다는 것이 가능하다는 것을 알게 되었다. 또한 이북도 서점에 많이 생기기 시작했다. 또한, 어느 유투버가 책을 스캔하는 것에 대해서도 설명하는 것을 후에 책을 스캔하고 혹은 이북으로 책을 구매 후에 책을 TTS(Text To Speech) 이용해서 듣는 것을 시도해보기 시작했다. 사실은 오디오북을 시작하려고 했지만, 오디오북을 구할 있는 한계가 명확했다. 특히, 우리 나라 책에서는 그랬다. 이렇게 책을 스캔해서 읽는 부분은 나에게 혁명적이었다. 내가 운전을 하면서 혹은 운동을 하면서 들어도 라디오나 음악을 듣는 수준의 에너지로 책을 읽을 있었다. 나는 번역한 책을 퇴고 때도 들어서 3 정도 들었다. 앉아서 번역본을 보면서 듣기도 하고, 차를 타고 다니면서 듣기도 하였다.

 

그렇다면, 효과와 효율은 서로 상반되기만 한 것일까? 학위를 하려면 정말 많은 논문을 읽어야 한다. 하지만, 처음에는 어느 분야의 초보자가 그렇듯이 에너지가 많이 들고 어려움이 많다. 나도 논문 한편에 일주일, 혹은 이주일을 읽어도 어려웠다.  후에도 어느 정도 이력이 붙었는데도 어려운 부분이 있었는데, 이는 논문의 난이도가 매우 높을 때이다. 나도  편의 논문은 제출한 상황이었음에도 이런 경험이 있었는데, 참고할 논문[1] 내용이 수학적인 것이 너무 많고 난이도가 높아서 이해도가 낮은 경우였다.  때에  논문을 여러 번 필사하였다. 처음 읽을 때에는 내가 필요로 하다는 생각이 들었지만 내용이  이해가 되지 않았다. 그래서,   정도 필사를 했고, 전반적인 흐름은 이해하지만, 여전히 이해가 되지 않은 부분도 있었다. 그러고 나서, 몇 번   사하고 나서 논문에서 여기서 이야기 하는 수식의 유도가 이해가 되기 시작했다. 최종에는 내가 필요로 하는 수식을 추출을 하였고  것을 활용하여 내 졸업 요건에 필요한 주요 저널 논문의 작성이 가능했다. , 나의 에너지를 최대한 사용하여 목표에 도달하는 방법이었다. 효과와 효율을 고민하여 나의 최대한을 끌어 낸 경우였다고 생각된다.

 

앞에서 이야기 듯이 책을 읽을 , 목적과 비용에 대해서 생각하면서 읽는 것이 필요하다. 그렇게 해야 효과적으로 효율적으로 있다는 부분이다. 목적의 경우, 어떻게 활용할 것인가 글을 쓰기 위한 것인가 아니면 학습을 위해 나의 행동에 어떻게 연결 것인가 고민하면서 읽는 것이 중요하다. 정확한 목표 없이 흥미를 위해서도 읽을 있다. 하지만, 목표를 분명히 하지 않으면 효과가 떨어질 있다. 효율 측면에서는 에너지를 많이 넣어야 하는가 적게 넣을 것인가도 고민해 부분이다. 마치 산책을 하듯이 힘을 최대한 빼고 읽어야 하는 상황이 있을 수도 있고, 남극 탐험을 하듯 이 내가 가야 하는 목표를 향해 나의 에너지를  써야 한다면 어떻게 해야  것인가도 고민할  있는 것이다.

 

참조 문헌

[1] L. Xu and J. Heizer, "Media streaming via TFRC: An analytical study of the impact of TFRC on user-perceived media quality", Proceedings of IEEE INFOCOM, Jan. 2006, http://personal.ie.cuhk.edu.hk/~dmchiu/reading/infocom06_tfrc.pdf

+ Recent posts