<div id="readability-page-1" class="page"><div><div><h2 id="8a40">좋은 개발자는 좋은 경험을 원한다.</h2><div><a rel="noopener" href="/?source=post_page-----2f14925fd074--------------------------------"><div><p><img alt="조은, Eun Cho" src="https://miro.medium.com/fit/c/56/56/1*rWr6lzT5Ce1UGmteY0YPYw.jpeg" width="28" height="28"></p></div></a></div></div><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/11232/1*bj31A3JBbGQPwXWYZtgrcA.jpeg" width="5616" height="3744" role="presentation"></p></div><figcaption>Photo by <a href="https://unsplash.com/@artbyhybrid?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener nofollow">Hybrid</a> on <a href="https://unsplash.com/s/photos/happy?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener nofollow">Unsplash</a></figcaption></figure><p id="cb2d">지난 글에서 ‘비슷한 연봉이라면 자아실현을 더 할 수 있는 곳에서 일하고 싶어한다’ 라는 내용을 작성했던 적이 있다. 어떤 경험이 좋은 경험인가에 대해서는 사람에 따라서 다르겠지만, 내가 겪었던 좋은 경험을 몇가지 작성해보려고 한다.</p><p id="f266">다음 회사를 찾는 사람에게도 도움이 될 거라 생각되고, 현재 조직에서 어떤 경험에 집중해야 개발자들이 이직하지 않게 할 수 있을까 고민 중인 곳도 좋겠다.</p><h2 id="560f">실수를 개인에게 떠넘기지 않는다.</h2><p id="bfc3">개발자로 일을 하다보면 가장 자주 겪게되는 상황이 장애를 마주하는 상황이다. 장애<span id="rmm"><span id="rmm">는</span></span> 내가 짠 코드가 잘못되어 발생하기도 하고, AWS 같은 클라우드 서비스에 문제가 생기기도 하고, 다른 사람이 짠 코드가 잘못되어 발생하기도 한다. 한 가지 확실한 건 장애는 언제나 주변에 도사리고 있고, 개발자들은 장애 대응에 꽤 많은 리소스를, 더 해서 스트레스를 받는다는 점이다.</p><p id="7f1b">내가 있었던 좋은 회사들의 공통적인 특징은, 장애를 개인에게 떠넘기지 않고 그 상황 자체에 집중한다는 것이다. 장애를 누가 일으켰는가에 대해서보다, 어째서 일어났는가에 집중하는 것이다. 과거를 돌이키며 미래를 고민하는 건 중요하지만, 그 이상으로 개인이 일으킨 실수를 절대 개인에게만 책임을 전가해선 안된다는 점이다.</p><p id="7564">실수는 프로세스로 얼마든 지 막아낼 수 있다. 그러니 실수가 발생한 상황 자체는 조직 전체의 문제이며, 조직 전체가 그런 실수를 방지할만한 방지책을 고민하고 함께 연구해나가야 한다. 그러니 우리가 고민해야하는 건 미래에 장애가 발생했을 때 얼마나 빠르게 복구시킬 수 있을 지, 혹은 인간이 일으킬 수 있는 실수에 대해 최대한 방지책을 마련하는 것이다.</p><h2 id="cc3d">지속하여 배울 점을 준다.</h2><p id="3187">처음으로 프로젝트를 릴리즈하고, 새로운 기능을 지속해서 추가한다고 해도 제품을 지속해서 유지보수하는 일은 개발자에게 그렇게 매력적인 일이 아닐 수 있다. 현 상태를 유지하는 것만으로도 상당한 리소스가 들어가는 데, 거기에 신규 기능까지 추가해야하며, 거기에 버그나 장애가 일어나면 그 개인에게 책임을 돌리는 조직은 많다.</p><p id="2e4f">개발자가 지속하여 성장하는 포인트는 단순히 제품이 커지는 영역보다, 좋은 코드를 만들어내기 위한 여유 시간에서 찾아오기도 하고 리팩토링에 리소스를 투자하는 영역일 수 있으며, 더 나은 개발자가 우리 회사에 합류하여 해당 개발자가 작성하는 코드를 보는 것 만으로도 성장에 이를 수 있다.</p><p id="08a5">만약 개발 상으로 배울 점을 줄 수 없다면 그 외적 영역에서라도 배울 점을 지속하여 줄 수 있어야 한다. 성장하는 조직에 있다는 게 어떤 경험인 지, 유지 보수 할 때에는 어떤 점을 신경써야 하는 지, 하다 못해 외부 교육 지원을 해주는 한이 있더라도 어떻게든 성장에 도움을 줄 수 있어야 한다.</p><h2 id="342a">개발자의 의견을 존중한다.</h2><p id="ae72">다른 직군에서 개발자의 비즈니스 시야에 대한 무시가 날이 갈수록 심해지고 있다는 생각을 종종 한다. 예를 들어, 제품을 만드는 초기 단계에는 코드 설계와 안정성에 그렇게까지 투자하지 못할 수 있지만, 제품이 어느정도 안정화되고 나서는 코드 설계와 안정성이 중요해지는 순간이 온다.</p><p id="b95f">그러나 그런 순간에도 어떤 조직은 비즈니스에만 신경쓰다가, 즉 조직에서 생산하고 있는 코드가 얼마나 방대해지고 설계상 이슈가 생기고 있는 지에 대해서는 신경쓰지 않은 채로 기능을 지속해서 추가하다 보면 언젠가 코드 베이스가 돌이킬 수 없을 정도로 더러워지는 순간이 온다.</p><p id="4a9a">문제는 그럴 때의 생산성 저하조차 개발자의 책임으로 전가되는 경우가 많으며, 그런 상태의 개발자는 대부분의 경우 이직을 꿈꾼다 (아주 크게 지금 회사에 남아있어야하는 이유가 있는 게 아니라면 말이다).</p><p id="875d">이 과정은 꽤나 예민한 포인트가 많다. 개발자가 자신의 의견을 주장할 때 설득을 위한 과정을 생략하는 경우도 존재하고, 반대로 경영진이나 PM이 개발자를 설득시킬 때 설득 과정을 생략하는 경우도 종종 존재한다. 그럼에도 불구하고 모든 일이란 커뮤니케이션을 바탕으로 이루어지기 때문에, 언제나 서로 이야기를 나눌 수 있는 상황이어야 한다 생각한다.</p><h2 id="ba6f">더 나은 개발 조직을 만들기 위해</h2><p id="09b5">더 나은 개발 조직을 만들어나가기 위해서는 무엇보다 개발자들과 자주 이야기하면서, <strong>회사가 망하지 않는 수준</strong>에서 서로가 서로의 요구사항을 잘 들어주는 것이 중요하다. 물론 어떤 경우라도 회사가 망하는 수준의 요구사항이라면 당연히 거부할 수 있어야 한다. 모든 일에 긍정해서는 안된다 (…)</p><p id="6c46">본문에서 작성하지 않았지만 누군가는 코드 리뷰를 하는 걸 중요한 가치라고 생각하고, 누군가는 스터디 시간을 보장해주는 걸 중요한 가치라고 생각하는 사람도 존재한다. 하지만 그런 영역은 모두 지속하여 배울점을 준다는 소제목에서 다루었다고 생각하여 상세한 내용은 생략해보고자 한다.</p></div></div>

