📀 개발 경력 14년, 여전히 프로그래밍은 어렵다 (2)

Piglei님의 블로그를 의역/요약한 글입니다. --- 3) 효율적인 시행착오 환경을 구축하는 것은 중요하다 한 때 나는 유명한 제품을 개발했었다. 디자인이 세련되고, 기능이 풍부했으며, 매일 사용하는 사람의 수도 엄청났다. 시장에서의 성공과는 달리, 엔지니어링은 처참했다. 백엔드는 간단한 단위 테스트조차 없었고 비즈니스 로직은 복잡했으며 그로 인해 감당하지 못할 정도의 의존성이 강하게 결합되어 있었다. 새로운 기능 개발을 하면 기존 코드 어딘가를 망가지게 했다. 그래서 배포할 때 마다 개발팀과 제품팀은 상당한 긴장감 속에서 예민할 수 밖에 없었다. 배포 과정은 항상 살얼음판 같았고 롤백은 밥 먹듯이 했다. 이런 환경에서 일하다 보면, 기술적으로 성장하기 어렵고 멘탈만 강해질 뿐이다. 개발은 재미있어야 한다. 근데 이런 환경이라면 무슨 재미가 남아있는가? 어떤 요소가 재미를 반감시키는걸까? 이상적인 프로그래밍 경험은 LeetCode 문제를 푸는 것과 유사하다. LeetCode는 인터넷 문제 풀이 사이트이며 하나의 문제가 주어질 때 코드를 작성하고 제출하면 즉각적인 단위 테스트를 거친 뒤 합/불 결과를 받는다. 이는 게임을 하는 것과도 같다. 적당히 어렵고 재밌으며 과정 자체가 소프트웨어 개발을 축소 시켜 놓은 것 같다. * 관심사 분리: 각 문제는 서로 다른 문제에 영향을 주지 않아서 개발자가 한번에 하나씩 집중 할 수 있게 해준다. * 빠르고 정확한 피드백: 코드 수정 후 제출하면 단위 테스트를 통해 즉각적인 피드백을 얻을 수 있다. * 무비용 시행착오: 로직에 허점이 있거나 syntax 에러가 있어도 막대한 비용을 감당하지 않아서 심리적 압박감이 적다. 혹자는 “LeetCode 문제랑 실제 현업 문제랑 같냐? 복잡도와 스케일이 차원이 다른데?” 라고 생각할 수 있다. 맞는 말이다. 실제 우리가 접하는 문제는 LeetCode 문제처럼 답이 정해져 있는 것도 아니고 쉽게 결론 지을 수 없는 것도 많다. 하지만 이거를 핑계 삼아 우리가 일하는 프로그래밍 환경을 방치해두는 건 말이 안된다. 어떤 환경이든 더 나은 곳으로 발전할 수 있기 때문이다. 개발 환경을 더 발전 시키기 위해 고려해볼 만한 것들은: * 모듈식 사고: 각 모듈을 제대로 설계해서 결합도를 낮추고 직교성 (독립성)을 높여라 * 디자인 원칙: 마이크로 레벨에서 검증된 디자인 패턴이나 원칙을 적용해라. ex) SOLID 원칙 * 테스트 자동화: 좋은 단위 테스트를 작성하고 필요 시 적절한 mocking 기법을 활용해서 비즈니스 로직의 핵심을 테스트하고 자동화해라 * 피드백 사이클을 빠르게 해라: 더 빠른 컴파일 툴을 사용하고, 단위 테스트를 최적화해라. 피드백을 얻기까지의 시간을 단축할 수 있는 것이 있다면 뭐든지 가리지 말고 다 반영해라 * 마이크로서비스 아키텍처: 필요 시 모놀리식한 서비스를 더 작은 서비스 여러 개로 분리 시켜 책임을 나누고 복잡성을 분산 시켜라 시행착오를 더 쉽게 경험하고, 더 개발하기 편한 환경을 구축하면 LeetCode 문제들을 푸는 것처럼 현업에서도 재미를 얻을 수 있다. 이런 환경을 구축하는 건 경력 있는 개발자들이 팀을 위해 기여할 수 있는 최고의 방법 중 하나다. 4) 코드 완벽주의에 빠지지 마라 코드 퀄리티를 추구하는건 칭찬 받아 마땅하다. 다만, 완벽주의에 빠지지 않도록 경계해야 한다. 코딩은 완벽함을 끊임없이 추구하는 예술 작품이 아니다. 작가는 글의 완성도를 높이기 위해 수년 동안 걸작을 붙들고 있을 수 있지만, 프로그래머가 이런 완벽함을 추구한다면 문제가 된다. 완벽한 코드는 없다. 대부분 비즈니스 요구 사항을 충족하고 발전의 여지가 있는 코드라면 배포해도 된다. 가끔 “클린 코드에 충실함” 이라는 문구를 이력서에서 볼 때면 얼마나 코드 퀄리티에 진심인지 와닿으면서 한편으로는 완벽주의자가 아니길 빈다. 5) 기술은 중요하다. 하지만 사람이 더 중요할 때도 있다 Single Responsibility Principle (SRP, 단일 책임 원칙)은 소프트웨어 개발에서 유명한 원칙이다. 이는 곧 “모든 소프트웨어 모듈은 단 한 가지 이유로만 변경되어야 한다.” 라는 문장으로 해석할 수 있다. SRP는 결국 무엇이 “변경”을 유발하는지 이해하는 것이 핵심이다. 프로그램은 스스로 변경할 수 없다. 변경을 요구하는 건 사람이다. 예를 들어보자면, 아래 두 가지 클래스에서 SRP를 위반하는 것은 무엇일까? * Dictionary 데이터 클래스: 데이터 저장, 데이터 조회를 지원한다 * Employee 클래스: 개인정보 수정, 사용자 프로필 카드 렌더링을 지원한다 대부분, 전자는 괜찮다고 생각하지만 후자는 SRP를 위반한다고 생각한다. 이는 거의 직관적으로 알 수 있는데 그 이유를 좀 더 생각해보면 왜 그런지 알 수 있다. 후자의 경우 변경을 유발하는 주체가 다수기 때문이다. 예를 들면, * 매니저는 프로필에 있는 “핸드폰” 항목에 숫자 외에 허용되지 않은 문자가 들어가면 안된다고 생각해서 간단한 검증 로직을 추가할 것을 요구했다 * Employee (직원)는 프로필에서 이름 영역이 너무 작은 것 같아 폰트 크기를 키워줄 것을 요구했다 “변경을 요구하는 건 사람이다. 서로 다른 이유로 변경되어야 할 코드를 섞어서 다른 사람들을 헷갈리게 하지 말아라” - 단일 책임 원칙 SRP를 제대로 이해하려면 사람들을 이해하고 이들이 소프트웨어 개발에서 어떤 역할인지 생각해봐야 한다. 다른 예시로는 마이크로서비스 아키텍처가 있다. 알다시피 MSA는 근 몇 년 동안 핫토픽이었다. 애석하게도 많은 글들이 기술적인 관점에서 MSA를 분석하고 논했을 뿐, MSA와 사람의 관계에 집중하는 글은 많이 못 봤다. MSA의 본질은 감당하기 힘든 거대한 모놀리식한 서비스를 여러 개의 서비스로 분할하는 것이다. 이는 거대한 모놀리식 서비스에 몇 백 개의 개발팀이 붙어서 일하는 것보다 서비스를 나누고 담당 팀을 나눠서 일을 하는 것이 더 효율적이기 때문이다. MSA와 같은 기술적인 개념을 논하면서 사람을 고려하지 않는 것은 이치에 맞지 않는다. 기술은 중요하다. 기술을 다루는 사람으로서 저명한 아키텍처나 신기하고 유용한 코드를 보면 흥미가 가는 것은 당연지사다. 하지만 “사람”을 소프트웨어 개발에서 빼놓지는 말자. 때로는 기술 중심 관점을 사람 중심으로 바꿔보는 것도 엄청난 차이를 만들 수 있다. --- (TBC) 원글: https://www.piglei.com/articles/en-programming-is-still-hard-after-14-years/