모든 문제의 시작: “내가 지금 뭘 하고 있었지?”
<짤>
코드 작성 중에 문득 이런 생각이 들 때가 있습니다. 방금 전까지 무언가를 하고 있었는데, 어느새 다른 코드를 만지고 있거나, 수많은 브라우저 탭을 방황하고 있는 자신을 발견합니다.
그럴 때 가장 먼저 점검해볼 것은 ‘한번에 하나씩’ 하고 있는지 여부입니다.
많은 개발자들이 목표 의식 없이 일단 코드부터 작성합니다. 지금 내가 무엇을 완성하려고 시간을 쓰고 있는지 명확히 하지 않으면, 길을 잃은 채 예정된 어려움에 빠져들게 됩니다.
이것은 의지나 집중력의 문제가 아닙니다. 우리 뇌의 '작업 기억 용량'이 한정되어 있기 때문에 발생하는 자연스러운 '인지 과부하(Cognitive Overload)' 현상입니다. 그리고 이 머릿속의 혼돈은 코드에 그대로 흔적을 남깁니다.
•
불확실한 상태를 감당하지 못해 수많은 if 분기문으로 모든 경우의 수를 방어하려 하고,
•
잦은 맥락 전환은 타입 안정성을 무너뜨리고 예기치 못한 런타임 에러를 유발하며,
•
거대한 문제를 작게 '분할 정복'하지 못해 어디서부터 손대야 할지 모르는 막막함에 빠집니다.
결국, 우리는 '정신없이' 코드를 짜는 것이 아니라, '정신없는 코드'를 양산하게 됩니다. 이 고질적인 문제의 고리를 끊어내는 것이 우리의 첫 번째 훈련 목표입니다.
정신을 차리고(mindful) 목표를 명확히 해보는 게 중요한 또 다른 이유는 목표 없이는 잘 되고 잘못된 것이 없습니다. 평가가 없으므로 이터레이션 사이에 학습도 일어나지 않습니다.
내가 하고 있는 지금 당장의 일 딱 하나에만 집중해야 합니다. 의외로 조급함을 버리고 멀티 태스킹을 하지 않는게 좋은 코드를 작성하기 위해 가장 중요하고 즉각적인 효과를 냅니다.
목표는 작게, 안전영역을 늘리기
<짤>
인지 과부하를 극복하는 가장 강력한 전략은 '한번에 하나씩만' 하는 것입니다. 우리는 이 단순한 원칙을 체계적인 리듬으로 만들기 위해, TDD(테스트 주도 개발)의 핵심 감각을 빌려옵니다.
바로 Red → Green → Refactor 사이클입니다.
TDD 리듬, 간단히 이해하기
TDD를 몰라도 괜찮습니다. 이 리듬의 핵심만 빌려오는 것입니다.
•
Red (일부러 넘어지기): 먼저 '이것만 되면 성공'이라는 아주 작은 목표를 세우고, 일부러 실패하는 상태를 만듭니다. (예: 아직 만들지 않은 함수를 호출하는 테스트 코드 작성)•
Green (일단 일어나기): 어떻게든 그 목표를 달성시켜, 다시 '안전한(성공하는)' 상태로 돌아옵니다. 코드가 비효율적이거나 지저분해도 괜찮습니다.•
Refactor (자세 바로잡기): 이제 안전지대에 왔으니, 안심하고 코드의 구조를 개선합니다.이 리듬을 따르면, 우리는 항상 Green이라는 안전지대에서 다음 탐험을 시작할 수 있습니다.
한번에 달성할 목표는 작게 잡습니다. 한 번에 달성할 목표가 작기 때문에 실패의 두려움이 줄고, 매 사이클마다 학습하고 개선할 기회가 생깁니다. 불확실성으로 가득했던 거대한 동굴이, 하나씩 불을 밝혀나가는 수많은 작은 방으로 바뀌는 것입니다.
불확실성으로 가득했던 거대한 동굴을 탐험하는 대신, 매 사이클마다 안전한 랜턴(Green)을 하나씩 놓으며 전진하는 것과 같습니다. 전체 작업에서 불확실한 부분은 작아지고, 확실한 부분은 늘어납니다. 작게 나눌 수록 집중하기 좋고, 실패하더라도 손실이 적습니다.
이 작은 성공의 이터레이션을 반복하는 사이사이에 다음 사이클에 더 잘하기 위한 방법을 회고합니다. 조금씩 거듭하며 상승 곡선을 그립니다.
-
최종적으로는 아래와 같은 방식으로 진행합니다.
•
내가 최대 10분 동안 뭐할건지 선언한 뒤 타이머 세팅하고
•
그 시간 안에 딱 그거 하나만 해보고
•
끝나고 나면 이번 10분 어땠는지 회고 하고
•
다음 10분 뭐 해볼지 생각하고 다음 이터레이션을 진행함
1. RGR 하기, 한 번에 하나만
(Red → Green → Refactor, TDD의 감각)
<짤>
•
Why
◦
Red, Green, Refactor 상태를 명시적으로 태깅하면 컨텍스트 전환이 뚜렷해져 집중력이 유지된다.
◦
인간의 작업 기억 용량은 5±2개로 제한되어 있어, 여러 작업을 동시에 처리하려 하면 인지 과부하가 발생한다.
◦
Green 지점을 자주 만들면 쉽게 안전 지점으로 롤백이 가능하다. 불확실성이 높은 상황에서 점차 확실한 부분을 넓혀갈 수 있다.
•
How
곧바로 최종 버전으로 연습해보셔도 좋습니다. 만약 한번에 하기 어려우면 단계적으로 훈련 난이도를 높이며 접근해봅니다.
level 1 - 시간 감각
level 2 - 신호 감지 훈련 (멈춤 트리거 리스트)
level 3 - 실전 동굴 탐험 (목적 있는 탐험가)
2. 한 번에 하나만 Advanced
'10분 동굴 탐험'은 복잡성을 다루는 가장 기초적인 체력입니다. 이 기초 체력이 단단해졌다면, 이제 '한번에 하나씩'이라는 원칙을 더 높은 차원에서 활용하여 문제 해결의 각 단계(디버깅, 코딩, 설계)에 적용해 볼 차례입니다.
2-1. 디버깅: 단 하나의 가설에 집중하기
<짤>
버그가 발생했을 때, 우리는 종종 "이것도 문제 같고, 저것도 문제 같아"라는 생각에 여러 곳의 코드를 동시에 수정하며 '무지성 로그 / 수정 토끼굴'에 빠집니다.
이는 우리의 뇌가 가진 작업 기억 용량의 한계를 무시한 채, 한 번에 여러 개를 처리하려는 대표적인 함정입니다.
'한번에 하나씩' 원칙을 디버깅에 적용하는 것은, '단 하나의 가설'을 세우고 그것만을 검증하는 것입니다. '감'에 의존하는 대신, 아래 예시와 같이 체계적인 프로토콜을 따라 문제를 해결하는 훈련을 합니다.
1. 현상: "장바구니에 상품을 추가하는 '담기' 버튼을 클릭해도 아무런 반응이 없다. 개발자 도구 콘솔에 에러도 보이지 않는다."
2. 가능한 가설 수립: 가장 유력한 원인부터 순서대로, 여러 가능성을 나열해 봅니다.
•
가설 1: 컴포넌트의 onClick 이벤트 핸들러(handleAddToCart)가 아예 호출되지 않고 있다.
•
가설 2: 핸들러는 호출되지만, 내부의 addToCart API 호출 로직이 실패하고 있다 (하지만 에러 처리가 없어 조용히 실패 중이다).
•
가설 3: API 호출은 성공했지만, 리액트 상태(state)가 업데이트되지 않아 UI에 반영되지 않고 있다.
3. 첫 번째 가설 검증: 가장 먼저 확인할 것은 "사용자의 클릭이 코드에 닿기는 하는가?"입니다. 가설 1을 먼저 검증해봅니다.
•
검증 계획: handleAddToCart 함수의 가장 첫 줄에 console.log를 찍어, 함수가 호출되는지 확인한다.
•
결과 확인: 버튼을 다시 클릭했으나, 개발자 도구 콘솔에 로그가 나타나지 않았다.
4. 결론: 가설 1("핸들러가 호출되지 않고 있다")이 사실로 확인되었다. 이제 문제는 '왜 이벤트 핸들러가 연결되지 않았는가?'로 좁혀졌다.
5. 다음 스텝: JSX 코드에서 Button 컴포넌트에 onClick={handleAddToCart} props가 제대로 전달되었는지, 혹은 컴포넌트 이름에 오타가 있는지 등을 확인할 것이다.
가설을 세웠다면, 다른 부분은 일절 건드리지 않고 오직 그 가설 하나만을 확인하는 코드를 추가하거나 디버거를 사용합니다.
가설이 맞든 틀리든, 우리는 한 사이클에 딱 하나의 명확한 사실을 배우게 됩니다. 이 작은 사실들이 모여 거대한 문제의 윤곽을 드러냅니다.
2-2. 코드 레벨 예시: 불확실성을 입구에서 차단하기
<짤>
'한번에 하나씩' 원칙을 코드 레벨에서 구현하는 것은, '예측 불가능성'을 한 곳에 격리하고 나머지 코드는 오직 '하나의 시나리오'에만 집중하도록 만드는 것입니다.
우리는 수많은 if문에 딸린 조건문을 사용해 방어적으로 코딩하는 대신, 아래와 같은 패턴을 통해 불확실성을 입구에서부터 원천 차단하는 훈련을 합니다.
패턴 1: Parse, Don't Validate - 입력단의 불확실성 제거
패턴 2: 데이터/계산/액션 분리 - 실행 시점의 불확실성 제거
패턴 3: Discriminated Union - 흩어진 상태를 하나의 타입으로 통합하기
이 세 가지 패턴의 공통점은 명확합니다. 다루기 힘든 '불확실성'을 한 곳에 격리하여, 우리가 한 번에 딱 하나, 즉 '예측 가능한 핵심 로직'에만 집중할 수 있는 환경을 만드는 것입니다.
이를 통해 우리는 더 이상 수많은 예외 상황을 동시에 걱정할 필요 없이, 오직 핵심 비즈니스 로직이라는 단 하나에만 집중할 수 있게 됩니다.
3. 진보적 심화: 숲과 나무를 함께 보기
<짤>
전문가들은 자신이 자주 접하지 않았던 문제, 혹은 잘 정의되지 않은 문제를 접하면 접근법을 바꾼다. 탑다운과 바텀업을 섞어 쓴다. 뛰어난 전문가일수록 더욱 그러하다. (...) 비전문가는 자기의 문제 풀이 전략을 상황에 맞게 능동적으로 선택하거나 변경하지 못한다.
- 김창준 <함께 자라기>
"이번 일은 복잡하고 불확실하니까, 더 철저하게 계획하고 단계적으로 접근하자!"
우리는 종종 이런 결심을 합니다. 불확실성이 클수록 더 완벽한 '하향식(Top-down)' 설계를 추구하는 것이죠. 하지만 놀랍게도, 연구에 따르면 이는 전문가가 아닌 초심자의 접근 방식에 더 가깝습니다.
'한번에 하나씩' 원칙의 가장 높은 단계는, 부분에 집중하는 능력(Zoom-in)과 전체 구조를 조망하는 능력(Zoom-out)을 끊임없이 오가는 것입니다. 잘 만들어진 수많은 나무(부분)들이 모여 조화로운 숲(전체)을 이루는지 확인하는 과정이기도 합니다.
마치 엘리베이터를 타고 건물의 각 층(부분)을 세밀하게 살피다가도, 주기적으로 1층 로비(전체)로 돌아와 전체 구조도를 확인하는 것과 같습니다.
•
컴포넌트를 설계할 때(Zoom-in): 우리는 하나의 컴포넌트가 단 하나의 책임만 갖도록 집중하여 만듭니다.
•
동시에(Zoom-out): "이 컴포넌트의 API(props)는 페이지 전체의 상태 관리 로직과 어떻게 맞물리는가?"를 끊임없이 질문하며 전체 구조 속에서의 위치를 조망해야 합니다.
진짜 전문가는 깔끔하게 정리된 길을 한 방향으로만 걷지 않습니다.
그들은 원칙(숲)에서 출발해 구체적인 코드(나무)를 만져보고, 다시 나무에서 얻은 통찰을 가지고 숲 전체의 지도를 수정하는, 즉 추상과 구상을 끊임없이 오가는 유연한 사고를 합니다.
상호 참조 전략: 구체와 추상을 오가기
진보적 심화: 어떻게 두 세계를 오가는가
눈 앞의 코드 한 줄(구체/부분)에 집중하면서도, 주기적으로 전체 설계도(추상/전체)를 다시 조망하며 끊임없이 되묻는 감각. ‘한번에 하나씩’은 바로 이 전문가의 사고 리듬을 훈련하기 위해 설계되었습니다.
갤러리 보기
Search
