그리고 당신은 대부분의 시간을 회의에 쏟으며 구현 감각이 무뎌지고 있다는 사실 때문에 깊은 고민을 하고 있을 것입니다. 특히 퇴근길에 갑작스레 찾아오는 '아무것도 남지 않았다'라는 불안감과 프로젝트 릴리스 일정 압박으로 인한 감정 소모는 참으로 힘든 일이 아닐 수 없었던 기억이 납니다.

탈출구를 찾고 싶고 대리만족을 위해 늦은 저녁과 주말에 리팩토링을 하거나 소셜 미디어에 개발 관련 포스팅을 하는 것은 순간의 안정감을 느끼게 해 줄 수 있지만 근본적인 해결책은 아닐 거에요.

만약 코드 기여를 통해 구현과 운영에 참여하고자 하는 마음이 아주 크다면, 우선 팀 규모를 작게 만들건 리더의 역할에서 벗어나 자유롭게 코드에 기여할 수 있도록 상위 의사 결정자에게 제안하는 것이 더 나은 방법이라고 생각해요.

그래야 동료들과 함께 스케줄을 조정하여 병목 현상을 최소화할 수 있어요.

그리고 불필요한 스트레스를 줄이면서 자신의 만족도를 높일 수 있는 최선의 방법이 아닐까 싶습니다.

그런데 만약에 개발 조직을 리드하는 것에 대해서 더 도전을 하고 싶은 마음이 든다면 미래의 당신인 내가 당신에게 몇 가지 이야기를 해주고 싶어요.

개발 패러다임 변화에 관하여.

TDD, 리팩토링, 객체지향, 모듈화, DDD 등의 기초 개념들은 수 년이 지난 지금도 여전히 소프트웨어 개발 분야에서 중요한 개념으로 쓰이고 있어요. 하지만 이것만으로 개발 역량이 높다고 판단하지 않는 시대가 다가오고 있답니다.

많은 사람들의 노력으로 해당 개념들을 쉽게 풀어쓴 콘텐츠들이 많아졌고 이를 무료로 공유함으로써 관련 지식이 빠르게 보편화되었기 때문에 이제는 해당 개념들은 엔지니어에게 기본 소양이 되었다고 생각해요.

최근에는 개발 경험이 적은 개발자들도 이러한 개념들을 명확하게 이해하고 적용하는 경우가 눈에 띄게 많아졌어요. 유명한 프레임워크나 라이브러리를 원리를 알고 능숙하게 사용하는 것이 개발자로 첫 발을 딛는 신입 개발자들의 기본기가 되어가고 있다는 느낌마저 들어요. 요즘들어 주변에서 부쩍 문제 상황을 빠르고 정확하게 해결하는 주니어 개발자들을 쉽게 찾아 볼 수 있기도 하고요.

물론 이와 같은 움직임은 지식 산업에서는 흔하게 일어나는 현상이고 과거에도 같은 양상으로 흘러가는 경우를 쉽게 찾아 볼 수 있죠. 그 흐름 중 하나는 경험이라는 가치가 중요하게 여겨지는 시기가 있는데 오늘날 개발에서 도메인 구현 경험과 함께 레거시 개선에 대한 경험에 대한 가치가 높아지는 시기를 맞이하고 있는 것은 아닌가 싶어요.

최근 여러 회사에서 Temporal Coupling 문제를 해결하고 싶은 경우를 쉽게 접할 수 있는데요.

지난 10년간 다양한 서비스가 고객들의 사랑을 받으면서 급성장을 하게 되었고 이에 발맞추기 위해 빠르게 개발했던 것들의 부채를 상환해야 하는 시기가 도래한 것으로 볼 수 있죠.

이러한 Temporal Coupling이 발생하는 현상은 Sequencing 원인으로 귀결되는 경우가 적지않고 이를 해결하려면 구현 스킬의 문제인지, 요구사항을 수렴하기 위해서는 어쩔 수 없는 선택인지 파악이 되어야 그 개선점을 찾을 수 있다고 생각해요.

