상대의 의견을 받아들일 때, 옵션(선택권)을 인식하다
지식 덕후의 탄생
어제 <객체지향 사고와 Event Driven 그리고 그 구현>을 올리고 페이스북에서 뜻밖의 피드백을 받았습니다.
처음 페벗 님들의 피드백을 한번 훑어본 후에는 여러 가지 생각이 들었습니다. 반박하고 싶은 마음도 들고, 내 입장에 대한 속말도 떠올랐습니다. 그러다 일상의 일들에 휩쓸려 다른 일로 시간을 보내다가 다시 살펴보았습니다.
누군가의 의견을 지적으로 받아들일 때
그러는 중에 문득 2005년 즈음으로 기억하는 사건이 생각났습니다. 지금은 친한 형이 된 Toby 님이 제가 당시 블로그에 남긴 글의 오류를 지적하는 댓글을 남긴 일이었죠. 당시 대규모 프로젝트에서 Spring 도입을 주장했다가 책임을 지느라 한 화면에서 다수의 Form 처리를 하느라고 삽질을 할 때였습니다. 책이나 검색으로 풀 수가 없어서 Spring 소스 코드를 보고 시행착오를 거듭하며 더듬더듬 익히고 있을 때였죠. 처음 댓글을 보았을 때, 아마도 제 속마음은 이런 식이 아니었을까 싶습니다.
뭐야? 이 사람, 남의 속도 모르고... 나는 하루하루 정신없어 죽겠는데...
그렇지만, 그런 지식 공유와 댓글 나눔은 수년간 일상이 되었습니다. 어떤 목표 없이 꾸준히 그냥 해온 기록으로 심지어 유명 개발 블로거가 되는 행운을 맛보기도 했지만, 지식 공유가 애초 의도는 아니였습니다.
사실은 오늘 배운 것을 잊지 않으려고 부지런히 써 둔 것이었죠. 한국에서는 레퍼런스도 없고 물어볼 곳도 없을 때 차세대급[1] 프로젝트에 Spring 도입을 주장했다가 모르는 내용이 너무 많아 매일 소스를 까 보고, 시도를 해 보고 다른 개발자들에게 Spring을 설명해 주고 함께 트러블슈팅을 한 기록을 까먹지 않기 위해 기록하던 때였습니다.
티스토리 블로그를 방치했더니 기록이 사라져서 당시 댓글에 제가 어떻게 반응했는지는 알 수 없습니다. 기억도 흐릿하고요. 다만, Toby 님과는 KSUG(한국 스프링 사용자 모임)도 같이 만들고 지금도 친한 형으로 남아 있죠.
인식과 반응(행동)의 간격
그때를 떠올린 후에 다시금 페이스북 댓글을 보았습니다. 내용에 즉각적으로 반응하던 첫 번째와 달리 이 분들은 왜 이런 글을 썼을까 생각해 보았습니다.
그리고 이번에는 서로 다른 인식을 전제로 읽을 수 있었습니다. 같은 주제를 다루지만 저와는 조금 다른 관심사를 지향하고 있었습니다. (이를 판단하는 대신에) 이 분들의 입장을 따라가 보았습니다. 수긍이 가는 내용들을 만날 수 있었고, (제가 거기에 관심을 두고 말고를 떠나서) 한 가지는 분명했습니다.
바로 이 분들이 제가 내놓은 주제에 관심이 꽤 많은 분들이라는 점이죠. 사실, 그렇지 않다면 스크롤 한번 하고 말 수 있는 페이스북에 이렇게 자기 의견을 내놓지도 않았겠죠.
그러다가 읽고 느낀 내용에 대해 어떻게 반응할까 생각하게 되었습니다. 저도 무언가 피드백을 해야 할까를 고민한 것이죠. 그중에 가장 먼저 한 일은 제 첫 번역서에서도 베타 리더 역할을 했던 박성철 님 의견 중에 즉각 수용할 수 있는 부분을 받아들이는 것이었습니다. 놀랍게도 브런치에 글을 올리기 직전 급조한 제목을 박성철 님이 눈치챈 듯한 댓글이 보였습니다. 그래서 그의 마음을 받아들이고 싶었습니다. 다만, 브런치의 제목 글자 제약 때문에 그의 의견을 최대한 수용해서 <객체지향 사고와 Event Driven 그리고 그 구현>이라고 제목을 바꾸었습니다.
그러고 나서 <객체지향 사고와 Event Driven 그리고 그 구현>을 다시 읽어 보았습니다. 이번에는 독자의 눈으로 저의 의도를 다시 훑어볼 수 있었습니다. 무슨 말인고 하니, 제 머릿속에서 나오긴 했어도 그 배경이나 동기가 다른 이야기 셋을 급조한 점이 보였습니다. 독자들이 읽기에 난해할 수 있다는 사실이 보였습니다. 그럼에도 불구하고 그 정도의 가치(혹은 품질)를 그대로 두기로 하고 박성철 님 의견에 따라 제목 정도를 수정하고, 마지막에 그림으로만 표현한 내용을 추후에 별도 글로 써 보기로 했습니다.
한편, 얼마 전 <문제의 인식과 문제의 정의는 전혀 다른 일이다>라는 글을 쓴 탓인지 무언가 인식하는 일과 이를 문제 삼는 일은 전혀 다르다는 점을 명료하게 깨달았습니다. 그리고, 제 피드백의 마지막으로 이 글을 쓰기로 결심했습니다.
협상론적 세계관의 작은 실천
페북에서 받은 댓글을 그저 듣고 싶지 않은 지적으로만 받아들거나 시시비비 논쟁에만 그치지 않았다는 사실을 분명하게 하기 위함이죠. :)
너무 정서적으로만 표현하면 읽기 싫은 글이 되니까 소통에 대한 작은 깨달음 의미로도 풀어보겠습니다. 어제 동료가 제가 쓴 글 <설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다>를 읽고 다음과 같은 경험담을 들려주었습니다.
OOO 님이 설계를 하고 제가 개발하던 시절, 초반 설계가 개발을 하면서 맞지 않음을 제가 깨닫게 되었고 바로 옆에 앉아 있던 OOO 님에게 대화를 요청하고 피드백을 드렸습니다. OOO 님이 이를 인지하고 설계를 바꾸던 일이 자주 있었습니다. XP에서 말하는 '함께 앉기'를 실천해야 하는 이유입니다.
저는 여러 가지 생각을 할 수 있었습니다. 그중에서 피드백을 받아들이는 사람 입장에서 감정이 아닌 기능적인 관점에서 생각을 해 보게 되었습니다. 그러다가 이런 생각을 했습니다.
마치 유닉스의 파이프라인 혹은 Chain of responsibility 디자인 패턴처럼 다른 사람 의견 중에 기능적으로 유용한 내용을 받아들일 수 있다면...
말줄임표 형태로 끝을 맺었지만, 지금 당장 그렇게 해야겠다고 마음먹는 순간이었습니다. 그래서 그 생각과 실천이 습관이 되었으면 하는 마음에 기록도 남깁니다. <어떻게 원하는 것을 얻는가>를 읽을 때 '협상론적 세계관' 실천이 너무 어렵다고 생각했는데, 지금 보니 제 방식 대로 꾸역꾸역 아기 발걸음을 개발하며 실천하는 중이란 생각도 들었습니다.
설계가 시너지가 나려면 소통은 필수다
더불어 동료의 의견을 보면서 제가 이전에 쓴 글에서 설득의 의미도 다시 깨달았습니다.
설계자가 소프트웨어 구현을 위해서 설계를 했다고 하면, 개발을 직접 하거나 개발자를 설득해야 결과를 낼 수 있습니다. 그래야 자기 일을 가치 있다고 주장할 수 있습니다. 이를 위해 설득은 반드시 필요하죠. 개발자가 받아들일 수 없는 결과를 설계라고 주장한다고 해도 무슨 소용이 있겠습니까? 또한, 여기서 자기가 직접 개발할 때보다 다른 사람에게 맡길 때 결과가 빨리 나오거나 개발 대신에 설계로 더 넓은 범위에 관여하는 편이 팀(조직)에 유리하다면, 개발을 맡기는 것이 더 나은 전략이겠죠. 이때 우리가 신뢰가 생기고 소통이 되고 협업이 일어날 때를 시너지에 비유하는 듯도 합니다.
주석
[1] 당시 PM에게 들은 프로젝트 총예산은 700억이었습니다.
