폭포수모델의극복,애자일,도메인주도설계등 IT 소프트웨어 개발방법서에서 다양한 철학과 높은수준의 역량을 요구합니다. 라고 이야기합니다.

소프트웨어 개발에서 필요한 높은 수준의 중요한 역량이 도대체 무엇일까?  메타인지와 관련된 내용을 최근 접하면서 그 능력이 메타인지 능력인가? 고민을 해보았으며,

몇가지 성공한 개발방법론을 이해하고 채택하는 그 자체가 아닌 개발방법론을 이용하면서 팀의 공유된 메타인지 능력 향상이 중요해보이며 

개발방법론과 함께 메타인지개념을 연결해보았습니다.

메타인지 정의 

1970년대 발달심리학자인 존 플라벨(J. H. Flavell)에 의해 만들어진 용어로 '자신의 생각에 대해 판단하는 능력'을 말한다. ‘자기가 생각한 답이 맞는지’, ‘시험을 잘 쳤는지’, ‘어릴 때의 이 기억이 정확한지’, ‘이 언어를 배우기가 내게 어려울지’ 등의 질문에 답할 때에도 사용되며, 자신의 정신 상태, 곧 기억력이나 판단력이 정상인지를 결정하는 데에도 사용한다. 상위인지라고도 한다.

메타인지는 아이들의 발달 연구를 통해 나온 개념이므로 교육학 등에 주로 등장하는 용어다. 뛰어난 메타인지능력을 가졌다면 적절한 시기에 적절한 도전을 함으로써 학습속도를 빠르게 가져갈 수 있다. 예를 들어, 수영을 한 달 배운 아이가 '나는 100m를 완주할 수 있는가'를 스스로 판단하고, 만약 완주할 수 없다면 나에게 부족한 게 체력인지 기술인지를 스스로 판단하는 데에 메타인지가 사용되므로, 메타인지능력이 높다면 자신의 능력과 한계를 더욱 정확히 파악해 시간과 노력을 필요한 곳에 적절히 투자하므로 효율성이 높아진다.

또한 성인이 되어감에 따라 자연스럽게 메타인지능력은 향상된다.

사람의 무지함을 일깨우려 할 때 자주 사용되는 개념이기도 하다. 모르는 것을 아는 척하는 것도 위험하지만, 진짜로 위험한 건 내가 모르고 있다는 것조차 모르고 있는 것 등으로 등장한다.


소크라테스의 '너 자신을 알라' 라는 유명한 문구는, 철학의 시작점과 함께 메타인지의 기원으로 볼수있습니다.

메타인지와 관련된 추천서적

최고의 회사만 아는 메타인지의 힘 메타인지가 업무 능력을 높이는 열쇠다!

일 잘하는 사람의 특징은 무엇일까? ‘업무 센스가 있다.’ ‘유능하다.’ ‘일머리가 있다.’ 등으로 흔히 표현되지만 일 잘하는 사람은 결국 메타인지가 뛰어난 사람이다. 메타인지란, 쉽게 말해 자신이 무엇을 알고 무엇을 모르는지 아는 것을 뜻한다. 더 나아가 업무의 목적과 절차, 상황과 맥락을 파악하는 능력을 의미한다. 메타인지가 높은 사람은 문제해결력 또한 높은데, 문제해결력은 업무에 가장 필요한 역량으로 손꼽힌다. 결국 메타인지가 업무 능력을 결정짓는 중요한 요소라는 말이다.

상대방의 사고 및 인지 흐름을 이해하고 활용하는 것은 인간만이 할 수 있다. 이것이 바로 AI에 위협받지 않는 경쟁력이다. 저자는 글로벌 경영 컨설팅사에서 9번이나 승진한 기록을 세운 남다른 메타인지의 소유자로, 그동안 메타인지가 뛰어난 수많은 리더와 인재를 만나왔다. 그 경험을 바탕으로 업무 환경에서 활용할 수 있는 메타인지에 대한 모든 것을 집대성해 이 책을 집필했다. 메타인지의 기본 개념부터 메타인지를 향상시키는 방법, 조직에서 메타인지가 발휘되면 어떤 효과가 나타나는지 구체적인 사례를 보여준다. 메타인지가 뛰어난 사람은 업무 상황에 닥친 문제를 어떻게 해결하는지, 그 비밀을 알고 싶다면 이 책을 펼쳐보자.


