긍정적 사고, 음식의 절제, 규칙적인 운동

내가 싫어했던 매니저가 나에게 가르쳐준 교훈 

https://www.blog4ems.com/p/the-manager-i-hated

• 지금은 엔지니어링 매니저가 되었지만 내가 소프트웨어 엔지니어로 일하던 시절, 복잡한 기능을 며칠간 작업해 PR를 올렸음
• 피드백은 단호하고 냉정했음 “오버 엔지니어링임. 복잡함. 리팩토링하시오”는 간단한 문장이 전부였음
• 칭찬 한마디 없이 비판만 받은 경험에 분노했으나, 그 매니저와의 일화는 단지 시작에 불과했음

감정을 배려하지 않는 리더 스타일

• 이 매니저는 기존에 알고 있던 리더들과 달랐음
• 손을 잡아주지도, 부드러운 말도 하지 않음
• 다음과 같은 특징이 있었음
  • 설익은 아이디어는 바로 거절함
  • 복잡함을 위한 복잡함을 싫어함
  • 깔끔하고 유지 보수 가능한 효율적인 코드만 중요시함
• 회고에서도 돌려 말하지 않고 문제를 직접 지적함
• 처음에는 냉혹한 성격이라 생각했지만, 그 이면에는 다른 철학이 있었음

자존심을 흔든 피드백의 전환점

• 스프린트 리뷰에서 자신 있는 기능을 시연했지만 매니저는 중간에 끊고 물음“이건 취약해. 부하 상황에선 어떻게 돼? 롤백 계획은?”
• 대답을 제대로 하지 못하자 매니저는 말함:“지금 넌 코더처럼 생각하고 있어. 엔지니어처럼 생각해야 해”
• 처음엔 화났지만, 결국 스스로의 코드 스타일이 회복력보다는 영리함에 치중했다는 걸 자각하게 됨

진짜 교훈: 그 매니저는 나를 개인적으로 공격한 게 아니었음

• 사고방식에 큰 변화가 생김
  • “똑똑한” 코드 대신 읽기 쉬운 코드를 작성함
  • 실패 상황을 대비한 설계에 집중함
  • 본인을 위한 코드가 아니라 후속 개발자를 위한 코드를 작성함
• 이후 그 매니저의 코드 리뷰는 거침없이 통과됨
• 매니저가 달라진 게 아니라, 나 자신이 성장했기 때문임

내 리더십 스타일에 남긴 영향

• 엔지니어링 매니저가 된 후 그 경험을 많이 떠올렸음
• 사람들이 싫어하는 리더는 되고 싶지 않았지만, 부드럽기만 한 리더도 되고 싶지 않았음
• 다음과 같은 방식으로 스타일을 정립함
  • 배경 설명이 있는 직설적인 피드백을 줌
  • 시스템적 사고를 강조함
  • 높은 기준은 유지하되 인간적인 피드백을 제공함
• 엔지니어들은 도전받는 걸 원하지만 무시당하는 느낌은 싫어함

단호한 매니저가 필요할 때

• 리더십에는 자존심, 마감, 압박이 얽혀 있어 혼란스러움
• 단호한 매니저는 다음을 통해 이 혼란을 걷어냄
  • 기능이 아닌 확장성을 생각하게 함
  • 영리한 코드보다 유지 가능한 코드를 쓰게 함
  • 실패와 예외 상황을 미리 대비하게 함
• 감정보다 코드의 생존 가능성을 더 중요하게 여김

단호한 매니저 아래에서 생존하고 성장하는 방법

• 숨 막히는 리더 아래에 있다면 다음과 같이 대처할 수 있음
  • 개인적인 공격으로 받아들이지 말 것: 피드백은 코드에 대한 것
  • 피드백 이후 “왜?”를 물어볼 것: 대부분 단호한 리더는 호기심을 존중함
  • 실패 지점을 스스로 먼저 생각해 볼 것: 매니저처럼 사고하기 시작해야 함
• 리더라면 다음을 실천해야 함
  • 높은 기준을 제시하되, 그 기준이 중요한 이유를 설명할 것
  • 모호한 피드백 대신 구체적으로 말할 것
  • 성공보다 성장을 축하할 것: 개발자가 매니저보다 먼저 문제를 포착했다면 칭찬할 것

거절된 Pull Request가 준 최고의 선물

• 처음엔 자존심이 상했지만, 지금 돌아보면 그 거절된 PR은 인생 최고의 기회였음
• 코딩을 개인 프로젝트가 아닌 시스템 구축으로 보게 되는 계기였음
• 단호한 매니저는 기분을 좋게 해주진 않지만, 개발자로서 성장하게 함
• 진정한 성장은 PR이 통과될 때가 아니라, 거절될 때 시작됨

저는 여전히 소프트웨어 엔지니어였습니다.

모든 것은 코드 리뷰에서 시작되었습니다.

며칠 동안 복잡한 기능을 작업했습니다. 수백 줄의 코드, 엣지 케이스 처리, 성능 조정까지 완료했습니다. 저는 그것이 자랑스러웠습니다. "풀 리퀘스트 생성"을 누르고 피드백을 기다렸습니다. 아마도 한두 개의 댓글 정도를 예상했습니다.

제가 받은 것은 잔혹했습니다.

"오버 엔지니어링. 너무 많은 움직이는 부분. 리팩토링."

그게 전부였습니다. "잘 했어요"도, "좋은 시도였어요"도 없었습니다. 그냥 단호한 중단이었습니다.

저는 화가 나서 앉아 있었습니다. '이 사람은 사람들을 깎아내리는 걸 즐기는 걸까?'라고 생각했습니다.

하지만 이건 시작에 불과했습니다.

내 감정 따위는 신경 쓰지 않는 매니저

그는 제가 함께 일했던 다른 리더들과는 달랐습니다.

어떤 손길도, 허세도 없었습니다.

그는 반쯤 익은 아이디어를 눈 하나 깜짝하지 않고 거절했습니다.

그는 영리함을 위한 복잡성을 혐오했습니다.

