아무도 가르쳐주지 않는 프로그래밍 원칙

한국어العربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語PortuguêsРусский中文
TThe Coding Koala
Computing/SoftwareManagement

Transcript

00:00:00왜 어떤 사람들은 수년간 이 분야에 종사했음에도
00:00:04개발자로서 성장하지 못하는 걸까요? 여러 가지 요인이 있습니다. 그중 하나는
00:00:09프로그래밍의 근본 원리를 이해하지 못하기 때문입니다. 이건 단순히 한 번 배우고
00:00:14잊어버리는 이론적 개념이 아닙니다. 여러분을 더 빠르게 성장시켜 줄 실제적인 내용들이죠.
00:00:19첫 번째 원칙인 보이스카우트 규칙부터 시작해 보죠. 이 원칙은 미국의 보이스카우트에서 유래했습니다.
00:00:25그들에게는 '캠프장을 발견했을 때보다 더 깨끗하게 정리하고 떠나라'는 간단한 규칙이 있습니다.
00:00:31엉클 밥(Uncle Bob)을 아시는 분이 얼마나 계실지 모르겠지만, 이 개념을
00:00:36프로그래밍 커뮤니티에 널리 알린 분입니다. 코드를 처음 발견했을 때보다 약간 더 깨끗하게 만드는 습관이죠.
00:00:41기존 코드베이스를 수정할 때 코드 품질은 종종 저하되며, 이는
00:00:47기술 부채를 증가시킬 수 있습니다. 그리고 기술 부채는 아무리 사소하더라도
00:00:52지속적인 개선을 통해 줄일 수 있습니다. 예를 들어, 이 함수에서
00:00:57값을 변경하라는 작업을 할당받았다고 가정해 봅시다. 작업을 마쳤는데 변수명이 이해하기
00:01:03어렵다는 걸 알게 됩니다. 대부분의 개발자처럼 그냥 무시하고 작업을 커밋할 수도 있겠죠.
00:01:08하지만 이 원칙을 따른다면, 변수명을 더 이해하기 쉬운 이름으로
00:01:12바꿨을 것입니다. 이건 아주 간단한 예시일 뿐입니다. 변수명뿐만 아니라 개선할 수 있는
00:01:18부분이 보인다면 그냥 고치세요. 이런 작은 행동 하나가 코드베이스에 큰 가치를 더합니다.
00:01:24두 번째 원칙, 성급한 최적화를 피하라입니다. 이 말은 코드가
00:01:30정말로 빨라져야 할 상황이 오기 전에 미리 최적화하지 말라는 뜻입니다. 일단 작동하게 만드세요. 필요할 때만 최적화하면 됩니다.
00:01:36도널드 커누스(Donald Knuth)의 유명한 명언 중에 "성급한 최적화는 모든 악의 근원이다"라는 말이 있습니다.
00:01:42정말 맞는 말입니다. 프로그래머들은 프로그램의 중요하지 않은 부분의 속도를 고민하느라
00:01:47시간을 허비하곤 하니까요. 뭐든지 최적화해야 한다는 강박 때문이죠.
00:01:51이 원칙은 코드베이스를 최적화하지 말라는 뜻이 아닙니다. 무엇을 최적화해야 할지,
00:01:57그리고 가장 중요한 것은 언제 최적화해야 할지를 이해하라는 뜻입니다. 저는 이게
00:02:03대다수 개발자의 약점이라고 생각합니다. 사용자가 100명뿐인데도 마이크로서비스를 도입하거나,
00:02:08전혀 필요 없는 기능에 캐싱을 추가하는 경우를 많이 봤거든요. 세 번째 원칙,
00:02:14유지보수 담당자를 위해 코드를 작성하라입니다. 이는 코드를 작성할 때 미래의 담당자가
00:02:19코드를 관리하고 이해하는 데 어려움을 겪지 않도록
00:02:23작성해야 한다는 의미입니다. 오늘 여러분이 쓴 코드는 다른 개발자나
00:02:29미래의 여러분 자신이 유지보수하게 될 테니까요. 당장 작동하는 것에만 급급해서 명확성을 놓치면,
00:02:35나중에 코드를 다시 봤을 때 무슨 일이 일어나고 있는지 파악하기 힘들 겁니다. 이 예시를 보세요.
00:02:39둘 다 똑같이 작동하고 같은 기능을 수행합니다. 하지만 여러분의 코드베이스에는 어떤 코드가 있길 원하시나요?
00:02:45그러니 결론은, 스스로 코드를 작성하거나 AI로 코드를 생성할 때
00:02:50커밋하기 전에 항상 이해하기 쉽고 유지보수가 가능한지 확인하라는 것입니다.
00:02:55네 번째 원칙은 YAGNI입니다. "You Aren't Gonna Need It(당신은 그것을 필요로 하지 않을 것이다)"의 약자죠.
00:03:01이 원칙은 단순히 미래에 필요할지도 모른다는 이유만으로
00:03:06지금 당장 필요 없는 것을 만들지 말라는 뜻입니다. 대부분의 개발자는 미래에
00:03:10필요할 것을 예측하는 습관이 있습니다. 하지만 대부분의 경우 실제로 사용되지 않고 프로젝트에
00:03:16복잡성만 더할 뿐입니다. 항상 기억하세요. 미래에 필요할지도 모르는 일에 시간을 쏟는 것은
00:03:21지금 당장 필요한 것에 집중하지 못하게 만듭니다. 다섯 번째 원칙, 작동하는 가장 단순한 것을 하라입니다.
00:03:27이는 문제에 직면했을 때 언제나 실제로 작동하는 가장 단순한
00:03:32해결책을 선택하라는 의미입니다. 너무 깊게 생각하거나 과도하게 설계하지 마세요. 그저 스스로에게
00:03:38지금 당장 이 문제를 해결할 수 있는 가장 단순한 방법이 무엇인지 물어보세요. 이 아이디어는 익스트림 프로그래밍에서
00:03:43나왔는데, 일단 간단하게 만들고 나서 더 나은 방식으로 리팩터링하라고 가르칩니다.
00:03:48대부분의 개발자는 처음부터 완벽한 해결책을 구축하려고 하지만,
00:03:53결국 해결책을 지나치게 복잡하게 만들 뿐입니다. 이 원칙을 따르면
00:03:59더 빨리 작동하는 코드를 얻을 수 있고, 나중에 수정하더라도 잘못된 복잡한 설계를
00:04:04수정하는 것보다 훨씬 쉽습니다. 믿으세요. 개발자로서 자신이 과도하게 설계하고 있다는 것을 깨닫는 것은
00:04:10매우 중요합니다. 자, 여기까지가 바로 실천해야 할
00:04:14다섯 가지 프로그래밍 원칙이었습니다. 이 외에도 제가 이 영상에서 다루지 않은
00:04:19다른 원칙들도 많습니다. 도움이 되셨다면 댓글로 알려주세요. 2편을 만들어 보겠습니다.
00:04:24오늘은 여기까지 하겠습니다. 많은 응원 부탁드리고, 다음 영상에서 뵙겠습니다.

