Sign In
해봄의 아카이브

개발조직장은 개발만 잘하면 되는거 아님? 🤷‍♀️

Haebom
비즈니스 결과만을 중시하는 회사에서 발생하는 기술 부채와 엔지니어에 대한 비난 문제가 발생하는 상황하곤 합니다. 기술에만 몰두하여 실질적인 비즈니스 가치 개선보다는 기술적 요소에 치중하는 경향이 해외에선 다수 발생하는데 이를 이력서 중심 개발(Resume-Driven Development:RDD)이라는 용어가 나옴
💡
Résumé-Driven Development (RDD), a phenomenon describing the overemphasis of trending technologies in both job offerings and resumes as an interaction between employers and applicants.
→ 간단하게 말해서 채용 공고에 최신기술 이야기 적고 그리고 최신 기술 개척자들이 모여 사상누각을 만든다는 이야기...
RDD가 가져오는 짧은 기간의 이득과 장기적인 제품 실패 위험. 하지만, 멋있긴함. 그리고 할 말 많음.
크고 안정적인 회사일수록 더 많은 중간 관리자와 연결되어 있는 실무진과의 소통 부재가 발생
대표적인게 LOCs, PR 카운트, 티켓 수 등과 같은 비효율적인 지표 사용
필요 이상의 티켓 생성, 무의미한 PR 사이클 촉진, 핵심 비즈니스 로직 외적인 최적화 논쟁
실제로 일어난 사례라고 하면...
서비스 지향 아키텍처(SoA:PostgreSQL, Django)나 GraphQL과 같은 것들의 현재 상황
마이크로서비스, JS 프론트엔드 프레임워크의 높은 이질성과 시간, 비용 낭비 (결국 Next.js?)
기술 부채 발생 없이 가치 있는 비즈니스 로직에 집중할 수 있는 조직적 구조와 정책의 필요하긴 한데 거의 고양이 목에 방울 달기. 구조와 정책이 개발자들을 복잡한 기술 도입으로 이끄는 방식의 문제 인식되는 것도 한 몫 함. CTO가 단순 기술적 전문성이 아닌 사업적 전문성도 가져야 한다는 생각
기술과 비즈니스 사이의 균형 잡힌 접근 방법을 찾는 것이 기업의 지속 가능한 성장과 혁신에 필수적. 또한, 이러한 문제를 해결하기 위한 구체적인 방안에 대해 다양한 커뮤니티에서의 토론이 필요. 비즈니스 로직에 집중하는 것이 기술적 혁신과 어떻게 조화를 이룰 수 있는지에 대한 심도 있는 논의를 해보면 어떨까? 하는 망상. 물론 정답은 없음.
Subscribe to 'haebom'
Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'haebom'!
Subscribe