Stories by 조은, Eun Cho on Medium

choeun

좋은 개발자는 좋은 경험을 원한다.
지난 글에서 ‘비슷한 연봉이라면 자아실현을 더 할 수 있는 곳에서 일하고 싶어한다’ 라는 내용을 작성했던 적이 있다. 어떤 경험이 좋은 경험인가에 대해서는 사람에 따라서 다르겠지만, 내가 겪었던 좋은 경험을 몇가지 작성해보려고 한다.
다음 회사를 찾는 사람에게도 도움이 될 거라 생각되고, 현재 조직에서 어떤 경험에 집중해야 개발자들이 이직하지 않게 할 수 있을까 고민 중인 곳도 좋겠다.
실수를 개인에게 떠넘기지 않는다.
개발자로 일을 하다보면 가장 자주 겪게되는 상황이 장애를 마주하는 상황이다. 장애는 내가 짠 코드가 잘못되어 발생하기도 하고, AWS 같은 클라우드 서비스에 문제가 생기기도 하고, 다른 사람이 짠 코드가 잘못되어 발생하기도 한다. 한 가지 확실한 건 장애는 언제나 주변에 도사리고 있고, 개발자들은 장애 대응에 꽤 많은 리소스를, 더 해서 스트레스를 받는다는 점이다.
내가 있었던 좋은 회사들의 공통적인 특징은, 장애를 개인에게 떠넘기지 않고 그 상황 자체에 집중한다는 것이다. 장애를 누가 일으켰는가에 대해서보다, 어째서 일어났는가에 집중하는 것이다. 과거를 돌이키며 미래를 고민하는 건 중요하지만, 그 이상으로 개인이 일으킨 실수를 절대 개인에게만 책임을 전가해선 안된다는 점이다.
실수는 프로세스로 얼마든 지 막아낼 수 있다. 그러니 실수가 발생한 상황 자체는 조직 전체의 문제이며, 조직 전체가 그런 실수를 방지할만한 방지책을 고민하고 함께 연구해나가야 한다. 그러니 우리가 고민해야하는 건 미래에 장애가 발생했을 때 얼마나 빠르게 복구시킬 수 있을 지, 혹은 인간이 일으킬 수 있는 실수에 대해 최대한 방지책을 마련하는 것이다.
지속하여 배울 점을 준다.
처음으로 프로젝트를 릴리즈하고, 새로운 기능을 지속해서 추가한다고 해도 제품을 지속해서 유지보수하는 일은 개발자에게 그렇게 매력적인 일이 아닐 수 있다. 현 상태를 유지하는 것만으로도 상당한 리소스가 들어가는 데, 거기에 신규 기능까지 추가해야하며, 거기에 버그나 장애가 일어나면 그 개인에게 책임을 돌리는 조직은 많다.
개발자가 지속하여 성장하는 포인트는 단순히 제품이 커지는 영역보다, 좋은 코드를 만들어내기 위한 여유 시간에서 찾아오기도 하고 리팩토링에 리소스를 투자하는 영역일 수 있으며, 더 나은 개발자가 우리 회사에 합류하여 해당 개발자가 작성하는 코드를 보는 것 만으로도 성장에 이를 수 있다.
만약 개발 상으로 배울 점을 줄 수 없다면 그 외적 영역에서라도 배울 점을 지속하여 줄 수 있어야 한다. 성장하는 조직에 있다는 게 어떤 경험인 지, 유지 보수 할 때에는 어떤 점을 신경써야 하는 지, 하다 못해 외부 교육 지원을 해주는 한이 있더라도 어떻게든 성장에 도움을 줄 수 있어야 한다.
개발자의 의견을 존중한다.
다른 직군에서 개발자의 비즈니스 시야에 대한 무시가 날이 갈수록 심해지고 있다는 생각을 종종 한다. 예를 들어, 제품을 만드는 초기 단계에는 코드 설계와 안정성에 그렇게까지 투자하지 못할 수 있지만, 제품이 어느정도 안정화되고 나서는 코드 설계와 안정성이 중요해지는 순간이 온다.
그러나 그런 순간에도 어떤 조직은 비즈니스에만 신경쓰다가, 즉 조직에서 생산하고 있는 코드가 얼마나 방대해지고 설계상 이슈가 생기고 있는 지에 대해서는 신경쓰지 않은 채로 기능을 지속해서 추가하다 보면 언젠가 코드 베이스가 돌이킬 수 없을 정도로 더러워지는 순간이 온다.
문제는 그럴 때의 생산성 저하조차 개발자의 책임으로 전가되는 경우가 많으며, 그런 상태의 개발자는 대부분의 경우 이직을 꿈꾼다 (아주 크게 지금 회사에 남아있어야하는 이유가 있는 게 아니라면 말이다).
이 과정은 꽤나 예민한 포인트가 많다. 개발자가 자신의 의견을 주장할 때 설득을 위한 과정을 생략하는 경우도 존재하고, 반대로 경영진이나 PM이 개발자를 설득시킬 때 설득 과정을 생략하는 경우도 종종 존재한다. 그럼에도 불구하고 모든 일이란 커뮤니케이션을 바탕으로 이루어지기 때문에, 언제나 서로 이야기를 나눌 수 있는 상황이어야 한다 생각한다.
더 나은 개발 조직을 만들기 위해
더 나은 개발 조직을 만들어나가기 위해서는 무엇보다 개발자들과 자주 이야기하면서, 회사가 망하지 않는 수준에서 서로가 서로의 요구사항을 잘 들어주는 것이 중요하다. 물론 어떤 경우라도 회사가 망하는 수준의 요구사항이라면 당연히 거부할 수 있어야 한다. 모든 일에 긍정해서는 안된다 (…)
본문에서 작성하지 않았지만 누군가는 코드 리뷰를 하는 걸 중요한 가치라고 생각하고, 누군가는 스터디 시간을 보장해주는 걸 중요한 가치라고 생각하는 사람도 존재한다. 하지만 그런 영역은 모두 지속하여 배울점을 준다는 소제목에서 다루었다고 생각하여 상세한 내용은 생략해보고자 한다.

Developer Experience

댓글