Key Takeaway

성급한 설계나 최적화 대신 보이스카우트 규칙과 YAGNI 원칙을 준수하며 가장 단순한 형태의 코드를 유지하는 것이 장기적인 개발 성장의 핵심이다.

Highlights

  • 보이스카우트 규칙에 따라 기존 코드베이스를 수정할 때마다 원래보다 조금 더 깨끗하게 정리하면 기술 부채를 방지할 수 있다.

  • 성급한 최적화는 프로그램의 중요하지 않은 부분에 시간을 허비하게 만들어 모든 악의 근원이 된다.

  • 코드를 작성할 때 미래의 유지보수 담당자가 이해하기 쉽도록 명확성을 최우선으로 고려해야 한다.

  • YAGNI(You Aren't Gonna Need It) 원칙은 미래에 필요할지도 모른다는 이유로 지금 당장 불필요한 기능을 구현하는 것을 금지한다.

  • 익스트림 프로그래밍에 기반하여 가장 단순한 해결책으로 먼저 작동하게 만든 뒤 점진적으로 리팩터링하는 방식이 효과적이다.

Timeline

보이스카우트 규칙과 기술 부채

  • 코드를 수정할 때마다 기존 상태보다 조금 더 깨끗하게 만드는 습관이 필요하다.
  • 기술 부채는 사소한 수정이라도 지속적으로 개선하면 줄일 수 있다.

보이스카우트의 캠프장 정리 규칙을 프로그래밍에 적용하여 코드 품질을 관리한다. 단순히 작업만 끝내는 것이 아니라 변수명 개선 등 작은 부분이라도 더 읽기 쉽게 수정하면 코드베이스에 가치가 더해진다.

성급한 최적화 지양

  • 코드가 실제로 성능 개선을 필요로 하는 상황이 오기 전까지는 최적화하지 않는다.
  • 불필요한 기능에 마이크로서비스나 캐싱을 도입하는 것은 대다수 개발자의 흔한 약점이다.

도널드 커누스의 견해처럼 성급한 최적화는 불필요한 작업에 시간을 낭비하게 만든다. 최적화 기술 자체를 배격하는 것이 아니라, 무엇을 언제 최적화해야 할지 결정하는 판단력이 중요하다.

유지보수와 명확성

  • 오늘 작성한 코드는 미래의 자신이나 동료 개발자가 관리하게 된다.
  • 작동 여부만큼 코드의 가독성과 유지보수 가능성을 확인하는 과정이 필수적이다.

당장의 기능 구현에만 매몰되면 나중에 코드를 다시 파악하기 어렵다. AI가 생성한 코드든 직접 작성한 코드든 커밋 전에 유지보수가 가능한 상태인지 반드시 점검해야 한다.

YAGNI 원칙과 단순성 유지

  • YAGNI는 미래의 필요를 예측하여 미리 기능을 만들지 말라는 원칙이다.
  • 문제 해결 시 과도한 설계보다는 가장 단순한 방법을 선택하는 것이 리팩터링에도 유리하다.

대부분의 경우 미래를 위한 준비는 프로젝트의 복잡성만 높일 뿐 실제로 사용되지 않는다. 익스트림 프로그래밍의 원칙에 따라 가장 단순한 해결책으로 일단 작동하게 만든 뒤, 필요한 경우 더 나은 방식으로 발전시키는 것이 효율적이다.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video