나는 개발을 못 해서 프로그래밍 코드를 들여다보면 나에겐 이건 마치 단어만 몇 개 알고 있는 외국어랑 비슷하다. 하지만, 사람들을 자주 만나고 이야기하다 보니, 좋은 개발력을 가진 창업가들을 알아보는 눈은 어느 정도 갖춰졌다고 생각한다. 우리가 투자한 회사의 많은 대표들이 개발 능력이 있는 분들인데, 이분들 중 정말 뛰어난 개발자이고, 동시에 뛰어난 창업가라고 할 수 있는 분들이 한 5명 정도 된다. 이런 분들은 개발 능력도 좋지만, 모든 걸 코드로 보는 제한된 시각에서 벗어나서, 모든 걸 비즈니스와 사업으로 보는 시각과 능력까지 겸비한 분들이다. 이런 분들은 찾기가 쉽지 않다. 사업 능력이 뛰어난 분들은 개발 실력이 아쉽고, 개발 능력이 뛰어난 분들은 비즈니스 감각이 대부분 모자란다.
개발과 사업 능력이 좋은 분과 얼마 전에 오랜만에 오랫동안 이야기를 했다. 내가 직접 경험해보지 못 한 스타트업의 개발 조직을 운영한 경험에 대해 많은 배움이 있었던 대화였는데, 이 중 내가 굉장히 공감했던 내용에 대해서 몇 자 적어보고 싶다.
개발팀원, 개발팀장, 개발임원, 그리고 직접 창업까지, 많은 역할을 경험한 이 지인이 지적하는 전 세계 개발자들이 간과하는 게 바로 모든 개발자들은 이들이 속한 회사의 조직원이라는 것이다. 그리고 이들이 소속된 회사의 가장 중요한 목표는 돈을 벌 수 있는 제품과 서비스를 만드는 건데, 굉장히 많은 개발자들이 자신에게 월급을 주는 회사의 목표와는 상관없는 생각과 행동을 한다는 것이었다.
똑똑하고 능력 있는 엔지니어들은 주로 기술적으로 어렵고 난이도가 높은 문제를 해결하고 싶어 하고, 이건 나도 충분히 이해한다. 머리가 좋고 문제해결 능력이 뛰어난 분들은 당연히 일반인들은 이해도 못 하는, 난이도가 높은 문제를 해결해서 높은 가치를 만들어야 한다. 하지만, 개발자들이 항상 명심해야 하는 건 바로 이들이 해결하고자 하는 문제의 솔루션이 본인들이 소속된 기업의 비즈니스 목표와 매출에 직접적으로 기여해야 한다는 점이다. 지금까지 그 누구도 할 수 없던 엄청난 기능을 개발했더라도, 이 기능이 회사의 KPI 달성에 전혀 기여할 수 없다면, 이건 시간과 돈 낭비다.
어떻게 생각해 보면 너무나 당연한데, 우리 주변, 또는 우리 회사의 많은 개발자들이 그냥 본인들이 풀고 싶은 문제를 풀고, 본인들이 개발하고 싶은 기능을 개발하고, 단순히 기술적으로 어려운 문제를 코드로 미화하고 싶어 한다. 단순히 엔지니어링 측면에서 보면 이게 대단하게 보일 수도 있지만, 이런 결과물들이 회사의 경영진들이 설정한 핵심 지표와 연관 없다면, 이들은 조직에 전혀 기여하지 못하고, 오히려 스타트업을 좀 먹고 있는 존재들이다. 이런 지적을 받았지만, 개선되지 않는다면 이런 분들은 회사에서 해고해야 한다. 개발자들도 회사의 조직원이고, 모든 스타트업 조직원의 목표는 단 하나다. 좋은 제품을 만들어서 돈을 버는 것이다.
우리 같은 투자자는 좋은 개발자에게 투자하는 것도 아니고, 좋은 기술에 투자하는 것도 아니다. 이 기술과 개발력이 만들 좋은 비즈니스의 가능성에 투자하는 것이다. 비즈니스와는 상관없는 코딩과 기술에만 집착하는 사람들은 회사에서 일하지 말고 그냥 학교에서 공부하거나 연구소에서 연구하는 걸 권장한다. 우리는 이 코드가 만드는 제품, 그 제품이 만드는 사업, 그리고 그 사업이 만드는 매출에만 관심 있다.
개발 그 자체만을 좋아하고, 기술 그 자체만을 좋아하고, 본인이 만드는 코드, 기능, 제품이 회사가 만드는 비즈니스에 어떻게 실질적으로 기여할지에 대해서 많이 고민하지 않는 분들은 창업하면 안 된다. 그리고 이런 분들이 조직의 개발팀장이나 CTO 자리에 있다면, 지금 당장 내보내는 게 좋다.
익명
기술을 추구하지 않는 개발자가 목표에 맞는 도구를 어떻게 잘 활용 할 수 있다는건지 이해가 안가네요
Kihong Bae
조직에 속한 개발자는 기술을 추구하는게 아니라, 조직의 목적에 맞춰서 기술을 구사해야 한다고 생각합니다. 다시 한 번 말씀드리지만, 돈을 벌어야 하는 회사는 fancy한 기술을 추구하는 실험실이 아닙니다.
익명
조직 구성원으로 함께하고 있다면 조직의 공동목표를 위해 함께 노력하는 게 맞고, 자기 하고 싶은 게 있으면 경영진을 설득하든, 설득이 안되면 나가서 본인 회사 차리면 되는 간단한 거 아닌가요? 그걸가지고 경영진 탓 직원 탓 할게 있는지 댓글들 보면 이해가 안가네요.
경영진 입장에서는 당연히 성과내고 좋은 인재들은 추가 보상을 줘서라도 붙잡으려 할거고, 실력있는 구성원 입장에서는 성과 대비 보상이 적거나, 적정한 보상을 받을 가능성이 적어보이면 이직하거나 창업하면 되는거 아닌가요?
무슨 주인의식을 가질 필요가 없으니까, 충분한 보상도 안해주니까, 경영진을 못 믿어서 열심히 할 필요도 없다?
이 말은 본인 실력이 그거밖에 안되면서 다른 핑계대는 걸로만 보이네요…참 답답합니다…
RoenissMoon
본문의 주장, 그리고 그 주장의 배경에… “우리 주변에 Software 회사가 거의 없어서” 라는 근본적인 원인이 있다고 생각합니다. 이에 대해 어떻게 생각하시는지 궁금합니다.
RoenissMoon
오해의 소지가 있는 듯하여 부연하자면,
> “이런 결과물들이 회사의 경영진들이 설정한 핵심 지표와 연관 없다면, 이들은 조직에 전혀 기여하지 못하고, 오히려 스타트업을 좀 먹고 있는 존재들이다.”
‘기술’ 그 자체가 핵심 비즈니스 아이템이 아닌 경우가 많기 때문에, 핵심 지표와 거리가 멀어지는 경우가 많이 발생하는 것 아닐까 하는 의심을 해보았습니다.
ㅇㅇ
동의하지않습니다. 무슨 주인의식을 ㅋㅋㅋ개발자가 매출로 kpi 측정?? ㅋㅋ 인프랩은 그렇게하나보네요
익명
주변에 비즈니스와 개발을 동시에 잡은 개발자 케이스들을 보면 이렇습니다.
1. 둘 다 갖췄다면 창업을 하지 않을 이유가 없습니다. 이미 가장 말 잘 듣고 비싼 인력을 한 명 고용하고 시작하는 거니까요. 초반에 얘기하셨듯 이런 분들은 이미 잘 나갑니다.
2. 그럼에도 불구하고 다른 기업에 들어갔다면
2-1. 아예 대기업에 들어가서 이미 잘 갖춰진 인프라(영업, 디자인 등)를 가지고 시작하고 싶기 때문입니다. 이런 분들은 결국 임원까지 가거나 결국 중간에 사람들을 데리고 나와 새로운 스타트업을 차리게 됩니다.
2-2. 아예 대기업에 들어가서 자신의 구상이 실패하더라도 연봉을 잘 받는 개발자가 되고 싶어합니다. 이런 분들은 자신의 구상 성공 여부와 상관 없이 개발팀에 있으면 종종 듣는 유명인이 되죠.
3. 스타트업에는 이 사람들을 부를 유인이 부족한데
3-1. 이 사람들이라면 자기가 직접 금방 갖출 수 있는 인프라만 들고 있고
3-2. 이런 사람들을 부르기에 터무니없이 적은 보상밖에 줄 수 없습니다
3-3. 요새같이 런웨이가 짧은 시대에는 기회도 별로 없고요
4. 그럼 왜 스타트업에서 이런 사람들을 부를 수 있다고 생각하죠?
연애나 결혼의 문제에서 그렇듯이, 이상형이야 얼마든지 만들어 볼 수 있는 것 아니겠습니까. 다만 그런 사람이 안 들어오고 고만고만한 사람만 온다면, 그런 사람이 우리 회사에 들어올 이유를 만들어주기 위해 노력해야겠죠.
익명
그러면 또 누군가는 대기업에 있으면 부품이 어쩌고… 스타트업에 가야 전 과정을 어쩌고… 할 거라는 건 압니다만, 그런 사람은
1. 애초에 대/중/소를 떠나 비즈니스를 이해하고 있기 때문에 결국 시기의 문제지 전 과정에 영향을 미치게 되며
2. 스타트업은 구멍가게 비즈니스라서 전 과정이래봤자 깊이가 얕아 경험할 수 없는 부분도 많습니다
익명
(펌) 투자 실패와 관리 실패를 개발자에게 돌리는 것으로 보이네요.
사업이 되려면 운과 때와 사람이 모두 만나는 지점이 있어야 되는건데 제가 보기엔 사업능력 부족이나 제대로된 팀을 꾸릴 능력이 안되어서 운과 때를 만나고도 실패하는 케이스를 더 많이 봤던 것 같습니다.
그리고 사장의 목표는 돈을 버는 것이지만 직원의 목표는 월급을 받는 것입니다. 이 차이를 모르면 관리자로서의 자격이 없다고 생각되네요. 투자자로서도 썩 바람직하지 않은 자세인 것 같습니다. 모두가 사장같이 생각하라니 그럴거면 지분부터 좀 나눠주고 시작하던지 말입니다.
익명
ㅇㅈ
익명
그러니까요 ㅋㅋㅋ 만약 비즈니스와 개발을 다 잘 하는 사람이 스타트업에 지분 하나 없이 들어가는 일이 있다면, 시장을 탐색하러 간 거거나 아니면 쓸만한 사람들이나 영업선 데리고 먹튀하려는 목적일 겁니다.
ㅇㅇ
ㅇㅈ전형적인 경영진들의 가스라이팅
Kihong Bae
이런걸 가스라이팅으로 볼 수 있다는 관점이 놀랍긴 하네요…
익명
개발자이기 이전에 회사의 회사원이다. 이부분에서 가장 크게 의견이 갈리는 점은 새로운 프레임워크나 도구를 사용하고 싶어하는 개발자와 비용을 줄이고 싶어하는 임원으로 갈린다고 생각합니다. 개발자로서 드는 생각은 초저연차 일 때(지금도 저연차지만), 새롭고 유명한 프레임워크를 사용하는게 개발자로서의 기술력이라고 생각했었는데 점점 드는 생각은 최소한의 비용으로 최대한의 효율을 내는게 개발자로서의 기술력이라고 생각되더라구요.
굳이 필요치 않으면 만들지 않아야 하고 만든다면 나중의 비용까지 계산을 할줄 알고 쉽게 바꿀수 있게 구현하는 개발자가 되어야 하겠더라구요. 지금 구현하는 수단은 언제까지(요청을 얼마까지 견딜 수 있는지) 쓸 수 있고 나중에 이 한계점을 넘어가면 어떻게 바꿔야 하는지, 그리고 이게 진짜로 필요한지 이런걸 계산을 하고 구현해내는 개발자가 되어야 겠다고 생각들더라구요. 그렇기 때문에 유연하게 개발해야 한다고 생각하구요. 결국 개발자는 집착이 없어야 한다고 생각되더라구요
익명
그리고 정말 필요하다면 설득을 해야하는 것도 개발자의 역량이라고 생각합니다. 비즈니스는 떼를 쓴다고 되야 하는건 아니니까요.
익명
시니어 엔지니어급 개발자를 구하기 위해 언리얼 엔진으로의 전면 재개발을 수행했던 팰월드의 사례처럼, 평생 구멍가게로 근근이 살아남는 게 목표가 아니라면 적당히 대세 기술을 따라가는 것도 필요하죠.
개발이 아니라도 더존같은 ERP 도입 없이 엑셀로만 주먹구구 재무를 한다면 영원히 쓸만한 재무 인력은 뽑을 수 없는 것 아니겠습니까.
정말 대세 기술을 따라가지 않을 이유가 있고 비즈니스와 개발을 겸비한 비싼 개발자를 싸게 모셔올 요량이면 그런 어려운 설득을 하는 건 대표의 역량이죠. 구인도 떼를 쓴다고 되는 건 아니잖아요.
익명
글쓴이 분 의견에 동의합니다. 그런데 개발자로서 기술적 모험을 제한받는다면 개인 입장에서는 스타트업에 갈 인센티브가 뭘까요?
익명
그게 현실이죠. 본문과 같은 역량을 지닌 인력에게는, 별 되도 않는 인력과 인프라만 있는 기업에 재직하면서 의사결정권은 이미 형성된 창업자 무리에게 있다는 게 더 리스크인지라.
MinWoo Ju
개발자로서 너무 공감가는 이야기라 댓글을 안달수가 없었네요 ㅎㅎ
저도 주니어 개발자분들에게 종종 “개발자 이전에 회사원” 이라고 생각했으면 좋겠다고 이야기해요.
비즈니스와 무관한 “좋은 코드”라는게 존재한다는 환상을 갖지 말라는 뜻이에요.
개발 언어와 방법론, 프레임워크, 라이브러리, 컨벤션 모두 결국은 도구일 뿐이고
개발을 잘한다는건 목표에 맞는 도구를 선택하고 사용하는 것이라고 생각하거든요.
보통 이걸 빨리 깨닫는 분들이 잘하는 개발자들한테 잘하는 개발자로 인정받더라구요.
AI가 발전할수록 이런 현상은 가속화될거라고 생각해요.
비즈니스(=인간)과 무관하게 코드만 붙잡고 씨름했던 분야가 AI에 가장 빨리 정복될거고
비즈니스에 따라 코딩 의사결정이 필요한 부분이 진짜 실력으로 남을 것 같아요.
항상 좋은 글 잘 읽고가요! 이번엔 특히 더 좋은 글 감사합니다.
Kihong Bae
공감해주셔서 고맙습니다. 말씀하신대로 단순 코딩은 기계가 사람을 대체하겠지만, ‘결정’ 자체는 항상 좋은 사람, 좋은 개발자, 좋은 회사원의 몫인것 같네요.
익명
어디까지나 회사에서 개인적 성취에 매몰되지 말라는 취지의 정론으로 보이지만, 이런 태도를 가진 분들의 모습이 떠올라서 공감이 되지 않는다는 게 슬픕니다.
Kihong Bae
이런 태도를 가진 분들의 모습을 조금 더 구체적으로 설명해주시면 저에게도 큰 도움이 될 것 같습니다. 고맙습니다.
익명
돈도 많이 안주면서 개인의 성장이 이루어지지 않는 회사는 갈 이유가 없죠.
엑싯하고 끝내는게 아니라면 조직원들을 성장시키는 큰 그림을 그리는 것도 필요하잖아요.
첫 문장부터 개발을 전혀 모르신다고 말씀하셔놓고 개발자들의 생각은 다 아는 듯이 글을 쓰시는게 너무 오만한 것 같네요.
익명
여기는 VC 블로그입니다. 엑싯하고 끝내는 게 목표인 곳이 맞아요 ㅎㅎ
그렇게 뜬구름 잡게 쓰시면 스타트업은 지분이 있지 않냐 뭐 그런 논쟁이 될 수밖에 없을텐데요. 여기서 문제가 되는 포인트는 그렇게 숫자로 잘 보여줄 수 있는 개발자가 자신의 기회 비용에 대해서는 숫자로 계산을 안 할 거냐는 포인트가 되겠죠.
이 글이야 그냥 개발자에 대한 이상형을 쓴 거니 그러려니 하세요. 독자들도 상식이 있을테니 현실과 적당히 타협들 하지 않겠습니까. 만약 타협 못 하고 그런 핵심 인재를 두고 너는 조직원이니 뭐니 하면서 똑같이 0.2% 주는 시장이 되면 스타트업 구인구직도 중고차 시장처럼 레몬 시장이 되는거죠 뭐.
Kihong Bae
글에서 말 한대로 저는 개발을 모르고, 개발자의 생각도 잘 모릅니다. 이건 맞습니다. 그런데 이 글은 제한된 자원으로 제품을 만들고 수익을 창출해야 하는 조직의 관점에서 개발자를 포함한 (대표적인 사례로 개발자에 대해서 썼지만, 실은 운영, 마케팅, 기획 등 모든 조직원에 적용되는 내용입니다) 다른 조직원들의 태도와 자세에 대한 내용이라고 봐주시면 좋을것 같습니다. 말씀하신대로 돈도 많이 안주면서 개인의 성장이 이루어지지 않는 회사에는 갈 이유가 없다면, 그냥 그런 조직에 안 가면 됩니다. 만약에 오롯이 본인의 선택으로 그런 조직에 몸 담고 있다면, 여기서 열심히 하거나 그냥 조직을 나오면 된다고 생각합니다.
익명
발더스 게이트3라는 2024년도 명작 게임이 있습니다. 유명한 젤다 야숨을 제치고 GOTY를 받은 게임이죠.
이 개발사 대표가 이 게임의 DLC를 만들지 않겠다고 했었는데 개발 팀이 새로운 프로젝트를 하고 싶다는 것이 이유라고 합니다
CEO를 비롯한 회사 사람들이 이 게임의 확장팩(DLC)은 돈이 된다는 것을 모르지 않았을 겁니다
하지만 개발 팀은 돈이 보장된 DLC 보다 신규 프로젝트를 원했고 회사는 이것을 존중한 것 같습니다
본문의 내용은 이해합니다. 개발자는 회사의 조직원이 맞고 회사를 위해 일을 해야 하는 것은 맞습니다. 하지만
본문의 내용 대로 (우리 나라 뿐만 아니라) 전 세계 개발자들이 그렇다면 경영자 분들이 거꾸로 더 고민해봐야 될 문제가 아닐까 하고 물어보고 싶습니다
Kihong Bae
안녕하세요. 좋은 사례와 의견 공유해주셔서 고맙습니다.
“회사는 이것을 존중한 것 같습니다” -> 저는 이 상황 자체가 회사의 경영진과 개발진간의 좋은 합의가 이루어 진거라고 생각해요. 그리고 분명히 거기서 회사의 KPI와의 연관 논의가 있었을겁니다.
익명
그렇다면 기술부채를 해결하거나 유지보수성을 높이거나 DX를 올리고자 하는 것들에 대해서는 어떻게 생각하시나요? 비즈니스적 KPI에 직접적으로 대응되는 것들은 아닌데 말이죠.
Kihong Bae
기술부채나 유지보수도 궁극적으론 회사의 핵심 KPI와 매우 밀접하게 연관되어 있습니다. 고맙습니다.
익명
근데 생각보다 한국에서 개발자 1,2명이 심심해서 만든게 회사먹여살리는 경우를 많이 봐버려서요;;
Kihong Bae
네, 이건 한국 뿐만이 아니라 다른 나라에서도 자주 보는 현상입니다. 그런데 말씀하신 부분은 제가 쓴 글의 핵심과 취지와는 상관이 없긴 합니다.
익명
나카무라 슈지의 청색 LED 건이 본문에도 해당되고 개발자 1명이 회사 먹여 살리는 케이스에도 들어갈텐데요. 제정신인 VC는 이런 데는 투자 못하고 본문 같은 조언을 남길 수밖에 없을 겁니다.
익명
이런 글들은 보통 개발팀 외 주변은 다 정상이고 같은 목표를 바라보고 있고 특정 소수만을 지정해서 좀먹는 사람 취급하더라구요. 정작 개발 외 주변 환경에서도 좀먹는 사람들이 많은데 말이죠.
글만 읽으면 다 공감하는 얘기지만 실제 회사 환경을 대입하면 공감하기가 힘들더라구요.
Kihong Bae
안녕하세요. 말씀하신 내용에 대해서 저도 생각을 좀 해 봤습니다. 실은 이 글의 내용은 개발자 뿐만 아니라 모든 조직원들에게도 적용되긴 하구요. 다만, 테크 스타트업의 경우, 개발이 매우 중요한 역할을 하기 때문에, 그리고 실제로 매출을 만드는 제품을 만드는 분들이 개발자라서 이런 포스팅을 했습니다. 좋은 의견 고맙습니다.
익명
ㅋㅋㅋ
익명
최근에 유튜브에서 봤던 기술 컨설팅 기업 유튜브 영상이 떠오르네요.
내용이 거의 비슷한 것 같습니다.
익명
?
익명
그런데 기술적으로 고도화되고 확장가능한 코드가 IT 비지니스를 횡이던 종이던 확장 역량을 키워준다는 것. 그것 또한 중요한 점을 시사하고 있어요.
고난이도의 코드와 사업의 방향성 이건 이율배반적인 관계가 아닌 오히려 리니어한 곡선을 가진 함수 관계라는 거죠.
문제는 고난이도 코드를 이해못하는 다른 사람들로 부터 정치적 압박을 받는.. 개인화된 개발자가
실질적인 조직에 대한 베네핏을 하느냐 마느냐가 아니라 “정치적인 이유로” 박해받으며 발언권도 잃고 개발의 동기 마져도 곡해 받는 일은 참으로 부당한 부분들 일 거에요.
단지 중요한 부분은 타당함과 적절성인데 개발자라는 이유만으로 박해 받아서 발언권을 뺏기는 점이 사라지면 좋겠네요.
익명
말씀이 어려워서 답변이 안 달린 것 같습니다만. 개발자들이 요게 좀 부족하죠. 개발하고 있는 아이템을 KPI화해서 보여주는 능력.
그런데 이게 되면 VC한테 투자도 잘 받을텐데요. 왜 남의 밑으로 들어가서 (본 홈페이지의 가이드에 따르면) 5년 안에 500억 가치는 되어야 대기업 사원 대비 간신히 본전 찾을 0.2% 지분 받고 남의 꿈을 이뤄주는 일을 할까요?
익명
좋은 시사점이 있는 글을 써주셔서 감사합니다.
저는 개발 팀원들이 기술자로서 성장하고자하는 마음을 채워줄 수 있도록 개발 팀장과 임원이 함께 고민하고 그 고민의 결과물을 회사의 성장과 결합시키는 과정이 중요한 것 같습니다. 각각의 위치에 따라 입장이 다른건 당연하기 때문에 회사의 이익을 위해 그 인식을 하나로 모으는 과정을 원활히 하기 위한 개발 리더의 역할이 정말 크다고 느껴지네요.
Kihong Bae
네, 저도 동의합니다. 개발 리더와 팀원, 그리고 결국엔 대표이사와 임원, 모두의 역할이 매우 중요하다고 생각합니다.
익명
이런 분들이 위에 있으면 코드는 계속 스파게티가 되어가고 실무자가 리팩토링 해야된다 말해도 뭉개고 당장 돈 벌리는 기능만 추가하려고 함. 이런분들은 개발팀장이나 CTO에 있으면 안 된다.
익명
리팩토링도 경제적인 이득때문에 하는겁니다
익명
그렇기 때문에 ‘그냥 본인들이 풀고 싶은 문제를 풀고, 본인들이 개발하고 싶은 기능을 개발하고, 단순히 기술적으로 어려운 문제를 코드로 미화하고 싶어 하는’ 개발자가 주변에 많은 거겠죠.
저는 반대 케이스도 많이 봤습니다만, 인수라도 하지 않는 이상 스타트업 입장에서 구인이라는 방법으로는 아무리 걸러도 찾기 힘들 겁니다. 본인의 능력을 저평가한 케이스가 아니고서야 그 풀에 있을리가 없잖아요.
익명
윗댓분.. 실례지만 그런 생각이시면 본인이 직접 창업하시는게 맞지않나요?
정치꾼 사기꾼 밑에서 왜 일하시는지;;;;;;
익명
돈 벌고 싶으니까요.ㅋㅋㅋ
익명
그러면 다물고 다녀 불평불만하지말고
익명
상황마다 달라요.
1. 한국에서는 압도적 천재급 인력이 없으니
대부분 거기서 거기인 사람들은 기술적인 것보다 장사를 생각해야 돈을 벌 것이고
하지만 이런건 만들어봤자 중국애들이 금방 따라 만드니 초반에만 반짝하지 오래 갈 수가 없음.
쿠팡이나 배민도 한국이라는 고립된 섬이라는 환경 덕분에 살아남은 것이지..
2. 천재급 인력이 있는 미국이나 중국에서는
분명한 수요가 있는데 아무나 못 만드는 그런걸 만들 줄 아는 사람은
기술로 밀어부치면 그 누구도 따라오지 못 하는 것이고
3. 고만고만한 기술이라도
시간이 오래 걸리는 것을 십년넘게 만들어둔 사람은 그것만으로 가치가 생기는 것이고
이런건 대체제가 나오기까지 몇년이 걸리니
저도 회사에서 제가 하고 싶은것만 하는데
이게 회사에 기여하는지 안하는지 몰라서 그러는게 아니에요.
내가 회사가 돈 버는것을 만들어봤자
정치꾼 사기꾼 놈들한테만 이익인데 내가 그걸 왜 만듦?
난 호구가 아니거든요.
Kihong Bae
어떤 회사에서 일하시는진 모르겠지만, 같이 일하는 동료분들이 불쌍하다는 생각이 드네요.
익명
레전드네
익명
오 개발자도 예술병에 걸리는군요
익명
상황마다 다르다는 첫 줄 뺴고 한 줄도 공감이 안되네요
익명
회사에서 하고싶은 것만 하는게 가능한가? 님은 회사 나오셔야할 듯…진짜 글쓴사람 말대로 같이 일하는 동료분들이 불쌍하다는 생각이 드네요.
익명
이 분이 이렇게 흑화(?)한 이유를 나름 생각해보면…
엔지니어들은 보통 사업적인 의사결정에서 배제되는 경우가 많습니다. 개발도 잘하고 사업도 잘하신 분 이야기를 듣고 다시 나의 회사로 돌아와 그 감동을 재현하려고 하면 넌 왜 깝치냐는 소리나 안들으면 다행입니다. 그 직책이 CTO라 하더라도 말이죠. 개발자도 조직원입니다. 개발자의 KPI가 유의미해지려면 기술적인 방향성이 사업의 방향성과 일치되어야 합니다. 그리고 그건 회사의 매출과 직결됩니다. (비용효율성이 극대화되기 때문이죠) 그건 어느 한쪽의 노력만으로 되는 일이 아닙니다. 댓글쓴이가 흑화된 것도 잘못되었고, 안타깝지만 밑에 악플(?) 다신 분들도 다시 한번 삶을 뒤돌아보시는 계기가 되시길 바랍니다.
익명
> 사업적인 의사결정에서 배제되는 경우가 많습니다
오너나 핵심 C레벨들이 아닌 이상 그런 의사결정에서 배제 되는 건 모두에게 해당됩니다.
글의 내용은 그런 의사결정에 의해 정해진 목표를 달성하는 과정중에 있어서 오버 엔지니어링을 조심하자는 취지라고 이해됩니다.
레거시 시스템에 CRUD 덕지덕지 붙여서 개발하기 보다 이참에 신규 MS 띄우고 얼마전에 공부했던 핵사고날 도입해서 해볼 생각에 두근두근 하는 개발자들을 때에 따라서는 워워~ 시켜야 할 필요가 있다는 거죠.
쓰다보니 저도 상황 마다 다르다는 한 줄 빼고는 전혀 공감이 안되는 것은 마찬가지군요.
익명
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 레전드
익명
진짜 다행이다 주변에 이런사람 없어서 안봐도 SI에서 1x년 이상 굴린 틀니딱딱일듯