또한, 예전에는 문제가 되지 않았던 도메인이 갑자기 트래픽 증가로 인해 데이터에 대한 동시성 문제가 간헐적으로 발생하여 디버깅에 어려움을 겪는 경우도 적지 않게 찾아볼 수 있게 되었어요.

최근에 접한 레거시를 개선하면서 말도 안 되는 상황 중 하나를 겪은 적이 있는데요.

특정 도메인의 레이턴시 개선으로 인해 다른 도메인에서 참조하는 데이터가 예전과는 다르게 수정된 값을 읽어서 처리하는 예외사항이 발생했었죠. 개선 전에는 접근하는 클라이언트가 데이터의 값을 변경하는 프로세스보다 무조건 늦는다는 암묵적인 로직이 적용되어 있었기에 해당 문제가 부각되지 않았던 케이스였던 거죠.

이와 같은 이슈는 데이터에 영향을 주거나 받는 모든 주요 코드를 확인해서 수정하는 방법을 선택하여 해결(시간이 없다는 것은 안 비밀) 해야 하는 것이 정석이라고 생각해요.

다만 주의해야 할 것은 초기부터 레거시를 개선하기 위해 철저하고 자세한 계획을 세우고 세워진 계획대로 개선을 하는 방법을 쓰지는 않는다는 거에요.

그 이유는 그렇게 많은 시간을 투자한 계획이 계획대로 되지 않는다는 현실 때문이죠.

계획을 철저하게 잡고 수행할 때 여러 문제가 발생하는데, 그중에 가장 빈번하게 발생하는 것은 민감한 데이터들을 다루는 로직의 뭉치가 계획의 순서를 예측하지 못하게 만들어 버리는 문제라고 생각해요.

이를 수정하려면 뒤에 변경해야 하는 구현체가 줄줄이 연결되어 수정해야 하는 상황 발생하기 때문에 기존의 계획은 무너지기 마련이죠.

이런 상황은 우리가 기존 레거시 구현체와 코드를 100% 파악하지 못하는 것이 현실적으로 가장 큰 문제죠. 뿐만아니라 살아있는 서비스를 운영해야 하기 때문에 많은 변경점을 가진 작업을 한번에 진행하는 리스크를 안을 수 없기도 하고요. 따라서 우리는 작은 변경점을 가지고 잦은 개선을 해야 한다고 생각해요.

고전이지만 마틴파울러가 제안한 Strangler Fig Pattern(bliki: StranglerFigApplication)에 인사이트를 얻으면서 말이죠.

즉, 레거시의 개선에서는 레거시 로직의 증분을 최소화하는 것을 기준을 삼아야 하고 신규 및 수정 요구 조건이 생기면 그와 관련된 레거시 개선을 도려내면서 관련로직을 새롭게 만들어 내는 방법을 취해야 해요.

만약 이렇게 함에도 불구하고 포기해야하는 정책이 생긴다면 해당 정책을 구현했을 때 고객에게 발생하는 문제점이 무엇이고 우회 방법은 없는지 고객 접점에서의 고민을 필연적으로 해야 한다고 생각해요.

앞서 언급한 Temporal Coupling 이슈도 Async/Await 등 명시적인 비동기 처리 코드를 사용해서 가독성을 올리면서 미해결된 코드들을 도려내는 것을 기준으로 해당 도메인을 둘러싼 요구사항/정책을 정리해야 하죠. 그리고 클라이언트의 수정 및 필요에 따라 데이터까지 수정하는 등의 부분적인 모듈화를 점진적으로 진행하는 것을 추천해요.

이것은 마치 얽혀있는 실타래를 푸는 방법과 비슷하다고 생각하는데요. 실타래에서 가장 복잡하게 얽혀있는 실을 잡아 빼면 더 단단하게 얽히게 되는데 이때 적게 얽혀 있는 실을 풀어내면서 복잡하게 얽혀 있는 순으로 실을 풀어내면 더 쉽게 풀 수 있는 것처럼 말이죠.

레거시 개선에 대한 이야기로 논점이 흐려졌네요.

다시 말하고자 하는것은, 개발자의 경험이 앞으로도 중요한 시대를 맞이하고 있다는 것이에요.

이러한 시대성은 기술의 진보를 통해 여러 자동화된 시스템과 AI를 통해 더 효율성 있게 발전하고 있어요.