메타 인지는 다음과 같이 분류될수 있으며

메타인지 3요소 분류

  • 서술 지식 - 자신이 학습하는 부분에 대해서 얼마만큼의 지식과 능력을 가졌는지 아는 능력
  • 절차 지식 - 이해 정도를 아는 능력.
  • 전략 지식 - 지식 습득 방법 중 무엇을 선택해야 하는지 아는 능력

메타인지 4요소 분류

  • 문제에 대한 메타인지 : 우리는 해당문제를 인식하는가?
  • 메타인지 컨트롤의 모니터링 : 인식한 문제를 잘 해결하고 있는가?
  • 메타인지 상호작용 : 다른 사람은 어떻게 문제를 인식하고 있으며, 상호 커뮤니케이션을 통해 함께 해결해 나가는가?
  • 메타인지 컨트롤에서 평가 : 인식한 문제가 잘해결되었는가?


소프트웨어 개발방법론도 대부분 어떠한 문제를 해결하고 도움을 주는 그 자체 솔류션을 만드는것에 목적이 있으며

고객이 원하는것이 무엇인가? 어떻게하면 개선을 할것인가? 잘 작동하고 해결해나가고 있는가?

메타인지의 요소들이 개발방법론에서 요구되는 필요 철학과 그 프레임이 크게 다르지 않다란것을 알수 있습니다.


소프트웨어 개발에서 필요한 메타인지 기술

도메인 주도설계에서는 우리가 만들어가는 소프트웨어가 왜 복잡해지고, 통제가 안되는지? 문제에 대한 메타인지의 시작으로 다양한 전략/전술을 포함 고급적 철학이 포함되어 있습니다.

애자일에서는 빠르게 변화해야하는 소프트웨어에서 팀을 어떻게 구성하고 긴민하게 움직일지, 팀의 공유된 메타인지로 확장이 됩니다.

도메인 주도와,애자일은 개발방법론이자 철학이기도 하며 소프트웨어를 성공시켜야하는 생존의 문제와 함께 메타인지 능력을 보통수준아닌 전문성과함께 훨씬더 높은수준을 요구합니다.



집단이 애자일하게 움직이기 위해서는 팀 경영 환경 전반에 관한 메타인지를 팀 리더만이 보유하고 있는 것이

아니라, 팀 구성원 전체가 팀 리더와 유사한 수준으로 공유하는 것이 매우 중요하다. 우리는 이를 가리켜 팀의

'공유된 메타인지(shared meta-cognition)'라고 칭하겠다. 즉 팀 구성원 개개인들이 각각의 좁은 시야에서

각자의 의견만을 주장하는 것이 아니라, 팀을 둘러싼 상황과 맥락 전반을 함께 이해하고 공유하며 확장하고,

나아가 팀 전체의 목적 달성을 염두하여 통합적으로 집단 의사 결정을 내릴 수 있는 것이 애자일의 공통된 첫

번째 핵심 역량인 것이다


메타인지와 관련된 몇가지 구체적인 개발방법론을 살펴보겠습니다.

우리가 사용하는 개발방법은 무엇인가?

현재보다 더 나은 개발방법을 찾고 팀이 채택해야할 방법론을 고민하면서, 그 개발방법론에 따라 팀의구성및 개발문화에 영향을 끼치게 됩니다.

이 과정에서 오랫동안 사용된 폭포수모델의 문제를 이야기하며 시작하거나 참고 합니다.

우리가 현재 채택한 개발방법은 무엇인가? 메타적 사고인지의 출발점이 될수 있으며 수직적인 절차를 요구하는 폭포수 모델을 먼저 이해하는것은 중요합니다.


폭포수 모델은 나일강을 따라 내려가는 여왕의 유람선처럼 복잡하고 장엄한 프로세스이다. 대개 큰 조직에서 소프트웨어를 생산하는 데 사용하며, 프로젝트의 복잡성과 규모를 관리하는 하나의 방법이다. 

