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

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://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 코딩 도구 활용, 스크립트 자동화 등의 영역에 대한 역량을 키우는 것을 추천한다.

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

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

일부 IT 리더들은 AI가 코드 작성에 더 능숙해지면서 소프트웨어 개발팀이 시니어 몇 명 수준으로 축소될 수 있다고 내다봤다.
 
초기 성과는 각기 다르지만, 결과는 분명해 보인다. 생성형 AI 코딩 어시스턴트가 소프트웨어 개발팀의 구성 방식을 바꾸고, QA와 주니어 개발자의 일자리는 위험에 처할 수 있다는 것이다. 

일부 IT 리더는 AI 어시스턴트가 코드 작성을 더 잘하게 되면서 CIO와 개발 리더들이 AI 전문가와 선임 개발자를 중심으로 팀을 재편해 AI 생성 코드를 감독하게 할 수 있다고 말했다.

클라이밋 테크 전략 어드바이저의 설립자이자 차량-그리드 간 애플리케이션 제공업체 페르마타 에너지의 전 개발팀장인 안나 데메오는 애플리케이션 개발팀이 더 간소화되고, 남은 시니어 개발자들이 제품 요구 사항을 소프트웨어 개발로 옮기는 일에 집중하게 될 것이라고 전망했다.

데메오는 특히 기업들이 AI 코딩 어시스턴트에 의존하면서 주니어 개발자, 인턴, 경우에 따라서는 제품 관리자의 역할을 AI로 대체할 것이라고 예상했다. 그는 “큰 팀에는 항상 A 플레이어와 B 플레이어가 있다. C 플레이어는 없길 바라지만 그들도 존재한다. AI는 어떤 면에서 C나 B 플레이어의 설 자리를 더 줄일 수 있다”라고 말했다. 

그는 남은 개발자들이 이제 비즈니스 요구사항을 이해하고 제품 전문가, 마케팅 부서, 기타 직원들과 교차 기능팀에서 활약할 수 있는 비판적 사고를 가져야 한다고 조언했다. 

‘편집자’로서의 개발자
데메오는 이미 일부 고객사가 AI를 중심으로 개발팀을 재편하고 있으며 시니어 개발자나 소프트웨어 아키텍트가 AI 생성 코드를 감독 및 수정하고 있다고 말했다. 그는 다양한 역할에 영향을 미치고 있는 이런 변화를 소설 출판 과정에 비유했다.

데메오는 “개발자는 더 이상 작가가 아니라 편집자다. 시니어 개발자는 콘텐츠와 독자가 누구인지, 다시 말해 고객이 누구이며 조직이 무엇을 달성하려고 하는지 이해해야 한다”라고 설명했다.

세일즈포스용 데브옵스 플랫폼 제공업체 코파도(Copade)의 에반젤리즘 담당 수석 부사장인 데이비드 브룩스는 미래의 개발팀이 제품 매니저 또는 비즈니스 분석가, UX 디자이너를 비롯해, AI 도구로 프로토타입을 생성한 다음 출시 준비가 될 때까지 코드를 조정하는 소프트웨어 아키텍트 등으로 구성될 것이라고 말했다. 그는 보안 및 규정 준수 검토 등의 나머지 소프트웨어 개발 역할을 AI가 담당할 가능성이 높다고 언급했다.

브룩스는 “언젠가는 현재의 소프트웨어 개발 일자리가 없어질 수 있다. 그렇다면 주니어 소프트웨어 개발자가 가장 먼저 피해를 볼 것"이라며 "소프트웨어 아키텍트는 코딩 대신 더 높은 수준의 시스템을 설계하며 AI가 생성한 솔루션을 확인하는 일을 주로 맡게 될 수 있다"라고 설명했다.

브룩스는 몇 가지 난관도 있다면서, 특히 다음 세대의 소프트웨어 아키텍트를 양성하는 일이 주요 과제라고 언급했다. 주니어 개발자 일자리가 줄어들면 더 높은 직급으로 자연스럽게 올라갈 수 있는 길인 도제식 교육도 이뤄질 수 없기 때문이다.