그는 한 가지, 즉 깨끗하고 유지 보수 가능하며 효율적인 코드에만 관심이 있었습니다.

스프린트 회고에서 그는 상황을 미화하지 않았습니다. 마감일을 놓쳤나요? 그는 "우리가 범위를 잘못 잡았어. 고치자."라고 말했습니다. 확장성이 없는 것을 만들었나요? "그건 기술 부채야. 감당할 수 없어."라고 말했습니다.

처음에는 그가 그저 엔지니어를 불행하게 만드는 그런 매니저라고 생각했습니다. 하지만 더 깊은 무언가가 있었습니다.

이런 게시물을 즐겨 읽으신다면, 제 작업을 지원하고 이 뉴스레터를 구독해 보세요.

무료 구독자는 다음을 얻습니다.

• ✉️ 주간 게시물 1개
• 🧑‍🎓 엔지니어링 매니저 마스터클래스 이용 권한

유료 구독자는 다음을 얻습니다.

• 🔒 50개 이상의 템플릿과 플레이북 (79달러 상당)
• 🔒 EM이 직면하는 실제 과제에서 나오는 주간 "당신이라면 어떻게 하시겠어요?" 시나리오 및 분석
• 🔒 전체 아카이브에 대한 완전한 액세스 권한 고성능 팀을 만드는 것에 대한 주간 기사를 읽는 최고의 엔지니어링 리더들과 함께 하세요!

구독하기

모든 것을 바꿔놓은 자아 점검

결정적인 순간은 스프린트 리뷰 중에 찾아왔습니다.

저는 그에게 깊은 인상을 줄 것이라고 확신했던 기능을 시연했습니다. 대신 그는 중간에 저를 끊었습니다.

"이건 약해. 부하가 걸리면 어떻게 되지? 롤백 계획은?"

저는 답을 찾기 위해 더듬거렸지만 제대로 된 답이 없었습니다. 그는 잠시 멈추더니 말했습니다. "당신은 코더처럼 생각하고 있어, 엔지니어처럼 생각하고 있지 않아. 실패를 견딜 수 있는 것을 만들어."

그것은 저에게 힘든 순간이었습니다.

저는 밤새도록 그 말을 곱씹었습니다. 처음에는 화가 났습니다. 하지만 생각할수록 그가 옳다는 것을 깨달았습니다. 저는 회복력이 있는 해결책이 아닌 영리한 해결책에 너무 집중하고 있었습니다.

진정한 교훈: 그것은 나에 대한 것이 아니었다

저는 제 일에 접근하는 방식을 바꾸기 시작했습니다.

저는 "똑똑한" 코드를 쓰는 것을 멈추고 읽기 쉬운 코드를 쓰기 시작했습니다.

저는 이상적인 경우뿐만 아니라 실패 시나리오를 염두에 두고 설계했습니다.

저는 저 자신을 위해 코딩하는 것을 멈추고 다음에 제 코드베이스를 건드릴 사람을 위해 코딩하기 시작했습니다.

그리고 놀라운 일이 일어났습니다.

그가 검토하는 제 풀 리퀘스트가 막힘없이 통과되기 시작했습니다.

그가 부드러워진 것이 아니었습니다. 제가 마침내 성장한 것입니다.

그것이 제 자신의 리더십 스타일에 미친 영향

제가 결국 엔지니어링 매니저가 되었을 때, 저는 그 경험에 대해 많은 생각을 했습니다.

저는 사람들이 싫어하는 그런 리더가 되고 싶지 않았습니다. 하지만 부드럽기만 한 리더도 되고 싶지 않았습니다.

그래서 저는 효과가 있었던 부분을 훔쳤습니다.

• 맥락이 뒷받침되는 잔혹할 정도의 솔직함. "이건 엉망이야"라고 말하는 대신 "이건 숨겨진 기술 부채를 만들어. 이유는 이거야."라고 말합니다.
• 시스템 사고에 집중. 저는 엔지니어들에게 그들의 티켓을 넘어 그들의 코드가 더 큰 그림에 어떻게 들어맞는지 생각하도록 밀어붙입니다.
• 높은 기준, 하지만 인간적인 피드백. 저는 단지 결함을 지적하는 것이 아니라 나아갈 길을 제시합니다.

저는 엔지니어가 도전을 원하지만, 그 과정에서 무시당하는 느낌을 받고 싶어하지 않는다는 것을 알게 되었습니다.

왜 터프한 엔지니어링 매니저가 당신에게 꼭 필요한 존재일 수 있는가

리더십은 엉망진창입니다. 자아, 자존심, 마감일, 그리고 압박이 있습니다.

터프한 매니저는 그 소음을 뚫고 나아갑니다. 그들은:

• 기능뿐만 아니라 확장성에 대해 생각하도록 강요합니다.
• 영리한 코드뿐만 아니라 유지 보수가 가능한 코드를 작성하도록 밀어붙입니다.
• 엣지 케이스와 실패는 일어날 것이기 때문에 그것들을 계획하도록 가르칩니다.

이러한 매니저들은 당신이 어떻게 느끼는지보다는 당신의 코드가 프로덕션 환경에서 살아남을 수 있을지에 더 관심을 가집니다. 그리고 그것은 나쁜 것이 아닙니다.

터프한 매니저 밑에서 살아남고 번성하는 방법

만약 당신이 현재 목덜미에 숨결을 불어넣는 것처럼 느껴지는 매니저 밑에 있다면, 이것이 효과를 발휘하게 만드는 방법입니다.

• 개인적으로 받아들이지 마세요. 피드백이 코드에 대한 것이라면, 그것은 당신에 대한 것이 아닙니다.
• 모든 피드백 후에 "왜"를 물어보세요. 대부분의 터프한 매니저는 호기심을 존중합니다.
• 그들이 지적하기 전에 실패 지점을 예측하세요. 그들이 하는 것처럼 생각하기 시작하세요.

만약 당신이 엔지니어를 관리하고 있다면:

• 기준을 높게 설정하되, 무엇이 걸려 있는지 설명하세요. 엔지니어는 높은 기준이 왜 중요한지 알 때 그것을 존중합니다.
• 피드백을 구체적으로 하세요. 모호한 비판은 사람들을 좌절시킵니다. 요점을 말하세요.
• 성공뿐만 아니라 성장을 축하하세요. 누군가가 당신보다 먼저 문제를 발견하는 첫 번째 순간은요? 그것을 칭찬하세요.

내가 거절당해서 기쁜 풀 리퀘스트

그 잔혹했던 풀 리퀘스트를 돌이켜보면, 그것은 엔지니어로서 저에게 일어난 최고의 일 중 하나였다고 말할 수 있습니다.

그것은 제가 코딩을 개인적인 예술 프로젝트로 취급하는 것을 멈추고 시스템 구축자처럼 생각하기 시작하도록 강요했습니다. 엔지니어처럼요.

터프한 매니저는 당신을 기분 좋게 만들지는 않을 것입니다. 하지만 그들은 당신을 더 나은 존재로 만들 것입니다. 그리고 당신이 당신의 자아를 넘어서면, 그들이 당신에게 남기는 교훈은 당신의 경력 전체에 걸쳐 지속될 것입니다.

때때로, 최고의 PR은 거절당하는 PR입니다. 왜냐하면 그곳이 진정한 성장이 일어나는 곳이기 때문입니다.

https://news.hada.io/topic?id=20051

https://m.mk.co.kr/news/it/11284014

20대 직장인 주 모씨는 월급을 받으면 매달 10만원이 넘는 고정비가 온라인 서비스 구독 비용으로 빠져나간다. 넷플릭스, 스포티파이처럼 기존에 이용하던 온라인동영상서비스(OTT), 음원 스트리밍 서비스 말고도 챗GPT를 포함한 인공지능(AI) 서비스 구독을 추가했기 때문이다. 업무와 커리어를 위해 사용하는 마이크로소프트(MS)의 문서 서비스와 비즈니스용 사회관계망서비스(SNS)인 링크트인의 유료 멤버십 또한 구독비 지출에서 큰 비중을 차지한다. 주씨는 "AI 구독 서비스를 하나둘 추가하면서 고정 지출도 빠르게 늘고 있다"며 "신용카드도 구독 비용을 할인해주는 카드로 바꿨다"고 말했다.

각종 정보기술(IT) 구독 서비스가 늘어나면서 주씨의 사례처럼 시민들의 디지털 지출 부담도 빠르게 커지고 있다. OTT나 유튜브, 음악 구독 서비스가 젊은 세대에서 필수 소비재로 자리 잡은 가운데 챗GPT를 필두로 생성형 AI 유료 서비스도 쏟아지고 있기 때문이다.

최근 KB국민카드가 자사 고객의 결제 데이터를 분석한 결과에 따르면 2024년 구독 서비스 이용을 위해 지출한 비용는 전년 대비 17.1% 증가했다. 같은 기간 생성형 AI 서비스 유료 구독 건수는 299% 급증해 1년 새 4배로 늘었다.

한국에서 이용자가 많은 서비스인 유튜브 프리미엄(1만4900원)과 넷플릭스 기본 요금제(1만3500원), 멜론의 무제한 듣기 요금제(1만900원) 정도만 구독하더라도 금액은 월 4만원 수준이다. 여기에 챗GPT 등의 구독 서비스가 두 개 이상 추가될 경우 구독료는 월 10만원에 육박하게 된다.

이 같은 구독비 지출을 두고 이제 '디지털 월세'라는 말까지 나온다. 디지털 서비스 구독료가 매달 나가는 주거비처럼 이제는 무시할 수 없는 고정 비용으로 자리 잡았음을 단적으로 보여주는 것이다.

AI 서비스 구독이 보편화되는 추세는 기술 수용도가 높은 2030세대를 중심으로 나타나고 있다. 시장조사업체 마크로밀 엠브레인이 올 1월 실시한 설문조사에 따르면 '새롭게 구독을 희망하는 서비스'를 묻는 질문에 생성형 AI가 20대에서 1위, 30대에서 2위를 기록했다. 마크로밀 엠브레인은 "이들이 이미 학습과 업무에 생성형 AI를 적극 활용하고 있는 세대임을 감안할 때 생성형 AI는 국민 구독 서비스로 자리매김할 것"이라고 분석했다.

챗GPT 같은 AI 구독 서비스는 유료 고객이 꾸준히 늘면서 벌어들이는 구독료 매출도 팽창하고 있다. 테크 전문매체 디인포메이션에 따르면 지난해 말 1550만명 수준이던 챗GPT 유료 이용자는 지난달 말 기준 2000만명을 돌파한 것으로 나타났다.

챗GPT 기본 요금제가 20달러에서 시작한다는 것을 고려하면, 오픈AI는 매달 챗GPT 구독료로만 최소 4억1500만달러(약 6000억원)의 수익을 올리는 것으로 추측된다. 오픈AI는 챗GPT 구독료를 2029년 월 44달러(약 6만4200원)까지 점진적으로 인상할 것으로 알려졌다.

디지털 구독 서비스 부담이 커진 이용자들은 구독료를 할인받을 수 있는 금융 상품을 찾거나, 대체재로 활용할 수 있는 무료 서비스를 찾아 나서고 있다. 특히 챗GPT 대신 무료로 사용할 수 있는 AI 검색 서비스에 대한 관심이 뜨겁다. 국내에서는 무료 AI를 내세운 뤼튼이 이 같은 수요를 흡수하며 이용자 수 3위권을 기록하고 있다. AI 얼리어답터들은 "무료 AI를 추천한다"며 카카오브레인 출신이 만든 'oo.ai', 이스트소프트의 '앨런' 등 무료 서비스 정보를 공유하기도 한다.

무료 오픈소스 문서 프로그램인 '리브레오피스'가 지난달 매주 100만건이 넘는 다운로드를 기록하며 사용자가 급격히 늘어나는 등 해외 상황도 비슷하다. 가장 대중적인 문서 프로그램인 MS의 'MS 365'가 올해 초 AI 기능을 추가하면서 구독료를 40% 넘게 인상한 영향이 컸다.