개발과정에 프로세스가 없고, 절차가 없다고하면 폭포수모델은 도움이 될수있습니다. 폭포수 모델에서 대부분의 책임과 중요의사결정은 설계를포함 제일 윗단계에 있으며 

릴리즈라는 하부단계로 내려가면서 실무자가 조정하거나 변경하는것 자체가 어렵지만 시원한 절차에 의해 성공을 향해 달려가는것입니다.

그래서 수직적인 개발문화가 요구되는것이지, 이것을 이해하지 못하고 수직적 개발문화가 항상 나쁘다라고 가정하는것은 오류입니다.

만약 비즈니스를 가장 잘이해하고 중요결정을 하는 전문가가 상부에 있다고하면 폭포수 모델이 적합할수 있으며 존중을 유지하면서 수직적인 절차가 

시원한 폭포수처럼  성공을 향해 달려 가고있다고하면 수직이란 단어자체가 부정적인 의미로 해석할 필요는 없습니다. 그 성공과정에 탑승을 하면 됩니다.


하지만 우리가 조금더 높은 수준의 전문가라고 한다면, 수직적인 개발문화를 포함 폭포수모델은 왜 한계가 있는것인가?

언제까지 이것이 유용할것인가? 고차원적인 고찰이 필요합니다.

폭포수모델을 활용하여 과거 대부분의 프로덕트는 성공해왔고, 초기프로젝트들은 아직도 이방식으로 일부 성공을 하고 있습니다.

하지만 프로덕트가 발전해감에 따라 사용자의 요구사항은 빨리 변하고 개발하고 있는중에도 트렌드가 바뀌며,

이것은 시대의 흐름에 따라 점점 가속화가 되어가고 있습니다. 이러한 점에서 폭포수 모델은 다음과 같은 한계가 있는것이지 항상 나쁜것은 아닙니다.


그래서 폭포수모델의 한계라고 이야기를 해야하며, 그것을 우리는 이해할 필요가 있습니다.

  • 지나치게 오래걸린다 : 문서 작업들과 승인 과정은 모두 빠른 개발을 방해한다. 산출문 문서는 생명주기 내내 '겉치레' 역활에 그치며 내재된 가치가 있다라고 생각한다.
  • 최종사용자와 의사소통에서 생기는 틈 : 맥크래켄은 다음과 같이 말했다. 폭포수 모델의 생명주기는 진열대를 돌아다닐 기회도 주지 않고 슈퍼마켓 입구에서 고객이 점원에게 완벽하게 주문하도록 강요하는 슈퍼마켓과 비교할수 있다. (진열대를 돌아다니면, 가격을 비교할수도 있고, 쇼핑 목록에 없는 항목을 기억할수도 있고, 그냥 외식하러 가기로 결정할수도 있다)
  • 폭포수모델에서는 문제의 정의및 설계단계와 그것을 해결하는 구현단계가 분리되어 있으며 그것을 수행하는 담당자 역시 분리되어 있습니다. '어떻게'에서 분리된 '무엇' : 문제를 정의할 때까지 해결책을 미룬다는 생각도 구조적 분석과 설계의 신조 가운데 하나다. 물론 문제 정의를 먼저하고 해결책을 나중에 내는것은 논리적인 귀결이다. 하지만 불행히도 사람들은 현실에선 그런 식으로 행동하지 않는다. 사람들은 문제를 고려할때 보통 일정한 범위 안에서 가능한 해결책을 동시에 고려한다.
  • 고약한문제 : 합당한 문제는 정의될수있고, 해결책이 나올수 있다. 하지만 고약한 문제는 정형화되어 있지않으며, 해결책의 일부가 문제 공간안에 있다. 특히 문제를 해결하고 나서야 완전히 이해할수있다. 이것은 최종 해결책에 도달하기 전에 중간 결과를 반드시 얻어야 한다는 것을 뜻하거나, 아니면 문제가 정의되면서 동시에 해결된다는 것을 의미한다. 폭포수의 하향식 접근방식으로는 고약한 문제를 해결할수가 없다.


어떠한 개발방법을 시도해 볼것인가?

은행업무 소프트웨어에서 도메인전문가는 누구일까요? 아키텍트? 아키텍트는 단지 자신의 계좌에서 송금을 할수 있을뿐입니다.

