서로 다른 도메인에 속한 소속원들의 커뮤니케이션을 위한 실천법이 있을까요?
Steve Yoon
몇 일 전에 회사에서 있었던 일 입니다.
저희 팀은 하나의 솔루션을 제공하기 위해 다양한 경력의 팀원들이 협업을 합니다.
방송 클라이언트 솔루션을 만드는데, 하드웨어 아트워크 엔지니어, 하드웨어 전파 분석 (안테나 정합) 엔지니어, 전송 표준 구현 엔지니어, 디바이스 드라이버 개발 엔지니어, PC 응용 프로그램(emulator) 개발 엔지니어가 한 팀 입니다. 저는 그 중 PC 응용 프로그램 개발을 하고 있습니다.
전송 표준 구현 엔지니어와 제가 대화를 자주 나누면서 일을 진행해야 하는데 (전직한지 다섯달 째임에도) 너무 부담이 느껴졌습니다.
저도 이전 직장에서 전송 표준 구현을 해봤었기에, 표준의 이해도가 서로 달라서 부담을 느끼는게 아니라 그저 대화하는 방법에 어려움을 느꼈던 것 입니다.
'불안하다'라고 생각하고만 있고 해결을 딱히 못하고 있던 차에 문제가 드디어 터졌습니다.
필드 테스트를 위해 중간 릴리즈를 하고 팀장님과 몇몇 분들이 유럽으로 출장을 나갔는데, PC 응용 프로그램과 방송 모듈 칩과의 통신이 일부 기능에서 이상하게 동작하는 것이었습니다.
알고보니 칩 모듈에서 프로토콜이 일부 바뀌었던 것이었습니다. 문제점을 수정하고 재배포를 하며 '마지막까지 확인하지 못해서 죄송합니다'라고 했지만, 불편한 마음이 들었습니다.
이해를 돕기 위해 도메인을 간단한 그림으로 표현하면 아래와 같습니다.
[PC emulator] --> UART serial(IPC communication) <-- [ARM9 based chip module(with broadcast functionality)]
불편한 마음의 정체를 생각해보다가, 문득 저는 두 도메인 사이의 통신이 '프로토콜'로 이루어진다고 했는데 전송 표준 구현 엔지니어는 거창하게 '프로토콜'이 아니라 그냥 IPC 통신일 뿐이라고 했던 기억이 떠오르네요.
저는 프로토콜은 규약, 즉 약속이니까 어느 한 쪽이 상대쪽에 공지 없이 바꿀 수 없다고 계속 생각하고 있던 것이었습니다.
그러니까, 대화를 시작하는 주체는 변경을 가하는 쪽이어야 한다고 생각했던 것 같습니다. 그래서 가만히만 있던 것 같았구요.
그래서 이런 불편함을 없애줄 무언가 실천해볼 수 있는 게 있다면 좋겠다는 생각이 들어 질문을 올려봅니다.
실천법이 아니라 제게 부족하게 보이는 부분을 알려주시거나 제가 생각해보지 못했던 화두를 주셔도 고맙겠습니다.
그럼 이만 줄이겠습니다.
윤경록 드림
--
-----------------------------------------------------------------
Name : 윤경록
Mobile : +팔이-일공-삼공공팔-칠사칠구
MSN : steveyoon77@지메일.com
Nateon : steveyoon77@네이트.com
Blog : http://steveyoon77.tistory.com
twitter : @steveyoon77
- 日新又日新
Jake Kim
제가 exper 에서도 몇번 언급한 적이 있는것 같은데요, 도메인 드리븐 디자인 (Domain-Driven Design) 에서
Eric Evans 가 설명하는 Ubiquitous Language 라는 부분입니다.
서로 다른 도메인의 사람들과 의사 소통을 하기 위해서는 우선 하나의 언어로서 얘기를 하는 것이 바람직하다라는 것이 그 내용입니
다. 그리고 주 도메인의 사람들이 사용하는 용어를 변경없이 사용해야 한다는 것이고요.
저도 윤경록님과 비슷한 경험을 하고 있고 또 해봤습니다만 이 부분이 아마 가장 근본이 되면서도 중요한 부분이라고 생각합니다.
컨설팅을 하거나 같은 조직에서 다른 부서, 특히 엔지니어링 부서가 아닌 마케팅이나 비지니스 부서 사람들과 대화를 할 때는 단어
의 사용에도 주의가 필요하다고 생각합니다.
서로 같은 단어를 얘기하면서 다른 걸 생각하고 있는 적도 있었거든요. 그래서 저는 프로젝트를 시작하는 시점에서는 이 단어는 이
걸 뜻하는 것이다라는 정의를 하려고 노력합니다.
그렇다고 거창하게 용어 정의 문서를 작성하는 것은 아니구요.
회의때나 전화 통화로 대화를 할 때, "너 방금 한 말이 ~를 말하는 거지?" 라고 확인을 하는 수준이죠. 그리고는 다음번에 그
것을 언급할 필요가 있으면 그 단어를 사용합니다.
제 예를 들어 드리자면, PDF 파일이 두가지 종류가 있었습니다. 하나는 그냥 읽기만 할 수 있는 것이고 하나는 채워넣을 수 있
는 PDF 폼이었죠. 읽기만 하는 PDF 를 놓고 어떤 사람은 Flat PDF, 어떤 사람은 Static PDF, 또 어떤 사
람은 Read-only PDF 이런식으로 불렀습니다. 채워넣을 수 있는 것은 fillable pdf, pre-populated
pdf, submitable pdf... 새로 투입된 개발자가 하루는 물어 보더군요. flat pdf 하고 static pdf
하고 어떻게 다른거냐구요...
그리고 한가지 덧 붙여서, 비슷한 엔지니어링 부서 사람들과 일 할 때는 윤경록님의 예와 같은 경우 그것을 진행하는 주체가 되는
쪽의 용어를 사용하는 것이 바람직하다고 생각합니다. 비지니스 쪽 사람들과는 달리 같은 프로젝트를 진행하는 엔지니어들 사이에서는
확실한 용어 정의가 필요하다고 생각하구요.
> MSN : steveyoon77@지메일.com <steveyoon77@%EC%A7%80%EB%A9%94%EC%9D%BC.com>
> Nateon : steveyoon77@네이트.com <steveyoon77@%EB%84%A4%EC%9D%B4%ED%8A%B8.com>
June Kim (김창준)
안녕하세요? 윤경록입니다.
몇 일 전에 회사에서 있었던 일 입니다.
저희 팀은 하나의 솔루션을 제공하기 위해 다양한 경력의 팀원들이 협업을 합니다.
방송 클라이언트 솔루션을 만드는데, 하드웨어 아트워크 엔지니어, 하드웨어 전파 분석 (안테나 정합) 엔지니어, 전송 표준 구현 엔지니어, 디바이스 드라이버 개발 엔지니어, PC 응용 프로그램(emulator) 개발 엔지니어가 한 팀 입니다. 저는 그 중 PC 응용 프로그램 개발을 하고 있습니다.
전송 표준 구현 엔지니어와 제가 대화를 자주 나누면서 일을 진행해야 하는데 (전직한지 다섯달 째임에도) 너무 부담이 느껴졌습니다.
저도 이전 직장에서 전송 표준 구현을 해봤었기에, 표준의 이해도가 서로 달라서 부담을 느끼는게 아니라 그저 대화하는 방법에 어려움을 느꼈던 것 입니다.
'불안하다'라고 생각하고만 있고 해결을 딱히 못하고 있던 차에 문제가 드디어 터졌습니다.
필드 테스트를 위해 중간 릴리즈를 하고 팀장님과 몇몇 분들이 유럽으로 출장을 나갔는데, PC 응용 프로그램과 방송 모듈 칩과의 통신이 일부 기능에서 이상하게 동작하는 것이었습니다.
알고보니 칩 모듈에서 프로토콜이 일부 바뀌었던 것이었습니다. 문제점을 수정하고 재배포를 하며 '마지막까지 확인하지 못해서 죄송합니다'라고 했지만, 불편한 마음이 들었습니다.
이해를 돕기 위해 도메인을 간단한 그림으로 표현하면 아래와 같습니다.
[PC emulator] --> UART serial(IPC communication) <-- [ARM9 based chip module(with broadcast functionality)]
불편한 마음의 정체를 생각해보다가, 문득 저는 두 도메인 사이의 통신이 '프로토콜'로 이루어진다고 했는데 전송 표준 구현 엔지니어는 거창하게 '프로토콜'이 아니라 그냥 IPC 통신일 뿐이라고 했던 기억이 떠오르네요.
저는 프로토콜은 규약, 즉 약속이니까 어느 한 쪽이 상대쪽에 공지 없이 바꿀 수 없다고 계속 생각하고 있던 것이었습니다.
그러니까, 대화를 시작하는 주체는 변경을 가하는 쪽이어야 한다고 생각했던 것 같습니다. 그래서 가만히만 있던 것 같았구요.
그래서 이런 불편함을 없애줄 무언가 실천해볼 수 있는 게 있다면 좋겠다는 생각이 들어 질문을 올려봅니다.
실천법이 아니라 제게 부족하게 보이는 부분을 알려주시거나 제가 생각해보지 못했던 화두를 주셔도 고맙겠습니다.
그럼 이만 줄이겠습니다.
윤경록 드림
--
-----------------------------------------------------------------
Name : 윤경록
Mobile : +팔이-일공-삼공공팔-칠사칠구
MSN : steveyoon77@지메일.com
Nateon : steveyoon77@네이트.com
Blog : http://steveyoon77.tistory.com
twitter : @steveyoon77
- 日新又日新
--
Google 그룹스 'Agile Beginners' Q&A' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ab...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 abqna+un...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/abqna?hl=ko에서 그룹을 방문하세요.
Steve Yoon
전송 표준 구현 엔지니어는 프로토콜을 변경시키고 그 행동이 다른 사람에게 어떤 영향을 줄지(그리고 그 이후 어떤 일이 일어날지) 예측을 못했던 것인가요?
그 분은 당시 프로토콜 변경 후 왜 다른 사람들에게 그 사실을 알리지 않아도 된다고 생각을 하셨을까요?
이런 것들을 그 분과 직접 이야기 해보셨나요?
그 분은 당시 왜 그런 결정을 했는지 아시나요?
그 분의 사고(reasoning)가 어떠했는지 설명을 들어보셨나요?
소심한 사람도 커뮤니케이션을 잘 할 수 있는 실천법이 있다면 좋겠습니다.
김정훈
Jake Kim
발자들과 일을 하는게 아니어도, 심지어 바로 옆 큐빅에 앉아 있는 개발자와 같은 프로젝트를 할 때도 일어 날 수 있는 일이라고
보여집니다.
문제는 한 개발자의 변경사항이 다른 개발자의 일에 영향을 미친다는 것인데, 이를 의사소통의 "문제"라고 보기에는 너무 확대해석
일 수도 있겠다는 생각이 듭니다. 이런일 한두번 겪어보지 않은 개발자가 있겠습니까.
어떤 부분이 바뀌어 다른 개발자에 영향이 미친다면 (첫번째 영향이 일어나기 전에는 모르는 경우가 많죠) 아주 간단하게는 그 부분
의 변경사항에 대해서는 알림 메일을 보내기로 약속을 하는 방법도 있을것 같고요. 약속이 잘 지켜지지 않는 다거나 이런 약속을 하
기에 껄끄러운 상황이 있을 때는 자동화된 시스템을 사용하는 것도 바람직하지 않을까요. 소스 컨트롤 시스템이 지원을 한다면 그 부
분의 소스가 변경되면 알림메일을 보내게끔 설정을 하는 방법도 있구요. (저는 이 방법을 사용하고 있습니다.)
자신의 변경사항이 다른 개발자에게 영향이 없을 거라 생각하고 변경을 한 분에게 왜 그렇게 생각을 했냐고 물어보는 건 자칫 잘못하
면 책임소재를 묻는 것 같은 느낌도 줄 수 있을것 같네요. 이런 종류의 사고는 프로젝트를 관리하거나 리드하는 분의 중재로서 충분
히 미연에 방지될 수도 있다고 보여집니다.
실천법같은 건 잘 모르지만 그냥 웃으면서 다음에 그 부분이 또 바뀌면 얘기해달라고 하면 되지 않을까요... :=)
On Sep 5, 4:30 am, 김정훈 <wond...@gmail.com> wrote:
> 소심한 사람을 위한 커뮤니케이션 실천법으로 NVC(비폭력 대화)를 추천합니다.
>
> 내 느낌 혹은 의견을 상대에게 전달하고 싶은데 행여나 오해하지는 않을까?
> 기분 나쁘게 받아들이진 않을까? 관계가 오히려 악화되진 않을까? 그런 걱정을 하신다면
> 상당히 도움이 되실 것으로 생각됩니다. 저의 경우 많은 도움이 되었습니다.
>
> 다만 비폭력 대화를 실천하다보면 본인의 생각이 처음과 다르게 바뀌게 되는 경우가
> 많더군요. 즉 상대가 변화하지 않아도 자신이 스스로 변화하면서 문제라고 생각했던
> 부분이 문제가 아니게 되거나 다른 해결책을 생각해내기도 합니다.
>
> 10. 9. 5., Steve Yoon <steveyoo...@gmail.com>님이 작성:
>
>
>
>
>
> > 안녕하세요? 윤경록입니다. 아래에 김창준님께서 물으신 내용에 답변을 달아봅니다.
>
> > 전송 표준 구현 엔지니어는 프로토콜을 변경시키고 그 행동이 다른 사람에게 어떤 영향을 줄지(그리고 그 이후 어떤 일이 일어날지) 예측을
> >> 못했던 것인가요?
>
> > 문제점을 들었던 시점에 원인을 알아낸게 아니라, 함께 디버깅을 하다가 알게 된 것으로 보아 예측하지 못했던게 아닌가 해요. 요즘 그 분
> > 아이가 돌이 막 지나고 계속 아파했기(아이가 최근 유행하던 병들은 다 걸렸던 것 같습니다;) 때문에 정신이 없는 것 처럼 보였습니다.
> > 그리고 제가 작업하는 PC emulator의 중요도를 조금 낮게 보고 있는 것 같이 느끼기도 했습니다. 얼마 전 고객사에 중간 솔루션을
> > 배포할 때(칩 모듈이 포함된 evaluation board, 서비스 솔루션 바이너리, 칩 모듈 테스트를 위한 PC emulator) 부담
> > 갖지 말고 배포 바이너리(PC emulator)를 만들라며 안되면 나중에 재배포는 쉽다는 뉘앙스로 얘기했었기 때문에 그렇게 느꼈습니다.
>
> > 그 분은 당시 프로토콜 변경 후 왜 다른 사람들에게 그 사실을 알리지 않아도 된다고 생각을 하셨을까요?
>
> > 아마도 변경에 따른 영향에 대해 미처 생각치 못했기 때문에 알릴 생각도 못한 것 같습니다.
>
> > 이런 것들을 그 분과 직접 이야기 해보셨나요?
>
> > 어떤 식으로 이야기를 풀어가야 할지 고민되어서 아직 하지 못했습니다.
>
> > 그 분은 당시 왜 그런 결정을 했는지 아시나요?
>
> > 그 분의 업무에 대한 열정이 약해진 것으로 보여서 대화를 했던 적이 있었는데, 제가 알지 못하는 히스토리가 있어 보이기는 했습니다.
> > 하지만 술자리에서 물어본 것이라 깊게 파고들어 묻지는 못했습니다. 제가 일찍 취해버렸거든요;
>
> > 그 분의 사고(reasoning)가 어떠했는지 설명을 들어보셨나요?
>
> > 요즘 더 친해져보려고 노력 중입니다만, 아직 어떤 식으로 사고를 하시는지 파악하기에는 덜 친한 것 같습니다; 친해져야만 이런걸 물어볼
> > 수 있는걸 보니 제가 많이 소심한 모양입니다.
>
> > 소심한 사람도 커뮤니케이션을 잘 할 수 있는 실천법이 있다면 좋겠습니다.
>
> > 그럼 이만 줄이겠습니다.
>
> > 윤경록 드림
>
> > --
> > Google 그룹스 'Agile Beginners' Q&A' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> > 이 그룹에 게시하려면 ab...@googlegroups.com(으)로 이메일을 보내세요.
> > 그룹에서 탈퇴하려면 abqna+un...@googlegroups.com<abqna%2Bunsu...@googlegroups.com>로
> > 이메일을 보내주세요.
> > 더 많은 옵션을 보려면http://groups.google.com/group/abqna?hl=ko에서 그룹을 방문하세요.- Hide quoted text -
>
> - Show quoted text -
Steve Yoon
가족들과 함께 외식을 하고 왔더니 벌써 술에 취해서 제가 느낀 고마움을 제대로 표현할 수 있을까 걱정입니다.
먼저 비폭력 대화에 대해서 언급해 주신 점 너무 고맙게 생각합니다.
사실 저도 비폭력 대화에 대해서 김창준님의 블로그를 통해 접한 적(링크)이 있고 나름 열심히 비폭력 대화를 몸에 익숙하게 하려고 노력하고 있습니다만, 쉽지 않은 대화법(오히려 폭력을 부를수도;; )인 것을 몇 차례 확인했었습니다;
"소크라테스 식 산파법을 따르는 대화법에 이길 자가 없는데, 친구 사이에 도대체 뭘 노리고 이딴 대화 방식을 시도하는 것이냐."라는 이야기를 들은 적이 있어요. ^^;
그래도 여전히 비폭력 대화법에 대한 확신을 하고 있고, 언젠가는 대화를 나누는 상호간에 상처를 주지 않고 서로가 원하는 것을 얻을 수 있는 대화를 나눌 수 있다고 기대하고 있답니다.
아무튼 답변 너무 감사합니다. 제가 아직은 서툴러서 많은 부분에서 용기를 못내고 있었던 것을 일깨워주신 것 같아서 고맙습니다.
그럼 이만 줄이겠습니다.
윤경록 드림
Steve Yoon
너무 감사합니다. Xper 글타레를 통해 domain-driven design에 대해서 들은 바 있었는데, 아직 새로운 것을 배울만한 여력이 되지 않아서(지금 널리 알려져 있는 것을 따라가기도 쉽지 않아서요;) 건성으로 봐왔었는데, 말씀하신 것과 같은 것이 있다는 것을 알려주셔서 너무 고맙게 생각하고 있습니다.
그럼 이만 줄이겠습니다.
윤경록 드림
--
Google 그룹스 'Agile Beginners' Q&A' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ab...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 abqna+un...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/abqna?hl=ko에서 그룹을 방문하세요.
--
-----------------------------------------------------------------
Name : 윤경록
Mobile : +팔이-일공-삼공공팔-칠사칠구
MSN : steveyoon77@지메일.com
June Kim (김창준)
이런 경우 보통 쓰는 해결책은(저도 모두 사용해 봤는데):
* 프로토콜을 XML이나 YAML 등으로 서술하고, 거기에서 코드(인코딩/디코딩)가 자동생성되게 한다 (혹은 동적으로 처리)
* Continuous Integration의 테스트 항목에 (함께 만든) 프로토콜 테스트를 넣고, 인코딩과 디코딩을 짝으로(상대역함수 개념) 테스트한다
* commit/log 등의 규칙(주기, 전제 조건 등)을 다시 세우고 확인한다
* 일주일씩 최근 코드 변경에 대해 함께 코드 리뷰를 한다
* 종종 함께 짝 프로그래밍한다
등이 있습니다.
하지만 근본적인 원인을 이해하지 못하면 다른 쪽에서 이런 류의 문제가 다시 나오는 경우가 있습니다.
이번 기회에 전송 표준 구현 엔지니어와 잘 소통하셔서 이런 문제가 앞으로 안일어나기를 빕니다.
Steve Yoon
당시 그분이 상황파악(sensemaking)을 어떻게 했는지, 어떤 결정을 왜 내렸고(왜 다른 일련의 행동은 선택을 안했고), 어떤 예측을 했는지 등에 대한 이해가 중요하다고 생각이 듭니다. 이것이 문제/갈등 해결의 출발점입니다.
...
하지만 근본적인 원인을 이해하지 못하면 다른 쪽에서 이런 류의 문제가 다시 나오는 경우가 있습니다.
그러다 오늘 있던 일이 하나 떠올랐습니다.
앞선 이야기의 전송표준 엔지니어는 대리 3년차로 저보다 한 살 어립니다. 저는 대리 1년차로 경력으로 치면 저는 DVB(digital video broadcast) 솔루션과 방송 보안 솔루션을 그 분은 DAB(digital audio broadcast) 솔루션과 여러가지 embedded OS의 디바이스 드라이버 개발 경험이 있습니다.
제가 지금의 회사로 전직할 때 어떤 분께서 "모두 나이가 비슷하니 그냥 말 놓고 편하게 지냅시다"라고 하면서 제게 반말을 쓰도록 권유했는데, 당시 저는 겸손과 겸양에 대해서 고민하고 있던 때라서 결과적으로 그 제안은 거부하고 지금까지 존대말을 쓰고 있는 상황입니다.
그런데 제가 자존심이 무척 강한 편이고 게다가 소심하기 까지 해서 살짝 문제가 있었던 적이 있었습니다. 그 동안은 작은 회사에서 약간은 리딩하는 입장으로 일을 진행했었는데, 이곳에서 부사수가 되어 업무를 follow up 받으면서 생긴 일이었습니다. 사수는 전송 표준 엔지니어였고, 디바이스 드라이버를 제게 맡기려고 했던 것이었습니다. 그 때 저와 의견이 달랐던게 "쉬운 거니까 금방 하실꺼에요"라고 했던 것이었습니다. 이 때 저는 디바이스 드라이버 개발 경험이 전무하다는 것을 알려줬고 자존심의 상처를 받았던 모양입니다.
그 일이 있은 뒤, 저는 포스트 잇에 해야 할 일과 기한을 적었고 모니터 앞에 붙여놓기 시작하였습니다. 우선순위는 기한이 짧은 것을 먼저 하기로 하였구요.
지금은 위 사진처럼 작은 화이트 보드를 사다가 그 위에 붙여놓고 있습니다.
그리고 요구사항이라던지 F/U를 위해 해야할 일들을 모두 제게 얘기하는 그 순간 바로 적어서 붙였습니다. 물론 이미 하고 있던 일이 있다면 우선 순위에 대해서 물어봐서 Doing을 바꿔야 할지 Waiting의 맨 앞에 둘지 아니면 Pool에 던져둘지를 결정받기도 했죠.
게다가 상호간에 알아야 할 일들은 위키 서버를 돌려서 문서로 작성하고 업데이트 될 때 마다 메일로 해당 내용을 PDF나 jpg 이미지로 만들어서 공유해주기도 했답니다.
위의 이미지는 당시 메일로 공유했던 이미지의 일부분 입니다.
이렇게 일을 하다 보니, 제게 업무에 관해 말을 거는데 조금 어려움을 느끼는 듯 보였습니다.
그래서 같이 술자리도 하고 우리 팀에서 제일 좋다고 너스레도 떨어보았습니다.
그러다 오늘 제가 다음 주에 할 일이 없다고 얘기해서 다시 F/U 얘기가 나왔고 (제가 살짝 표정이 굳었던 모양입니다. F/U에 대해서 제가 많이 어려워 하는 모양입니다.) 매우 어렵게 대화가 진행되는 것을 느꼈습니다.
창준님의 글을 보기 전까지 별 일 아니게 생각했었는데, 이제는 제가 그 동안 존대말만 썼지 진짜로 겸손/겸양하지 않았다는 것을 깨달았습니다.
감사합니다. 내일은 전송 프로토콜 엔지니어와 오랜만에 차라도 한 잔 하면서 이 얘기를 나눠봐야 할 것 같습니다.
Steve Yoon
이지연
Steve Yoon
Steve Yoon
http://picasaweb.google.com/lh/photo/3zStWtmJPfko5wRrO2Fvjg?feat=directlink
누락된 위키 페이지 캡쳐 이미지 입니다.
http://picasaweb.google.com/lh/photo/j3ls1X6iCYFU4HDsQ7s1PQ?feat=directlink