확산되고 있는 코딩 어시스턴트
개발팀 재편이 얼마나 빨리 이뤄질지는 불분명하지만, 깃허브가 최근 실시한 설문조사에 따르면 개발자들 사이에서 AI 코딩 어시스턴트의 사용은 이미 확산되고 있다. 4개국 개발자의 97% 이상이 직장에서 AI 코딩 어시스턴트를 사용한 적이 있다고 답했는데, 이는 코딩 어시스턴트가 오늘날 생성형 AI의 최대 인기 사용 사례 중 하나라는 업계의 관측과 일맥상통한다.

깃허브는 지난 1월 말 기준 코파일럿 코딩 어시스턴트 사용자가 130만 명으로 전 분기 대비 30% 증가했다고 밝혔다. 마이크로소프트에 따르면 지난 7월 말까지 7만 7,000개 이상의 조직에서 코파일럿을 도입했다.

한편 온라인 교육 제공업체 플루럴사이트의 최근 연구 결과에 따르면, 조사에 참여한 IT 전문가의 약 4분의 3이 AI로 인해 자신의 기술이 쓸모없게 될 것을 우려하고 있었다.

또한 일부 전문가는 많은 개발팀이 빠른 시일 내에 AI를 최대한 활용하기 위해 노력하는 상황에서 AI의 영향이 장기적으로 나타날 전망이라고 언급했다.

IT 컨설팅 및 서비스 제공업체 인텔리버스(Intelibus)의 설립자 에드 와탈은 기존 팀의 생산성을 높이고 AI 프롬프트 엔지니어링 기술을 구축하는 데 추가 코치가 필요하기 때문에 향후 1~2년 내에 개발팀 규모가 실제로 더 커질 수 있다고 말했다. 하지만 3명의 소프트웨어 엔지니어가 과거 5~6명이 하던 코딩 업무를 할 수 있기 때문에 장기적으로는 개발팀이 점점 더 축소될 것이라고 덧붙였다.

와탈은 더 많은 직원이 AI와 로우코드/노코드 도구를 사용해 애플리케이션을 작성하게 되면 기존 개발팀의 혼란이 가중될 수 있다면서, “직원들은 AI 생성 코드가 어떻게 작동하는지 깊이 이해하지 못할 수 있지만 코드를 작성할 역량은 충분하다”라고 언급했다.

많은 IT 리더들이 AI 코딩 어시스턴트가 궁극적으로 개발자 일자리를 줄일 것이라고 예측했지만, 일부 개발 리더들은 AI를 사용한 코드 작성과 디버깅이 현명한 방법인지 의문을 제기하기도 했다.

과대 평가된 장점?
코드 테스트 솔루션 기업 소스랩스의 수석 테스트 전략가인 마커스 머렐은 일부 조직이 AI 코딩 어시스턴트로 절약되는 시간을 과대 평가했을 수 있다고 말했다. 그는 개발자 생산성을 약 30% 개선한다는 것이 좋은 출발점으로 작용할 수는 있지만 근본적인 변화로 이어질 정도는 아니라고 지적했다. 

머렐은 “오늘날 현장에서는 팀들이 이런 도구를 통해 엄청난 이익을 얻을 수 있다고 생각해 도구에 과잉 투자하거나, 구조 및 프로세스 변경을 과도하게 진행하거나, AI 도구의 예상되는 장점만 갖고 이미 계획했던 직원 감축을 한층 더 심화하는 모습을 볼 수 있다”라고 지적했다. 

머렐은 생성형 AI가 개발자 일자리를 대체할 것이라고 생각하지 않으며, 그보다 로우코드/노코드 도구가 더 큰 영향을 미칠 수 있다고 내다봤다. AI 코딩 실험이 적당한 성공을 거두며 계속되더라도 결국 AI 대기업들은 막대한 투자액만큼의 수익을 거둬야 하기 때문이다.

