2015.04.09

지혜로운 개발자가 되기 위한 격언 65가지

이수경 기자 | ITWorld
소프트웨어 개발을 하면 할수록 인생의 지혜를 얻게 된다. 어떤 이들은 개발은 단순한 작업이 아닌, 삶을 사는 방식이라고도 말한다. 코드를 작성하는 일 자체가 직장과 일상 속에서 자신의 모습을 구현하는 일이기 때문이다. 깃허브(GitHub)에는 개발자 속담(Programmer’s Proverbs)이라는 저장소가 생성됐는데, 개발자를 위한 지혜로운 문장들을 모아놓은 것이다. 이제 미래 세대를 이끌어나갈 새싹들이 보고 배울 지혜에 대해 알아보도록 한다.

개발자의 현실
- 때로는 QA의 역할을 때로는 버그 수정 역할을 감당해야 한다는 사실을 인정하라.
- 일을 잘할수록 남들은 난이도가 쉽다고 생각한다.

개발자 사명서
- A/B 시험은 두 번 진행하고 변경사항을 한 번에 배치하라.
- 게으름이 자신의 가장 좋은 친구이다. 한 번에 자동화할 수 있는 것을 두 번 하지 마라.
- 최고의 요청은 아예 요청하지 않는 것이다.
- 웹 표준만 설정할 수는 없다.
- 자신의 데이터 구조를 파악하면 코드는 자연히 따라갈 것이다.
- 오래된 코드 중 일부는 다시 작성할 수 없고, 약간만 변경해도 깨져버린다.
- 취했을 때 자신이 춤추는 모습을 떠올리고 다음에 맥주를 마시고 코드를 작성할 때는 책임을 져야 한다.
- 술에 취했을 때는 상사와 대화하지 마라.
- 많은 시도를 통해 더 높은 품질을 달성할 수 있는 경우가 많다.
- 최종 버전의 성공은 거짓이다. 반복만이 있을 뿐이다. 반복을 통해 더 나은 제품을 얻는다. 더 나은 제품을 통해 인기를 얻는다. 인기를 통해 성공을 얻는다. 성공을 통해 잘못 이해한 기술 사양이 깨진다. 개발 사이클이 우리를 자유롭게 하리라.
- 버전 관리에 신경 써야 한다.
- 데모 페이지를 위한 프레임워크를 선택하는 대신에 코드를 위해 선택하라.
- 측정하기 전에 절대로 최적화하지 말라
- 지트(Git)에서 있었던 일은 지트에 남겨 둔다.
- 포리치 루프(Foreach Loop)를 피하면 CPU 사이클을 얻는다.

개발은 하루아침에 이뤄지지 않는다
- 프로그래머가 백 명이라도 2년짜리 프로젝트를 일주일 만에 끝낼 수 없다.
- 페이스북은 하루아침에 만들어지지 않았다.
- 호프스태터(Hofstadter)의 법칙에 따르면 프로젝트를 위해 필요한 시간보다 더 많은 시간을 더해야 한다. 왜냐하면, 호프스태터의 법칙을 고려하더라도 생각한 것보다 더 오래 걸리기 때문이다.

개발은 기초작업이 중요하다
채색하기 전에 밑그림을 그리듯이, 소프트웨어도 설계와 시공에 대한 가이드가 될 큰 밑그림이 필요하다. 이를 '아키텍처'라고 부르는데, 일단 시스템이 개발된 뒤에는 잘못된 구조를 바로잡기가 쉽지 않다는 점에서 매우 중요한 작업이다.

- 프로토타입 없이 완성품을 만들지 마라.
- 표준문안이 없다면 개발도 빠를 수 없다.
- 아키텍처와 디자인은 실행 시간의 핵심이 아니라 문제와 변화를 위한 대비책이다.
- 장기 지원이 필요한 애플리케이션의 아키텍처를 남겨두라.

간결성은 핵심이다
- 충분히 복잡한 앱 아키텍처는 스파게티 코드와 차이가 없다.
- 코드를 간소화하라. 읽고 이해하기 힘든 코드는 골치 아픈 잔재가 될 뿐이다.
- 코드가 간소할수록 버그가 적다.