그렇다면 데이터전문가? 아마 업무프로그램의 사용에 아무런 관심이 없어  한번도 사용못해볼 가능성이 높습니다.

정답은 이분야의 도메인 전문가는 은행소프트웨어를 사용하는 은행직원입니다.


수직적인 절차에서는 최상위에서 주요의사결정을 하고, 하위에서는 변경이 어렵습니다. 

그렇기 때문에, 도메인 주도 설계에서는, 도메인 전문가를 초기에 참여시키라고 합니다.

Eric Evans가 출간한 ‘도메인 주도 설계-소프트웨어의 복잡성을 다루는 지혜’는 DDD라고 짧게불리며, 개념을 정립하고 세상에 널리 알리기 시작하였습니다.

도메인전문가를 참여시켜라

자신이 무엇을 알고 무엇을 모르는지가 메타인지의 시작이다 여기서 개발팀과 비즈니스팀이 잘하는 영역과 못하는 영역이 있으며 서로 같이 알고 있는 영역도 있으며 모두가 모르는 영역도 있을수 있다. 모두가 모르는 영역을 어떻게 알수있는가? 개발팀과 비즈니스팀이 이것을 알기위한 협업과정이 없다고 하면 우리전체는 무엇을 모르는지 조차 알수가 없다.

도메인은 발명이 아니라, 끝없는 여정을 통한 발견이라고 표현하기도 합니다.  끝없는 메타인지 사용의 연속입니다.


도메인 주도 개발은 이름에 나온것 처럼 실제 비즈니스 모델을 개발 아키텍트에 투영시키는 개발방법론이다. 도메인 전문가들은 IT용어를 잘 모른다, 반대로 개발자들은 도메인 전문가들의 용어를 잘 이해하지 못한다. 이런 과정에서 상당히 많은 이슈가 발생하게 되고 개발 Release가 늦어지게 된다. 이를 해결하기 위한 방안으로 도메인 주도 설계라는 방식이 등장하게 되었습니다.

도메인 주도설계에서는 메타인지의 중요성을 포함 , 메타인지를 실천하기위한 구체적인 전략적인 내용이 있습니다.


문서가 대화를 지배하는 상황 

특정 도메인에대해 올바른 질문을 할수있어야하고, 보완의 가능성을 열수 있는것이 메타인지 컨트롤의 모니터링에 해당하는 부분입니다. 

도메인 주도설계 에서는 문서가 대화를 지배하는 상황을 다음과같이 경고합니다.

도메인 전문가와 개발자는 모두 문서가 대화를 지배하는 상황을 피해야하고, 최고의 보편언어를 협업에 의한 피드백으로 산출해야한다. 이로서 화합된 멘탈 모델을 구성할 수 있다. 열린사고와 깊은 탐구를 현재의 지식기반에 대한도전을 통해 핵심도메인에 대한 통찰을 얻어야한다.


다음은 문서가 대화를 지배하는 상황이다. 

  1. A:  우리가 가진 기능중 OOO가 이렇게 작동되는것 같은데 , 작동방식이 약간 불편해보입니다. OO렇게 개선되면 좋을것같습니다.
  2. B: 그것은 O달전에 회의를 하여 기록한것같습니다. 기획의도에 아무런문제가 없는것 같습니다. 
  3. A : 그러면 이것을 개선하려면 어떻게 해야합니까?
  4. B :기획의도 조정이 필요해보이며, 승인과정을포함 문서작업까지 O주가걸리니 문서가 업데이트되고나서 그일을 시작할수 있을것같습니다.


메타인지 컨트롤의 모니터링은 우리가 올바르게 하고 있는가를 끊임없이 체크하고 변경하는것으로

우리의 문서가 메타인지 컨트롤의 모니터링기능을 수행할수 있는가? 에 대해 고민해볼필요가 있습니다.