요구 조건/정책이 변화가 적은 도메인의 경우는 SaaS(System as a Service) 플랫폼으로 제공되어, 여러 가지 인터페이스를 조합해서 연동만 하면 사용 가능한 수준으로 빠르게 발전하고 있어요.

또한, 앞서 나온 레거시의 부분과 관련된 운영과 장애 대응도 모니터링 SaaS 로 제공하는 추적의 깊이와 정보 전달력이 매우 우수하기 때문에 문제 원인을 빠르게 발견하며 개선할 수 있게 되었어요.

뿐만 아니라 Copilot이나 AWS Whisperer를 통해서 코드의 자동화된 리팩토링이 일어나고 있기 때문에 코드 개선에 투입되는 많은 비용이 혁신적으로 줄어들 것으로 예상해요.

물론 레거시 구현체 중에 가장 골치 아픈 문제인 ‘상식적이지 않지만 구동되는 로직’은 사람의 손을 통해서 대부분 해결할 수밖에 없다고 생각하는데요. 오히려 이와 같은 구조의 개선 작업은 더 가치 있는 부분으로 부각될 것이라고 판단된답니다.

2023년 상반기는 2022년 11월부터 시작된 AGI의 열풍으로 지난 수 개월동안 엄청난 AI 서비스들이 쏟아져 나왔고 여러 서비스에서 시너지를 낼 방안을 강구하며 사람들의 사고도 많은 변화를 겪고 있어요.

이제는 암기를 위주로 개발하는 시대는 정말 끝자락에 와 있는 것 같은데 그 대상은 여러 서비스에서 기본적으로 사용하는 구현체부터 그 변화를 겪고 있다고 생각해요.

많이 사용하는 일부 구현체들은 베스트 프랙티스로 패턴화되어 있거나, 클린 코드의 개념에 따라 구현되어 있어요.

이러한 구현체는 AI 모델의 학습 데이터로 사용되기 때문에 프로젝트, 패키지, 기본 클래스의 스켈레톤 정도는 몇 분 안에 자동으로 생성할 수 있게 되었으며 세부 코드 역시 자동화로 구현 시간을 많이 절약할 수 있게 되었어요.

여전히 자동화로 만들어진 구현체에 대해서 리터칭이 필요할 수 있지만 요구사항을 잘 정리하고 간단한 클래스의 책임과 기능을 파악해서 AI에게 코드 구현을 위임한다면 많은 시간을 절약할 수 있다고 생각해요.

이제 멀지 않은 시간에 개발이라는 것은 1) 산업에 대한 이해를 바탕으로 짜임새 있게 단계별 구현 구상을 하고 2) 구상에 맞는 모듈을 설계를 해서 3) 조리 있게 단계별로 IDE를 통해 프롬프팅을 하는 것으로 구현의 큰 틀을 만들게 되는 것 같아요. 그리고 4) 세부사항을 요구사항에 맞게 구현하는 것으로 개발 프로세스의 패러다임이 변화할 것이라고 생각해요.

개발팀 매니지먼트를 위한 딱 한가지 소프트스킬에 관하여.

그 시절에 개발팀을 리드함으로써, 본인을 인정하는 기준이 무엇인지 궁금했었던 것 같아요.

어떤 소프트스킬을 키워야 할지도 고민이었죠.

저는 팀의 상황에 따라 조금씩 다르겠지만 리더의 중요한 역량으로 팀 전략 수립, 조직 변화 대응, 비전 수립 등이 있고 이런 요소로 하여금 리더로 인정받는 기준이 될 수 있다고 생각해요.

하지만, 현업에서는 구체적인 것으로 리더의 역량을 가늠하기 때문에 사고의 흐름은 팀의 현재 모습으로부터 시작되곤하죠. 대표적인 역량은 다음과 같아요.

•

어려운 문제를 해결하고 나아가는 과정과 결과.

•

구성원들이 성장하고 있다고 느끼는 정도.

•

맡은 업무의 깊이와 넓이의 지속적인 확장.

•

구성원 간의 신뢰와 건강한 경쟁 요소 존재 여부.

•

팀 내/외부 협업 능력.