디버깅
입력 데이터 유효성을 검증하는 것에 각별한 주의를 쏟아야 하는 부분이다. 버퍼 초과나 SQL 인젝션 공격에 이르기까지, 아주 흔한 보안 취약점은 올바른 입력 포맷인지 검증하지 않은 사용자 입력에 근거한 코드가 직접적인 원인인 경우가 많다. 한편으로는 제품을 출시하기 전에 많은 단위 테스트를 진행할수록 나중에 정식 출시 후 나비효과처럼 불어날 피해에 대한 근본적인 대책을 마련하는 데 도움이 된다.

- 모니터링하지 않는 앱을 배치하는 것은 연료계 없이 자동차 여행을 떠나는 것과 같다.
- 프로그램을 작성하는 것보다 디버깅할 때 두 배나 똑똑해야 하므로 동료에게 검토를 부탁하라. 왜냐하면, 자신의 코드를 디버깅할 만큼 똑똑할 수는 없기 때문이다.
- 동료의 코드 검토가 없는 코딩 스타일가이드는 자발적인 세금으로 국가를 운영하는 것과 같다.
- 처음부터 자신이 문제라는 사실을 인정하면 디버깅이 훨씬 쉬워진다.
- 프로그래머에게 올바른 코드를 주면 하루 동안 일 할 수 있다. 프로그래머에게 디버깅을 가르치면 평생 일할 수 있다. - 지락 구드(Chirag Gude)
- 디버깅(Debugging)보다는 시험이 쉽다.
- 동료가 검토하거나 자신이 사는 곳을 알고 있는 폭력적인 사이코패스가 유지 관리한다고 가정할 때만 오래도록 지속하는 코드를 작성할 수 있다.
- 코드에 대한 불만은 코드 재작성에 도움이 되지 않는다.
- 시스템이 완벽하게 동작하면 그 안에 뭐가 있는지 아무도 관심을 갖지 않는다. 문제가 발생하면 시스템 디자인과 아키텍처가 자신의 운명을 결정하게 될 것이다.
- "그냥 넘겨"라는 말로 설계를 대신할 수는 없다

새 출발이 더 나은 대안일 수도 있다
전임 개발자가 작성한 코드 일부분을 유지 보수하거나 디버깅하는 작업은 정말 어려운 일이다. 기존 코드 한 조각의 작동 원리를 파악하고, 최초 개발자의 의도를 파악하는 것, 특히 문서나 주석이 엉망일 경우에는 거의 불가능에 가깝다. 중복된 코드를 남발하거나 억지로 갖다 붙인 결과, 지나치게 비대해진 취약한 코드 베이스만 남을 뿐이다. 기존의 것에 새로운 기능을 연이어서 탑재하려는 욕심을 우선 버려야 하며, 기존 코드의 질과 정비 용이성을 평가하는 것이 우선이다. 코드 재작성 비용을 청구하는 것이 업그레이드 개발을 하는 것보다 더 저렴할 수도 있다.

- 레거시 코드를 다시 작성하면 품질이 나아진다.
- 다시 작성하라. 유지 관리가 불가능한 레거시 코드를 위한 패치는 존재하지 않는다.
- 때로는 레거시 지원을 중단해야 새로운 제품이 피어날 수 있다.
- 오랜 시간 작업할수록 코드 수가 늘어난다. 대부분 최고의 품질에서 역행하고, 버그를 유발하는 기능들이다.

끊임없는 자기개발
C#, 자바, 자바스크립트 등 전세계적으로 많이 쓰이는 개발 언어들 이외에도 스위프트 등의 새로운 언어들이 대세로 떠오르고 있다. 고지식한 개발자라 하더라도 이와 같은 변화와 새로운 기술을 익히는 데 언제까지나 저항할 수는 없는 노릇이다. '죽어도 다른 언어로는 개발하지 않겠다'는 식의 미숙한 발언은 피해야 한다. 개발자라면 무릇 하나 이상의 개발 언어를 잘 알아야 하며, 새롭게 떠오르는 주제에 대해서도 잘 알아야 한다.