문서의 목적성에대한  문제인지로, 문서는 다음과 같은 문제점을 가질수 있습니다.

  • 개발자만이 아는 UML 문서는, 도메인 전문가와 함께 개선하기가 어렵습니다.
  • 설계문서는 구현과 일치하지 않는 경우가 있습니다. 이것은 설계자와 구현자가 다르기 때문에 나타는 현상입니다.
  • 기획문서가 항상 최신내용을 표현하기를 기대하며, 상세기획문서대로 개발을 하면 구현이될것같지만, 사실은 QA단계 디펙을 내면서 기획문서의 대부분이 수정됩니다.
  • 우리의 어떠한 문서에도 도메인 모델 핵심을 표현하는 문서가 존재 하지 않습니다. UI/UX를 표현하는 목업만 존재합니다.
  • 작업을 위한 문서가아닌, 보고 하기 위한 문서에 가까울수록 작업자에게는 아무런 쓸모가 없을수 있습니다.


도메인 문제를 해결하기위해, 룩앤필(목업)에 너무 집중한 나머지 우리에게 필요한 도메인모델과 규칙등을 제대로 정의하지 못하는경우가 많습니다.

룩앤필이 먼저일까요? 도메인 모델을 발견하고 그것을 시각화하는것이 먼저일까요?

UI/UX 목업 기획서가 아닌 이벤트 스토밍,스토리맵핑등 다양한 협업기획방식을 살펴보면서 그 힌트를 찾을수 있을것같습니다.

이 기반으로 만들어진 협업문서는  테스트 케이스를 포함, 작동되어야한 규칙을 구현단계 이전에 정의할수 있으며 이 기반으로 

우리가 무엇을 해야하는지 알수있으며 문서를 대체할수 있습니다.



여기서 정리하고 싶은 이야기는 문서 위주 또는 절차중심의 구조적인 방법론으로는 제품을 발전시키기 위한 메타인지가 지속적으로 작동되기 어렵다란 점입니다.

여기서 제품의 발전을 위해 2001년 소프트 업계를 주도하는 리더들이 애자일 선언을 다음과 같이 하게됩니다.

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.

  • 공정과 도구보다 개인과 상호 작용을 
  • 포괄적인 문서보다 작동하는 소프트웨어를 
  • 계약 협상보다 고객과 협력을
  • 계획을 따르기보다 변화에 대응하기를 가치있게 여긴다. 

여기서 앞에 나온 것들을 무시한다기 보다 둘 다 가치가 있지만 무게 중심을 뒤쪽에 더 둔다란것이다.

애자일은 사람중심(고객과 그것을 해결하는 사람모두) 이기도 하고, 다른사람의 개발을 도와줘야하는 이타적인 사상이기도하고, 제품이 어떻게하면 생존을 할수 있는가? 품질과 관련될수도 있지만

2001년 소프트업계의 리더들이 모여 공유된 메타인지에서 출발하였습니다.


애자일이 잘못해석되는 경우, 생존을 위해 속도만 생각하는경우 입니다. 이것은 단지 스피드(빨리빨리) 일뿐입니다.

애자일의 가치는 올바른 방향을 찾아가며, 안전하게 달리는것으로 시스템중심이 아닌 사람중심에 더 가깝습니다.


그래서 애자일선언과 애자일 방법론을 우리는 구분해야할 필요가 있습니다. 애자일선언에 의해 그 철학과 가치를 추구하기 위해

기업마다 각각 자신의 방식으로 프레임화한것이 애자일 방법론입니다. 스크럼/린스타트업/xp/칸반등 다양하게 있습니다.

칸반의 경우 애자일선언보다 더 일찍 나왔지만, 애자일의 철학이기도 하기때문에 애자일에 분류가됩니다. 


애자일 방법론을 사용함에 따라 , 수평적 개발문화를 필요로 하게되었으나 , 여기서 이야기하는 수평은 평등이아니라 훨씬더 고차원적인 개념입니다.

수직 VS 수평

내가 속한 조직이 수평인가? 팀에서 채택된 개발방법이 수직인가? 명확하게 정의하고 구분을 하는것은 어려워보이기도 하지만

수직과 수평을 선악으로 이분하기보다, 메타인지 상호작용부분으로 상황마다 다를수 있고 수직이여서 좋은점이 있을수 있습니다.

여기서 상호작용은 작용을 통해서 발생하는 부분으로 내가 상대하는 반대편도 인지해야하는 부분으로 메타인지중에서도 어려운 요소입니다.


