SingleFocus

주니어 개발자들을 위한 패턴 언어 - 혼란을 방지하고 작업의 완결성을 높이는 일인(一人) 집중의 기술

The Story: The Multi-Tasking Chaos vs. The Laser Focus

두 명의 개발자, 민수와 하나가 '버그 수정과 기능 개선' 작업을 동시에 진행하고 있다.

민수의 작업 방식 (The Juggler): 민수는 의욕이 넘친다. 버그를 잡으려고 코드를 열었다가, 근처에 있는 지저분한 코드를 발견하고 리팩토링을 시작했다. 그러다 갑자기 새로운 기능 아이디어가 떠올라 그 부분도 건드렸다. "이것도 고치고 저것도 고치면 금방 끝나겠지?" 1시간 후, 민수의 화면에는 10개의 파일이 열려 있고, 수많은 수정 사항이 뒤섞여 있었다. 테스트는 빨간색이었고, 민수는 자신이 처음에 어떤 버그를 잡으려 했는지조차 잊어버렸다. 그는 결국 모든 변경 사항을 되돌려야 했다.

하나의 작업 방식 (The Laser): 하나는 철저히 한 번에 하나만 한다.

1. 먼저 버그만 잡는다. (수정 완료 -> 테스트 통과 -> 커밋)

2. 그 다음, 리팩토링을 한다. (수정 완료 -> 테스트 통과 -> 커밋)

3. 마지막으로 새로운 기능을 추가한다.

하나는 각 작업 사이에 명확한 경계선을 그었다. 작업이 바뀔 때마다 뇌를 비우고 다시 집중했다. 하나는 민수보다 느려 보였지만, 단 한 번의 실수도 없이 모든 작업을 마쳤다.

Context

여러 가지 할 일이 쌓여 있다. 버그도 잡아야 하고, 코드도 정리해야 하며, 새로운 기능도 구현해야 한다. DetectiveWork 중이거나 BabySteps를 밟고 있는 상황이다.

일상적인 상황:

• 버그를 잡다가 "이 김에 이것도 고치자"며 다른 코드를 건드린다.
• 수정 사항이 너무 많아져서 무엇 때문에 테스트가 깨졌는지 알 수 없다.
• 여러 가지 일을 동시에 하느라 머릿속이 복잡하고 피곤하다.
• 작업 중간에 중단되었을 때, 어디까지 했는지 기억하기 힘들다.

당신은 지금 여러 마리의 토끼를 동시에 쫓느라 한 마리도 잡지 못하고 있다.

Problem

동시에 여러 목표를 추구하면 컨텍스트 스위칭 비용이 발생하고, 작업의 인과관계가 꼬여버린다.

• 원인 파악 불가: 버그 수정과 리팩토링을 섞으면, 시스템이 망가졌을 때 무엇이 범인인지 알 수 없다.

• 정신적 에너지 고갈: 뇌는 한 번에 하나의 복잡한 문제만 처리하도록 설계되어 있다. 멀티태스킹은 뇌를 빠르게 지치게 한다.

• 완결성 부족: 이것저것 건드리다 보니, 어느 하나도 완벽하게 마무리되지 않은 "작업 중"인 상태만 늘어난다.

Solution

한 번에 정확히 한 가지 목표만 설정하고, 그 일이 완전히 끝날 때까지 다른 유혹을 차단하라.

작업의 리듬을 "하나씩, 확실하게" 가져가는 것이 가장 빠른 길이다.

Principle 1: Separate "Red" and "Green" (빨강과 초록의 분리)

버그를 잡는 일(Red -> Green)과 코드를 정리하는 일(Green -> Green)을 절대로 섞지 마라.

• 리팩토링은 반드시 테스트가 통과하는 상태에서만 시작하라.
• 버그를 잡는 동안에는 코드 정리에 대한 유혹을 메모장에 적어두고 무시하라.

Principle 2: Finish Before Moving On (마침표 찍기)

