선배 개발자가 말하는 소프트웨어 개발, “훌륭한 프로그래머는 000가 되어야 한다.”

한빛미디어

2024-05-02

by 피트 구들리프

1,200

“ 삶이 세속에서 벗어날 때 우리는 나무가 말하는 것을 듣고, 흐르는 시냇물에서 책을 발견하며, 돌에서 교훈을 얻고, 존재하는 모든 것들로부터 좋은 점을 발견할 수 있다. ” 셰익스피어, 『As You Like It』 중에서  슬픈 일이지만, 나는 날카롭게 연마된 지성에 영원히 의지할 수 없을 것이다. 지금의 순발력은 언젠가 사라질 것이고, 더 이상 날카롭고 학구적이며 겸손한 천재도 아니게 될 것이다. 그래서 노후를 대비하기 위해 돈을 많이 벌어놔야 한다.  세계 정복을 위해 내가 세웠던 계획은 너무나도 명료해서 실패할 리가 없었다. 그것은 바로 탄산 우유fizzy milk의 발명이었다! 하지만 레시피를 더 정교하게 만들기도 전에, 탄산 우유가 이미 발명되었다는 절망적인 뉴스를 들어야만 했다. 충격과 함께 특허권이 날아감을 느끼며, 새로운 연금 수령 계획을 세울 수밖에 없었다. 물론 지금 와서 생각해보면 참으로 잘된 일이었다. 나는 이 천재적 발상을 어린 시절의 음식들에 대입해보았다. 커스터드와 알파벳 모양 파스타가 바로 그것이다. 내가 어느 쪽으로 방향을 잡을지 짐작할 수 있을 것이다. 당연히 알파벳 모양 커스터드가 아니겠는가! 초기 실험 결과는 성공적이었고 맛도 괜찮았다. 질감은 라이스 푸딩과 약간 비슷했으나 밀가루 맛이 더 강했다. 확실히 몇 번은 더 먹어봐야 맛있다고 생각할 만한 수준이었지만, 이 정도로도 인기를 끌 만하다고 여겼다. <figure class="image image_resized" style="width:64.28%;"><img style="aspect-ratio:900/675;" src="https://www.hanbit.co.kr/data/editor/20240502145205_ckeditor.png" width="900" height="675"></figure><h2> </h2><h2>소프트웨어(음식) 성분</h2> 많은 현대적 소프트웨어는 이 알파벳 모양 커스터드와 비슷하다. 터무니없는 것이자 잘못된 방향성을 근간으로 만들어진 것이다. 알파벳 모양 커스터드를 만드는 올바른 방법은 먼저 손수 파스타를 만든 뒤 커스터드와 한데 섞는 것이다. 부정 행위 즉 나쁜 방법으로는 파스타 통조림을 사서 소스를 씻어내고 바로 커스터드를 붓는 것이 있다. 두 가지 방법 중 하나는 안정적인 제조를 위한 조리법이다. 나머지 하나는 프로토 타입에 적절한 방법으로 대규모 제조에는 적합하지 않다. 양심적인 소프트웨어 개발자로서, 우리는 적절한 방식으로 적절한 제품을 작성하길 갈망해야 한다. 훌륭한 프로그래머의 주요 특징 중 하나는 작성한 소프트웨어와 그 작성법에 대해 진심으로 주의를 기울이는 것이다. 통조림 파스타를 만들어내기보다는 더 애정 어린 장인 정신을 바탕으로 코드를 작성해야 한다. 책 <더 나은 프로그래머 되는 법> 14장에서는 작성되는 소프트웨어의 특성을 알아보고, 알파벳 모양 파스타 같은 것을 만들어내지 않도록 냄비 속을 들여다볼 것이다. 나아가 여기서 배운 교훈을 적용하는 방법에 관한 일련의 질문도 제시할 것이다.  첫 번째 질문은 다음과 같다. 당신은 프로그래머로서 나아지길 원하는가? 적절한 방식으로 적절한 코드를 작성하기를 실제로 원하는가? 만약 대답이 ‘아니오’라면, 당장 하던 일을 때려치우고 이 글을 읽는 것을 멈춰야 한다. 소프트웨어 개발이란 과연 무엇인가? 다양한 요소들이 한데 뒤섞여 있다 보니 복잡하다는 것만은 확실하다. 책에서 소프트웨어 개발에 관한 포괄적이고 지식적인 내용까지 다루지는 않겠지만, 미묘한 몇 가지 부분에 대해서는 살펴볼 것이다. 몇몇 측면에서는 과학이나 예술, 게임, 스포츠, 가사일 등으로 비춰질 수도 있다.  <h2>소프트웨어 개발은 예술이다</h2>훌륭한 프로그래머는 어느 정도는 위대한 예술가가 되어야 한다. 하지만 프로그래밍을 정말 예술이라고 부를 수 있을까? 이는 소프트웨어 개발자들 간에 오랫동안 이어져온 논쟁거리다. 어떤 사람들은 프로그래밍을 엔지니어링의 한 분야로 생각하고, 어떤 사람들은 예술의 한 형태로 바라본다. 또 어떤 사람들은 중도적 입장에서 공예품 정도로 생각한다. 저명한 컴퓨터 과학자인 도널드 커누스는 소프트웨어를 예술로 바라보는 이들 중에서도 가장 유명한 지지자일 것이다. 자신의 유명 저서의 제목을 『The Art of Computer Programming 4A 컴퓨터 프로그래밍의 예술』(한빛미디어, 2013)으로 짓기까지 했던 커누스는 이렇게 말했다.  “일부 프로그램은 우아하고, 어떤 것은 절묘하며, 어떤 것은 빛이 난다. 나는 웅장한 프로그램, 고귀한 프로그램, 정말 멋진 프로그램을 작성하는 것이 가능하다고 주장한다!” 흥분되는 말이다. 코드에는 비트와 바이트 혹은 대괄호와 중괄호보다 더 심오한 부분이 존재한다. 구조와 우아함이 있고, 평형과 균형이 있으며, 취향과 미적 감각이 있다.  소프트웨어 개발 절차 중 많은 부분이 예술 작품을 창조하는 것과 유사하다. 그 절차란 다음과 같다.<h3> 창조적</h3>상상력이 필요하다. 소프트웨어는 능숙하게 구축하고 정확하게 설계해야 한다. 프로그래머는 자신이 만들고자 하는 코드에 대한 비전, 그리고 만드는 방법에 대한 계획이 있어야 한다. 때로는 엄청난 독창성을 필요로 한다. <h3>미학적</h3>좋은 코드의 특징은 우아함, 아름다움, 그리고 균형에서 찾을 수 있다. 이 말은 좋은 코드의 기준이 특정 문화적 관례의 프레임워크 안에 있음을 의미한다. 우리는 코드의 기능 외에 외관 역시 고려한다.<h3> 기계적·수동적</h3>예술가에 비유하자면, 지정된 매개물을 가지고 지정된 도구와 절차, 기법으로 작업하는 것이나 마찬가지다. 또한 관대한 후원자의 주문에 따라 작업하는 것과 같다.<h3> 팀 기반</h3>수많은 형태의 예술은 한 사람이 아닌 여러 사람의 노고에서 비롯된 결과물이다. 예술 형식을 통틀어 예술가는 걸작을 완성할 때까지 밤낮으로 스튜디오에 노예처럼 앉아 있지만은 않는다.  거장 조각가와 견습생들의 관계를 생각해보라. 지휘자에 의해 각 단원의 화음이 맞아가는 오케스트라를 생각해보라. 작곡가가 곡을 만들고 연주자들이 그 곡을 해석하는 관계에 대해 생각해보라.  많은 측면에서 예술가가 사용하는 일련의 기술은 프로그래머와 비슷하다. 미켈란젤로는 전형적인 르네상스 시대의 인간이었다. 화가이자 조각가, 건축가, 시인이며 엔지니어다. 아마도 (가능했다면) 엄청난 프로그래머이기도 했을 것이다.  누군가 가장 유명한 작품인 다비드상을 어떻게 만들었는지 물었을 때, 그는 이렇게 대답했다. “나는 돌을 보았고 거기에서 다비드를 보았다. 단지 그가 아닌 모든 부분을 깎아냈을 뿐이다.” 당신의 방식도 이와 같은가? 목표로 하는 아름다운 코드에 도달할 때까지, 문제가 되는 공간 내의 복잡한 것들을 줄이고 제거하는가? 소프트웨어를 예술로 보는 관점에서 던질 가치가 있는 질문은 다음과 같다.<ul><li>소프트웨어 개발의 창조적인 측면을 고려하는가? 아니면 기계적인 일로 취급하는가?</li><li>코드와 관련해 우아함과 미학에 대한 더 날카로운 감각을 키워야 하는가? 기능적인 부분과 코앞에 닥친 문제를 해결하는 부분을 넘어서야 하는가?</li><li>‘아름다운’ 코드에 대한 자신의 견해가 유일하고 진정한 방향이라고 생각하는가? 예술적 방향을 팀이 추구하는 바에 맞추도록 고려해야 하는가?</li></ul> <h2>소프트웨어 개발은 과학이다</h2>우린 컴퓨터 과학에 대해 이야기하고 있다. 지금도 어딘가에서는 막연하지만 과학적인 그 무언가가 일어나고 있음이 분명하다. 하지만 대부분의 개발 조직에서는 훨씬 덜 과학적인, 즉 하수구 파이프에 오물을 쑤셔넣은 뒤 끝에서 강제로 분출해내는 것과 다름없는 일이 벌어진다고 하는 게 적절한 표현일 것이다. 전형적인 과학자 중 한 명으로 알베르트 아인슈타인을 꼽을 수 있다. 그는 천재일뿐만 아니라, 이 세상에 존재했던 가장 인용할 가치가 있는 사람 중 한 명이다(실제로 논문 저자들에게 상당한 도움을 주고 있다). 그는 이렇게 말했다.  “지적인 바보는 일을 더 크고 복잡하며 폭력적으로 만들 수 있다. 그 반대 방향으로 일을 진행하기 위해서는 천재의 손길이 필요하다. 더불어 많은 용기도 필요하다.”  심오한 이야기다. 실제로 대부분의 소프트웨어 프로젝트는 부적절한 복잡성으로 인해 완전히 실패하고 만다. 아인슈타인 역시 탐미주의자였다. 그는 자신의 이론에 내재된 우아함과 아름다움에 감사했으며, 자신의 이론을 하나의 일관된 전체로 만들어내기 위해 간결하게 압축하려 했다. 그는 말했다.  “나는 상상력을 바탕으로 자유롭게 무언가를 그려내는 예술가라 할 수 있다. 지식보다 중요한 것은 상상력이다. 지식에는 한계가 있다. 하지만 상상력은 세상의 모든 것을 끌어안는다.” 보라. 그는 확실히 인용할 만한 가치가 있다. 소프트웨어 개발이 과학과 같다는 말은 곧 다음과 같은 의미와 일맥상통한다(혹은 그래야만 한다). <h3>엄격함</h3>우리는 언제나 그리고 매번 버그 없이 작동하는 코드를 기대한다. 코드는 유효한 모든 입력에 대해 작동해야 하고, 잘못된 입력에는 적절하게 대응해야 한다. 좋은 소프트웨어는 정확하고, 입증되고, 측정되고, 실험되며, 검증되어야 한다. 이를 실현하려면 어떻게 해야 할까? 좋은 테스트가 그 해결책이다. 우리는 단위 테스트, 통합 테스트, 시스템 테스트를 기대한다. 인간에 의해 빚어지는 오류의 위험을 제거하기 위해 되도록이면 자동화 작업을 해야 한다. 물론 경험에 근거한 테스트도 기대할 만하다 <h3>체계화</h3> 소프트웨어 개발은 무작정 덤벼들 만한 일이 아니다. 작동하는 것처럼 보일 때까지 무작위로 코드 덩어리를 합치는 것만으로는 제대로 구조화된 대형 컴퓨터 시스템을 만들어낼 수가 없다. 먼저 계획을 세우고 설계를 하며, 예산 계획을 세우고 체계적으로 구성할 필요가 있다. 이는 지적이고 논리적이며 합리적인 과정이다. 즉 체계를 세우고 문제 공간과 설계 대안들을 이해하는 것이다.<h3> 통찰력</h3>소프트웨어 개발에는 지적 노력과 더불어 기민한 분석력이 필요하다. 특히 까다로운 버그를 추적할 때 그 필요성은 명백히 드러난다. 과학자처럼 우리는 가설을 설정하고, 과학적인 방법과 유사한 무언가를 적용한다. 설정된 가설을 기반으로 실험을 수행하고, 이론을 검증하는 것이다. 앞에서 설명한 세 가지 의미를 기반으로 자신에게 물어보라.<ul><li>자신이 작성한 소프트웨어는 언제나 완전히 정확하고 완벽하게 정밀한가? 이를 증명하는 방법은 무엇인가? 어떻게 하면 현재와 미래에 명시할 수 있는가?</li><li>혼돈에 질서를 가져오려 노력하는가? 갯수가 적고 규모가 작으며 통합된 부분들이 만들어질 때까지, 코드 내의 복잡성을 줄이려 하고 있는가?</li><li>문제에 질서 있고 신중하게 접근하는가? 아니면 구조화되지 않은 방식으로 돌진하는가?</li></ul> <h2>소프트웨어 개발은 스포츠다</h2>대부분의 스포츠는 상당한 기술과 노력을 필요로 한다. 끈기와 교육, 훈련, 팀워크, 코칭, 그리고 자각self-consciousness이 그것이다. 마찬가지로 소프트웨어 개발도 이 같은 요소를 포함한다. <h3>팀워크</h3>서로 다른 기술을 보유한 채 한데 어우러지는 많은 사람의 협업이 필요하다.<h3> 훈련</h3>각 구성원은 자신의 팀에 전념해야 하고 기꺼이 최선을 다해야 한다. 여기에는 헌신과 노력, 많은 훈련이 필요하다. 소파에 앉아 축구 훈련 영상을 보는 것만으로는 축구를 잘할 수 없다. 특히 맥주와 팝콘을 함께 먹으면서 훈련 영상을 볼 경우 축구를 더 못하게 될 것이다. 사람들과 함께 축구 경기장에서 연습해야 기술을 향상할 수 있다. 즉, 훈련을 해야 한다는 것이다. 여기에 기술을 알려줄 누군가도 필요하다. 팀원들은 함께 훈련하고 팀 전체와 함께 작업하는 방법을 익혀야 한다. <h3>규칙</h3>우리는 일련의 규칙과 특정 팀 문화를 기반으로 개발을 진행한다. 이는 개발 절차와 개발 방법, 소프트웨어팀의 의례나 의식, 그들의 작업 도구를 통한 업무 흐름으로 구성된다(소스 제어 도구와 같은 것을 사용하면서 어떻게 협업할지에 대해 고려해보라). 개발팀의 팀워크는 축구와 같은 스포츠에 비유할 때 가장 명확해진다. 잘 정의된 규칙에 따라 게임을 진행하듯이, 개발자는 작업하는 사람들과 긴밀하게 그룹을 지어 일한다. 일곱 살 아이들로 구성된 축구 팀이 축구하는 것을 본 적이 있는가? 골대 안에 한 명의 아이가 있고, 다른 아이들은 미친 듯이 축구공을 쫓는다. 패스도 없고 대화도 없다. 다른 팀 구성원을 의식하지도 않는다. 단지 움직이는 작은 축구공 주변에 뭉쳐져 있을 뿐이다.  반면 높은 수준의 프리미어리그팀은 응집력 있는 방식으로 축구를 한다. 모두가 각자의 역할을 알고 있고 팀으로서 응집력을 발휘한다. 목표로 하는 비전을 공유하고, 높은 수준에서 각자의 기능을 담당하며, 잘 구성된 조직을 형성한다.<ul><li>이러한 기술을 모두 갖추고 있는가? 팀원으로서 일을 잘하는가? 몇몇 영역에서 더 나아질 여지가 있는가?</li><li>모두의 이익을 위해 기꺼이 팀에 헌신하는가?</li><li>여전히 소프트웨어 개발에 대해 학습하고 있는가? 다른 사람으로부터 배우고, 팀 내에서 일하는 기술을 완벽하게 습득하고 있는가?</li></ul> <h2>소프트웨어 개발은 아이들 놀이다</h2>나에게 이 같은 관점은 특히 적절해 보인다. 필자는 진심으로 어린아이와 같다. 사실 모두가 그렇지 않은가? 아이들이 어떻게 자라고 배우는지, 세계관이 어떻게 변화하는지 그리고 새로운 경험에 의해 어떻게 구체화되는지를 지켜보는 것은 꽤 흥미로운 일이다. 우리는 어린아이가 배우고 세상에 반응하는 방식으로부터 많은 것을 얻어낼 수 있다.  소프트웨어 개발에 이를 적용할 방법을 생각해보자. <h3>학습</h3>아이들은 자신이 아직 배우는 과정이며 모든 것을 알지는 못한다는 점을 인지하고 있다. ‘겸손'이라는 간단한 특성 덕분이다. 내가 보기에 협업하기 가장 어려워 보이는 일부 프로그래머들은 자신이 모든 것을 알고 있다고 생각하는 사람들이다. 알아야 할 새로운 어떤 것이 있을 때, 그들은 책 한번 읽어본 것만으로 자신이 전문가가 되었다고 여긴다. 겸손이라는 말은 완전히 쌈 싸먹는 행태다. 아이는 끊임없이 새로운 지식을 흡수한다. 더 나아지기를 원한다면 더 배워야 함을 깨달아야 한다. 아는 것과 모르는 것을 받아들여야 한다. 새로운 것을 배우고 찾는 것을 즐기라. 더 연습하고 기술을 향상시키라. <h3>단순함</h3>가장 간결한 코드를 작성하는가? 이해하기 쉽고 쓰기도 쉬운 코드를 만들기 위해 모든 부분에서 줄일 것을 찾아 없애고 가장 간결한 형태로 만드는가? 자신의 제한된 관점에서 사물을 이해하기 위해, 아이들이 사물의 진상에 도달하고자 노력하는 방법을 필자는 사랑한다. 그들은 언제나 이유를 묻는다. 다음은 필자가 여섯 살 된 딸 아이와 나눈 대화이다. 앨리스: “아빠, 왜 밀리가 내 동생이야?” 피트: “그 아이와 너는 가족이기 때문이란다.” 앨리스: “왜?” 피트: “음, 엄마와 아빠가 같으니까.” 앨리스: “왜?” 피트: “음, 저기 새와 꿀벌이 있구나. 저기 가서 책 좀 가져오겠니!” 앨리스: “… (잠시 생각하다가) 왜 그런 건데?” 이처럼 끊임없이 이유에 대해 질문해야 한다. 지금 무엇을 하고 있는지, 그렇게 하는 이유는 무엇인지에 대해 질문해야 한다. 문제와 최고의 해결책에 대해 더 잘 이해할 방법을 찾아야 한다. 그리고 자신의 작업물에서 간결함을 추구해야 한다. 간결한 작업물이란 가장 단순한 ‘멍청이’ 코드가 아닌, 적절하게 명료한 코드이다.<h3> 즐기기</h3>다른 모두가 하지 않는다 해도 자신은 즐기는 것에 별다른 문제는 없다. 모든 좋은 개발자는 약간의 놀이 시간을 즐긴다. 실제로 필자의 사무실에서는 최근 외발자전거와 임시적인 크리켓 구장을 허용하고 있다.  이를 염두에 두고 다음과 같은 질문을 할 수 있다.<ul><li>가장 간결한 코드를 작성하려 노력하는가? 아니면 그냥 생각나는 대로 키보드로 타이핑할 뿐 일반성이나 리팩터링, 코드 설계에 대해서는 생각하지 않는가?</li><li>여전히 배우고 있는가? 무엇을 배울 수 있는가? 무엇에 대해 배워야 하는가?</li><li>겸손한 프로그래머인가?</li></ul> <h2>소프트웨어 개발은 집안일이다</h2>소프트웨어 개발 작업은 재미없고 매력적이지 않으며 평탄한 작업이라 할 수도 없다. 프로젝트를 완료하기 위해 거쳐야 하는, 집안일처럼 단조롭고 고된 일이다. 하지만 효율적인 프로그래머가 되려면 집안일을 두려워해서는 안 된다. 프로그래밍이 어려운 일임을 인지하라. 그렇다. 제품의 최신 버전에 대해 멋진 설계를 하는 것은 대단한 일이지만, 제품을 출시하고 오래되고 지저분한 코드에서 오류를 찾아 수정하는 지루한 작업을 해야할 때도 종종 있다. 때로는 소프트웨어에 대한 가정부가 되어야 한다. 이를 위해 필요한 것은 다음과 같다. <h3>청소하기</h3>문제를 찾아내 해결해야 한다. 잘못된 부분이 어디인지 적절한 수정 방법은 무엇인지 찾아내야 한다. 수정 방법을 찾았다면, 적절한 시점에 파괴적이지 않은 방식으로 수정해야 한다. 청소부로서 다른 사람에게 즐겁지 않은 작업을 넘겨버리지 말고 책임을 져야 한다. <h3>보이지 않는 곳에서 작업하기</h3>청소부는 각광받으며 일하지 않는다. 자신의 영웅적인 노력에 대해 약간의 인정만 받는다. 완전히 지원하는 역할일 뿐 앞에서 선도하는 역할은 아니라는 뜻이다.<h3> 유지보수</h3>소프트웨어 청소부는 죽은 코드를 제거하고, 망가진 코드를 수정한다. 적절하지 않은 코드를 리팩터링하고 재구성하며, 코드를 줄이고 깔끔하게 만든다. 코드가 황폐한 상태에 빠지지 않도록 하기 위함이다. 스스로에게 물어보자.<ul><li>코드에 대해 집안일과 같은 단순한 작업을 할 때 행복한가? 아니면 화려한 작업만을 원하는가?</li><li>지저분한 코드에 대해 책임감을 가지고 청소를 하는가?</li></ul> <h2>은유 과부화</h2>소프트웨어를 개발하는 행위를 빗대기 위한 은유적 표현이 종종 만들어지곤 한다. 하지만 그 어떤 은유도 완벽하지 않다. 소프트웨어 개발은 그 자체로 특별한 작업이며, 소프트웨어를 만드는 행위와 완전히 유사한 분야는 존재하지 않는다. 여전히 탐험하고 개선해야 하는 분야다. 잘못된 은유로부터 시시한 추론을 이끌어내는 것에 주의하라. 좋은 코드와 좋은 코더는 적절한 방법으로 적절한 것을 작성하려는 욕구로부터 태어난다. 앞에서 언급한 것처럼, 알파벳 모양 커스터드와 같은 소프트웨어에서 태어나는 것이 아니다. <hr>위 글은 『<a href="https://www.hanbit.co.kr/store/books/look.php?p_code=B2842485463">더 나은 프로그래머 되는 법</a>』에서 내용을 발췌하여 정리한 내용입니다. <figure class="image image_resized" style="width:42.87%;"><img style="aspect-ratio:700/822;" src="https://www.hanbit.co.kr/data/editor/20240502172629_ckeditor.png" width="700" height="822"></figure>

TAG : 리팩터링 ,클린코드 ,업무관리 ,개발자성장 ,소프트스킬 ,개발자멘토링 ,오라일리 ,프로그래머 ,소프트웨어개발 ,한빛미디어

이전 글 : 소프트웨어 설계 20년 해 보고 깨달은 ‘좋은 설계’의 조건

다음 글 : 인공지능 기술의 안전하고 윤리적인 활용을 위해 ─ 『머신러닝 리스크 관리 with 파이썬』 번역 후기

최신 콘텐츠

한빛출판네트워크

인기 검색어 (최근 1개월간)

BOOK

CONTENTS

IT/모바일

선배 개발자가 말하는 소프트웨어 개발, “훌륭한 프로그래머는 000가 되어야 한다.”

최근 본 책0