이용자들은 가족이나 친구들과 OTT 계정을 공유했듯 챗GPT 계정을 같이 쓰며 구독료를 나눠 내기도 한다. 만약 글로벌 계정 공유 서비스인 갬스고에서 월 22달러인 챗GPT 플러스 요금제를 6인 공유로 사용하면 원래 요금의 25%인 월 5.67달러로 사용할 수 있다. 올해도 생성형 AI 서비스가 꾸준히 확산하면서 디지털 월세가 증가하는 추세는 한동안 이어질 전망이다. 과학기술정보통신부의 조사에 따르면 지난해 국내에서 생성형 AI 서비스를 경험해 봤다는 비율은 33.3%로 전년 대비 2배 가까이 증가했다.

https://www.cio.com/article/3950506/%ec%a0%95%ec%b2%a0%ed%99%98-%ec%b9%bc%eb%9f%bc-%ec%bd%94%eb%94%a9%eb%a7%8c-%ec%9e%98%ed%95%98%eb%a9%b4-%eb%90%a0%ea%b9%8c-%eb%af%b8%eb%9e%98%ec%9d%98-%ea%b0%9c%eb%b0%9c%ec%9e%90%ea%b0%80-%ea%b0%96.html

미래의 개발자는 단순한 프로그램 코딩을 넘어서, 해결하고자 하는 도메인의 문제 해결자로 거듭나야 한다. 즉 단순한 ‘코드 작성자’가 아니라, 문제를 해결하고 가치를 창출하는 전략적 사고를 가진 전문가가 되어야 한다.


오래전, 아마도 1990년대로 기억하는 시기에 우리나라 최초의 SI기업이었던 쌍용정보통신의 대표가 신문에 기고했던 칼럼의 내용이 아주 인상깊게 각인이 된 적이 있다. 요약하면 ‘후진국은 저렴한 임금을 무기로 선진국과 제조업 경쟁에서 우위를 가지고 성장했지만 제조업 종사자의 개인별 생산성 측면에서는 선진국이 후진국보다 경쟁력이 높다. 하지만 제조업에서의 개인별 생산성 차이는 커야 두세배에 지나지 않는다. 임금이 1/10이라면 비록 후진국의 개인별 생산성이 뒤져도 비용대비 생산성은 충분한 경쟁력이 나온다. 하지만 소프트웨어 분야에서는 그렇지 않다. 후진국과 선진국 개발자의 생산성 차이가 많게는 100배 이상도 날 수 있기 때문이다. 따라서 소프트웨어 산업은 저렴한 임금을 무기로 후진국이 선진국을 따라잡을 수 없다’라는 내용이다.

여전히 미국은 세계 최고의 경쟁력을 가진 소프트웨어 강국이다. 실리콘밸리의 임금 수준은 세계 최고 수준을 자랑하지만 여전히 강력한 경쟁력을 유지하고 있다. 이는 미국 소프트웨어 기업의 개발자 수준이 세계 최고이기 때문이다. 하지만 미래는 어떻게 될까?

지금까지 개발자의 실력을 좌우하는 것은 코딩 실력이라고 생각돼 왔다. 즉 ‘코딩을 잘하는 개발자’가 개발자로의 성공의 중요한 조건이었지만, IT 산업이 빠르게 변화하면서 이제는 그 이상이 요구되고 있다. 단순히 뛰어난 코딩 실력만으로는 우수한 개발자가 되는 것은 고사하고 살아남기조차 어려운 시대가 오고 있는 것이다. 그렇다면 미래의 개발자는 어떤 역량을 갖춰야 할까?


우선 문제 해결 능력과 논리적 사고력을 강화해야 한다. 1990년대 클라이언트/서버 붐이 한창이던 시절 갑작스러운 개발자 수요 폭발로 인해 초급 개발자를 구하는 것이 매우 어려운 시절이 있었다. 그때 회자되었던 농담이 ‘개발자의 전공 중 제일 많은 비중을 차지하는 것인 불문과다’라는 것이다. 개발자 채용에 대부분의 기업이 ‘전공 불문’ 이라는 조건을 달았기 때문이었다.

그래서 당시 유명했던 비트컴퓨터 학원의 6개월 개발자 과정을 이수한 인력들이 개발 시장에 많이 투입되었다. 이들은 프로그램 코딩의 문법과 작성에 대해 잘 배웠지만 실전에서 보면 컴퓨터공학이나 전산학을 전공한 인력과 분명한 차이가 있었다.

프로그램 코딩이 단순히 문법을 익히는 것이 아니라 논리를 구현하는 작업인 것처럼, 개발자에게는 문제 해결 능력이 필수적이다. 단순히 요구사항을 구현하는 것이 아니라, 문제의 본질을 파악하고 최적의 해결책을 찾는 능력이 중요하다. 이를 위해 알고리즘, 데이터 구조, 디자인 패턴 등 기본 CS 지식은 여전히 강력한 무기다. 이런 기본적인 배경 지식이 있는 것과 없는 것은 장기적으로 분명한 차이를 가져온다. 이를 위해 개발자는 알고리즘 & 데이터 구조 학습, 시스템 설계, 문제 해결 역량 등을 강화하여야 한다.


다음으로 커뮤니케이션과 협업 능력이 중요하다. 과거에는 개발자가 코드만 작성하면 됐지만, 이제는 기획자, 디자이너, 마케팅 팀과의 협업이 필수적이다. 특히 생성형 인공지능의 발전으로 단순 코딩 영역이 점차 자동화되는 상황으로 발전하는 상황에서 개발자의 역할이 단순한 ‘기능 구현자’에서 ‘문제 해결사’로 확장되면서, 비개발자와 원활하게 소통하는 능력이 중요해지고 있다. 이와 관련하여 코드 리뷰, 기술 문서 작성, 프레젠테이션 등의 소통 스킬도 필수적이다.