새로운 기술이 번져가기 시작하면, 최소한 그 배경과 그 기술의 작동 원리를 이해할 필요는 있다. 세부적인 사항은 그 기술이 요구사항을 해결하는 데 도움이 될 때 파악해도 늦지 않다. 오래된 도구로는 새로운 문제를 해결할 수 없다는 점을 기억하고, 계속해서 새로운 언어를 익혀나가야 한다.

- 말을 잘하는 개발자는 빨리 일자리를 찾을 수 있지만, 마지막 순간에 간단한 시험에서 실패한다.
- 더 많은 기술을 배울수록 자신이 아는 것이 별것 아니라는 것을 알게 된다.
- 프로그래밍 언어를 배우고 새로운 개발자가 되라.
- 형편없는 프로그래머가 언어를 탓한다.
- 더 이상 배우지 않고 쉬운 길을 택하면 기존의 방법론에서 영원히 벗어나지 못하게 될 것이다.
- 오늘의 유행은 내일의 구식.
- 잘 알려지지 않고 이상한 언어를 배우면 이해의 폭과 깊이가 넓어진다.

오픈소스
오픈소스를 잘 활용하면 잠재적인 고용주에게 자신의 능력을 보여줄 있다. 오픈소스 커뮤니티에서는 '직접 이 부분을 작성했다'고 말하는 데 그 어떤 제약도 없는데, 특히 커미터(Committer) 지위를 얻었다는 것은 협동심이 있고, 진행 중인 프로그램에 기여할 수 있는 능력이 있다는 것을 어필하는 것이다.

옴니TI(OmniTI)에서 15년이상 개발자로 일해온 로버트 트리트는 "사이드 프로젝트(Side Proejct)나 오픈소스 커뮤니티에 참여해서 다양한 기술을 사용하는 기업에 입사하는 것도 좋은 방법"이라고 말했다. 물론, 여러 조직의 전문가, 준전문가 등 다양한 사람들이 협력하는 만큼 '다시는 만나고 싶지 않은 사람'으로 낙인찍힐 수도 있음을 주의해야 한다.

- 오픈소스 개발자는 개인의 명성을 추구하지 않는다.
- 오픈소스 프로젝트에서의 협업으로 우정과 커뮤니티를 얻음과 동시에 파벌과 전쟁도 생겨난다.
- 공개적인 코드 검토로 더 나은 자신이 될 수 있다. 더 나은 활동, 더 스마트한 솔루션, 개발자로서의 성장을 얻거나 깨지게 된다.

건강이 우선이다
개발자들은 컴퓨터 앞에서 많은 시간을 보낸다. 그러나 제때에 적절한 휴식을 취하지 않으면 안구건조증, 거북목, 손목 터널 증후군, 근막통증후군 등에 걸려 종합병원 신세를 면치 못할 수도 있다. 프로가 되기 위해서는 건강 관리도 병행하는 것이 무엇보다 필수다.

- 억지로 잠을 자라.
- 바보는 의사를 멀리한다.
- 지칠 때까지 코드를 작성하는 개발자는 생각 없이 산다.
- 모든 애플리케이션은 화면을 껐을 때 아름답다.

기타
- 수염을 깎지 못할 정도로 개발에 몰두하고 있는 정도라면 이미 그 수염이 자라 백발이 된 사람은 최소 백 명이다.
- 고객이 최고의 시험자이다.
- 오류 로그만큼은 없을 때 아름답다.
- 마케팅 담당자는 QA가 아니고 개발자는 홍보를 하지 않는다.
- 무료 사용자에게 행복감을 주는 제품은 재정이 바닥나면 투자자를 겁먹게 할 뿐이다.
- 하나는 하나 이상의 일을 하지 않는다.
- 언젠가라는 말이 가장 쉽다.
- 가장 매력적인 풀(Pull) 요청은 빨간색으로 도배되어 있다.
- 개발자는 먼 곳에서 동료를 찾는다.
- 코드의 미학을 스스로 터득할 수는 있지만 다른 사람들도 쉽게 배울 수 있으리라 착각하지 마라.
editor@itworld.co.kr 