머렐은 “앞으로 2~3년간 이 기술에서 온갖 생산성을 짜내기 위해 노력한 다음에는, 결국 허울에 불과했다는 것을 인정하는 데까지 매우 오래 걸릴 수 있다. 우려되는 점은 도구에 익숙해지고 나면 기업들이 모델을 운영하는 데 드는 비용을 청구하기 시작한다는 것이다. 그 때가 되면 시스템에는 큰 충격을 줄 수 있다”라고 진단했다.

https://www.ciokorea.com/news/350438

https://www.itworld.co.kr/numbers/82001/344908

아틀라시안이 최근 발표한 2024년 개발자 경험 현황 보고서(State of Developer Experience Report 2024)에 따르면, 많은 기업이 개발자 생산성을 잘 이해하지도, 잘 활성화하지도 못하는 것으로 나타났다. DX(developer experience)에 대한 관심은 증가하고 있지만 개선하려는 노력은 그보다 뒤처지고 있는 것으로 조사됐다.
 

ⓒ Getty Images Bank
2024 개발자 경험 현황 보고서는 미국, 독일, 프랑스, 호주의 엔지니어링 리더 1,250명과 전 세계 개발자 900명을 대상으로 실시한 설문조사를 기반으로 작성됐다. 해당 설문조사는 오늘날 소프트웨어 개발 업무의 원활한 흐름을 유지하는 관행과 마찰을 유발하는 관행을 파악하기 위해 실시됐다. 

생성형 AI와 마이크로서비스 시대의 업무 환경에 대한 인식도 조사했다. 조사 결과, 기업이 개발자 경험을 우선시한다고 생각하는 개발자는 절반 미만이었으며, 개발자 3명 중 2명은 비효율적인 업무로 인해 주당 8시간 이상 손해를 본다고 답했다. 또한 AI 도구를 사용해도 생산성 향상을 크게 체감하지 못하는 개발자도 3명 중 2명꼴이었다. 

엔지니어 리더들이 꼽은 개발자 역할 복잡성의 상위 5가지 원인은 인력 부족, 개발자 역할 확장, 새로운 기술, 도구 간 컨텍스트 전환, 다른 팀과의 협업 등이다. 개발자의 시간 손실에 기여하는 상위 5가지 요인은 기술 부채, 불충분한 문서화, 빌드 프로세스, 심층 작업을 위한 시간 부족, 명확한 방향성 부재 등이 지적됐다. 설문조사에 참여한 거의 모든 엔지니어링 리더(99%)가 개발자 역할이 더 복잡해졌다는 사실을 인정했다. 리더들이 개발자 생산성과 만족도를 향상시킬 수 있다고 생각하는 상위 5가지 사례에는 AI 자동화, 새로운 협업 도구 제공, 위험 감수 및 실험, 의사 결정 간소화, 해커톤 개최가 포함된다. 

그 외 2024 개발자 경험 현황 보고서의 주요 조사 결과는 다음과 같다. 

• 응답자 12%는 향후 2년 내 AI 도구가 개발자의 생산성을 향상시키지 못할 것이라고 답했다.
• 개발자 생산성 측정에 집중하는 기업은 51%, 개발자 만족도에 집중하는 기업은 49%다.
• 엔지니어링 리더 41%는 개발자 생산성을 측정하는 도구를 사용해 개발팀 만족도를 평가한다.
• 38%의 기업이 근무 시간으로 개발자 생산성을 측정한다.

소프트웨어 개발이 쉽다고 생각하는 사람은 아무도 없지만, 이렇게나 다양한 방식으로 어려울 수 있다고 누가 생각했을까? 에반스 데이터에 따르면, 전 세계의 소프트웨어 개발자는 약 2,690만 명으로 추산된다. 

