반응형
소프트웨어를 설계하고 개발하는 것은 IDE나 어떤 도구가 아니다. 바로 우리의 머리가 상상하고 창조해내는 것이다. 이를 소프트웨어와 비교하여 웻웨어(wetware)라는 말도 있다. 웻웨어(wetware)는 소프트웨어를 생각해내는 인간의 두뇌, 인간의 뇌세포나 사고과정을 의미한다. 이런 의미에서 초보자에서 전문가에 이르는 여정을 모델링한 드라이퍼스 모델에 대해 알아보고, 어떻게 성장 해야하는지 자신은 지금 어느 단계인지 생각해본다.
전문가의 특징
- 전문가들은 그들의 행동을 세세하게 설명하지 못하는 경우가 많다. 그들의 반응은 거의 습관화되어 있어서 생각하기 전에 움직인다. 그들의 많은 경험은 뇌에서 언어를 사용하지 않는 무의식 영역에 저장되어 있기 때문에 관찰하기 어렵고 그들이 직접 말로 설명하기도 어렵다.
- 하지만 전문가가 세계를 인지하는 방식, 문제를 푸는 방식, 그들이 사용하는 마음의 모델 등은 풋내기와 다르다
- 모든 영역에서 전문가이거나, 초보자인 사람은 없다. 예를들어, 대부분의 비장애인은 걷는데 전문가이고, 초보 요리시가 스카이다이징 전문가일 수 있다.
드라이퍼스 모델(Dreyfus Model)
- 기술의 전문을 연구한 유명한 모델, 간호사, 상업 항공의 비행기 조종사, 세계적인 체스 마스터 등 고도로 숙련된 전문가들이 어떻게 기술을 습득하고 통달하게 되는지에 대한 연구
- 초보자에서 전문가로 가는 5단계의 과정을 정의
- 실제 현실에서 대부분은 일생 내내 2단계(고급 입문자)를 넘어서지 못한다고 함
1. 초보자
- 해당 기술영역에서 사전 경험이 거의 없는 사람
- 경험은 그 기술을 계속 쓰면서 사고에 변화가 생기는 경험을 의미함 10년 개발 경력이 있더라도 그냥 1년치의 경험을 9번 반복하는 것은 경험으로 보지 않음
- 일을 해내기 위한 능력에 관심이 많음
- 뭔가를 배우고 싶어기 보다는 당면 과제를 달성하고 싶어함
- 실수에 어떻게 대응해야 할지 모르고, 뭔가 잘못되면 혼란에 빠지기 쉬움
- 초보자는 레시피(고정된 규칙)가 필요(X가 일어나면 Y를 하라)
- 레시피는 상황에 무관한 규칙으로 모든 사항을 완벽하게 정의할 수 없다. 규칙들이 점점 많아지고, 규칙을 설명하는 규칙이 필요할 수도 있어서 무한회귀에 빠질 수 있다. 어느 순간이 되면 명시적으로 정의하는 것을 그만두어야 할 때가 있다.
- 규칙이 있으면 시작할 수는 있지만 앞으로 나아갈 수는 없다
2. 고급 입문자
- 고정된 규칙에서 조금씩 벗어나기 시작함, 자신만의 작업을 시도하기도 하지만 여전히 문제 해결에는 어려움을 느낌, 큰 그림은 못 봄
- 정보를 빨리 얻고자 하는 욕구가 커짐(ex. 새로운 기술, 새로운 언어 등).
문서를 대략 훑어보고 메소드 시그니처, 파라메타 등을 빨리 찾으려 하고, 길고 지루한 설명을 읽기 싫어하고 기초적인 내용을 다시 보고 싶어하지 않음. - 조금씩 종합적인 원칙을 하나씩 도출해내기 시작하지만 여전히 “큰 그림”은 잘 모른다. 큰 그림을 필요로 하지 않고, 큰 그림은 자신과 상관없는 일로 간주하고 거부한다(ex. CEO가 회사 판매 현황을 설명하지만 아직 수준이 낮아 자기와의 연관성을 깨닫지 못해 관심이 없음)
3. 중급자
- 문제영역에서 개념적인 모델을 정립하고, 그 모델을 효과적으로 활용할 수 있음
- 문제를 스스로 찾아서 해결하고, 새로운 문제를 해결할 방법을 찾아내기 시작 함 하지만, 경험 부족으로 문제 해결 시 어디에 초점을 맞춰야 하는지 판단하는데 어려움이 있음
- 전에 접하지 못했던 문제라도 당황하지 않고, 전문가의 조언을 찾아서 듣고 효과적으로 활용
- 보통 ‘스스로 일을 찾아서 한다’, ‘능력 있다’라는 평가를 듣게 됨
- 팀에서 리딩하는 역할을 하게되고, 초보자의 멘토가 되기도 함, 전문가의 시간을 많이 뺏지 않음
- 이 수준에서도 실무자들은 애자일 방법론을 제대로 적용하기 어려움. 자기 자신을 돌아보고 잘못을 스스로 교정할 수 있는 능력이 부족하기 때문
4. 숙련자
- 큰 그림이 필요해짐, 해당 기술에 관한 큰 개념적인 틀을 찾아서 이해하고자 함, 너무 단순한 정보는 좋아하지 않음
- 스스로를 자가 교정할 수 있다. 이전에 잘못된 일을 스스로 돌아보고 교정 할 수 있음 애자일 방법론의 핵심인 회고와 피드백을 최대한 활용 가능
- 다른 사람의 경험에서도 배움(ex. 사례 연구, 실패한 프로젝트 등)
- 원론적인 진실(ex. 격언, 조언, 디자인패턴)을 실제 상황과 맥락에 적용할 수 있는 능력이 생김
- 예시) “뭐든지 잘못될 수 있는 것은 모두 테스트하라”
- 초보자: 뭘 테스트 해야할지? 필드에 어떤 값을 넣어서 테스트해야 할지? 어떤걸 로그출력으로 해야할지? 등 판단을 못함
- 숙력자: 어떤 것이 문제가 될 소지가 있는지 판단이 가능하고 상황에 맞게 테스트 가능
- 예시) “뭐든지 잘못될 수 있는 것은 모두 테스트하라”
[ 잘못 적용한 패턴 및 방법론 ]
일반적으로 소프트웨어 개발 커뮤니티에서 가장 획기적인 움직임은 숙련자나 전문가 개발자를 대상으로 함.
애자일 개발은 피드백에 기초를 하고 있다. “애자일 개발은 협력하기 쉬운 환경에서 피드백을 통해 끊임없이 조정하는 것이다”. 하지만 이전에 했던 실행 결과에 기초해서 자가 교정을 할 수 있으려면 높은 기술 수준에 도달해야 한다.
애자일은 아주 효과적인 도구이지만 초보자나 고급 입문자로만 구성된 팀에서는 제대로 되지 않는다.
고급 입문자와 중급자는 종종 소프트웨어 디자인 패턴을 레시피로 착각하곤 한다. 그 결과 재앙이 된다.
5. 전문가
- 지식과 정보의 근원. 늘 더 나은 방법과 수단을 찾음, 방대한 경험
- 세부사항 중에서도 중요한 것과 그렇지 않은 것을 식별할 수 있음
- 전문가는 이유가 아니라 “직관”으로 일을 함. 그동안의 경험, 정제된 판단, 기억, 그 외 여러가지 정신적인 활동들이 머릿속에서 광범위하게 얽혀서 직관의 형태로 나옴, 완벽하게 말로 설명하지 못하고, 거의 무의식적으로 나오는 경우가 많음.
전문가에게 직관은 중요한 도구이지만 조직은 직관이 과학적이지 않고, 측정하기 어렵고, 반복하기 어렵다는 이유로 배척 함(목욕물과 함께 아기까지 내던져버리는 꼴) - 어떤 영역에 기술이 부족한 경우 오히려 스스로를 전문가라고 생각하기 쉽다 ’기술도 없고, 없다는 사실도 모른다’. 정확한 자기 평가가 없다는 것은 곧 무능력을 뜻한다.
‘무지가 지식보다 더 자주 확신을 준다’ - 찰스다윈 - 고정된 규칙은 전문가의 생산성을 갉아먹는다. 규칙은 초보자를 위한 것으로 초보자의 생산성 향상에는 도움이 되지만 전문가의 생산성을 초보자 수준으로 떨어뜨린다.
기술 수준 변화에 따른 특성
- 규칙에 의지하던 것에서 직관에 의존하는 것으로 변화
- 인식의 변화가 생겨서 문제가 더이상 같은 비중의 조각들 모임이 아니라 중요한 부분은 일부에 불과하는 식별이 가능
- 유리된 관찰자가 아니라 전체 시스템의 일부가 된 입장에서 사고하게 됨
실전에서 전문성 활용
- 전문가를 남아 있게 만들어라. 소프트웨어 개발을 단순 기계적인 일이라는 고정관념을 가지는 환경에서는 전문가가 남아 있지 않는다(ex. 아웃소싱)
- 정형화된 모델은 도구일 뿐이다. 현실적인 상황과 맥락을 고려하라.
- 정형화 할 수 없는 것을 가치 없는 것으로 판단하지 마라(ex. 문제 해결 능력은 정형화하기 힘들다)
- 개개인의 독립성을 훼손하는 행동을 법제화 하지마라. 정형화된 모델에 너무 의지하게 되면 군중 심리에 의한 행동이 나타나고 개인의 창의성이 떨어진다.
- 방법론 및 프로세스를 초보자에게 맞추면 경험 많은 구성원들에게는 형편없는 작업 환경이 된다
- 너무 많은 세부사항을 정의하면 무한 회귀에 빠질 수 있다. 가정에 대한 가정, 또 그 가정에 대한 가정..
- 복잡한 상황을 지나치게 단순화하지 마라. 특정 프로세스만 따른다고 해서 모든 문제가 해결되고 프로젝트가 성공하지 않는다
- 지나친 일관성은 회피하라
소프트웨어 개발이 창의성, 직관, 고안력이 필요한 작업이라고 생각한다면 정형화된 방법론 및 환경을 피하라.
반응형
'개발 > 기타' 카테고리의 다른 글
MyBatis Invalid bound statement (not found) 오류 조치 (0) | 2024.10.18 |
---|---|
브라우저에서 화면 css 스타일 전체 제거 (0) | 2024.09.07 |
웹 프론트(화면) 성능 지표 알아보기 (0) | 2024.07.04 |
DX(Digital Transformation) 이해하기 (0) | 2024.06.23 |
하이브리드 클라우드, 멀티 클라우드, 분산 클라우드 개념 (0) | 2024.04.06 |
댓글