또한 생성형 인공지능 기반의 자동화된 코딩 시대가 오면 개발자의 실력을 차별화할 수 있는 핵심 역량은 시스템 개발과 관련된 업무 도메인 지식과 비즈니스 이해력이 될 수 있다. 기술은 결국 특정 문제를 해결하기 위한 도구일 뿐이다. 개발자가 자신이 속한 산업(예: 제조, 금융, 헬스케어, 커머스 등)에 대한 이해가 깊을수록, 더 가치 있는 솔루션을 제공할 수 있다. 즉 단순히 ‘어떻게 개발할까?’가 아니라, ‘왜 이 기능이 필요한가?’를 고민할 줄 아는 개발자가 경쟁력을 갖게 된다. 이러한 역량을 키우기 위해서는 특정 산업의 동향 분석, 데이터 기반 의사결정 역랑을 강화해야 할 것이다.

그리고 1990년대부터 지금까지 변하지 않는 중요한 개발자의 역량은 지속적인 학습 능력 및 기술 트렌드에 대한 파악 노력이다. IT분야의 기술은 빠르게 변하고, 현재 주류인 기술이 몇 년 후면 사라질 수도 있다. 그렇기 때문에 IT분야 대학교수들 사이에서 수학이나 물리 심지어 역사학 분야의 교수들을 부러워한다는 우스개 소리도 있는 이유일 것이다. 이와 관련하여 새로운 언어나 프레임워크가 등장했을 때 빠르게 적응할 수 있는 능력도 중요하다. 이러한 역량을 키우기 위해서는 유명한 기술 블로그 구독, 사이드 프로젝트 진행, 오픈소스 기여 등을 통해 가능하다.


‘피할 수 없으면 즐겨라’라는 말처럼 점점 발전하고 있는 생성형 인공지능 기술을 위협으로만 받아들이지 말고 적극적으로 자동화 및 생산성 도구를 활용하는 능력을 키워야 한다. 어차피 미래에는 개발자가 직접 코드를 작성하는 시간이 점점 줄어들게 될 것이기 때문이다. 또한 개발 환경의 대세가 되고 있는 CI/CD, 테스트 자동화, 코드 생성 AI(GitHub Copilot, ChatGPT) 등을 적극적으로 활용하면 개발자의 생산성을 크게 향상시킬 수 있다. 결국 단순 반복적인 업무를 자동화할 줄 아는 개발자가 더 높은 가치를 제공할 수 있다. 이를 위해 데브옵스 기본 개념, AI 코딩 도구 활용, 스크립트 자동화 등의 영역에 대한 역량을 키우는 것을 추천한다.

결국 미래의 개발자는 단순한 프로그램 코딩을 넘어서, 해결하고자 하는 도메인의 문제 해결자로 거듭나야 한다. 즉 단순한 ‘코드 작성자’가 아니라, 문제를 해결하고 가치를 창출하는 전략적 사고를 가진 전문가가 되어야 한다는 것이다. 뛰어난 개발 관련 기술력은 기본이고, 원활한 커뮤니케이션과 협업 능력, 비즈니스 이해력과 지속적인 학습 태도가 필수적이다.

당신은 어떤 개발자가 되고 싶은가?

https://www.yna.co.kr/view/AKR20250401034600091

(샌프란시스코=연합뉴스) 김태종 특파원 = 미국 반도체 기업 인텔 최고경영자(CEO) 립부 탄은 31일(현지시간) 수년간 잃어버린 인재들을 다시 확보하는 것이 우선 과제 중 하나라고 밝혔다.

탄 CEO는 이날 라스베이거스에서 열린 '인텔 비전' 콘퍼런스에서 "유능한 엔지니어를 채용하고 현재의 인재들을 유지하는 것이 필요하다"며 이같이 말했다.

인텔 CEO로서 처음 공개 석상에 선 그는 이날 참석한 파트너사 등에 "앞으로 해야 할 일이 많다"며 "여러분의 기대에 부응하지 못한 부분이 있다"고 말했다.

또 "우리는 혁신에서 뒤처졌다"며 "변화에 적응하고 여러분의 요구를 충족하는데 너무 느렸다"고 인정했다.

탄 CEO는 그러면서 "일하는 방식을 단순화하겠다"며 관료주의를 타파하겠다고 강조했다.

그는 "작고 집중된 팀이 기민하게 혁신하며 기존 기업을 인수하는 사례를 많이 봐왔다"며 "관료주의는 혁신을 죽인다"고 강조했다.

인텔 CEO를 맡게 된 이유에 대해서는 "회사가 어려움을 겪는 모습을 보는 것은 힘들었다"며 "내가 도울 수 있다는 것을 알면서 방관할 수는 없었다"고 설명했다.

미국 반도체 설계 소프트웨어 기업인 케이던스 디자인 시스템즈 CEO를 지낸 그는 2022년부터 약 2년간은 인텔 이사회 멤버로도 활동한 바 있다.

하반기 1.8나노(18A) 공정의 차질 없는 가동도 재확인했다.

그는 "18A를 적용한 중앙처리장치(CPU)는 하반기 대량 생산에 들어가 연내 출하될 것"이라며 "새로운 첫 번째 외부 테이프 아웃(설계가 파운드리로 넘어가는 단계)에 접근하고 있다"고 했다.

18A 공정은 인텔이 2021년 파운드리 사업 재진출을 선언하며 야심 차게 추진하고 있는 공정이다.

현재 5나노 이하 파운드리 양산은 세계에서 TSMC와 삼성전자만 가능한데, 1.8나노는 두 회사가 양산 중인 3나노보다 앞선 공정이다.

로이터 통신은 앞서 작년 10월 18A 공정에 일부 차질이 발생해 2026년까지 1.8나노 공정에 들어갈 가능성은 작아 보인다고 보도한 바 있다.

탄 CEO는 지난해 12월 사임한 팻 겔싱어 전 CEO의 뒤를 이어 이달 중순 인텔의 새 수장이 됐다.

전 CEO인 겔싱어는 2021년 자사 제품뿐 아니라 다른 회사의 칩을 생산하는 파운드리 사업으로 변모시키겠다는 야심 찬 계획을 내세웠다.

하지만, 계속된 실망스러운 실적으로 시장의 신뢰를 잃었고, 특히 2024년 8월 발표된 실적은 전문가들이 인텔 역사상 최악이라는 평가를 받았다.