최근 인터뷰및 면담에서 다음과같은 질문을 하는 케이스를 상당 경험하였습니다.

  • 수평적 개발문화가 좋습니다. 저의 사수는 어디에 있나요?
  • 저는 수직적 의사결정이 싫으며 주도적이고 싶습니다. 또한 저는 주니어이기때문에 10년차 정도 저를 성장시킬(사실은 방어해주는입니다.) 누군가가 필요합니다. 

위 질문에대한 인터뷰에 응답한 내용입니다.

우리는 수평에 가까운 개발문화에 도전하고 있으며 다양한 개발방법론을 팀이 선택하고 시도할수 있습니다.

사수는 수직적인 상명하복 조직인 군대에서 사용하는 용어이며, 당신의 모든 실수를 

책임져줄 상급자를 찾는것으로 수평과는 반대되는 개념입니다.

우리에게 사수라는 개념은 없으나 다음과같은 팀문화로 당신이 적응하는데 도움을 줄것입니다.

업무이해를 위해 컨플런스 팀의 온보딩및 CTO의 아키텍트 소개는 도움될것이며,

팀리더는 당신이 할수 있는 만큼 개발을 주며, 책임을 질것이며 , 그 과정에 여러분의 팀동료가 도와줄것입니다.

이 부분에서 완전한 수평이라고 할수 없지만, 팀과 함께 당신의 발전을 위해 노력할것입니다.

당신도 팀이 변화할수 있게 주체자가 되어주세요


수평은 너와 내가 평등하냐?  나이,직책,책임별역활등의 비교대상이 아닌,  어떻게하면 우리가 변화하고 발전할것인가? 밸런스를 계속 맞춰가는 밸런스 게임입니다.

종이 한 장을 세로로 손바닥 위에 세울 수 있을까요? 조금 아슬아슬하겠지만 불가능하진 않습니다. 중심을 맞추느라 손바닥을 조금 움직이면 종이는 손바닥 위에 세워집니다. 와우!

이렇듯 균형을 잡기 위해서는 중심을 찾는 것이 중요합니다. 조직의 비전과 개인의 실행이 균형을 맞추고 있는가를 알려면 팀의 구조를 봐야 합니다. 불확실하다는 것은 단지 앞만 잘 안 보이는 것이므로 리더 혼자 앞만 보고 가다 보면 언젠가는 도착하리라 생각하지만 절대 그렇지 않습니다. 통신을 통해 보이지 않는 영역과의 소통, 전체를 보는 시스템의 활용, 주변 지형지물에 관련된 정보 수집등은 팀 차원에서 해결해야 밸런스 작업입니다.

밸런스의 반대 의미는 바로 사일로(Silo)입니다. 칸막이로 된 전문화된 조직은 밸런스를 논할 필요가 없습니다. 자신이 보고 있는 것을 하기만 하면 되기 때문이죠. 그것이 조직의 비전과 무슨 개연성이 있을까하고 고려하지 않습니다. 팀은 조직과 개인을 연결하는 통로가 되어야합니다. 조직의 방향을 인식하고 경영자적 관점으로 자신의 역할을 수행해야 합니다.

이 두 가지의 관점이 밸런스를 맞출 때 비록 안개 낀 도로일지라도 모든 팀원들은 즐거운 마음으로 헤쳐 나갈 수 있습니다. 두려움을 피하는 기존의 사일로에서 이제는 용기를 얻는 밸런스 경영을 유지해야 하는 이유입니다.

벨런스 게임에 참가하기위해서  수직적인 개발에서 요구하는 역량보다, 고급철학과함께 높은 개발역량을 요구하게 됩니다.

그래서 우리는 이미 수평적 문화입니다가 아니라, 우리는 조직의 비전과 개인의 가치 실행이 균형될수 있게, 수평문화에 끊임없이 도전하고 있는중입니다. 여야합니다.


수평을 원하면서 사수를 찾거나, 자신이 주니어여서, 자신의 역량을 제한을 건다고 하면

수평적 개발문화라고 할수있는 애자일을 도입한 개발팀에서, 스프린트 한사이클조차 제대로 수행하기 어려울수도 있으며

간신히 버틴다고 해도 스프린트 4사이클 이내에 번아웃이될 확률이 높습니다.

수평적 개발문화가 채택하는 개발방법론의 이면에는 개발자의 경우 보통이상의 높은수준의 개발철학과 역량을 요구합니다. 


