과도하게 생각하지 않고 기술적 문제를 분해하는 더 나은 방법

Source: Dev.to

나는 한 번은 문제를 해결하는 데 20분밖에 걸리지 않았던 해결책을 설계하는 데 삼 일을 보냈다. 생각을 멈추고 코딩을 시작했을 때 비로소 해결할 수 있었다.

문제는 간단했다: 하나의 데이터베이스 스키마에서 다른 스키마로 사용자 데이터를 마이그레이션하는 것. 하지만 마이그레이션 스크립트를 작성하는 대신, 나는 완벽한 추상화를 설계하는 데 며칠을 보냈다. 클래스 계층 구조를 그리고, 의존성 주입 패턴을 논의하고, 시스템이 어떻게 동작해야 하는지에 대한 정교한 다이어그램을 만들었다.

드디어 코딩을 시작했을 때, 전체 마이그레이션은 오류 처리를 포함한 150줄짜리 직관적인 SQL에 불과했다. 그 모든 아키텍처는 내가 실제로 필요하지 않은 문제들을 해결하고 있었다. 나는 **95 %**의 시간을 과도하게 생각하는 데, **5 %**만 실제 문제를 해결하는 데 사용했다.

이것이 기술적 사고의 저주다: 복잡성을 보는 우리의 능력이 단순함에 행동하지 못하게 만든다.

과도한 생각의 함정

엔지니어는 문제에 대해 깊이 생각하도록 훈련받는다. 우리는 엣지 케이스를 예상하고, 규모에 대비하며, 유지보수를 위해 설계한다. 이러한 스킬은 귀중하지만, 필요하지 않을 때도 작동한다면 위험하다.

모든 문제가 깊은 사고를 요구하는 것은 아니다. 어떤 문제는 진정으로 단순하다. 직관적인 해결책을 능숙하게 구현하면 된다. 그러나 우리의 패턴 매칭 본능은 모든 문제에 반응하고, 우리는 한 번 실행되는 스크립트에 대해 기업 수준의 아키텍처를 설계하게 된다.

분석 마비는 철저함으로 가장한다. 우리는 스스로를 신중하고, 엄격하며, 전문적이라고 말한다. 구현에 급하게 뛰어드는 것이 아니라 충분히 생각하고 있다고 믿는다. 하지만 종종 우리는 접근 방식을 확정짓는 것을 두려워한다. 확정은 우리가 잘못 선택했을 위험을 받아들인다는 의미이기 때문이다.

과도한 생각은 인위적인 복잡성을 만든다. 코드를 만지기 전에 문제에 대해 너무 오래 고민하면 요구사항을 스스로 만들어낸다.

• “다중 데이터베이스를 지원해야 한다면?”
• “롤백이 필요하다면?”
• “수백만 건의 레코드까지 확장해야 한다면?”

이러한 가정은 책임감 있게 보이지만, 실제로는 변명의 형태인 경우가 많다.

핵심은 더 깊게 생각하는 것이 아니라 언제 생각을 멈추고 바로 구축을 시작할지 배우는 것이다.

문제 분해의 적절한 수준

기술 문제를 나누는 것은 가능한 가장 상세한 계획을 만드는 것이 아니다. 진행을 시작할 수 있게 하는 최소한의 이해를 만드는 것이 목표다.

• 입력과 출력을 먼저 이해한다.
  먼저, 무엇이 들어오고 무엇이 나가야 하는지를 명확히 한다. 내 데이터베이스 마이그레이션 예시: 입력은 구 스키마 레코드, 출력은 신 스키마 레코드다. 그 외는 구현 세부사항이다.

• 구현이 아닌 변환을 식별한다.
  실제로 바뀌어야 하는 것은 무엇인가? 데이터 타입 변환? 필드 매핑? 검증 규칙? 무엇에 집중하고 어떻게는 코딩을 시작하면 자연스럽게 드러난다.

• 알려진 제약조건을 나열한다.
  시간 제한, 성능 요구사항, 호환성 필요 등 실제 제약조건만 적는다. 가상의 제약은 제외한다. 현재 레코드가 수백만 개가 아니라면 그 규모를 설계에 반영하지 않는다. 롤백이 요구되지 않으면 사전에 구현하지 않는다.

• 모르는 부분을 인정한다.
  엣지 케이스를 조사하는 데 시간을 낭비하기보다 “중복 레코드가 시스템에서 어떻게 처리되는지는 아직 모른다. 테스트하면서 알게 될 것이다.”라고 명시한다. 모르는 것을 아는 것은 미지의 영역을 과도하게 생각하는 것과 다르다.

• ‘완료’를 사전에 정의한다.
  성공은 어떻게 보이는가? “데이터가 손실 없이 성공적으로 마이그레이션됨”이 명확하다. “우아하고, 확장 가능하며, 미래 지향적인 솔루션”은 과도한 생각이다. 완료는 검증 가능해야지 미적 기준이 아니어야 한다.

