주니어가 "이거 어떻게 해야 할지 모르겠다" 또는 "이거 내가 다 만들어야 하나?"라는 '트리거'를 감지했을 때, 아래의 3단계 프로토콜을 따르도록 안내합니다.
주니어에게 패턴 목록을 외우게 하는 대신, "당신의 특별한 문제는, 사실 흔한 문제의 다른 얼굴일 뿐이다" 라는 통찰을 줍니다. 그리고 그 '흔한 문제'의 이름을 찾아내는 방법(일반화)과, 그 해답(일반해)을 세상의 집단 지성으로부터 가져오는 방법(탐색)을 가르칩니다.
하지만 주의할 점은, 한번 쯤 떠올려보는 것에 의미가 있지 모든 것을 일반해로부터 시작할 수는 없습니다.
패턴이 보일 때는 패턴으로 풀고, 패턴이 보이지 않을 때는 패턴이 보일 때까지 일단 뭉쳐둔 상태로 직접 나아가다가 추후 패턴이 보이면 적용하는 것이 바람직 합니다.
•
Why
◦
체스 챔피언 연구(de Groot, Chase & Simon)에 따르면, 전문가는 흩어진 조각이 아니라 패턴(청크) 단위로 정보를 기억, 사고한다. 패턴이 없으면 전문가도 일반인과 동일한 기억력을 보인다.
◦
전문가는 패턴으로 사고함. 예를 들면, 체스에서 “아, 이거 시실리안 디펜스 패턴이네!” 하고 직관적인 한 덩어리로 봄. 초보자는 말 하나를 따로 따로 봄. “여기 폰, 저기 나이트랑 비숍, …”
◦
바퀴를 재발명하지 않는 차원에서 이미 현실의 문제를 바람직하게 모델링 해둔 패턴들을 활용할 수 있음. 처음부터 다 만들지 않고 일반해의 조합 위에 현재의 구체적인 요구사항을 먼저 해결하면 문제가 쉬워짐.
“초보자들은 "좋은 객체지향 설계란 무엇일까요?" 를 이해하는 데만도 꽤 오랜 시간이 걸립니다. 경험자들은 초보자가 모르는 그 뭔가를 알고 있다는 것인데, 과연 그것이 무엇일까요? (…) 전문가들은 초보자들처럼 모든 문제를 처음 기초 단계에서부터 해결하려고 하지 않습니다. 대신, 전에 사용했던 해결책을 다시 사용해 봅니다. (…)
대부분 소설가나 극작가들은 빈 종이에 새로운 줄거리를 매번 쓰는 것이 아니라, 햄릿이나 맥베스처럼 "비극적으로 흘러가는 영웅"이나, 다른 연애 소설에서 볼 수 있는 "로망스"에 살을 덧붙이기 마련입니다. 마찬가지로 객체지향 설계도 동일한 방식으로 풀 수 있습니다. "객체를 가지고 표현한다거나, 특성을 쉽게 빼고 넣을 수 있도록 객체 꾸미기"를 하는 것이죠.” - GoF의 디자인 패턴, 25~26p
•
How
1. 문제를 만났을 때 즉각적으로 몇 가지 문제 해결 방법이 떠오르는지 점검해본다. 최대한 다양하게 떠올려 본다.
2.
떠올린 문제 해결 패턴들을 나열하고 각각 얼마나 적합한지, 즉 트레이드 오프가 있는지 평가해보고 그 이유를 적어본다.
3.
이후 세부 사항은 언급하지 않고 문제 해결 패턴만 조합하여 현재 구현해야 하는 기능을 설명해본다(‘글쓰기를 통해 구현 미루기’와 유사). 그 속에서 일반적인 부분과 특수한 부분을 구분해본다.
떠오르지 않을 때는 아래와 같은 절차를 시도해봅니다.
1단계: 문제의 증상 언어화하기 (Verbalize)
•
행동: 해결책을 고민하기 전에, 지금 겪고 있는 구체적인 문제 상황을 군더더기 없이 한 문장으로 적어봅니다.
•
이유: 문제의 본질을 파악하기 위한 첫 단계는, 모호한 불안감을 구체적인 '증상'으로 명확하게 기술하는 것입니다.
•
실천 예시 (대화 기록 기반):
◦
"날짜가 뒤죽박죽인 소비 내역 리스트를, 날짜별로 묶어서 보여줘야 한다."
◦
"API 호출이 실패했을 때, 사용자가 버튼을 다시 누르지 않아도 자동으로 몇 번 더 시도하게 만들어야 한다."
2단계: 문제의 본질 '일반화'하기 (Generalize)
•
행동: 1단계에서 기술한 구체적인 '증상'을 보고, "이 문제의 진짜 이름은 무엇일까?" 라고 스스로에게 질문합니다. 내 문제의 고유한 맥락(소비 내역, API)을 제거하고, 컴퓨터 과학의 보편적인 용어로 문제를 재정의하는 것입니다.
•
이유: 이것이 바로 '생성성'의 핵심인 '추상화 근육'을 사용하는 단계입니다. 구체적인 문제에 갇혀 있으면 해결책을 '발명'해야 하지만, 일반화된 문제로 바꾸면 해결책을 '검색'할 수 있게 됩니다.
•
실천 예시 (대화 기록 기반):
◦
"날짜별로 묶어서 보여줘야 한다." → "아, 이건 그냥 '그룹핑(Grouping)' 문제구나."
◦
"실패 시 자동으로 재시도해야 한다." → "이건 '재시도 로직(Retry Logic)' 문제네."
◦
"사용자 입력이 너무 많고 복잡하다." → "이건 결국 '폼 상태 관리(Form State Management)' 문제야."
3단계: '일반해' 탐색 및 연결하기 (Explore & Connect)
•
행동: 2단계에서 도출한 일반화된 '문제의 이름(키워드)'을 가지고, 세상의 지식을 탐색합니다. (Google, GPT, Stack Overflow 등)
•
이유: '그룹핑'이라는 키워드를 아는 순간, 주니어는 더 이상 혼자가 아닙니다. 지난 수십 년간 전 세계 개발자들이 쌓아 올린 lodash.groupBy, Array.prototype.reduce, SQL GROUP BY 같은 수많은 '일반해'와 연결될 수 있습니다.
•
탐색 예시 (대화 기록 기반):
◦
검색어: javascript array grouping by key → 발견하는 일반해: lodash.groupBy, reduce 활용법
◦
검색어: react query retry → 발견하는 일반해: Tanstack Query의 retry 옵션
•
최종 연결: 탐색한 일반해를 자신의 코드 맥락에 맞게 적용합니다. 이로써 '자신에게 없던 정보'를 통해 문제를 해결하는 생성적 사이클이 완성됩니다.
핵심: 내가 사용할 수 있는 ‘패턴 북’, 즉 ‘심적 표상’이 생기는 것이 최종적인 목표입니다. 내가 실제 코드를 작성하는 상황에서 개별 로직을 작성하는게 아니라 하나의 패턴을 직관적으로 떼어다 쓸 수 있도록 공구함을 가득 채워보세요.