개발자여! 기술이 아니라 논리로 설득하라 | 면접·보고·발표·논문 다 통하는 W²HO 프레임워크

Video: 개발자여! 기술이 아니라 논리로 설득하라 | 면접·보고·발표·논문 다 통하는 W²HO 프레임워크
Channel: 코딩하는기술사
Duration: 14m 24s
Source: subtitle (auto, ko)
Transcript:
안녕하세요. 멤버 여러분. 우리 개발자분들은 기술은 잘 아는데 소위 말발은 좀 약하죠. 어 물론 잘하시는 분도 계시겠지만요. 대체로 개발자들은 기술을 중요시 하다 보니까이 화려한 엄변하고는 좀 거리가 있고 사실 관심도 별로 없죠. 말 잘하면 뭐 해? 기술이 중요하지. 저도 한땐 그랬습니다. 그런데 이왕이면 다웅치마라고 기술도 잘 알고 말도 조리 있게 잘하면 좋겠죠. 특히 연차가 올라갈수록 각종 브리핑 보고 자리가 생기죠. 그리고 또 더 좋은 회사로 이직할 때도 1차 면접, 2차 면접, 이모 면접 말로 잘 어필해야 되는 순간들이 오게 되죠. 저는 팀 리더 그리고 기술 리더로 오랜 기간 근무하면서 수많은 보고를 해 왔고 20년 넘는 경력 동안 여러 차례 이직을 하며 실무 면접, 임원 면접을 많이 경험했습니다. 거기에 대학원 면접, 기술사 논술 시험과 2차 면접 그리고 석사 논문 작성까지 논리적으로 말하고 써야 하는 상황을 꽤 많이 겪어 왔습니다.이 이 과정에서 제 의견을 보다 설득력 있게 전달할 수 있는 논리 구조를 하나 깨달았는데요.

오늘 그것을 소개드려 볼까 합니다. 제가 who. W는 두 개고요. W제HO 프레임모크라고 이름을 붙였는데요. 논리 전개 각 단계 앞글자를 따 이름입니다. Y, 왓, how, op피니언.이네 이네 단계로 나의 주장을 구조화 하면 어떤 상황에서도 설정력 있게 말을 할 수 있게 됩니다. 각종 보고 자리에서 그리고 면접을 볼 때 그리고 기술을 발표할 때 논문을 작성할 때 기술사 시험칠 때이 틀을 기본 구조로 잡고 활용을 하시면 분명히 달라지실 겁니다. 자 같이 알아보시죠. 자, 개발자요. 기술이 아니라 논리로 설득합시다. 많은 개발자분들이 이런 문제를 겪을 수 있습니다. 기술은 잘 아는데 설득은 왜 어려운가? 10년을 개발을 했는데도 조직의 의사 결정에 목소리를 내지 못하는 이유. 그것은 기술이 부족해서가 아닙니다. 아는 것을 논리적인 순서로 꺼내는 훈련이 없었기 때문입니다. 자, 오른쪽 사례를 보시죠. 기술적인 솔루션부터 말합니다. 자, 이렇게 레지스 캐시 사용하면 됩니다. 왜 필요한지 설명이 없이 바로 솔루션만 던지죠.

그리고 하우만 지나치게 강조합니다. 많은 개발자들에게 볼 수 있는 특징인데요. 기술을 잘 알다 보니까 해당 기술에 대한 구현 방법 하우를 지나치게 강조하는 경우가 많습니다. 비개발 직군이나 임원들은 이런 얘기를 잘 알아듣지도 못하고 지쳐 버릴 수 있습니다. 자, 그리고 논리적인 결론 향후 방향성에 대한 의견이 없다. 기술은 쭉 나열하지만 결과적으로 우리 조직에 어떤 식으로 적용을 하고 앞으로 방향성은 어떻게 가겠다 이런 부분이 부제하는 경우가 많습니다. 한마디로 내용은 있는데 구조가 없다는 거죠. 그래서 제가 수많은 경험에서 깨달은 논리적인 경계 구조입니다. 자, why, 왓, how, 오피니언. 이렇게 해서 wh입니다. 자, 먼저 Y부터 말을 하는 것이 좋습니다. 왜 문제가 되는가? 어떤 배경에서, 어떤 문제 인식에서, 어떤 맥락에서 이것을 하게 되었는지를 말하는 거죠. 이렇게 공감대가 먼저 형성되는 것이 중요합니다. 그리고 나서 왜 이게 필요한지를 얘기했으니 그것을 위해서 솔루션을 말하는 거죠. 해결책 그리고 개념 이것이 문제였는데 이것을 해결하기 위해서 왓이 필요하다 하는 것이죠.