이와 같은 눈에 보이는 팀의 퍼포먼스들은 개인의 능력의 합으로 만들어지게 되는데요.

개인의 대표적인 능력으로는 다음과 같은 것들을 꼽을 수 있어요.

•

스스로 만들어내는 동기.

•

수평적인 환경에서 만들어진 책임감.

•

잦은 성공 경험으로 단단해지는 열정.

이러한 구성원의 능력에 리더의 소프트 스킬이 많은 영향을 주는데 그 소프트스킬 중에서 ‘신뢰를 얻기 위한 노력’이 가장 중요한 요소라고 생각해요. 그럼 이제 신뢰에 대한 이야기를 나눠보도록 하죠.

꾸준하게 팀워크가 좋은 팀의 리더들을 살펴 보면 구성원의 이해를 돕기위한 시간을 수시로 가지는 모습이 자주 포착 되곤해요. 그리고 의사결정에 앞서 그 과정을 적극적으로 공유하는모습을 찾아 볼 수도 있죠.

우리가 오해를 하지 말아야 할 것이 있는데요. 신뢰를 얻을 수 있는 행동이 일을 편하게 해주는 것이라고 착각하는 거죠.

리더가 흔히 하는 실수는 구성원들에게 일을 더 편하게 만들어 주는 것이 좋을 것이라는 생각이고 그렇게 환경을 만들면 구성원들이 본인을 신뢰할 것이라 여기는 거에요.

물론 일을 편하게 만들어 주는 것은 짧은 시간 안에 관계를 좋게 만들어 줄 수도 있다고 생각해요.

하지만 신뢰 관계를 만드는 것과는 관계가 없어 보여요. 오히려 신뢰가 떨어지는 요인으로 작용하곤 하죠.

신뢰에서 가장 먼저 취해야 할 행동은 구성원이 진행하는 일의 상황과 환경에 대해서 이슈가 발생하면 그것을 온전하게 이해하는 것이에요. 그 다음 구성원 스스로가 해결할 수 없다고 판단되면 관련된 논의를 깊이 진행하는 거죠. 그리고 해결 방안을 같이 고민하는 것이에요.

이와 같은 일련의 과정에서 동질감을 느끼게 되고 신뢰가 형성되는 것이라고 생각해요.

그리고 또 다른 이야기를 하자면 권위에 의한 신뢰는 얕다는 것인데요.

권위 자체는 지속적으로 만들어 갈 수 있지만 구성원의 피부에 와 닿지 않으면 권위에 의한 신뢰는 점점 사라질 수 있어요. 그래서 결국 함께 생각하고 행동하는 것으로 신뢰가 관리되는 것이라 생각해요. 외부에서 영입된 리더의 경우가 권위에 의한 신뢰가 초기에 만들어지는 하나의 예라고 볼 수 있죠.

권위 있는 엔지니어가 외부에서 합류를 하더라도 구정물에 손을 담글 수 없는 가치관을 가지고 있다면 신뢰는 오래가지 못해요. 살아있는 서비스를 지속적으로 운영하고 레거시를 포함하면서 새로운 시스템을 구현하기 위해서는 이상적인 프로그래밍 방법론이나 베스트 프랙티스만 필요한 것이 아니기에 그보다 앞서 실제로 동작하는 코드를 만들어 내는 것이 우선 필요하죠.

그래서 권위있는 엔지니어 역시 레거시 개선에서 언급한 것처럼 엉망진창인 레거시 코드를 도려내면서 동시에 새로운 코드를 이식해야 하는 고된 작업을 함께 진행해야 해요.

그런 측면에서 아이들나라 서비스를 만들고 있는 미래의 당신은 실용주의 프로그래밍을 지향하도록 구성원들과 함께 개발문화를 만들어 가고 있답니다.

의심스러운 사람은 쓰지 말고, 일단 사람을 믿고 썼으면 의심하지 말라.

상대방을 신뢰하려고 노력하는 것은 쉽지 않아요. 관계가 좋더라도 동료의 실수가 생기면 그것이 크게 보이기 때문인데요. 누구나 이런 마음은 쉽게 생기곤 합니다.