이에 인텔은 1만5천명을 정리해고하는 등 대대적인 구조조정에 착수했으며, 오하이오 공장을 포함한 일부 건설 계획도 연기했다.

인텔은 최근 디자인과 제조 부문의 기업 분할 매각 가능성까지 나오고 있다.

브로드컴이 인텔의 칩 설계 및 마케팅 사업 부문에 대한 인수를 검토하고 있고, 대만 TSMC는 인텔의 공장을 운영할 합작 회사 설립을 위해 미국 반도체 기업에 제안한 것으로 알려졌다.

🕛열두 시
🕧열두 시 반
🕐한 시
🕜한 시 반
🕑두 시
🕝두 시 반
🕒세 시
🕞세 시 반
🕓네 시
🕟네 시 반
🕔다섯 시
🕠다섯 시 반
🕕여섯 시
🕡여섯 시 반
🕖일곱 시
🕢일곱 시 반
🕗여덟 시
🕣여덟 시 반
🕘아홉 시
🕤아홉 시 반
🕙열 시
🕥열 시 반
🕚열한 시
🕦열한 시 반

IT 부서는 효율성을 측정하기 위한 수많은 지표 속에서 헤매고 있다. IT 성과를 측정하는 데 활용할 수 있는 필수 KPI 지표 9가지를 소개한다.

IT 리더는 수많은 측정 지표와 도구 속에서 KPI를 달성하기 위해 애쓰고 있다. 이 과정에서 시간 낭비와 혼란을 겪으며, 때로는 인사이트에 모순이 발생하기도 한다.

버라이즌(Verizon)의 미주 지역 글로벌 기업 영업 수석 부사장인 조나단 니콜스는 “IT 부서가 혁신 성과를 달성하는 데 사용할 수 있는 여러 지표가 있다. 예를 들어 제품 및 서비스를 시간과 예산 내에 제공하는지, 전반적인 IT ROI는 어떠한지를 파악할 수 있다”라고 언급했다. 그는 모든 도입 성과 영역에 걸쳐 지표를 연구하는 것이 가장 효과적인 접근 방식이라면서, 지표를 통해 진행 상황을 효과적으로 모니터링할 수 있다고 말했다.

CIO가 기업 리더에게 혁신과 운영에 대한 IT의 영향 수준을 보여주기 위해 분석 결과를 준비할 때는 최소한의 핵심 지표만 선별하는 것이 중요하다. 혼란을 피하고 중요한 과제에 대한 명확한 통찰력을 제공하는 핵심 지표 세트에 집중해야 한다. 시간이 지나면서 주요 추세를 보강하고 조명하기 위해 추가 분석 도구를 도입할 수 있지만, 몇 가지 기본 도구로 시작하는 것이 가장 좋다.


IT 성과를 정확하게 측정하기 위해 CIO의 분석 도구에 포함돼야 할 기본 지표를 소개한다.

1. 투자 수익률(ROI)
수년간 그래왔듯 투자 수익률은 꾸준히 혁신과 관련한 핵심 지표로 자리잡고 있다. 딜로이트 컨설팅(Deloitte Consulting)의 미국 CIO 및 CDAO 프로그램 리더인 루 디로렌조는 “혁신은 비즈니스를 다르게 수행하고 가치를 창출하는 것”이라고 말했다. ROI는 가치에 대한 통찰력을 제공할 뿐만 아니라, 올바르게 측정될 경우 혁신에 필수인 비즈니스와 IT 부서 간의 공동 책임과 협력 관계를 명확히 보여줄 수 있다.

디로렌조는 프로젝트의 ROI가 독자적으로 일하는 단일 IT 프로젝트 관리자에 의해 정의되어서는 안 된다고 말했다. 계획은 항상 공동 노력이어야 한다는 것이다. 이런 구조에서 비즈니스 부서는 ROI 계산의 ‘분자’를 담당한다. 이는 혁신 프로젝트가 시작된 본질적인 이유로, 판매량 증가, 가격 책정을 통한 마진 최적화 등이 포함된다. IT 부서는 ROI 계산의 ‘분모’를 담당한다. 이는 정시에, 예산 내에, 그리고 높은 품질로 작업을 제공하는 데 드는 비용을 의미한다.


디로렌조는 “프로젝트가 성공하려면 양측이 각자 의무를 다해야 하며, 성공적인 가치 창출 프로젝트가 쌓이면 비즈니스 혁신에 실질적인 도움이 된다”라고 설명했다.

2. 창출된 비즈니스 가치
ROI와 밀접하게 관련된 것은 창출된 비즈니스 가치(business value delivered)다. 캡제미니 아메리카스(Capgemini Americas)의 애플리케이션 관리 서비스 CoE 부사장이자 책임자인 사미르 바그왓은 “비즈니스에 가장 관련성이 높은 지표이며, IT 조직이 혁신 이니셔티브를 추진하는 데 필요한 투자를 설득할 때 유용하다”라고 설명했다.

특정 IT 혁신 프로젝트는 종종 기업 전체 DX(Digital Transformation) 이니셔티브와 연결된다. 그러나 프로젝트의 성공 여부는 여전히 프로젝트 비용, 구현 일정, 제공된 기능 등과 같은 전통적인 지표로 측정될 수 있다. 바그왓은 “성공의 진정한 척도는 창출된 비즈니스 가치에 기반한다”라고 말했다.


바그왓에 따르면, IT 혁신을 비즈니스 성과와 직접 연결하는 역량이 비즈니스와 IT 리더 간의 협력을 강화할 수 있다. 그는 “또한 비즈니스에 더 높은 가치를 창출하는 이니셔티브가 우선시되므로 혁신 이니셔티브에 대한 거버넌스를 개선할 수 있다”라고 설명했다.

바그왓은 비즈니스 성과가 수익 개선, 비용 절감, 또는 운용 자금 개선이라는 3가지 차원에서 수치화될 수 있다고 말했다. 그는 “이를 통해 여러 이니셔티브를 쉽게 비교하고 혁신 성과가 뛰어난 전략을 식별할 수 있다. IT 이니셔티브의 예상 비즈니스 가치를 수치화하면 IT 팀이 구현 중인 혁신 이니셔티브의 의미와 영향력을 더 잘 이해하게 된다”라고 말했다.