자, 그리고 왜 필요하고 그걸 해결하기 위해서 무엇을 해야 되는지 말을 했으니까 그다음에는 구체적인 실행 방법 how우에 대해서 말을 하는 것입니다.이 왓을 구현하기 위해서 어떤 기술과 방법, 도구를 사용해서 구현을 하는지 말하는 것이죠. 자, 그리고 마지막으로 오피니언 본인의 의견입니다. 이렇게 구현하고 난 뒤에 나의 의견, 나의 판단, 향후, 방향성 이런 부분을 말하면서 결론을 내리는 거죠. 자, 이렇게 y가 있어야지 문제에 대한 인식, 공감이 생기고 그것을 해결하기 위한 왓에 대한 이해가 빨라지고 그리고 그 왓을 어떻게 구현할지 하우를 통해서 알게 되고 마지막으로 말하는 사람의 주관적인 전문적인 의견을 들으면 아주 논리적이고 구조적인 말하기가 되는 것이고 이렇게 말을 하면 설득력 있는 말하기가 된다고 생각합니다. 자, Y를 조금 더 자세히 보겠습니다. 먼저 필요성을 인식을 시키는 것이 중요합니다. y를 먼저 제시하는 순간이 듣는 사람은 그 문제를 스스로 떠올리게 되거든요. 그렇게 해서 공감이 생기고 그렇게 공감이 생기면 그 이후에 솔루션 즉 왓을 들으면 저항 없이 수용하게 됩니다.

자, 그래서 설득이 아니라 공감이 중요하다는 것이죠.이 이 문제 나도 겪었는데 알고 있는데 어 문제가 있어 보이네 하고 그 문제에 대한 인식이 선행이 되어야지 그 이후에 말하는 모든 내용이 설득력을 자연스럽게 가질 수 있다는 것이죠. 자, Y에 담을 수 있는 예시를 좀 보겠습니다. 자, 이것은 그냥 예시일 뿐입니다. Y에 어떤 내용을 담을지는 본인이 발표하는 혹은 말하는 주제, 내용에 따라서 달라질 수 있습니다. 자, 그래서 예시를 몇 개 보면 현재 어떤 문제 상황 그리고 받고 있는 고통 예를 들어서 장애가 발생하면 평균 4시간 서비스가 중단됩니다. 그때마다 고객가 폭주하고 짐 전체가 멈추게 되고 그렇게 되면 응대가 느려지고 회사의 신뢰도가 떨어집니다. 이렇게 문제를 먼저 던지는 거죠. 그리고 어 어떤 수치로 파급 효과를 말할 수도 있는 거고요. 그리고 어떤 트렌드, 환경, 변화 또는 어떤 한계점 이런 것으로 Y로 삼을 수 있고요. 그리고 기술사 논술 시험에서도 2교시, 3교시, 4교시에는 맨 첫 단락에 Y를 제시하는게 좋습니다.

물론 기술 문제에 따라서 조금씩 달라질 수 있지만 특별히 전기에 대해서 언급이 없는 이상 Y부터 작성하는게 답안지 최점하는 점자 입장에서도 이해가 잘되게 보일 수 있는 거죠. 자, 이렇게 y를 제시하고 난 다음에 그러면 그 문제를 해결하기 위해서 무엇을 해야 되느냐? 바로 왓을 제시하는 거죠. 해결책의 개념 솔루션을 y 다음에 배치하는 겁니다. 자, y에서 만든 공감대에서 아, 그래서 이런 것이 필요하다라는 방향성을 던지는 거죠. 예를 들면 이런 식이죠. 앞에서 문제 제기 했죠. 그로 가서 마이크로소비스 아키텍처로 전환이 필요합니다라고 솔루션을 제시하는 거죠. 또는 논술 시험에서 어 대부스 파이프라인을 도입을 해서 해결할 수 있습니다. 이런 식으로 솔루션 개념을 던지는 겁니다. 아직까지 구체적인 방법을 말하는 것은 아닙니다. 자 그리고 구체적인 방법은 하우를 통해서 제시합니다. 왓 다음에 하우인데요. 왓에서 제시했던 솔루션이 개념을 구현하기 위한 실제적인 실행 방안 사용할 기술 도구 같은 구체적인 실행 방법을 하웃 단에서 말하는 거죠.