물론 실수에 대해서 맹목적으로 묵인하라는 이야기는 아니에요.

중요한 것은 동료의 실수를 대하는 나의 행동이 상대방이 일으킨 실수를 해결하고 재발을 막기 위한 행동인지, 아니면 자신의 이득이나 가십거리를 위한 행동인지를 판단해야 해요.

조직 내에 경험이 많은 사람들이 다수일 경우 이해보다는 신뢰가 더 중요하다고 생각하는데요. 시니어 개발자는 성공 경험에 따른 각자의 방식을 갖고 있기 때문에 시니어들이 제시한 여러가지 방식중 어떤 것이 가장 효과적인지에 대한 논의 자체가 무의미할 때가 많죠. 즉 선택의 문제라는 거에요.

따라서 시니어들에게는 이해시키는 것보다는 선택의 맥락을 알려주어 정보의 비대칭을 없애는 것이 먼저라고 생각해요. 그리고 만약 동의하지 않는 결정사항을 바탕으로 어쩔수 없이 일을 진행해야 한다면, 개인이 느끼는 불편함을 구체적으로 해결하면서 업무의 명확한 지시를 통해 몰입할 수 있는 환경을 만드는데 집중해야 한다고 생각해요.

이와 반대로 경험이 적은 구성원으로 이뤄진 조직이라면 이해를 시키는 시간을 상대적으로 많이 투자해야 하는데요. 주니어에게 협력을 통한 작은 시도를 할 수 있는 구현 환경을 만들어야 합니다. 그래서 자신이 구현한 제품에 대해서 고객들의 반응을 얻는 잦은 경험의 기회를 만들어줘야 해요. 이와 같은 작은 성공 경험은 여러 상황에서 발생하는 이슈나 과정에 대해서 ‘이해시키는 것’에서 ‘이해하는 것’으로 문제 해결능력을 성장시킬 수 있어요. 그리고 해당 과정에서 구성원들의 신뢰는 차곡차곡 쌓이게 되죠. 이렇게 신뢰관계로 만들어진 단단한 조직은 오랫동안 ‘퍼포밍 단계’를 유지할 수 있답니다.

개발팀 리더로서 실패에 관하여

지금까지 당신은 “개발팀이 실패한다.”라는 것에 대해서 생각해 본 적이 없을 것입니다. 왜냐하면 구현과 운영의 굴레로 인하여 팀은 지속적으로 유지되어야 한다고 생각하기 때문이죠.

하지만 글을 읽는 것을 멈추고 다시 한번 생각해 보세요.

당신에게 개발팀 리더로서 실패라는 것이 무엇을 의미하는지 말이죠.

구체적으로 ‘우리 팀 때문에 개발 일정이 어긋나는 경우’, ‘같은 장애가 발생해서 큰 이슈로 이어지는 경우’, ‘구성원이 팀의 염증을 느끼며 퇴사를 하는 경우’, ‘내가 속한 조직을 대상으로 조직개편이 일어나는 경우' 등의 상황에서 실패를 느낄 수 있어요.

앞으로 많은 실패를 경험하게 되지만 이를 통해 많은 성장을 하게 될 것이에요.

그래서 당신에게 필요한 것은 실패를 피하는 방법보다 실패 후 회복할 수 있는 용기라고 생각해요.

이제 그런 용기를 얻기 위해 실패와 관련된 몇 가지 이야기를 나눠볼까 해요.

먼저 구성원들에게 인기를 얻고 싶어서 착한 척을 하려고 노력하는 것과 상위 조직장에게 인정을 받고 싶어서 가스라이팅을 당하는 척하고 있다면 이와 같은 목적을 띄는 노력은 하지 말라는 이야기를 해 주고 싶어요.

이렇게 만들어진 인기와 인정은 허공에 버려지는 헛된 시간과 노력이 될 것이에요.

물론 인기를 얻고 싶고 인정을 받고 싶은 마음은 누구나 생기는 마음이겠죠.

그렇지만 당신에게 인기와 인정이 목적이 되는 순간, 모든 행동과 결정이 잘못된 방향으로 흘러가곤 하는데요. 그렇기에 매일같이 자라나는 그런 마음은 매일같이 비우는 자세를 견지해야 유지될 수 있어요.

