<div id="readability-page-1" class="page"><div><h2 id="개발자는-비즈니스-요구사항을-구현하는-근로자입니다">개발자는 비즈니스 요구사항을 구현하는 근로자입니다</h2>
자극적인 제목으로 시작했지만, 이 글은 클린 코드를 비판하려는 것이 아닙니다. 오히려 좋은 코드를 작성하는 능력과 회사에서 인정받는 것이 항상 일치하지 않는다는 불편한 현실에 대해 이야기하고 싶습니다.
우리는 개발자입니다. 동시에 회사에 고용된 근로자이기도 합니다. 이 두 가지 정체성 사이에서 종종 혼란을 겪습니다. "나는 좋은 개발자인가?"라는 질문과 "나는 회사에 가치를 주는 직원인가?"라는 질문의 답이 항상 같지는 않기 때문입니다.
회사는 우리를 고용할 때 "기술적으로 훌륭한 코드를 작성해주세요"라고 말하지 않습니다. 그들이 원하는 것은 비즈니스 문제를 해결하는 것입니다. 코드는 그 문제를 해결하기 위한 수단일 뿐입니다.
<h2 id="회사는-나의-기술적-우아함을-펼치는-곳이-아닙니다">회사는 나의 기술적 우아함을 펼치는 곳이 아닙니다</h2>
솔직히 인정하기 어렵지만, 회사는 내가 배운 디자인 패턴을 실험하는 곳이 아닙니다. 최신 아키텍처를 적용해보고 싶은 욕구를 해소하는 곳도 아닙니다. 완벽한 추상화를 추구하며 리팩토링에 몰두하는 것이 항상 환영받지도 않습니다.
저도 과거에 이런 실수를 했습니다. "이 코드는 유지보수하기 어려우니 리팩토링이 필요합니다"라고 주장하며 일주일을 투자해 코드를 정리한 적이 있습니다. 기술적으로는 훨씬 나아졌지만, 그 일주일 동안 비즈니스 요구사항은 밀렸고, 팀의 스프린트 목표 달성에 기여하지 못했습니다.
또 다른 프로젝트에서는 기술적으로 훌륭한 기능들을 개발했습니다. 내부 아키텍처도 견고하게 설계하려고 공들였고, 2주간 온전히 그 작업에만 집중했습니다. 하지만 사용자 인터뷰를 진행해보니, 아무도 그 기능을 사용하지 않았습니다. 기술적으로 완벽했지만, 사용자가 필요로 하지 않는 것이었습니다. 결국 저는 팀의 소중한 시간과 리소스를 낭비한 셈이었습니다.
물론 기술 부채를 관리하는 것은 중요합니다. 하지만 그 타이밍과 범위는 비즈니스 맥락에서 결정되어야 합니다. "지금 당장 이 리팩토링을 하지 않으면 6개월 뒤에 이런 문제가 생깁니다" 또는 "3개월을 투자하여 디자인 시스템을 만들면 지금보다 2배 빠르게 UI를 만들 수 있습니다." 라고 비즈니스 언어로 설득할 수 있어야 합니다.
<h2 id="시니어가-될수록-비즈니스-성과가-중요해집니다">시니어가 될수록 비즈니스 성과가 중요해집니다</h2>
주니어 개발자일 때는 "코드를 잘 짜는가"가 중요한 평가 기준입니다. 하지만 시니어로 올라갈수록 평가 기준이 달라집니다. 경영진이 정한 비즈니스 방향에 맞춰서 성과를 만들어냈는가가 훨씬 더 중요해집니다.
시니어 개발자에게 기대하는 것은 단순히 복잡한 기술 문제를 해결하는 능력만이 아닙니다. 어떤 문제를 해결해야 하는지 판단하는 능력, 제한된 리소스로 최대의 비즈니스 가치를 만들어내는 능력, 기술적 결정이 비즈니스에 미치는 영향을 설명하는 능력이 필요합니다.
아무리 기술적으로 훌륭한 시스템을 만들어도, 그것이 회사의 비즈니스 목표와 맞지 않다면 인정받기 어렵습니다. 반대로 기술적으로는 완벽하지 않더라도, 빠르게 시장에 출시하여 비즈니스 기회를 잡는 것이 더 높이 평가받을 수 있습니다.
이것이 불공평하다고 느껴질 수 있습니다. 하지만 회사의 존재 이유가 이윤 창출이라는 점을 생각하면, 이해할 수 있는 구조입니다.
<h2 id="기여자로-남는-것도-쉽지-않습니다">기여자로 남는 것도 쉽지 않습니다</h2>
이러한 현실 속에서 시니어나 리더가 되는 것을 포기하는 개발자분들을 많이 봐왔습니다. 비즈니스 성과보다는 기술적 기여에 집중하며, Individual Contributor(IC)로 계속 남는 것이죠.
이 방향도 틀린 것은 아닙니다. 다만 훌륭한 기술 기여자로 오랫동안 남는 것은 생각보다 쉽지 않은 길입니다. 시장에서 그 자리(seat)는 적고, 경쟁자는 많습니다. 끊임없이 기술 트렌드를 따라가야 하고, 젊고 열정적인 개발자들과 경쟁해야 합니다.
결국 어떤 길을 선택하든 쉬운 길은 없습니다. 중요한 것은 자신이 어떤 방향으로 성장하고 싶은지 명확히 인식하고, 그에 맞는 전략을 세우는 것입니다.
<h2 id="그렇다면-기술적-열망은-어디서-해소해야-할까요">그렇다면 기술적 열망은 어디서 해소해야 할까요?</h2>
그렇다고 기술적 성장을 포기하라는 말은 아닙니다. 오히려 기술적 역량은 개발자로서의 커리어를 위해 반드시 갖춰야 할 기반입니다. 다만 그 역량을 어디서, 어떻게 발휘할지에 대한 전략이 필요합니다.
제 생각에는 기술적 훌륭함을 추구하는 가장 적절한 공간은 오픈소스와 사이드 프로젝트입니다.
오픈소스에서는 비즈니스 압박 없이 기술적 완성도를 추구할 수 있습니다. 커뮤니티의 피드백을 받으며 더 나은 설계를 고민할 수 있습니다. 최신 기술을 실험하고, 실패해도 괜찮습니다. 그 과정에서 쌓인 경험과 평판은 결국 커리어에도 긍정적인 영향을 미칩니다.
사이드 프로젝트도 마찬가지입니다. 내가 결정권자이기 때문에, 기술적으로 시도해보고 싶었던 것들을 마음껏 해볼 수 있습니다. "이 프로젝트에서는 TDD를 철저히 지켜보자", "이번에는 함수형 프로그래밍 패러다임을 적용해보자" 같은 기술적 도전을 제약 없이 시도할 수 있습니다.
<h2 id="균형을-찾는-것이-중요합니다">균형을 찾는 것이 중요합니다</h2>
결국 중요한 것은 균형입니다. 회사에서는 비즈니스 가치를 중심으로 일하되, 개인적인 기술 성장은 별도의 공간에서 추구하는 것입니다.
회사에서 기술적 우아함을 완전히 포기하라는 것은 아닙니다. 다만 그것이 목적이 아니라 수단이 되어야 합니다. "이 리팩토링이 6개월 뒤 개발 속도를 30% 높여줄 것입니다"처럼 비즈니스 가치로 연결할 수 있어야 합니다.
기술적으로 훌륭한 개발자가 되고 싶은 욕구와, 회사에서 인정받는 직원이 되어야 하는 현실 사이에서 많은 개발자들이 갈등합니다. 저도 그랬고, 아마 지금도 완전히 해결된 것은 아닙니다.
하지만 이 두 가지가 다른 공간에서 추구되어야 할 가치라는 것을 인식하는 것만으로도, 그 갈등이 조금은 줄어들 수 있다고 생각합니다.
<h2 id="마무리">마무리</h2>
클린 코드는 중요합니다. 좋은 아키텍처도 중요합니다. 하지만 그것이 언제, 어디서, 얼마나 중요한지는 맥락에 따라 다릅니다.
회사에서는 비즈니스 성과를 만들어내는 개발자가 되고, 개인 시간에는 기술적 완성도를 추구하는 개발자가 되는 것. 이것이 제가 찾은 답입니다.
물론 이것이 유일한 정답은 아닐 겁니다. 기술적 탁월함을 최우선으로 추구하는 회사도 있고, 그런 환경에서 일하는 것이 맞는 사람도 있습니다. 중요한 것은 나에게 맞는 균형점을 찾는 것입니다.
여러분은 어떻게 생각하시나요?
<a href="https://doong-jo.github.io/posts/%ED%81%B4%EB%A6%B0%EC%BD%94%EB%93%9C%EB%A5%BC_%EA%B5%AC%ED%98%84%ED%95%98%EC%85%A8%EB%8B%A4%EA%B5%AC%EC%9A%94_%EC%B6%95%ED%95%98%ED%95%A9%EB%8B%88%EB%8B%A4_%ED%95%98%EC%A7%80%EB%A7%8C_%EB%8B%B9%EC%8B%A0%EC%9D%80_%ED%95%B4%EA%B3%A0%EC%9E%85%EB%8B%88%EB%8B%A4.html">원문 링크</a></div></div>