5분 프레임워크

기술 문제를 마주하고 복잡한 계획을 세우고 싶을 때, 다음을 시도해 보라: 문제를 5분 안에 분해하고 바로 코딩을 시작한다.

1. 1분 – 실제 문제를 적는다.
   한 문장. “스키마 A에서 스키마 B로 50 k 사용자 레코드를 마이그레이션한다.” 상황이나 히스토리, 이상적인 미래 상태는 제외하고 문제 자체만 적는다.

2. 2분 – 가장 간단한 해결책을 스케치한다.
   최고의 해결책이 아니라 가장 단순한 해결책. “구 테이블에서 읽고, 각 레코드를 변환한 뒤, 신 테이블에 쓰는 스크립트를 만든다.” 이것이 기본선이며, 나머지는 최적화이다.

3. 3분 – 깨질 수 있는 요소를 나열한다.
   가상이 아닌 실제 위험. “대용량 배치 시 DB 타임아웃, 오류 시 데이터 손실, 아직 보지 못한 스키마 호환성 문제.” 이것이 테스트 케이스가 된다.

4. 4분 – 먼저 만들 것을 결정한다.
   보통은 행복 경로: “구 스키마 레코드 하나를 신 스키마로 성공적으로 마이그레이션한다.” 오류 처리나 엣지 케이스는 나중에.

5. 5분 – 코딩을 시작한다.
   진지하게. 5분의 생각이면 보통 시작하기 충분하다. 코딩 10분 동안 문제에 대해 더 많이 알게 될 것이며, 계획 2시간보다 효율적이다.

이는 무모함을 의미하지 않는다. 이해는 문제와의 상호작용을 통해 형성된다는 점을 인식하는 것이다.

빠르게 움직이게 하는 도구들

현대 AI 도구는 과도한 생각 없이 문제를 분해하는 데 탁월하다—올바르게 사용한다면.

• 문제 분해를 검증한다.
  접근 방식을 AI에 설명하고 blind spot을 물어본다. AI Debate Bot은 가정에 도전하고 놓친 이슈를 몇 초 안에 알려준다.

• 먼저 간단한 솔루션을 생성하고, 나중에 최적화한다.
  Crompt AI 같은 도구로 직관적인 구현을 빠르게 만들고, 동작을 확인한 뒤 최적화 여부를 판단한다.

• 엣지 케이스를 깊게 파고들지 않고 탐색한다.
  AI에게 가능한 실패 모드를 열거하게 한다. AI Fact‑Checker 는 가정을 빠르게 검증해 주어 분석에서 구현으로 전환을 가속한다.

• 복잡한 문제를 작은 조각으로 나눈다.
  Task Prioritizer 는 큰 기술 과제를 순서가 있는 단계로 분해해, 압도적인 문제를 관리 가능한 조각으로 만든다.

• 과도한 문서화 없이 사고를 기록한다.
  Content Writer 를 사용해 문제 분해와 접근 방식을 신속히 기록하고, 완벽주의에 빠지지 않으면서도 책임성을 확보한다.

핵심은 AI를 이해를 가속화하는 도구로 쓰는 것이지, 이해를 회피하는 도구로 쓰는 것이 아니다. 코드를 생성하되 그 코드가 무엇을 하는지 이해하고, 대안을 요청한 뒤 하나를 선택한다. 도구는 더 빨리 생각하게 하고, 더 오래 생각하게 하는 것이 아니다.

당신이 과도하게 생각하고 있다는 신호

분석이 도움이 되는 수준을 넘어 해를 끼치기 시작했을 때를 인식하라:

• 문제 해결보다 용어 논쟁에 더 많은 시간을 쏟는다.
  “서비스”와 “핸들러” 중 어느 것이 맞는지 20분을 논쟁한다면 과도한 생각이다. 하나를 정하고 진행한다.

• 가지고 있지 않은 규모에 맞춰 설계한다.
  현재 일일 요청이 100건인데 1,000만 건을 목표로 아키텍처를 짠다면 잘못된 문제를 풀고 있는 것이다. 오늘의 규모에 맞추고 내일을 대비한다.

• 코드보다 다이어그램이 더 많다.
  시각적 계획은 유용하지만, 다이어그램이 구현보다 복잡하다면 우선순위가 뒤바뀐 것이다.

• ‘무엇이’보다 ‘무엇이면’을 더 많이 묻는다.
  가상의 요구는 무한하고, 실제 요구는 유한하다. 지금 필요한 것을 집중하고, 언젠가 필요할지도 모를 것을 미리 고민하지 않는다.

• 방해받을 때 안도감을 느낀다.
  회의가 당신의 문제 분석을 중단시킬 때 비밀스럽게 기뻐한다면, 그것은 비생산적인 과도한 생각에 빠졌다는 뇌의 신호다.