마이크소비스 아키텍처가 필요하다 그랬으면 도메인 경계를 정의하고 API 게이트웨이를 앞단해 둬서 어 서비스별로 독립적인 배포 파이프라인을 구성할 수 있습니다. 이렇게 하우를 제시하는 겁니다. 그리고 마지막으로 오피니언 즉 본인의 견해 의견 고려상 재언 결론 권고 향후 방향 같은 것들을 오피니언에 담을 수 있습니다. 하우에서만 끝나면 단순 보고서가 됩니다.이 이 오피니언이 있어야지 아이 사람이 생각을 제대로 하는 사람이구나 하는 인상을 줄 수 있습니다. 우리 보통 기술사 시험이나 어떤 논문의 마지막 부분에 향후 연구 방향 있죠? 그게 오피니언일 수 있습니다. 현재는 이까지가 한 개인데 다음번에는 이렇게 더 발전시킬 수 있습니다라고 방장성을 제시하는 거죠. 자, 오피니언 형태도 예시입니다. 자, 결론 공고를 제시할 수 있고요. 그리고 트레이드 오프를 말해서 다음번에는 다른 어떤 기어 요소를 찾겠다. 그리고 향후 방향성 제시할 수 있고요. 그리고 교훈이나 반성을 넣을 수도 있습니다. 자, 이렇게 why이 왓니언으로 전체 내용의 흐름 구조를 잡으면 듣는 사람도 이해하기 좋고 말하는 사람도 논리를 전개하기가 좋습니다.

자,이 구조가 통하는 심리적인 이유가 있습니다. 먼저 왓을 제시하면 청중 머릿속에 그 문제에 대한 공감대가 형성됩니다. 그리고 나서 왓을 제시하면 청중의 머릿속에 아 그 문제를 이걸로 해결할 수 있겠구나라고 저항없이 수용하게 되는 거죠. 그리고 나서 구체적인 하우 즉 방법론 실행 방법론을 제시해서 청중들에게 구체적으로 어떻게 구현되는지 이해시키는 것이죠. 그리고 마지막으로 내 의견, 향후 방향성 오피니언을 제시해서 청중들에게 아이 사람은 확실히 본인의 의견과 향후 어떤 식으로 발전시켜 나가겠다는 확고한 의지가 있구나라고 하는 전문가 인상을 줄 수가 있는 겁니다. 자 인간은 Y가 해결되지 않으면 그다음 내용을 쉽게 받아들이지 못합니다. 그래서이 구조는 설득 기술 이전에 인간의인지 흐름을 맞춘 것이라고 할 수 있습니다. 그리고 참고 사항으로 청중이 어떤 대상이냐에 따라서 논리 구조의 깊이를 조금 다르게 할 필요가 있습니다. 상위 의사 결정자 즉 대표의사나 이임원 발표에서는 y가 제일 중요합니다. 그리고 왓까지.

그러나 하우는 요약을 하거나 별도 자료 혹은 자세히 설명을 드릴까라고 묻는 것이 좋습니다. 왜냐면이 상위 의사 결정자들은 구체적인 기술을 어떤 식으로 구현한다라고 하는 것에 대해서는 크게 관심이 없을 수도 있거든요. 그래서 대표의사나 이원 같이 상위 의사 결정자에게 발표할 때는와 왓 그리고 오피니언 중심으로 말을 하는 것이 좋습니다. 다음으로 우리 실무 책임자분들 팀장이나 아키텍트 기술 리더를 청중으로 두고 발표를 할 때는 와 왓도 중요한데요. how를 충분히 깊게 다루는 것이 좋습니다. 이분들은 기술을 중시하죠. 그리고 어떻게 구현하는지, 얼마나 시간이 소요될지, 어떤 도구들을 사용해야 될지 이런 부분들에 관심이 많은 분들이죠. 그리고 경우에 따라서는 y와 왓은 이분들이 이미 정해 놓은 것일 수도 있고요. 자, 그리고 우리가 보통이 엘리베이터 스피치라고 하죠. 짧은 시간 안에 상사를 설득해야 되는 그런 상황. 저는 그런 상황에서도이 Y와 왓 그리고 오피년 이렇게 세 단계로 압축해서 말을 하면 엘리베이터 스피치에도 좋은 효과를 볼 수 있을 거라고 생각합니다.

이렇게 시간이 많이 짧은 때는 하우는 관심 있으시면 자세히 설명드리겠습니다라고 약간 뒤로 빼놓는 거죠. 자, 예시를 하나 들어 보겠습니다. MSA 경험에 대해서 말씀해 보세요라고 질문을 했다고 봅시다. 자, 그러면 구조 없이 답변을 하면 이런 식입니다. 어, 저는 MSA 프로젝트를 해 봤습니다. 도커랑 쿠디을 쓰고 API 게이트웨이를 사용했습니다. 서비스를 여덟 개로 분리시켰고 각각 독립적으로 배포했습니다. JWT 인증도 붙이고 레빗 MQ로 서서 메시징 처리도 했습니다. 그래서 배포 시간이 줄었습니다. 자, 어떤가요? 기술 위주의 설명이죠. 와, 하우의 경계도 별로 없죠. 기술에 거치고 왜 그걸 했는지 그리고 그래서 너의 판단, 너의 의견, 앞으로의 방향성을 어떻게 되는지는 안 담겨 있는 거죠. 자, 이것을 우리 WHO 프레임워크를 대입한다 그러면 이런식이 될 겁니다. 자, 모놀리식 구조로 배포 주기가 3개월 장애시 전체가 다운되는데는 문제가 발생했습니다. 그래서 서비스 경계를 기준으로 MSA 아키텍처로 전환하기로 했습니다.