수평과 수직을 따지기보다, 자신이 성장할수 있는가? 성장형 사고방식 의 글 도움될수 있습니다.

커뮤니케이션 충돌

커뮤니 케이션 충돌의 3요소

  • 사실관계에 대한 차이
  • 노하우에 대한 차이
  • 시각 차이


커뮤니케이션중 발생하는 충돌의 프레임은 위 3가지가 있으나, 이것에 대한 프레임을 이해하지 못하고 당신이 나를 이해하지 못한다라고 언쟁을 하는 경우가 많다. 공감보다 상대방의 인식을 이해하는것이 중요하다. 

물컵을 이해하는 다양한 시각및 입장차이를 나열해 보자

  • 이것이 물컵이냐 아니냐는 사실관계에대한 차이이다.
  • 이 물컵을 꽃꽂이용으로 사용할것이냐? 컵을 판매용으로 바라볼것이냐?는 컵을 바라보는 시각의 차이이다. 비즈니스와 엔지니어의 인식 차이는 주로 여기서 난다. 
  • 이 물컵에 담긴 물을통해 갈증을 해소하기위해 , 얼만큼의 물이필요하며 나눠마실건가는 노하우에 대한 차이이다.

여기서 이야기하는것이 자신의 대상에대한 인지뿐만아니라, 상대가 그것을 어떻게 인지를 하고 있는가에 대한 자신과의 차이를 인지하는것이다.

커뮤니케이션에서 발생하는 차이는 주로 3가지 이며(더있을수 있으나 이것만으로 충분하다.)


공감대 형성을 통해 커뮤니케이션이 충돌을 해결되는것이 아니며, 오히려 공감하지 못하는 인식 차이에대한 인지를 함으로 

충돌을 해결할수 있다란것이며 , 커뮤니케이션의 충돌의 해결 프레임이 공감과는 약간 거리감이 있으며 메타적 사고인지에서

사회적 메타인지에 해당하는 부분으로 상대의도를 파악하는 능력을 의미한다. 


추가적으로 소프트웨어에서 커뮤니티가 더어려운것은 모든사람이 동의하는 전문용어가 없습니다. 

또한 비즈니스용어와 개발팀이 사용하는 단어조차 다를수 있습니다.

빅뱅이론은, 기 이론이 우주의 탄생을 설명하 기에 적합한 내용인지 모든 천문학자가 동의하는 건 아니지만,

천문학자 라면 이해는 한다. 하지만 소프트웨어 공학 분야에서는 모든 사람이 동의 하는 전문용어가 없다. 예를 들어, 객체지향 프로그래밍의 정의는 다양하다.

비지니스 환경에서 우리 분야를 원래 '데이터 처리'라고 불렀지만 지금은 '정보 처리'라고 부른다.

공학 환경에서는 '컴퓨팅'이라고 부른다. 우리 가운데 일부는 이제 우리분야의 이름을 '지식 처리'라고 바꿔 부르기를 원하기도 한다. 

-고약한 문제 합당한 해결 책 중에


이러한 커뮤니케이션 과정에서,  우리가 사용하는 용어를 도메인내에서 통일해야할 필요가 있으며, 우리가 생산한 아이디어를 어떠한 형태로든 모델화할 필요가 있습니다.

프로젝트에 사용되는 언어가 분열되면 의사소통을 무디게 하고, 지식탐구를 빈약하게 만든다.

설계측면에서 도메인에 관한 토론에 적합한 자신들만의 언어는 결국 코드 산출물에 녹아든것과

단절되게된다.  모델기반 언어는 개발자 사이에서 시스템의 산출물뿐 아니라, 업무와 기능을 기술할때도 사용해야하고

도메인 전문가와 의사소통하는것에도 해당 언어를 제공해야한다. 초기모델은 분명 제대로된 역활을 못할것이지만, 지속적으로 보편언어를 사용하고 언어공백이 발견되면

도메인 모델의 변화로 인식 될것이다. 용어의 의미가 바뀌면 클래스와 메서드의 이름을 변경하고 동작 방식도 변경을 한다.

보편언어의 변경이 곧 모델의 변화라는것을 인식해야한다.