여러 가지 노력으로 단기간에 인정과 인기를 얻을 수도 있다고 생각해요.

하지만 그렇게 얻은 인정과 인기는 지속적이지도 않을뿐더러 오히려 그런 당신의 모습이 함께 일을 하지 않아야 할 이유가 되기도 한답니다. 착한 사람 증후군과 같은 행동이라는 것을 동료들은 너무 잘 알고 있기 때문이에요.

마치 코드 리뷰에서도 의미 없는 따봉보다 매정한 개선 요구가 더 나은 코드를 만들어 낸다던지, 침묵으로 일관하는 회고보다 뼈 때리는 개선 요구를 하는 의견이 더 나은 프로젝트의 결과를 만들듯이 말이죠.

뿐만 아니라 레퍼런스 체크에도 사람이 좋다는 평을 받을 수 있지만 탁월한 성과를 만들어 낸다고는 답을 듣기는 어려울 수 있어요.

시간이 지나 몸 담았던 회사를 떠나게 되고 기존에 함께 일했던 동료들에게 일을 같이 하자고 제안을 할 때에도 그렇게 만들어진 인기와 인정은 오히려 독이 되어 돌아오게 되죠.

이렇듯 더 나은 것을 위해서라면 한순간의 불편함을 피하지 말고 옳은 방법을 선택하며 행동하세요.

동료의 인기와 인정에 대한 판단은 순간으로 만들어지는 것이 아니라 과정으로 만들어지는 거에요.

모든 조직이 존재하는 목적은 그 조직 외부의 사람들을 섬기기 위해서라는 것, 조직이 조직 내부의 사람들을 섬기기 위해 존재할 때 그 조직은 사멸한다는 것. - 피터 드러커 (Peter Drucker)

우리는 구현과 운영을 계속 수행하면서, 구성원의 업무 부담이 많은 상황을 자주 겪게 되는데요. 새로운 인력을 더 뽑더라도 쌓여있는 일의 양은 줄어들지 않는 경우가 많죠. 이는 팀의 구성원이 많을수록 더 정교하고 안정적인 구현과 기능을 요구하기 때문이에요.

업무 부담이 원활하게 분산되지 않는다면 리더는 업무의 스펙 아웃과 일정 연기에 대한 선택을 하죠. 이렇게 선택하는 이유는 리더가 구성원의 컨디션을 조절하기 위함이라고 생각해요.

하지만 그에 앞서 리더는 서비스의 상태와 고객 요구사항을 중심으로 판단을 해야 하는데요.

따라서 스펙 아웃이나 일정 연기에 대한 트레이드오프는 무엇이 있는지 살펴보고 대안을 마련하는 노력이 필요해요. 리더가 이러한 노력을 하지 않는다면 여러 팀 간의 협업이 무너질 수 있고 사업적인 타이밍을 놓칠 수 있으며 조직의 신뢰도는 낮아질 수 있어요.

따라서 지금은 제3자의 입장에서 팀의 성격을 판단해 보시길 바래요.

만약 팀의 성격이 내부 사람들을 섬기기 위해 기울어져 있다면 외부 사람들을 섬기는 모습으로 제자리를 찾는 노력이 필요하다고 생각해요.

이제 많은 사람들이 실패로 여기는 '조직 개편으로 인한 팀의 변화’에 대해서 이야기해 볼게요.

앞으로 당신은 수많은 조직개편을 맞이하게 될 것이며 그때마다 실패라는 단어를 연상하게 될 것이에요.

그런 감정은 당신 뿐만 아니라 많은 리더들도 느끼는 감정이죠.

특히 조직개편이 크게 일어나면서 그에 따른 리드 교체가 발생한다면 기존의 팀이 실패했다는 생각이 더욱 강하게 들곤 해요.

하지만 당신이 그렇게 느끼는 것과는 다르게 조직 개편은 특정 팀 때문에 실행하지는 않는다는 점이에요.

물론 그 팀의 영향 범위가 전체를 좌지우지하는 특수한 경우에는 그럴 수 있어요.