2015.04.09

지혜로운 개발자가 되기 위한 격언 65가지

이수경 기자 | ITWorld
소프트웨어 개발을 하면 할수록 인생의 지혜를 얻게 된다. 어떤 이들은 개발은 단순한 작업이 아닌, 삶을 사는 방식이라고도 말한다. 코드를 작성하는 일 자체가 직장과 일상 속에서 자신의 모습을 구현하는 일이기 때문이다. 깃허브(GitHub)에는 개발자 속담(Programmer’s Proverbs)이라는 저장소가 생성됐는데, 개발자를 위한 지혜로운 문장들을 모아놓은 것이다. 이제 미래 세대를 이끌어나갈 새싹들이 보고 배울 지혜에 대해 알아보도록 한다.

개발자의 현실
- 때로는 QA의 역할을 때로는 버그 수정 역할을 감당해야 한다는 사실을 인정하라.
- 일을 잘할수록 남들은 난이도가 쉽다고 생각한다.

개발자 사명서
- A/B 시험은 두 번 진행하고 변경사항을 한 번에 배치하라.
- 게으름이 자신의 가장 좋은 친구이다. 한 번에 자동화할 수 있는 것을 두 번 하지 마라.
- 최고의 요청은 아예 요청하지 않는 것이다.
- 웹 표준만 설정할 수는 없다.
- 자신의 데이터 구조를 파악하면 코드는 자연히 따라갈 것이다.
- 오래된 코드 중 일부는 다시 작성할 수 없고, 약간만 변경해도 깨져버린다.
- 취했을 때 자신이 춤추는 모습을 떠올리고 다음에 맥주를 마시고 코드를 작성할 때는 책임을 져야 한다.
- 술에 취했을 때는 상사와 대화하지 마라.
- 많은 시도를 통해 더 높은 품질을 달성할 수 있는 경우가 많다.
- 최종 버전의 성공은 거짓이다. 반복만이 있을 뿐이다. 반복을 통해 더 나은 제품을 얻는다. 더 나은 제품을 통해 인기를 얻는다. 인기를 통해 성공을 얻는다. 성공을 통해 잘못 이해한 기술 사양이 깨진다. 개발 사이클이 우리를 자유롭게 하리라.
- 버전 관리에 신경 써야 한다.
- 데모 페이지를 위한 프레임워크를 선택하는 대신에 코드를 위해 선택하라.
- 측정하기 전에 절대로 최적화하지 말라
- 지트(Git)에서 있었던 일은 지트에 남겨 둔다.
- 포리치 루프(Foreach Loop)를 피하면 CPU 사이클을 얻는다.

개발은 하루아침에 이뤄지지 않는다
- 프로그래머가 백 명이라도 2년짜리 프로젝트를 일주일 만에 끝낼 수 없다.
- 페이스북은 하루아침에 만들어지지 않았다.
- 호프스태터(Hofstadter)의 법칙에 따르면 프로젝트를 위해 필요한 시간보다 더 많은 시간을 더해야 한다. 왜냐하면, 호프스태터의 법칙을 고려하더라도 생각한 것보다 더 오래 걸리기 때문이다.

개발은 기초작업이 중요하다
채색하기 전에 밑그림을 그리듯이, 소프트웨어도 설계와 시공에 대한 가이드가 될 큰 밑그림이 필요하다. 이를 '아키텍처'라고 부르는데, 일단 시스템이 개발된 뒤에는 잘못된 구조를 바로잡기가 쉽지 않다는 점에서 매우 중요한 작업이다.

- 프로토타입 없이 완성품을 만들지 마라.
- 표준문안이 없다면 개발도 빠를 수 없다.
- 아키텍처와 디자인은 실행 시간의 핵심이 아니라 문제와 변화를 위한 대비책이다.
- 장기 지원이 필요한 애플리케이션의 아키텍처를 남겨두라.

간결성은 핵심이다
- 충분히 복잡한 앱 아키텍처는 스파게티 코드와 차이가 없다.
- 코드를 간소화하라. 읽고 이해하기 힘든 코드는 골치 아픈 잔재가 될 뿐이다.
- 코드가 간소할수록 버그가 적다.