-도메인 주도 개발 책 서적 중에


보편언어를 만드는것자체가, 중요한 생산활동이란점 이며 , 용어가 우리의 소프트웨어에 영향을 끼친다란 점입니다.

메타인지와 관련해서 인지에대한 차이를 인지하는 과정은 그 자체가 많은 시간을 필요할수 있으며

합의된 보편언어를 개발하여 그 과정의 비용을 점점 줄이는것에 목적이 있습니다.


데일리 미팅 문화

  • 내가 알고 모름을 아는것(Know-what)
  • 업무의 목적(Know-why), 절차의 흐름을 이해하는것 (Know-how)
  • 상황과 맥락에 대한 파악 ( Know-when,Know-where)


우리의 활동이 해야할일 완료로 넘어가는 과정만을 하는것을 전부로 여기고

동료가 무슨일을 어떠한 방식으로 완료하였는가? 아무런 관심이 없는경우가 있습니다.

자신의 턴일때  진행하고 완료한 일을 팀에 간단명료하게 설명을 할수 있어야하며, 상대의 턴일때 자신과 연관이 없다고 생각하더라도 경청을 해야합니다.

이 활동의 진정한 목표는 스케쥴을 준수하는것만이 아닌, 우리의 팀이 만들었던 문제를 잘 해결해나가고 있는가 과정에 관한것입니다.

다른사람의 이야기를 잘 경청을 해야,동료의 어려움 해결에 도움줄수 있으며 언젠가 내가 어려움이 있을때 도움을 받을 가능성이 높아집니다.

여기서 주의점은, 팀리더의 눈동자를 보지마세요~ 팀리더에게 보고하는 자리가 아닙니다. 당신의 이야기를 팀원에게 들려주세요


짤 : 라이언은 경청 전문가 입니다.(입이없어서) 

데일리 미팅은 팀이 메타인지를 지속적으로 짧게할수있는 중요한 활동중의 하나입니다. 말하기도 중요하지만 경청도 중요합니다.


회고문화

배운것은 무엇이며 얻은것은 무엇인가? 메타인지 컨트롤에서 평가에 해당하는 부분이며

개발의 한주기가 끝나면 회고를 통해 다음 주기를 발전시켜 나갈수 있습니다.

보통 15일또는 한달단위로 수행할수 있습니다.


우리만의 방식을 찾기

basecamp 의 개발 프로세스 - Shape Up

과거 몇년간 어떻게 작은 팀으로, 높은 품질의 소프트웨어를 그렇게 빨리 개발해내는지 물어보곤 했다. 또, 개발자들을 오랫동안 유지하는지도.

첫째, 우리는 워터폴, 스크럼같은 프로세스에 얽매이지 않았다.

둘째, 우리는 벽에 포스트잇을 줄세우지 않았다. 셋

째, 우리는 데일리 스탠드업, 스프린트, 백로그, 칸반, 벨로시티 체킹등 어느 것도 하지 않았다.

문제점

소프트웨어팀이 성장하면서 유사한 문제점들이 생겨난다.

- 팀원들은 프로젝트가 끝없는 행군처럼 느껴진다.

- 프로덕트 매니저들은 프로덕트에 대해 전략적으로 생각할 시간을 낼 수가 없다.

- 창업자들은 자문한다. 왜 우리는 예전에 했던 것처럼, 신속하게 기능을 출시할 수가 없을까?


우리는 4명에서 50명으로 늘어나면서 이런 문제에 직면했다.

사람 수가 늘어나면서, 창업자들의 직관을 전달하기가 어려워졌다. 그래서 새로운 스케일에 맞는 구조가 필요했다.

.......

우리는 우리의 길을 만들었다.

링크 : 


다른 조직이 성공한 케이스를, 우리가 도입해서 성공하는것은 아니다 Shape Up의 성공방식에서 배울점은

스스로 자신의  문제를 인지(메타인지)하고 자신에게 맞는 방식을 만들었다란 것이다.

애자일 개발방법론 도입에 피로도가 높고 거부감이 있다고하면 위 방식도 연구를 추천해본다.


참고 자료

여기서 작성된 글은 다음자료를 참고하거나 일부 인용하였습니다.


  • No labels
Write a comment…