최근 AWS의 알리 스피텔이 트위터를 통해 던진 "개발자로서 일하면서 가장 어려운 부분이 무엇인가?"라는 질문에 100명 이상의 개발자가 답했다. 답변은 대부분 몇 가지 핵심 주제에 수렴할 것으로 예상했지만, 실제로는 매우 다양했다. 개발자의 삶을 개선할 방법을 찾고자 하는 기업이라면, 이들 응답을 자세히 살펴볼 가치가 있다. 개발자들의 이야기를 들어보자.

점점 늘어나는 프로젝트 범위
때때로 우리는 개발자를 너무 사랑한다. 우리는 개발자(새로운 킹메이커와 퀸메이커)에게 의존해 혁신을 이루고 혁신을 지속한다. 카일 쉐블린은 "제품과 디자인에 대한 끊임없는 범위 확대의 위협"이 개발자의 삶을 어렵게 만든다고 지적했다. 이는 개발자의 재능에 대한 건강한 믿음에서 비롯된 것이지만, 무분별한 범위 확대는 잔뜩 부풀어 오른 소프트웨어를 낳고 이런 소프트웨어는 유지 관리도 어렵다. 브라이언 심쿠스가 강조한 것처럼 여기에 "비개발자가 설정한 비현실적인 마감일"이 더해지면 이중고를 겪게 된다.

또한 다니엘레 헤벌링이 지적하듯이 개발자는 "실제로 구축해야 하는 것과 기대되는 결과물에 대한 팀 내 의견 불일치"를 싫어한다. 개발자는 항상 "더 나은 솔루션이 있는지 끊임없이 의심"하게 된다. 물론 더 나은 솔루션은 존재하기 마련이다. 다만 뒤늦게 그 해결책에 도달할 뿐이다. 핵심은 자비어 곤잘레스가 주장하듯이 "완벽주의의 무한 루프를 멈출 때"를 파악하는 것이다. 코드는 결코 완벽할 수 없다. 이를 받아들이고 계속 나아가야 한다.
 
학습의 속도
수십 년 동안 코볼에 대한 이해에 안주해 온 모든 개발자는 오늘날 프레임워크의 유동성이라는 현실에 직면해 있다. 브랜던 트래본은 개발자에게 "언어와 프레임워크의 끊임없는 변화를 따라잡는 것"은 심각한 도전이 될 수 있다고 지적했다. "가장 주목받을 수 있다고 생각되는 것을 골라 거기서부터 시작”할 수 있지만, 그것만으로는 충분하지 않다. "물론 새로운 것으로 '전환'할 준비가 되어 있어야 한다." 프레임워크는 개발자가 데이터베이스나 기타 시스템을 제대로 활용하지 못하게 만드는 경우가 많지만, 때로는 개발자가 혁신의 속도를 따라잡을 수 있는 유일한 방법이기도 하다. 그럼에도 불구하고 쉬운 일은 아니다. 프레임워크가 도움이 되긴 하지만 프레임워크도 변화하고, 그 변화가 문제를 일으킨다.

이와 관련된 것은 애플리케이션 자체의 아키텍처이다. 마이클 자크제스키에 따르면, "애플리케이션이 어떻게 발전할지 예상해 최상의 아키텍처를 준비하되, 처음부터 무리하지 말아야 한다." 어려운 일이다. 예를 들어, 개발자는 확장에 대비해야 할 수도 있지만, 미리 비용을 초과할 정도로 과도하게 프로비저닝해서는 안 된다.
 
'더 많이 코딩할 수만 있다면'
루크 프로서는 "코딩하지 않는 모든 것"은 소프트웨어 개발을 어렵게 만든다고 말한다. 일부 조사에 따르면, 개발자는 전체 시간 중 5%만 코드를 작성하고 나머지 70%는 코드를 이해하려고 노력하거나 코드와 관련이 없어 보이는 일을 하는 데 소비한다. 이를 "코딩 프로세스를 시작하기 위해 모든 세부 사항을 파악하려고 노력하는 것"이라고 표현하기도 한다. 또 다른 까다로운 문제가 있는데, 바로 "팀 간 협업, 특히 대기업의 경우"이다. 0과 1에 초점을 맞추고 싶지만 소프트웨어 개발은 궁극적으로 사람이 하는 것이며, 사람은 어렵다.