디버깅
입력 데이터 유효성을 검증하는 것에 각별한 주의를 쏟아야 하는 부분이다. 버퍼 초과나 SQL 인젝션 공격에 이르기까지, 아주 흔한 보안 취약점은 올바른 입력 포맷인지 검증하지 않은 사용자 입력에 근거한 코드가 직접적인 원인인 경우가 많다. 한편으로는 제품을 출시하기 전에 많은 단위 테스트를 진행할수록 나중에 정식 출시 후 나비효과처럼 불어날 피해에 대한 근본적인 대책을 마련하는 데 도움이 된다.

- 모니터링하지 않는 앱을 배치하는 것은 연료계 없이 자동차 여행을 떠나는 것과 같다.
- 프로그램을 작성하는 것보다 디버깅할 때 두 배나 똑똑해야 하므로 동료에게 검토를 부탁하라. 왜냐하면, 자신의 코드를 디버깅할 만큼 똑똑할 수는 없기 때문이다.
- 동료의 코드 검토가 없는 코딩 스타일가이드는 자발적인 세금으로 국가를 운영하는 것과 같다.
- 처음부터 자신이 문제라는 사실을 인정하면 디버깅이 훨씬 쉬워진다.
- 프로그래머에게 올바른 코드를 주면 하루 동안 일 할 수 있다. 프로그래머에게 디버깅을 가르치면 평생 일할 수 있다. - 지락 구드(Chirag Gude)
- 디버깅(Debugging)보다는 시험이 쉽다.
- 동료가 검토하거나 자신이 사는 곳을 알고 있는 폭력적인 사이코패스가 유지 관리한다고 가정할 때만 오래도록 지속하는 코드를 작성할 수 있다.
- 코드에 대한 불만은 코드 재작성에 도움이 되지 않는다.
- 시스템이 완벽하게 동작하면 그 안에 뭐가 있는지 아무도 관심을 갖지 않는다. 문제가 발생하면 시스템 디자인과 아키텍처가 자신의 운명을 결정하게 될 것이다.
- "그냥 넘겨"라는 말로 설계를 대신할 수는 없다

새 출발이 더 나은 대안일 수도 있다
전임 개발자가 작성한 코드 일부분을 유지 보수하거나 디버깅하는 작업은 정말 어려운 일이다. 기존 코드 한 조각의 작동 원리를 파악하고, 최초 개발자의 의도를 파악하는 것, 특히 문서나 주석이 엉망일 경우에는 거의 불가능에 가깝다. 중복된 코드를 남발하거나 억지로 갖다 붙인 결과, 지나치게 비대해진 취약한 코드 베이스만 남을 뿐이다. 기존의 것에 새로운 기능을 연이어서 탑재하려는 욕심을 우선 버려야 하며, 기존 코드의 질과 정비 용이성을 평가하는 것이 우선이다. 코드 재작성 비용을 청구하는 것이 업그레이드 개발을 하는 것보다 더 저렴할 수도 있다.

- 레거시 코드를 다시 작성하면 품질이 나아진다.
- 다시 작성하라. 유지 관리가 불가능한 레거시 코드를 위한 패치는 존재하지 않는다.
- 때로는 레거시 지원을 중단해야 새로운 제품이 피어날 수 있다.
- 오랜 시간 작업할수록 코드 수가 늘어난다. 대부분 최고의 품질에서 역행하고, 버그를 유발하는 기능들이다.

끊임없는 자기개발
C#, 자바, 자바스크립트 등 전세계적으로 많이 쓰이는 개발 언어들 이외에도 스위프트 등의 새로운 언어들이 대세로 떠오르고 있다. 고지식한 개발자라 하더라도 이와 같은 변화와 새로운 기술을 익히는 데 언제까지나 저항할 수는 없는 노릇이다. '죽어도 다른 언어로는 개발하지 않겠다'는 식의 미숙한 발언은 피해야 한다. 개발자라면 무릇 하나 이상의 개발 언어를 잘 알아야 하며, 새롭게 떠오르는 주제에 대해서도 잘 알아야 한다.