MS 아키텍처를 위해서 도메인을 분석했고 여덟 개 서비스로 분리하고 API 게이트웨이와 이벤트 기반 통신을 적용했습니다. 그리고 나니까 배포 주기가 2주로 단축됐습니다. 다만 분산 트랙션 처리가 새로운 복잡도로 남아 있어서 다음 프로젝에서는 도메인 경계를 조금 더 신중하게 정의할 필요성을 느꼈습니다. 자, 어떤가요? 문제 인식 그리고 판단 실행 반성까지 전문가처럼 들리지 않나요? 앞서 구조가 없는 답변과 이렇게 WHO 기반으로 구조를 논리적인 구조를 기반으로 말을 하는 것에는 차이가 있습니다.이 WHO 프레임워크는 어 아래와 같은 많은 상황에 기본적인 틀로 적용할 수 있습니다. 자 기술 면접 어 설계 경험이나 트러블 슈팅 기술을 왜 선택했는지 이런 질문에 문제와 선택 구현 교훈과 같은 형태로 답변할 수 있고요. 그리고 기술사 논술 시험에서 배경 필요성을 먼저 말하고 그다음에 기술 개념 그리고 구속 요소 그리고 향후 방향 이런 식으로이 프레임워크를 적용할 수 있습니다. 그리고 임원 보고할 때도 Y와 왓을 깊게 설명하고 하우는 핵심만 요약하고 오피니언으로 의사 결정을 유도할 수 있습니다.

그리고 앞서 말씀드렸죠. 엘리베이터 스피치에서도와 what왓 how는 조금 뒤로 미루고요. 오피니언으로 빠르게 말을 할 수 있고요. 그리고 기술 발표 컨퍼런스에서도 문제를 제기하고 어떤 접근법을 사용했고 그걸 속에서 어떤 구현을 했고 그다음에 어떤 기온이 있었다. 그리고 기술 문서를 작성할 때도 왜이 결정을 내렸는지 컨텍스트를 먼저 설명하고 그다음에 디c is 즉 왓을 설명하고 그리고 구형과 결론을 내리는 방식으로이 프레워크를 기본으로 깔고 응용을 할 수 있고이 구조로 하면 아주 설득력 있는 말 글이 될 수 있다는 거죠. 자, 그래서 우리 멤버십 요런 거 한번 체크해 보시길 바랍니다. 자, 나는이 y로 시작하고 있는가? 기술이나 결론 하우를 먼저 말하지 않는가? 그리고 y의 구체적인 근거 수치 사례가 있는가? Y의 수치와 사례가 있으면 더 설득력이 있겠죠. 그리고 왓과 how를 명확하게 구분하고 있는가? 자, 무엇이 필요하고 그것을 위해서 어떤 구현이 필요하다. 어떤 방법이 필요하다. 이것을 조금 분류해서 말하기 권장드립니다.

그리고 청중의 수준에 따라서 혹은 청중의 관심사에 따라서 하우의 깊이를 조절하고 있는가? 이문 보고에 너무 깊은 기술 설명은 불필요할 수 있습니다. 물론 해당 이문이 기술 기반에 관심사가 있으면 기술 내용 깊이 얘기하면 좋고요. 자, 그리고 오피니언 즉 내 의견으로 끝내고 있는가? 하우에서 끝내지 말고 내 판단이 담긴이션인가? 자, 그래서 우리 멤버십들은 우리 프로젝트 회고나 기술, 블로그 글 어 회의 등에서 또는 발표 등에서이 논리적 WHO 구조를 한번 적용해서 테스트해 보시길 바랍니다. 자, 정리하겠습니다. Y가 없으면 설득이 아닙니다. 공감이 먼저입니다. 그리고 왓과 how를 구분해 주세요. 그리고 오피니언이 없으면 보고서로 거칩니다. 오피니언까지 가야지 전문가로 보입니다. 그리고 청중의 관심사에 따라서 깊이를 조절하세요. 자,이 구조는 기술사, 논술, 면접, 임원 보고, 엘리베이터 스피치 모든 상황에서 통하는 기본 틀입니다. 몇 번 연습하시면 금방 익숙해지실 겁니다. 아마 지금도 이런 식으로 말을 잘하고 계신 분도 계실 것 같아요.

WHO 프레임워크로 논리적으로 말하는 우리 개발자가 됩시다. 자, 메모심 여러분 늘 감사합니다. 여러분들의 성장이이 채널에 가장 큰 보람입니다. 저도 더욱 분발해서 좋은 콘텐츠로 계속 찾아뵙겠습니다. 감사합니다.