3. 변화 속도
IT 및 소프트웨어 개발 회사 글로반트(Globant)의 북미 CTO인 니콜라스 아빌라는 “IT 성공을 위한 가장 중요한 지표는 변화 속도(rate of change)”라고 언급했다.


아빌라는 많은 IT 리더가 기술 지출에서 최대한의 효과를 얻으려면 높은 ROI가 필요하다고 믿기 때문에 ROI를 최우선 지표로 설정한다고 말했다. 그는 “ROI도 중요하지만, 자주 간과되는 점은 변화를 이루는 속도가 빨라지면 더 빠르게 대응할 수 있을 뿐만 아니라 실패에 대한 두려움도 줄일 수 있다는 것이다. IT 부서가 빠르고 지속적으로 변화하고 개선한다면 실패는 그렇게 중요하지 않다”라고 설명했다.

아빌라는 변화 속도 지표가 실패라는 낙인을 지우는 데 유용하다며, 실패를 피할 수 없다면 빠르게 경험하는 것이 중요하다고 조언했다. 그는 “대부분의 기업은 실패를 피해야 할 것으로 생각하지만, 정말로 빠르게 변화하는 조직은 실패를 성공의 전 단계로 받아들인다”라고 설명했다.

또한 아빌라는 모든 리더와 팀이 변화 속도 지표를 사용해 특정 변화를 얼마나 빨리 이룰 수 있는지 결정해야 한다고 말했다. 그는 “많은 관리자가 진화 속도보다는 생산량으로 평가받는데, 이는 현대 사회의 문제이기도 하다. 어떤 팀이 빠르게 움직여야 하는지, 그리고 실제로 무엇을 달성하고 있는지 잘 파악할 수 있어야 한다”라고 지적했다.


그는 변화 속도 지표가 IT 부서 내에만 적용되지 않고 비즈니스 리더에게도 정보를 제공한다는 점이 중요하다면서, “비즈니스 성공을 극대화하기 위해 비즈니스 부서는 IT 부서와 협력해 빠르게 방향을 전환해야 한다”라고 말했다.

4. 애플리케이션 제공 성공률
네트워크 자동화 기술 제공업체 넷브레인 테크놀로지(NetBrain Technology)의 엔지니어링 수석 부사장인 송 팡은 IT 부서가 중요한 비즈니스 애플리케이션을 얼마나 잘 제공하는지를 파악하는 것이 필수적이라고 말했다. 그는 “대부분의 현대 애플리케이션은 함께 작동하는 많은 분산 서비스로 구성되어 있다. 각 마이크로서비스는 아키텍트가 설계한 대로 제공될 수 있어야 한다”라고 설명했다.

팡은 서비스 사용량 대비 제공 성공률이 방향성을 제시하는 좋은 지표라고 언급했다. 그는 “문제가 보고되기 전에 해결하기 위해 더 많은 노력을 기울일수록 더 효과적인 지표”라고 말했다. 문제를 사전에 발견하는 것은 모든 IT 조직의 기본적인 목표이며, 매월 그 가치를 비교하면 IT가 서비스 제공을 개선하고 있는지 판단할 수 있다.


5. IT 및 비즈니스 팀 참여도
기술 컨설팅 회사 SPR의 CTO인 매트 미드는 IT 및 비즈니스 팀 참여도가 혁신 성공을 측정하는 강력한 지표라고 말했다. 그는 “팀은 형성, 갈등, 표준화, 수행이라는 단계를 거치며 성장한다. 또한 조직 혁신을 위해 구성된 비즈니스와 IT 협력 팀이 서로 조화를 이루고 효율적으로 협업하기까지는 시간이 필요하다”라고 설명했다.

미드는 고객사가 혁신적 변화를 안착시킬 시간을 충분히 할애하지 못하는 경우가 많다고 언급했다. 참여도가 낮은 IT 및 비즈니스 프로젝트 리더가 일찍 성공을 선언하고 성급히 다음 혁신 단계로 넘어가는 상황을 자주 본다는 설명이다.

미드는 “특히 혁신의 첫 해에 가장 좋은 지표는 모든 팀 비즈니스 및 IT 팀원의 참여 수준을 측정하는 것”이라고 조언했다. 그는 “참여도가 높으면 성공의 기반이 마련된다. 참여도가 낮으면 혁신에 결함이 있다는 의미일 수 있다. 그러면 실패할 가능성이 높아진다”라고 말했다.


6. 고객 경험 수준
디지털 중심 기술 서비스 기업 에이펙슨(Apexon)의 책임자인 밀린드 담레에 따르면, DX 이니셔티브는 생산성 향상, 시장 점유율 확대, 운영 비용 최적화 등 다양한 목표를 포함할 수 있지만, 성공은 궁극적으로 한 가지로 정의된다. 고객이 기업의 브랜드, 제품 또는 서비스에 대해 어떻게 느끼는지다. 담레는 “DX 이니셔티브가 고객 경험 수준을 개선하지 못하면 지속적인 매출 성장을 이루는 데 정말 의미가 있을까?”라고 말했다.

담레는 지난 수년간의 보고서에서 고객이 브랜드를 결정할 때 가격보다 경험을 중시한다는 사실이 발견됐다고 언급하면서, “고객 경험이 모든 혁신 이니셔티브의 성공을 측정하는 가장 중요한 지표인 이유”라고 말했다.

7. 최종 사용자 만족도
최종 사용자 만족도는 IT 서비스가 사용자의 기대, 요구 및 인식과 얼마나 잘 부합하는지에 대한 인사이트를 제공한다. 기술 연구 및 자문 회사 ISG의 디렉터인 크리스 카랄리스는 높은 만족도가 IT에 대한 신뢰 증가, 섀도우 IT 감소, 비즈니스 리더와의 협력 장려, 직원 유지율 향상으로 이어져 궁극적으로 더 효율적으로 운영할 수 있게 된다고 설명했다.