한 가지 작업이 끝나면 반드시 AtomicCommit을 하거나 최소한 테스트 통과를 확인하라.

• "거의 다 됐는데"라는 상태에서 다른 일을 시작하지 마라.
• 마침표를 찍어야 뇌의 워킹 메모리(Working Memory)가 비워지고 다음 일에 집중할 수 있다.

Principle 3: Make a Small To-Do List (작은 할 일 목록)

작업 중에 떠오르는 다른 생각들은 즉시 포스트잇이나 텍스트 파일에 적어라.

• "오타 발견함", "변수명 바꿔야 함" 등을 적어두면, 지금 하던 일을 멈추지 않고도 나중에 그 일을 할 수 있다는 안도감이 생긴다.

Principle 4: Deep Debugging (심층 디버깅 시의 집중)

DetectiveWork 중일 때는 오직 '증거 수집'과 '가설 검증'에만 집중하라.

• 원인을 찾기도 전에 코드를 예쁘게 고치려 하지 마라. 범인을 잡는 것이 우선이다.

Real Examples

Example 1: The Refactoring Trap

버그를 수정하려고 클래스를 열었는데, 메서드들이 너무 길어서 읽기 힘들다.

• Bad: 메서드를 쪼개고 이름을 바꾸면서 동시에 버그를 고친다. (실패 시 원인 파악 지옥)

• Good: 일단 지저분한 상태 그대로 버그를 고친다. 테스트가 통과하면, 그때 깨끗하게 쪼갠다.

Example 2: The "By the way" Fix

UI 레이아웃을 고치다가 API 호출 로직의 비효율을 발견했다.

• Good: "API 최적화"라고 메모를 남긴다. 하던 레이아웃 수정을 먼저 끝내고 커밋한다. 그 다음 메모를 보고 API를 고친다.

Common Pitfalls

"It's just a small change!" (잠깐이면 되는데!)

오타 하나 고치는 것도 컨텍스트를 깨뜨릴 수 있다. 지금 하던 일의 흐름이 정말 중요하다면 그 작은 수정조차 미뤄라.

Feeling Slow (느리게 느껴짐)

한 번에 하나씩 하면 느린 것 같아 불안할 수 있다. 하지만 "다시 하는 시간"과 "디버깅하는 시간"을 합치면 훨씬 빠르다는 것을 기억하라.

Losing Track (기억 상실)

적어두지 않으면 잊어버릴까 봐 지금 바로 하려고 한다. 그래서 메모가 중요하다.

Connection to Other Patterns

• AtomicCommit - SingleFocus의 결과물은 항상 깨끗한 원자적 커밋이 된다. 결과

• BabySteps - SingleFocus는 BabySteps를 밟기 위한 마음가짐이다. 태도

• DetectiveWork - 수사 과정에서 집중력이 흐트러지면 범인을 놓친다. 수사 원칙

• TightLoop - 한 가지에만 집중할 때 피드백 루프는 가장 빠르게 회전한다. 효과

Signs of Success

• 작업 중에 "내가 지금 뭐 하려고 했지?"라고 묻는 일이 사라진다.
• 각 커밋 메시지가 명확하고 간결해진다.
• 예기치 못한 에러가 발생했을 때, 방금 바꾼 "단 한 가지"가 원인임을 즉시 알 수 있다.
• 퇴근할 때 "찜찜하게 남겨진 일" 없이 기분 좋게 마무리한다.

The Ultimate Insight

집중력은 유한한 자원이다. 렌즈를 하나에 맞출 때 비로소 불꽃이 일어난다.

멀티태스킹은 뇌를 속이는 환상일 뿐이다. 진정한 속도는 가장 중요한 한 가지를 끝까지 밀어붙여 완결 짓는 데서 나온다. 하나만 하라. 그리고 제대로 하라.

CategoryPatternLanguage CategoryProgramming CategoryMindset CategoryAgile