Feynman 알고리즘: ‘매우 열심히 생각하기’를 위한 개발자 가이드

Source: Dev.to

The Feynman Algorithm

리처드 파인만의 방법을 검색하면, 아이에게 설명하듯 새로운 개념을 배우는 프레임워크인 유명한 Feynman Technique을 만나게 될 것입니다.
하지만 그의 동료 머레이 겔‑만이 농담처럼 만든, 덜 알려진 파인만 방법도 있습니다. 겔‑만은 파인만의 문제 해결 과정이 다음과 같다고 했습니다:

1. 문제를 적는다.
2. 매우 열심히 생각한다.
3. 해결책을 적는다.

언뜻 보면 밈처럼 보이지만, 실제로는 디버깅과 소프트웨어 작성의 전체 흐름을 설명합니다.

“문제를 해결할 시간이 한 시간 있다면, 나는 문제에 대해 55분을 생각하고 해결책에 대해 5분을 생각한다.” – 알베르트 아인슈타인

프로그래밍에서는 생각하는 단계를 자주 건너뛰곤 합니다. 오류 로그를 보고 바로 변수 값을 바꾸고 브라우저를 새로 고칩니다. “문제를 적는다”는 정확히 무엇이 잘못됐는지를 정의하도록 강제합니다.

Bad vs. Good Problem Definition

• Bad: “로그인 페이지가 깨졌다.”
• Good: “재방문 사용자가 Google OAuth로 로그인하려 할 때, API가 모바일 Safari에서만 500 서버 오류를 반환한다.”

문제를 명확히 적으면 범위가 좁혀집니다. 절반 정도는 문제를 정확히 정의하는 것만으로도 해결책이 드러납니다.

How Developers “Think Very Hard”

• Rubber Duck Debugging: 코드를 한 줄씩 무생물(또는 인내심 있는 동료)에게 설명한다.
• Isolate: 코드 조각을 주석 처리해 버그가 여전히 발생하는지 확인하면서 변수를 좁혀간다.
• Step Away: 샤워를 하거나 산책을 한다. 뇌의 “확산 모드”가 배경에서 문제를 계속 처리한다.
• Resist Quick Fixes: 왜 작동하는지 이해하지 못한 채 첫 번째 Stack Overflow 답변을 그대로 복사‑붙여넣지 않는다.

Writing the Solution

코딩 맥락에서 “해결책을 적는다”는 세 가지를 의미합니다:

1. 깨끗한 코드 작성 – 해결책이 얕은 해법이 아니라 읽기 쉽고 유지보수가 가능한 로직인지 확인한다.
2. 테스트 작성 – 해결책이 실제로 동작함을 증명하고 향후 회귀를 방지한다.
3. 문서화 작성 – 왜 그렇게 했는지 설명하는 주석을 남긴다.

// Using a Set here instead of an Array because checking for duplicates
// was causing a massive performance bottleneck.

미래의 자신(그리고 팀)에게 이런 주석은 큰 도움이 될 것입니다.

Conclusion

Feynman Algorithm은 노벨상 수상 물리학자들 사이에서 농담으로 시작됐지만, 소프트웨어 엔지니어에게는 놀라울 정도로 실용적입니다. 다음에 까다로운 버그에 부딪혔을 때는 키보드를 무작정 두드리지 마세요:

1. 멈추고, 문제를 적는다.
2. 산책을 하며 매우 열심히 생각한다.
3. 문제를 해결하면, 해결책을 문서화한다.

이와 같은 disciplined(규율 있는) 접근 방식을 채택하면 답답한 디버깅 세션을 구조화되고 반복 가능한 성공으로 바꿀 수 있습니다.