메뉴 여닫기
개인 메뉴 토글
로그인하지 않음
만약 지금 편집한다면 당신의 IP 주소가 공개될 수 있습니다.

리누즈 토발즈 개발방법

데브카페

리누스 토발즈(Linus Torvalds)는 리눅스(Linux) 운영체제와 깃(Git)을 만든 전설적인 개발자입니다. 그의 개발 방식은 단순한 코딩 기술을 넘어, 거대한 소프트웨어를 수천 명의 사람들과 함께 고장 나지 않게 만드는 철학에 가깝습니다.

그의 강연, 인터뷰, 이메일 논쟁 등을 통해 알려진 핵심 개발 노하우 7가지를 정리해 드립니다.

1. 코드의 '좋은 취향(Good Taste)'과 데이터 구조 중시

토발즈가 개발자를 평가할 때 가장 중요하게 보는 것은 **'좋은 취향'**입니다. 이는 복잡한 예외 상황(Edge Case)을 if-else 문으로 덕지덕지 막는 것이 아니라, 데이터 구조를 잘 설계해서 예외 상황 자체가 발생하지 않도록 만드는 능력입니다.

명언: "나쁜 프로그래머는 코드를 걱정하지만, 좋은 프로그래머는 데이터 구조와 그 관계를 걱정한다." 노하우: 코드가 너무 복잡해진다면 알고리즘을 고치려 하지 말고, 데이터를 담는 그릇(구조체, 클래스 등)을 처음부터 다시 설계하세요. 좋은 데이터 구조가 나오면 코드는 저절로 단순해집니다. 2. "말은 쉽지, 코드를 보여줘 (Talk is cheap. Show me the code.)"

그는 끝없는 회의, 완벽한 사전 설계 문서, 추상적인 토론을 극도로 싫어합니다. 소프트웨어는 결국 돌아가는 코드로 증명되어야 한다는 실용주의 노선입니다.

노하우: 아키텍처에 대해 며칠씩 논쟁하지 마세요. 작게라도 실제로 동작하는 프로토타입(코드)을 먼저 작성해서 결과를 보고 이야기하는 것이 가장 빠르고 정확합니다. 3. 극단적인 모듈화와 단순성 (Keep It Simple)

리눅스 커널은 수천만 줄의 코드로 이루어져 있지만, 여전히 안정적입니다. 비결은 각 부분이 서로 엉키지 않게 철저히 분리(모듈화)되어 있기 때문입니다. 또한 그는 코드 작성 시 들여쓰기(Indentation)가 3단계 이상 깊어지면 그 코드는 망가진 것이라고 말합니다.

노하우: 함수 하나는 한 가지 일만 해야 합니다. 코드가 오른쪽으로 너무 깊어지면(조건문 안에 반복문 안에 조건문...), 함수를 쪼개거나 로직을 다시 생각해야 할 때입니다. 4. "성당이 아닌 시장(Bazaar)처럼 개발하라" (오픈소스 철학)

에릭 레이먼드가 토발즈의 개발 방식을 보고 쓴 책 <성당과 시장>에 나오는 개념입니다. 소수의 엘리트가 밀실에서 완벽한 프로그램을 만드는 것(성당 방식)이 아니라, **초기부터 코드를 공개하고 대중의 피드백을 받아 빠르게 수정하는 것(시장 방식)**입니다.

법칙: "보는 눈이 많으면 모든 버그는 사소해진다 (Given enough eyeballs, all bugs are shallow)." 노하우: 완벽해질 때까지 숨기지 마세요. 일찍 배포하고, 자주 배포하여 사용자와 동료들의 피드백을 수용하세요. 5. 제1원칙: "절대 사용자 공간을 망가뜨리지 마라 (Never break userspace)"

리눅스 커널 개발의 절대 규칙입니다. 커널 내부 코드를 아무리 멋지게 리팩토링했더라도, 그로 인해 기존에 잘 돌아가던 외부 프로그램(사용자 공간)이 멈춘다면 그 패치는 무조건 거절됩니다.

노하우: 개발자의 자기만족(아름다운 코드, 최신 기술 적용)보다 사용자의 경험과 하위 호환성이 언제나 우선입니다. 기존 기능을 망가뜨리는 업데이트는 버그일 뿐입니다. 6. 도구가 마음에 안 들면 직접 만들어라 (Git의 탄생)

리눅스 개발 초기에 쓰던 버전 관리 도구가 유료화되면서 사용이 막히자, 토발즈는 기존에 있던 다른 도구들을 써보았습니다. 하지만 전부 느리고 마음에 들지 않자, 커널 개발을 잠시 멈추고 단 2주 만에 'Git'을 직접 만들어 버렸습니다.

노하우: 매일 쓰는 개발 환경이나 도구가 비효율적이라면, 그 불편함을 감수하지 마세요. 스크립트를 짜거나 도구를 개선하는 데 시간을 투자하는 것이 장기적으로 훨씬 이득입니다. 7. 신뢰의 네트워크와 권한 위임 (Benevolent Dictator)

토발즈가 리눅스의 모든 코드를 다 보는 것은 불가능합니다. 그는 자신이 신뢰하는 소수의 핵심 개발자(Lieutenant, 부관)들이 검토한 코드를 병합하고, 그 부관들은 또 그 아래의 개발자들을 신뢰하는 피라미드 형태의 신뢰 네트워크를 구축했습니다.

노하우: 프로젝트가 커지면 모든 것을 통제하려는 욕심을 버려야 합니다. 믿을 수 있는 동료에게 권한을 위임하고, 자신은 전체적인 방향성과 최종 결합(Merge)에만 집중하세요. 요약: 내 업무에 적용하는 토발즈 스타일 코딩하기 전에 **데이터 구조(DB 스키마, 상태 트리 등)**를 먼저 완벽하게 짠다. if 문을 줄일 수 있는 더 근본적인 로직을 고민한다. 회의 시간은 줄이고 작동하는 결과물로 소통한다. 언제나 기존 사용자(또는 클라이언트)가 겪을 영향을 최우선으로 고려한다.