새로운 기술이 번져가기 시작하면, 최소한 그 배경과 그 기술의 작동 원리를 이해할 필요는 있다. 세부적인 사항은 그 기술이 요구사항을 해결하는 데 도움이 될 때 파악해도 늦지 않다. 오래된 도구로는 새로운 문제를 해결할 수 없다는 점을 기억하고, 계속해서 새로운 언어를 익혀나가야 한다.

- 말을 잘하는 개발자는 빨리 일자리를 찾을 수 있지만, 마지막 순간에 간단한 시험에서 실패한다.
- 더 많은 기술을 배울수록 자신이 아는 것이 별것 아니라는 것을 알게 된다.
- 프로그래밍 언어를 배우고 새로운 개발자가 되라.
- 형편없는 프로그래머가 언어를 탓한다.
- 더 이상 배우지 않고 쉬운 길을 택하면 기존의 방법론에서 영원히 벗어나지 못하게 될 것이다.
- 오늘의 유행은 내일의 구식.
- 잘 알려지지 않고 이상한 언어를 배우면 이해의 폭과 깊이가 넓어진다.

오픈소스
오픈소스를 잘 활용하면 잠재적인 고용주에게 자신의 능력을 보여줄 있다. 오픈소스 커뮤니티에서는 '직접 이 부분을 작성했다'고 말하는 데 그 어떤 제약도 없는데, 특히 커미터(Committer) 지위를 얻었다는 것은 협동심이 있고, 진행 중인 프로그램에 기여할 수 있는 능력이 있다는 것을 어필하는 것이다.

옴니TI(OmniTI)에서 15년이상 개발자로 일해온 로버트 트리트는 "사이드 프로젝트(Side Proejct)나 오픈소스 커뮤니티에 참여해서 다양한 기술을 사용하는 기업에 입사하는 것도 좋은 방법"이라고 말했다. 물론, 여러 조직의 전문가, 준전문가 등 다양한 사람들이 협력하는 만큼 '다시는 만나고 싶지 않은 사람'으로 낙인찍힐 수도 있음을 주의해야 한다.

- 오픈소스 개발자는 개인의 명성을 추구하지 않는다.
- 오픈소스 프로젝트에서의 협업으로 우정과 커뮤니티를 얻음과 동시에 파벌과 전쟁도 생겨난다.
- 공개적인 코드 검토로 더 나은 자신이 될 수 있다. 더 나은 활동, 더 스마트한 솔루션, 개발자로서의 성장을 얻거나 깨지게 된다.

건강이 우선이다
개발자들은 컴퓨터 앞에서 많은 시간을 보낸다. 그러나 제때에 적절한 휴식을 취하지 않으면 안구건조증, 거북목, 손목 터널 증후군, 근막통증후군 등에 걸려 종합병원 신세를 면치 못할 수도 있다. 프로가 되기 위해서는 건강 관리도 병행하는 것이 무엇보다 필수다.

- 억지로 잠을 자라.
- 바보는 의사를 멀리한다.
- 지칠 때까지 코드를 작성하는 개발자는 생각 없이 산다.
- 모든 애플리케이션은 화면을 껐을 때 아름답다.

기타
- 수염을 깎지 못할 정도로 개발에 몰두하고 있는 정도라면 이미 그 수염이 자라 백발이 된 사람은 최소 백 명이다.
- 고객이 최고의 시험자이다.
- 오류 로그만큼은 없을 때 아름답다.
- 마케팅 담당자는 QA가 아니고 개발자는 홍보를 하지 않는다.
- 무료 사용자에게 행복감을 주는 제품은 재정이 바닥나면 투자자를 겁먹게 할 뿐이다.
- 하나는 하나 이상의 일을 하지 않는다.
- 언젠가라는 말이 가장 쉽다.
- 가장 매력적인 풀(Pull) 요청은 빨간색으로 도배되어 있다.
- 개발자는 먼 곳에서 동료를 찾는다.
- 코드의 미학을 스스로 터득할 수는 있지만 다른 사람들도 쉽게 배울 수 있으리라 착각하지 마라.
editor@itworld.co.kr 


X