오히려 제가 경험한 조직개편의 이유는 사업의 환경 변화를 대응하는 경우나 조직 전반에 대해서 역동성을 더 많이 부여하는 측면으로 조직개편을 결정하는 경우였어요.

이와 같은 이유를 알고 있음에도 자신이 속한 조직에 대해서 조직 개편이 일어나게되면 상대적인 박탈감이 생겨나는 것은 어쩔 수 없는 감정의 변화라고 생각해요.

그렇게 생긴 감정을 억지로 감출 필요는 없어요.

중요한 것은 그 박탈감에서 얼마나 빠르게 벗어나서 새롭게 변화를 받아들이는 마음을 갖는지가 중요하죠.

만약 지금 다니고 있는 회사가 평생직장이라는 생각이 마음속에 자리 잡고 있다면 박탈감은 더 크게 다가올 수 있다고 생각해요.

그런 상황에서는 박탈감이 빠르게 해소되지 않을 수 있어요. 문제는 그다음에 연쇄적으로 일어나는 방어기제에요. 이 방어기제는 모든 업무 관점에 자리를 잡고 있기 때문에 당신에게 주어질 기회를 앗아가는 원인이 되며 변화와 도전에 대한 힘듦을 애초부터 예단하는 성질이 있어요. 결국 사람을 보수적으로 변화시키게 되죠.

따라서 박탈감에서 빠르게 벗어날 수 있는 방법 중 하나는 평생직장이라는 개념을 버리는 것 함께 자신의 무한한 능력을 신뢰하는 것 이예요.

그리고 자신이 만들고 있는 제품과 사용 고객에 집중하면서 이를 둘러싼 여러 가지 이벤트와 해결해야 하는 문제들을 스스로 극복하려는 관점의 변화가 필요해요.

시련은 인내라는 능력을 이끌어 내고,

인내는 도전과 회복의 능력을 이끌어 내며,

도전과 회복의 능력은 비전을 달성하는 주요한 원인이 될 것이에요.

따라서 지금 실패라고 느낀다면 오히려 반대로 성장이 멈추지 않았다는 시그널이라고 여기면 좋겠어요.

맺으며,

팀을 리드하는 것에 대해서 걱정이 많고 두렵기도 한 마음은 잘 알아요.

포기하고 싶은 마음이 생길 때도 많죠.

개발자로서 하고 싶은 것과 되고 싶은 것이 늘 일치하는 삶을 살았다가 어느 순간부터 그 차이가 생겼다는 것을 느낄 때 가장 힘들었던 것 같아요.

사실 시간이 지나서 뒤를 돌아보면 ‘하고 싶은 것’과 ‘되고 싶은 것’의 차이가 생긴것이 아니었던 거예요.

'하고 싶은 것'의 규모가 커지면 그 결과를 보기까지 시간이 많이 걸렸을 뿐이죠.

결국 그런 많은 시간으로 하여금 ‘되고 싶은 것’이 이뤄졌다고 생각해요.

어느 날 한 개발 팀을 리드하는 분이 저에게 와서 하소연을 한 적이 있어요.

”개발 리더로서 단위테스트가 있으면 좋겠어요”라고 말이죠.

저는 그 질문에 이렇게 답을 했답니다.

“개발 리더의 단위 테스트는 TestSuite로 구성되어야 의미가 있고, 전체를 수행하는 데 걸리는 시간은 한 일 년 정도 인 것 같아요” 라고 말이죠.

실패와 도전이 끊임없이 일어나고 있는 지금 당신이 치열한 도전과 실패에서 포기하지 않는다면 미래에 만들어질 엔지니어링 경쟁력에 대해서는 걱정하지 않아도 된다고 말하고 싶네요.

누구나 오늘은 처음 맞이하는 것이니 실패도 하고 도전도 하고 그러면서 당신의 스토리를 써 나아가면 그걸로 충분히 경쟁력 있는 삶을 사는 것이니까요.

이제 이야기를 맺어야겠어요.

마지막으로 많은 고민을 하고 있는 당신을 위해 어깨를 토닥이며 진심으로 해주고 싶은 말이 있어요.

”당신은 지금도 충분히 괜찮아요.”

미래에 서 있는 당신으로부터