AI가 소프트웨어 개발에서 인간을 배제할 것이라는 일반적인 두려움은 어떤가? AI가 사람을 대체할 수는 없다. 지금은 물론 앞으로도 없을 것이다. 그러니 "매일 아침 일어나서 내가 여전히 이 일과 이 산업에 관심이 있다고 스스로를 설득해야 하는", "LLM이 우리를 비롯한 모든 실제 가치를 창출하는 사람들을 쓸모없게 만들 것이라고 예측하는 관리자들이 걱정하는" 제시카 리와 나머지 모든 숙련된 소프트웨어 개발자들에게 이 말로 끝을 맺고 싶다. “기계가 소프트웨어 개발의 지루한 작업을 더 많이 맡게 되면서 진정으로 사려 깊고 혁신적인 작업은 여러분과 같은 창의적이고 훌륭한 개발자가 영원히 수행할 것이다.”

https://www.itworld.co.kr/news/335871

소프트웨어 개발자의 생산성을 측정하는 방법

https://www.itworld.co.kr/news/315198

소프트웨어 개발자의 효율성을 측정하는 것은 수십 년 동안 불가능한 것으로 여겨졌다. 두 명의 맥킨지 컨설턴트는 개발자가 개발자의 생산성을 측정할 수 있는 방법을 소개한다.

우리는 다양한 산업 분야의 많은 기업과 협력한 결과, 소프트웨어 개발자의 생산성을 측정할 수 있는 방법을 찾았다. 3년 전, 맥킨지는 440곳 대기업의 개발자 속도를 분석했다. 그 결과 소프트웨어 개발자의 성과와 회사의 성공 사이에는 분명한 상관관계가 있다는 사실이 밝혀졌다. 이는 IT 기업뿐만 아니라 다른 분야에도 적용된다. 전 세계 소프트웨어 엔지니어의 약 절반이 IT 산업이 아닌 다른 산업군에서 일한다.
 

ⓒ Getty Images Bank
현재 전 세계적으로 약 2,700만 명의 개발자가 있으며, 440만 명이 미국에 있다. 미국 노동통계국은 2021년부터 2031년까지 이 숫자가 25% 더 증가할 것으로 예측하고 있다. 생성형 AI의 급격한 확산을 고려하면, 개발자 수요는 훨씬 더 커질 것이다.
 

성과와 직결되는 개발자 생산성

이런 조사 결과를 종합하면, 관리자는 소프트웨어 개발 인재를 가장 잘 활용할 수 있는 방법을 정확히 알아야 한다는 결론에 도달할 수 있다. 오늘날의 소프트웨어 개발은 창의적인 과정일 뿐만 아니라 협업 과정이기도 하므로 이는 쉽지 않은 일이다. 노력과 수익 간의 합리적인 관계를 보장하는 것은 결코 쉬운 일이 아니다. 이미 많은 기업이 시스템, 팀, 개인의 생산성을 측정하는 데 실패했다.

배치 빈도와 같은 알려진 지표는 팀의 생산성을 추적하는 데 도움이 될 수 있지만, 개인의 생산성을 추적하는 데는 도움이 되지 않는다. 하지만 우리는 개발자의 생산성을 측정하는 일이 가능하다고 생각한다. 특히 맥킨지는 이미 이 작업을 수행하고 있는 20여 곳의 IT, 금융 및 제약 회사와 협력하고 있다. 아직 100% 신뢰할 수 있는 결과는 얻은 것은 아니지만, 유망한 결과이다. 맥킨지의 계산에 따르면, 이들 기업은 개발자의 생산성을 측정하고 개선해 오류율을 평균 20~30% 줄이고 고객 만족도를 60%까지 높일 수 있었다.
 

개발자의 생산성을 측정하는 방법