sdong001.log

개발자는 비즈니스 요구사항을 구현하는 근로자입니다
자극적인 제목으로 시작했지만, 이 글은 클린 코드를 비판하려는 것이 아닙니다. 오히려 좋은 코드를 작성하는 능력과 회사에서 인정받는 것이 항상 일치하지 않는다는 불편한 현실에 대해 이야기하고 싶습니다.
우리는 개발자입니다. 동시에 회사에 고용된 근로자이기도 합니다. 이 두 가지 정체성 사이에서 종종 혼란을 겪습니다. "나는 좋은 개발자인가?"라는 질문과 "나는 회사에 가치를 주는 직원인가?"라는 질문의 답이 항상 같지는 않기 때문입니다.
회사는 우리를 고용할 때 "기술적으로 훌륭한 코드를 작성해주세요"라고 말하지 않습니다. 그들이 원하는 것은 비즈니스 문제를 해결하는 것입니다. 코드는 그 문제를 해결하기 위한 수단일 뿐입니다.
회사는 나의 기술적 우아함을 펼치는 곳이 아닙니다
솔직히 인정하기 어렵지만, 회사는 내가 배운 디자인 패턴을 실험하는 곳이 아닙니다. 최신 아키텍처를 적용해보고 싶은 욕구를 해소하는 곳도 아닙니다. 완벽한 추상화를 추구하며 리팩토링에 몰두하는 것이 항상 환영받지도 않습니다.
저도 과거에 이런 실수를 했습니다. "이 코드는 유지보수하기 어려우니 리팩토링이 필요합니다"라고 주장하며 일주일을 투자해 코드를 정리한 적이 있습니다. 기술적으로는 훨씬 나아졌지만, 그 일주일 동안 비즈니스 요구사항은 밀렸고, 팀의 스프린트 목표 달성에 기여하지 못했습니다.
또 다른 프로젝트에서는 기술적으로 훌륭한 기능들을 개발했습니다. 내부 아키텍처도 견고하게 설계하려고 공들였고, 2주간 온전히 그 작업에만 집중했습니다. 하지만 사용자 인터뷰를 진행해보니, 아무도 그 기능을 사용하지 않았습니다. 기술적으로 완벽했지만, 사용자가 필요로 하지 않는 것이었습니다. 결국 저는 팀의 소중한 시간과 리소스를 낭비한 셈이었습니다.
물론 기술 부채를 관리하는 것은 중요합니다. 하지만 그 타이밍과 범위는 비즈니스 맥락에서 결정되어야 합니다. "지금 당장 이 리팩토링을 하지 않으면 6개월 뒤에 이런 문제가 생깁니다" 또는 "3개월을 투자하여 디자인 시스템을 만들면 지금보다 2배 빠르게 UI를 만들 수 있습니다." 라고 비즈니스 언어로 설득할 수 있어야 합니다.
시니어가 될수록 비즈니스 성과가 중요해집니다
주니어 개발자일 때는 "코드를 잘 짜는가"가 중요한 평가 기준입니다. 하지만 시니어로 올라갈수록 평가 기준이 달라집니다. 경영진이 정한 비즈니스 방향에 맞춰서 성과를 만들어냈는가가 훨씬 더 중요해집니다.
시니어 개발자에게 기대하는 것은 단순히 복잡한 기술 문제를 해결하는 능력만이 아닙니다. 어떤 문제를 해결해야 하는지 판단하는 능력, 제한된 리소스로 최대의 비즈니스 가치를 만들어내는 능력, 기술적 결정이 비즈니스에 미치는 영향을 설명하는 능력이 필요합니다.
아무리 기술적으로 훌륭한 시스템을 만들어도, 그것이 회사의 비즈니스 목표와 맞지 않다면 인정받기 어렵습니다. 반대로 기술적으로는 완벽하지 않더라도, 빠르게 시장에 출시하여 비즈니스 기회를 잡는 것이 더 높이 평가받을 수 있습니다.
이것이 불공평하다고 느껴질 수 있습니다. 하지만 회사의 존재 이유가 이윤 창출이라는 점을 생각하면, 이해할 수 있는 구조입니다.
기여자로 남는 것도 쉽지 않습니다
이러한 현실 속에서 시니어나 리더가 되는 것을 포기하는 개발자분들을 많이 봐왔습니다. 비즈니스 성과보다는 기술적 기여에 집중하며, Individual Contributor(IC)로 계속 남는 것이죠.
이 방향도 틀린 것은 아닙니다. 다만 훌륭한 기술 기여자로 오랫동안 남는 것은 생각보다 쉽지 않은 길입니다. 시장에서 그 자리(seat)는 적고, 경쟁자는 많습니다. 끊임없이 기술 트렌드를 따라가야 하고, 젊고 열정적인 개발자들과 경쟁해야 합니다.
결국 어떤 길을 선택하든 쉬운 길은 없습니다. 중요한 것은 자신이 어떤 방향으로 성장하고 싶은지 명확히 인식하고, 그에 맞는 전략을 세우는 것입니다.
그렇다면 기술적 열망은 어디서 해소해야 할까요?
그렇다고 기술적 성장을 포기하라는 말은 아닙니다. 오히려 기술적 역량은 개발자로서의 커리어를 위해 반드시 갖춰야 할 기반입니다. 다만 그 역량을 어디서, 어떻게 발휘할지에 대한 전략이 필요합니다.
제 생각에는 기술적 훌륭함을 추구하는 가장 적절한 공간은 오픈소스와 사이드 프로젝트입니다.
오픈소스에서는 비즈니스 압박 없이 기술적 완성도를 추구할 수 있습니다. 커뮤니티의 피드백을 받으며 더 나은 설계를 고민할 수 있습니다. 최신 기술을 실험하고, 실패해도 괜찮습니다. 그 과정에서 쌓인 경험과 평판은 결국 커리어에도 긍정적인 영향을 미칩니다.
사이드 프로젝트도 마찬가지입니다. 내가 결정권자이기 때문에, 기술적으로 시도해보고 싶었던 것들을 마음껏 해볼 수 있습니다. "이 프로젝트에서는 TDD를 철저히 지켜보자", "이번에는 함수형 프로그래밍 패러다임을 적용해보자" 같은 기술적 도전을 제약 없이 시도할 수 있습니다.
균형을 찾는 것이 중요합니다
결국 중요한 것은 균형입니다. 회사에서는 비즈니스 가치를 중심으로 일하되, 개인적인 기술 성장은 별도의 공간에서 추구하는 것입니다.
회사에서 기술적 우아함을 완전히 포기하라는 것은 아닙니다. 다만 그것이 목적이 아니라 수단이 되어야 합니다. "이 리팩토링이 6개월 뒤 개발 속도를 30% 높여줄 것입니다"처럼 비즈니스 가치로 연결할 수 있어야 합니다.
기술적으로 훌륭한 개발자가 되고 싶은 욕구와, 회사에서 인정받는 직원이 되어야 하는 현실 사이에서 많은 개발자들이 갈등합니다. 저도 그랬고, 아마 지금도 완전히 해결된 것은 아닙니다.
하지만 이 두 가지가 다른 공간에서 추구되어야 할 가치라는 것을 인식하는 것만으로도, 그 갈등이 조금은 줄어들 수 있다고 생각합니다.
마무리
클린 코드는 중요합니다. 좋은 아키텍처도 중요합니다. 하지만 그것이 언제, 어디서, 얼마나 중요한지는 맥락에 따라 다릅니다.
회사에서는 비즈니스 성과를 만들어내는 개발자가 되고, 개인 시간에는 기술적 완성도를 추구하는 개발자가 되는 것. 이것이 제가 찾은 답입니다.
물론 이것이 유일한 정답은 아닐 겁니다. 기술적 탁월함을 최우선으로 추구하는 회사도 있고, 그런 환경에서 일하는 것이 맞는 사람도 있습니다. 중요한 것은 나에게 맞는 균형점을 찾는 것입니다.
여러분은 어떻게 생각하시나요?
원문 링크

클린 코드를 구현하셨다구요? 축하합니다. 하지만 당신은 해고입니다.

댓글