Why 99% of People Fail to Learn to Code
Medium
지난 8월 2일, 인프콘 2024에서 이일민님이 클린 스프링
이라는 주제로 강연했다. 강연을 통해 클린 코드는 단순히 코드의 가독성이나 스타일을 넘어서, 소프트웨어의 유지보수성(maintainability), 생산성(productivity), 협력(teamwork)과 깊이 연결되어 있으며, 이를 통해 소프트웨어 개발 전 과정에서 품질을 높이고 비용을 낮추며, 개발자 경험(developer experience)을 끌어올릴 수 있다고 전했다.
강연 내용에 견해를 덧붙여 기록을 남겨본다.
"개발 생산성과 유지보수성은 서로 영향을 주는 관계이다"
클린 코드는 읽기 쉽고, 이해하기 쉬우며, 확장성과 유지보수성이 뛰어난 코드를 의미한다. 클린 코드는 조직 생산성 향상과 소프트웨어 품질 유지에 중요한 역할을 한다. 유지보수성은 소프트웨어 비기능적 요구사항 중 특히 중요하다.
유지보수성은 소프트웨어의 변경 용이성을 의미하며, 이는 코드의 유연성, 모듈성, 비용 효율성 등 여러 측면에 긍정적인 영향을 미친다. 유지보수성이 높을수록 시스템을 확장하거나, 보안을 강화하거나, 성능을 향상시키는 등의 다양한 요구 사항에 유연하게 대응할 수 있다. 반대로 유지보수성이 낮은 시스템에서는 기능 변경이 어려워지고, 그로 인해 개발 비용이 증가한다. 이는 조직 내(또는 조직 간) 갈등을 초래할 수 있으며, 궁극적으로는 소프트웨어(제품)의 가치를 떨어뜨릴 수 있다.
유지보수성이 높은 소프트웨어는 조직에 긍정적인 개발자 경험을 제공한다. 코드를 쉽게 변경할 수 있게 함으로써 소프트웨어 엔지니어가 더 효율적으로 작업할 수 있도록 돕고, 이는 생산성 향상과 조직 전체의 성과에 긍정적인 영향을 미친다. 이처럼 유지보수성과 생산성은 상호 보완적인 관계이다. 유지보수성이 뛰어난 코드는 변경이 쉬워 생산성을 높이고, 코드 품질을 향상시키며, 기술 부채를 줄인다.
잘 설계된 코드베이스 구조는 구성 요소 간의 결합도를 낮추고 응집도를 높여 유지보수성 향상에 큰 도움이 된다. 쉽게 탐색 가능하고 의존성이 명확한 코드베이스는 유지보수를 용이하게 한다. 또한, 지속적인 리팩토링을 통해 코드 중복을 제거하고, 설계 원칙을 준수하며, 코드 품질을 개선하여 기술 부채를 줄이고 장기적인 유지보수성을 확보할 수 있다. 이러한 노력은 생산성과 소프트웨어 품질 사이의 균형을 유지하며, 시스템의 지속적인 발전을 가능하게 한다.
"항상 친절하세요. 동료에게, 자신에게"
클린 코드는 유지보수성과 생산성을 넘어, 협력과도 연결된다. 클린 코드는 조직 내 협력을 촉진하고, 코드베이스를 함께 관리하며 발전시키는 토대가 된다. 조직 내 코드 리뷰나 공동 작업 시 명확하고 유지보수하기 쉬운 코드는 원활한 의사소통과 생산성 향상에 기여한다.
소프트웨어 개발의 중심에는 '친절함'이 있어야 한다. 이는 코드가 다른 동료들이 쉽게 이해하고 수정할 수 있도록 작성되어야 한다는 것을 의미한다. 다양한 경험과 배경을 가진 사람들이 함께 일하는 조직에서 클린 코드는 서로에 대한 배려와 존중을 표현하는 중요한 방식이다. 따라서, 클린 코드를 작성하는 것은 단지 기술적인 측면뿐만 아니라, 조직의 개발 문화를 개선하고, 구성원 간의 신뢰를 쌓는 과정이기도 하다.
"코드는 기계를 위한 것이 아니라 사람을 위한 것"이라는 점, 그 사람은 나뿐 아니라 함께 협력하고 있는 동료들을 포함하고 있음을 강조하신 것이 인상 깊었다. 이는 단순한 기술 조언을 넘어, 삶의 지혜로 다가왔다. 소프트웨어 엔지니어로서, 그리고 한 사람의 인간으로서 성장할 수 있는 길을 보여줬다. 이러한 따뜻한 멘토의 존재가 우리 개발 커뮤니티에 있어 큰 자부심을 느꼈다.
다음 내용이 궁금하다면?
이미 회원이신가요?
2024년 8월 4일 오전 3:24
안녕하십니까! 토비님의 강연은 보지 못했지만 클린코드에 대한 항상 의문이 있어 첨언을 구하고자 질문을 하나 남깁니다. 질문! 저도 '이쁜 것'을 선호하지만 클린 코드와 유지보수성을 봤을 때 항상 드는 질문있습니다! 1. 어디까지 친절할 것인가? 즉, 기술부채를 어디까지 감당할 것인가? - 친절하기 위한 역량이 부족하다면 - 당장 친절하기 위한 방법을 모른다면 알 때까지 개발을 멈춘다? - 제대로 모르고 사용한 것이 과연 클린코드인가? - 친절하기 위한 비용이 너무 비싸다면 - 기존 레거시 코드가 너무 구려서 리펙토링 엄두가 나지 않는다면? - 그렇다고 새로 만들기엔 너무 일정이 빡빡하다면? 2. 그렇다면 조직원들에게 어떻게 딜리버리 할 것인가? (저의 고민들) - 시작 시점이라면: 애초에 조직원 구성원의 필수 및 핵심 역량으로 클린코드를 넣고 검증한다. (과제 테스트) - 이미 구성된 조직이 있다면: - 역량 상승을 위해 하드 러닝을 시킨다? (언제까지 기다려줄것인가) - 조직원들은 따라올 것인가? - 지속적인 발전시키고자 한다. - 과정에 있는 조직원들은 오히려 퍼포먼스가 떨어질 것 같다. 장기적인 관점에서 이뻐야한다는 것은 맞는 말이라 생각하는데 그렇다면 '언제까지', '얼마나 친절해야 하는가?' 라는 의문에 대한 이야기가 혹시 있었을까요?? 저는 사실상 신규 기능을 폭발적으로 늘리고 고객의 반응을 통해 비즈니스 모델 및 정체성을 확립해 나가는 초기 스타트업에서 클린코드는 욕심이다 라는 생각이 있습니다. 나아가 클린코드 보다 클린코드를 할 수 있는 환경과 프로세스가 더 중요한 것 같다고 생각하는데 관련된 내용들은 언급된 것이 있을까요?
안녕하세요. 여러가지 많은 맥락이 질문에 녹아들어 있어 답해드리는게 쉬울 것 같지 않아 걱정스럽지만, 최선을 다해 답글을 써보겠습니다. 우선 질문자께서는 구체적으로 바로 적용할 수 있는 답을 찾고 있으신것 같습니다. 아쉽게도 강연은 클린 코드를 대하는 태도에 대한 내용이 중심이기 때문에 원하시는 답은 찾기는 어려울것 같습니다. 토비님이 운영하시는 디스코드 채널을 통해 토론으로 답을 찾아보시는 것도 권해드려보고 싶습니다. 디스코드 서버는 https://discord.gg/Hxw5PeFv 를 통해 접근하실 수 있습니다. 강연에서 토비님이 전달하고자 했던 것을 드려보겠습니다. 다만 추후 토비님의 강연이 인프런을 통해 공유되면 보신 후 다시 생각해보시길 권해드립니다. 이 답글은 제 개인의 생각이 많이 섞일 것 같습니다. 클린 코드의 많은 원칙은 동료 개발자들과의 협력을 바탕에 두고 있습니다. 클린 코드는 단순히 시스템의 유지보수성이나 개인의 작업 효율을 높이는 것이 아니라, 팀 전체가 함께 작업할 수 있도록 도와주는 도구입니다. 따라서 나만을 위한 코드가 아니라, 팀원 모두가 이해하고 함께 발전시킬 수 있는 코드를 작성하는 것이 중요합니다. 하지만 우리는 다양한 경험과 배경을 가진 사람들이 모여 팀을 이루고 있습니다. 때문에 클린 코드에 대한 생각도 모두가 다릅니다. 그래서 클린 코드의 원칙을 고정된 규칙이 아니라, 팀의 상황과 필요에 따라 유연하게 적용될 수 있는 가이드라인으로 사용해야 합니다. 이는 팀이 직면한 문제와 환경에 맞춰 최적의 방법을 선택할 수 있도록 돕는 역할을 합니다. 팀원 간의 열린 대화와 협력을 통해 클린 코드를 어떻게 적용할지 결정하는 과정이 필요합니다. 이 과정에서 토비님이 제안한 두 가지 요소가 "탐험"과 "친절"입니다. 팀과 함께 결정하고 탐험하고 학습하고 성장해야 하며, 친절로 팀원 간의 신뢰를 쌓고, 협력의 문화를 형성해야 합니다. 기술부채는 소프트웨어 개발 과정에서 의도적으로 단기적인 해결책을 선택하고, 이를 나중에 개선하거나 리팩터링해야 할 필요가 있는 상황을 비유적으로 표현한 개념입니다. 이는 소프트웨어 개발에서 불가피한 선택일 수 있지만, 이를 인식하고 관리하는 것이 중요합니다. 또한, 기술부채는 단기적인 필요를 충족시키는 도구일 뿐, 코드 품질을 희생하거나 변명하는 수단으로 사용되어서는 안됩니다. 이는 기술부채라는 용어를 만든 워드 커닝햄(Ward Cunningham)의 의도와 일치합니다. 클린 코드의 가장 중요한 특징 중 하나는 유지보수성이 뛰어나다는 점입니다. 유지보수성이 좋은 코드는 수정이나 확장이 용이하기 때문에, 새로운 요구사항이 생기거나 기존 기능에 변경이 필요할 때도 쉽게 대응할 수 있습니다. 이는 곧 코드의 변경 가능성을 높여줍니다. 그리고 변경 가능성이 높은 코드는 필요한 수정이나 추가 작업을 빠르게 진행할 수 있기 때문에, 개발 생산성이 자연스럽게 향상됩니다. 개발자가 복잡한 코드 구조에 얽매이지 않고 필요한 작업을 신속하게 처리할 수 있기 때문에, 팀의 전반적인 효율성이 높아집니다. 클린 코드를 유지하고, 변경 가능성을 높이기 위해서는 리팩터링이 필수적입니다. 리팩터링은 기존의 코드를 보다 깔끔하고 효율적으로 개선하는 과정으로, 이를 통해 코드의 품질을 지속적으로 높일 수 있습니다. 리팩터링은 클린 코드의 선순환을 유지하는 동력으로 작용하며, 이는 결국 소프트웨어의 장기적인 성공과 높은 생산성을 보장합니다. 결론적으로 개발 생산성이 필요하다면, 유지보수성이 좋은 코드를 작성해야 하며, 클린 코드는 유지보수성이 좋고, 변경 가능성이 높은 코드를 작성하는데 도움이 된다고 정리할 수 있을 것 같습니다. 이 답글이 충분한 답이 되기는 어려울 것 같지만, 생각을 정리하시는데 조금이라도 도움이 되셨으면 좋겠습니다.
@김창환 창환님 여기서 뵙네요 ㅎㅎ 디스코드 오셔도 편하게 개발 이야기 하면서 질문하실 수 있어요~! https://discord.gg/D7uVGbcd
올
... 더 보기클
... 더 보기클라우드 환경에서의 Redis 라이센스 정책에 의해서 최근 io.valkey 에 대한 마이그레이션을 준비하고 있습니다. Valkey 는 Redis 7.4 미만 버전의 fork 서비스로 현재는 valkey 8.0 까지 release 되었지만, 저희는 아직 Valkey 7.2.x 로 테스트를 하고 있어요.
... 더 보기자
... 더 보기