우선, 구글과 마이크로소프트에서 개발한 두 가지 지표, 즉 소프트웨어 배치 처리량과 안정성을 측정하는 DORA(DevOps Research and Assessment)와 개발자의 개별 생산성을 측정, 이해 및 개선하기 위해 설계된 프레임워크인 SPACE(Satisfaction, Performance, Activity, Communication/Collaboration and Efficiency)를 활용한다. 맥킨지는 이들 지표를 다음과 같은 네 가지 '기회 지향 지표'로 보완했다.

내부 루프 및 외부 루프에 소요된 시간. 내부 루프는 코딩, 빌드, 단위 테스트 등 소프트웨어 제품 개발과 직접 관련된 활동을 포함한다. 외부 루프는 코드를 프로덕션 환경으로 이전하는 것과 관련된 활동으로, 통합, 테스트, 릴리스, 배치 등을 말한다. 개발자가 내부 루프에 더 많은 시간을 할애할수록 생산성이 높아지는데, 상위 기업의 경우 이 비율이 70%에 달한다.

개발자 속도 지수(Developer Velocity Index, DVI) 벤치마킹. 사내 프랙티스를 다른 회사 또는 경쟁사의 프랙티스와 비교함으로써 개선해야 할 영역을 파악할 수 있다. 백로그 관리, 테스트 또는 보안 및 규정 준수 등이 이에 해당한다.

개발자 기여도 분석. 팀이 백로그에 어떤 기여를 하고 있는지 평가한다. 백로그 관리를 측정하는 지라(Jira) 같은 툴을 사용해 성과 향상을 방해하는 부정적인 흐름을 파악할 수 있다. 작업 환경을 개선하고 자동화 수준을 높이거나 팀원 개개인의 기술을 최적화할 방법을 보여줄 수도 있다. 예를 들어, 한 회사는 자사의 최고 개발자들이 코딩 이외의 활동에 너무 많은 시간을 소비하고 있다는 사실을 깨달았고, 모든 개발자가 자신이 가장 잘하는 일에 집중할 수 있도록 운영 모델을 변경했다.

인재 관리. 인재 관리의 목표는 직원들이 각자의 재능과 선호도에 따라 배치하는 것이다. 업계 표준 역량 맵을 사용해 조직의 기존 지식, 기술 및 능력을 가시화할 수 있는 점수를 만들 수 있다. 이를 통해 격차와 약점을 파악할 수 있다. 예를 들어, 한 고객사는 경험이 부족한 개발자를 너무 많이 고용하고 있다는 사실을 깨달았다. 이 문제를 해결하기 위해 맞춤형 학습 프로그램을 제공했고, 개발자의 30%가 6개월 이내에 다음 단계의 역량에 도달했다.

이런 접근법은 DORA 및 SPACE와 함께 소프트웨어 생산성에 대한 차별화된 관점을 가능하게 한다. 또한 개발자에게 동기를 부여할 수 있는 방법, 적절한 툴와 전문 지식을 보유하고 있는지, 시간을 어떻게 사용하는지, 팀 구성이 최적화된 상태인지 등을 파악할 수 있다.
 

성공의 증거는 없지만 명확한 지표

개발자 생산성 측정은 여전히 논란의 여지가 있는 주제이며, 많은 전문가가 우리의 시도를 부정적으로 생각한다는 것도 알고 있다. 하지만 맥킨지와 긴밀하게 협력하는 20개 기업은 이에 동의하지 않는다. 우리는 소프트웨어 개발이 측정이 불가능할 정도로 복잡하고 신비롭다고 생각하지 않는다. 오히려 업데이트를 코딩하고 구현할 때 생성형 AI 도구를 사용하면 얼마나 개선되는지 꽤 잘 예측할 수 있다.

여기서 설명한 개발자 생산성 측정 시스템은 아직 완벽하지 않다. 우리는 개선해야 할 부분에 대한 건설적인 비판을 언제나 환영한다. 하지만 소프트웨어 개발의 중요성이 날로 커지고 인재 확보 경쟁이 치열해지는 상황에서 복잡하다고 미뤄두기에는 너무나 중요한 주제이다.