이는 사용자 피드백을 수집하기 위한 정기 설문조사로 시작된다. 카랄리스는 “이런 설문조사는 기술 기기, 애플리케이션, 연결성 및 지원의 만족도를 포함해 사용자의 다양한 IT 경험을 다뤄야 한다”라고 조언했다. 또한 설문조사는 누구도 간과되지 않도록 전체 사용자 집단을 대상으로 실시돼야 한다.

ISG는 만족도 추세를 지속적으로 모니터링하기 위해 매년 설문조사를 실시할 것을 제안하고 있다. 또한 서비스 요청, 버그 수정, 사고 해결과 같은 사용자 상호 작용 후에는 간략한 만족도 조사도 정기적으로 실시해야 한다. 카랄리스는 “그런 다음 IT 부서는 데이터를 분석해 서비스 제공 방식에 잠재적인 문제가 있는지, 어떤 사용자 그룹이 가장 큰 영향을 받는지 파악해야 한다”라고 말했다. 그는 IT 리더가 실행 가능한 결과를 통해 문제점을 해결하지 않으면 사용자가 더 이상 의견을 제공하지 않고 장기적으로 서비스에 더 불만을 갖게 될 수 있다고 지적했다.

최종 사용자 만족도 지표의 강점은 IT 업무의 모든 부분과 관련이 있다는 점이다. 카랄리스는 “사용자와 더 직접적으로 대면하는 일부 구성 요소도 있지만, 모든 서비스 영역은 어떤 식으로든 사용자에게 영향을 미치는 종속성을 갖고 있다”라고 설명했다. 만족도 지표 결과는 IT 및 비즈니스 리더 모두와 공유돼야 하며, 실행 계획은 C레벨 임원과 IT 서비스 책임자에 의해 개발돼야 한다.

8. 기술 부채 지수
과도한 기술 부채는 유망한 혁신 이니셔티브에 치명적인 손상을 입힐 수 있다. ISG의 디지털 전략 및 솔루션 파트너인 샤프캇 아짐에 따르면, 프로젝트가 서둘러 개발되고 배포될 때 품질이 저하되고 호환성 문제, 보안 격차, 성능 및 예산 소모 문제를 야기할 수 있다. 그러면 이를 해결하기 위해 불가피하게 프로젝트를 재검토해야 한다. 아짐은 기술 부채가 민첩성과 혁신을 가로막는 큰 걸림돌이라고 언급하며, “운영의 일부로 기술 부채를 적극적으로 관리해야 조직이 필요할 때, 필요한 대로 혁신할 수 있다”라고 말했다.

아짐은 지출을 측정하고 추적하기 위해 기술 부채 지수를 활용할 것을 제안했다. 그는 “전략적 차원에서 가장 중요한 지표는 전체 기술 예산 중 혁신에 할당된 비율이다. 기술 예산이 비즈니스 운영, 점진적 혁신 지원, 급진적 혁신 지원이라는 세 영역에 할당되는 비율을 측정하는 것이 중요하다”라고 말했다. 전술적 차원에서는 혁신 역량과 혁신 속도를 측정하는 것이 중요하다고 그는 덧붙였다.

9. 속도, 품질, 가치 지표 결합
디지털 컨설팅 회사 퍼블리시스 사피엔트(Publicis Sapient)의 최고 제품 책임자인 셸던 몬테이로는 속도, 품질, 가치 지표의 결합이 기존 프로젝트 관리 방식에서 벗어나려는 모든 조직에 필수적이라고 말했다. 몬테이로는 “이 지표는 IT 조직 내 특정 역할이나 직급에 국한되지 않는다. 제품 개발 과정에 있는 모든 사람과 관련이 있다”라고 말했다.

속도, 품질, 가치 지표는 시간, 범위, 비용에 초점을 맞춘 기존 프로젝트 관리 지표에서 벗어난다는 의미다. 몬테이로는 “속도는 변화에 신속하게 대응할 수 있는 능력을 보장하고, 품질은 시스템의 무결성을 손상시키지 않고 변경이 이루어지도록 보장하며, 가치는 변화가 고객과 비즈니스 모두에 의미 있게 기여하도록 보장한다. 이런 총체적 접근 방식을 통해 IT 관행을 지속적으로 진화하는 환경의 요구 사항에 맞게 조정할 수 있다”라고 설명했다.

또한 이 지표는 조직의 적응력과 효율성과 관련해 보다 미묘한 차이를 이해하는 데도 유용하다. 몬테이로는 “이를 통해 지속적인 변화에 적응하는 조직의 역량에 대한 인사이트를 얻을 수 있다. 품질을 보장하고 고객과 비즈니스에 가치를 제공하면서 아이디어를 얼마나 빨리 실질적인 결과로 전환할 수 있는지를 측정할 수 있다”라고 조언했다.

몬테이로에 따르면, 속도, 품질, 가치 지표를 적용하는 좋은 방법은 아이디어 생성에서 시작해 전체 여정을 측정하는 것이다. 그는 “아이디어가 실험을 통해 얼마나 빨리 테스트되고 실제 작동하는 소프트웨어로 구축되는지, 결국 고객에게 기능으로 제공되는지 파악해야 한다”라고 말했다. 또한 이 시스템은 여정의 각 단계를 조명해 조직 전체에서 확인하고 측정할 수 있도록 개발돼야 한다. 몬테이로는 “이런 지표를 구현하면 조직은 제품 성공뿐만 아니라 업무 자체로 측정하고 개선하는 ‘데이터 풀’이 될 수 있다”라고 덧붙였다.

https://www.cio.com/article/3848745/%ec%a0%95%ed%99%95%ed%95%9c-%ec%84%b1%ea%b3%bc-%ec%b8%a1%ec%a0%95%ec%97%90-%ed%95%84%ec%88%98%c2%b7%c2%b7%c2%b7-it-%ed%98%81%ec%8b%a0%ec%9d%98-%ed%95%b5%ec%8b%ac-%ec%a7%80%ed%91%9c-9%ea%b0%80.html