일 잘 하는 개발자는 왜 비즈니스까지 신경쓸까?

이번 글에서는 개발자와 멀고도 가까운 주제인 비즈니스에 대해서 한번 이야기를 해보려고 한다. 개발자들은 좋은 설계와 튼튼한 어플리케이션을 만들기 위해 고심하고 노력하는 사람들이다. 하지만 좋은 설계를 위한 선택이 언제나 옳은 선택일 수는 없다. 왜냐하면 우리는 프로그래밍을 사용하여 돈을 벌기 위해 고용된 사람들이기 때문이다.

보통 개발자들에게 좋은 설계라고 했을 때 TDD, DDD, SOLID, 변경에 열린 구조, 순수 함수 등 기술적인 토픽들에 대해서 이야기하는 사람들은 굉장히 많지만 비즈니스에 대한 이야기를 하는 사람은 많지 않다. 개발자가 단순히 프로그래밍만 하는 사람이 아니라 프로그래밍을 이용한 비즈니스를 하는 사람들이라는 사실을 생각해보면 조금은 이상한 상황이라는 생각이 들었다.

우리는 고용되었다

간혹 프리랜서 개발자로 살아가시는 분들도 계시지만 필자를 포함한 대부분의 개발자들은 회사에 고용되어 일을 하고 있다. 그런데 회사라는 조직이 개발자를 고용하는 이유는 무엇일까? 당연히 여러분의 프로그래밍 스킬을 이용하여 돈을 벌기 위해서이다.

모두 알다시피 회사는 철저한 이익 집단이기 때문에 회사가 여러분에게 지급하는 연봉은 일종의 투자이다. 만약 회사가 여러분에게 3천만 원의 연봉을 지급한다면, 당연히 회사는 최소 3천만 원 혹은 그 이상의 가치를 가진 이익을 벌어다 주기를 바란다. 그 말인즉슨 개발자는 단순히 프로그래밍을 잘해야 하는 사람이 아니라, 프로그래밍을 바탕으로 돈을 잘 만들어낼 수 있는 사람이어야 한다는 의미이다.

회사가 개발자를 채용하는 이유는 결국 돈을 만들어 내기 위해서이다. (출처: Unsplash)

우리가 일하고 있는 IT 업을 전통적인 제조업에 빗대어 생각해보면 개발자나 디자이너의 역할은 물건 만드는 장인이다. 단지 만들어 내는 것이 실물에서 소프트웨어로 변화했을 뿐이다. 그리고 장인은 단지 제품의 퀄리티만 신경 쓰는 것이 아니라, 유저의 실제 만족도, 회사의 비즈니스적인 요구사항 등 많은 것을 동시에 책임져야 하고 신경 써야 하는 사람이다.

즉, 회사라는 이익 집단에는 그냥 프로그래밍만 잘하는 사람보다는 프로그래밍을 이용해서 유저를 만족시킬 수 있고, 이에 따라오는 매출을 만들어 낼 수 있는 사람이 필요하다는 것이다. 그렇기 때문에 많은 조직들이 좋은 장인들을 채용하기 위해 프로그래밍 스킬 외에도 원활한 제품 개발을 위해 필요한 이해관계자들과의 원활한 협업, 리더십, 비즈니스 인사이트, 유저 경험에 대한 이해 등 다양한 스킬을 요구하고 있는 것이다.

게다가 원활한 협업 스킬이나 유저 경험에 대한 이해 같은 것들은 당장 돈이 되지는 않더라도 장기적으로 보면 회사의 브랜딩과 문화에도 큰 영향을 미치며, 결국 그 조직이 일하는 방식과 퍼포먼스까지도 변화시킬 수 있는 것들이기 때문에 제대로 된 조직이라면 이런 점을 소홀히 하지 않는다.

즉, 개발자는 단지 프로그래밍을 하는 사람이 아니라 자신이 소속된 조직의 제품이 시장에서 성공하기 위해 달리는 많은 팀원들 중 하나라고 말할 수 있으며, 그렇기 때문에 개발자는 프로그래밍에만 집중하는 것이 아니라 전체적인 조직의 비즈니스 이슈들도 함께 볼 수 있는 넓은 시야를 가져야 한다.

왜 개발자들은 좋은 설계를 하려고 하는 걸까?

사실 개발자로 일을 하다 보면 내 자식 같은 제품을 위해 시간을 들여서라도 좋은 설계를 하고 싶은 마음이 들 수밖에 없다. 개발자들은 경험적으로 지금 설계를 개판으로 해놓으면 그 부채가 언젠가 부메랑이 되어 반드시 돌아온다는 것을 알고 있다. 그 대표적인 예시가 개발자들 사이에서 흔한 밈으로 구사되고 있는 “레거시 코드”이다.

프로그램의 흐름을 알아보기 힘들고 가독성이 떨어지는 코드는 잠재적으로 수많은 버그의 가능성을 품고 있다. 심지어 버그가 발생해도 요상한 예외처리 때문에 버그 트래킹 툴에 잡히지 않는 경우도 허다하다. 결국 이렇게 잠재적인 버그를 품고 있는 설계는 유저에게는 큰 불편함으로 다가올 수 있으며 심한 경우에는 유저의 중요한 해피 모먼트를 해쳐 유저를 이탈시킬 수도 있다.

더군다나 좋지 않은 설계를 개선하지 않고 그 위에 기능을 계속 붙인다면 결국 좋지 않은 설계만 늘어날 수밖에 없다. 개발은 매 기능을 만들 때마다 다 지우고 새로 시작하는 것이 아니라 이전에 만들어놓은 설계에 계속 이어 붙이는 것이기 때문이다.

이렇게 한번 설계가 어긋나게 되면 작은 것 하나만 건드려도 예상하기 어려운 곳에서 버그가 발생하는 상황이 잦아지기 때문에 개발자는 더 신중해질 수밖에 없고, 조직의 제품 개발 속도도 점점 느려진다. 심지어 나중에는 제품에 새로운 기능을 붙이고 싶어도 설계 때문에 정말로 불가능한 경우까지도 발생할 수 있다.

(출처: Unsplash)

결국 개발자들이 좋은 설계를 하려는 이유는 제품의 코드 퀄리티를 높여 빠른 개발 속도를 유지하고 예상하기 힘든 버그를 예방하기 위해서이다. 하지만 앞서 이야기했듯이 좋은 장인은 단지 프로그래밍만 바라보는 것이 아니라 비즈니스까지 포괄하는 넓은 시야를 가질 수 있어야 한다. 개발자는 결국 제품을 만들어서 유저에게 제공하는 사람들이기 때문이다.

유저에게 초점을 맞춰서 다시 생각해보면, 결국 개발자들이 좋은 설계를 하는 이유는 빠른 개발 속도를 유지함으로써 유저들에게 늘 빠른 속도로 개선된 제품을 제공할 수 있는 환경을 구축하고, 알 수 없는 버그로 인해 유저들이 이상한 경험을 하지 않게 하기 위한 것이라고 말할 수 있다.즉, 좋은 설계를 하는 것은 유저의 좋은 경험을 위한 것이다

하지만 잘 생각해보면, 개발자가 유저의 좋은 경험을 위해 할 수 있는 것은 좋은 설계만 있는 것이 아니다. 좋은 설계라는 것은 유저에게 좋은 경험을 선사하기 위해 할 수 있는 수많은 방법 중에서 하나일 뿐이기 때문이다. 좋은 개발자는 이런 여러 가지 선택지 중에서 현재 상황에서 가장 적은 비용으로 최대의 이익을 가져올 수 있는 방법을 선택할 수 있어야 한다.

우리는 방망이 깎던 노인이 아니다

흔히 장인 정신이라고 하면 대표적으로 이야기가 나오는 밈 중에 “방망이 깎던 노인”이라는 수필이 있다. 이 수필은 중학교 국어 교과서에도 실려있기 때문에 대부분 한번쯤은 읽어본 기억이 날 것이다.

이 글에 모든 내용을 작성하기에는 꽤나 내용이 길지만, 대략적으로 간추려 보자면 이런 내용이다.

대충 이런 내용인데, 마지막에는 장인의 깊은 뜻을 헤아리지 못한 주인공이 노인에게 찾아가서 사과하고 싶다는 말로 끝맺는다. 이 수필이 주는 교훈을 딱 한 마디로 줄여보자면 “장인정신에 대한 존중”이기에 뭔가를 만들어내는 사람들이 가져야 하는 마인드의 예시로 꽤나 자주 인용되고 있다.

작품 속 노인은 자신의 방망이 깎는 스킬에 대한 자부심이 큰 사람이다. 아마 오랫동안 이 업을 해왔을 것이고, 그렇기에 이 일에 대한 자신의 신념이나 가치관 같은 것도 명확할 것이다. 그리고 이런 점은 개발 업계에서 오랫동안 굴러온 개발자들도 딱히 다르지는 않을 것이라고 생각한다.

하지만 이 훈훈한 이야기와 현실 사이에는 결정적인 차이가 한 가지 있다. 이 노인은 애초에 자기 신념과 맞지 않는 사람에게는 물건을 팔 마음이 없었다는 점이다. 이건 마치 유저들이 “아니, 이 앱은 왜 이렇게 패치가 느려?”라고 하는 상황 속에서 개발자가 “난 꼼꼼하게 좋은 설계를 해야 하는 게 중요하니까 이게 싫으면 다른 앱 쓰세요.”라고 하는 것과 다를 바가 없다.

이렇게 생각해보니 이 노인이 더 이상 프로페셔널한 장인으로 보이지는 않는 것 같다. 진짜 프로페셔널이라면 유저가 원하는 시간 안에 최대한의 퀄리티를 뽑아내어 유저도 만족하고 나도 만족할 수 있는 방법을 찾아야 하는 것 아닐까?

작품 속의 주인공은 노인이 방망이를 깎는 모습을 보면서 “이 정도면 다 된 것 같은데 왜 계속하는 거지?”라는 불만을 품는다. 결국 노인을 개발자라고 생각하면 작품 속 주인공은 유저들이다. 그리고 이 착한 주인공과 다르게 유저들은 “왜 이래?”라는 생각을 하는 순간 더 이상 기다려주지 않으며, 개발자가 열심히 설계한 제품의 퀄리티를 보면서 감탄하지도 않는다. 유저들은 뭔가 이상하다고 생각이 드는 순간 여러분의 제품을 버리고 다른 제품을 사용할 것이기 때문이다.

비즈니스와 좋은 설계의 균형을 찾아보자

앞서 이야기했듯이 결국 개발자들은 비즈니스적인 요소까지 고려하면서 동시에 어플리케이션의 좋은 구조까지 고민해야 하지만 많은 개발자들이 좋은 설계에 대한 기술적인 공부에 비해 정작 비즈니스에 대한 고민은 많이 하지 않는다.

개발자들이 생각하는 일 잘하는 개발자는 프로그래밍을 잘하는 사람, 조금 더 넓게 보면 다른 개발자를 끌어줄 수 있는 능력이 있는 사람 정도인 경우가 많다. 그래서 우리는 일 잘하는 개발자가 되기 위해 함수형 프로그래밍 같은 패러다임이나 각종 디자인 패턴과 가이드라인들을 공부하고 실무에 녹이기 위해서 노력한다.

하지만 필자가 생각했을 때 진짜 일을 잘하는 개발자의 조건 중 하나는 저런 것도 다 하면서, 비즈니스적인 인사이트까지 있는 사람이라고 생각한다. 아니, 그 외에도 다양한 소프트 스킬을 모두 가지고 있어야 한다고 생각한다. 여러 번 이야기했듯이 개발자는 현실과 동떨어져 컴퓨터와 단 둘이 프로그래밍만 하는 사람이 아니기 때문이다.

사실 필자가 이야기하려고 하는 좋은 설계라는 것은 단순히 중복되는 로직을 추상화하여 분리하거나 변경과 확장이 용이한 패턴을 사용하는 것이 아니다. 상황에 따라서는 기존에 존재하는 코드를 그냥 복붙 하는 것이 좋은 설계일 수도 있으며, 매우 급박한 상황이라면 설계고 자시고 일단 작동만 가능하게 만들어서 배포하는 것이 좋은 설계일 수도 있다.

이게 정말 설계를 고민할 가치가 있을까?

사실 어플리케이션을 설계할 때 가장 선행되어야 할 고민은 바로 “이게 정말 설계를 고민할만한 가치가 있는가”이다. 이게 설계를 할만한 가치가 있는 것이라고 판단이 되면 그때부터 제대로 된 설계에 대한 고민을 시작하는 것이 맞다.

기본적으로 어플리케이션의 튼실한 설계는 당장의 단기적인 이익보다는 장기적인 관점에서의 이익으로 돌아올 가능성이 높기 때문에 내가 설계를 위해 투자하는 이 시간이 미래에 이익으로 돌아오지 못할 가능성이 더 크다면 그냥 설계를 대충 해버리고 일단 빠르게 기능을 만들어서 배포하는 것이 더 나을 수도 있기 때문이다. 비즈니스는 항상 Cost vs Benefit이다.

설계를 고민하는 시간에 무슨 코스트가 들어가냐고 할 수도 있지만 잘 생각해보면 분명히 소모되는 코스트는 존재한다. 여러분의 인건비 및 서버비, 사무실 월세 등 아무것도 하지 않고 시간만 흘러도 회사 통장에서 돈은 매일 줄줄 새 나간다. 특히 인건비 같은 경우는 의외로 많은 분들이 놓치고 있는 부분인데, 이게 은근히 돈이 많이 나간다. 지금 각자 계산기를 켜서 내 하루 일당 x 팀 인원수를 계산해보자. 한 팀에 연봉 3천만 원을 받는 사람이 5명만 있어도 하루에 52만 원 정도는 그냥 깨져나간다. 즉, 기능 하나를 만드는 데 5일이 걸렸다면 회사는 그 개발 비용으로 대충 260만 원 + @를 지출하게 되는 것이다. 이 플러스알파에는 아까 이야기했던 사무실 월세나 서버비 등이 포함되어있다.

물론 이 기능을 배포해서 중요한 전환율이 더 줄었다면 손해액은 더 커진다. 이게 바로 회사가 제품을 개발할 때 감수해야하는 리스크이다. 게다가 A/B테스트라도 한다고 치면 지금 내가 만드는 이 기능은 일주일도 안 돼서 지워질 운명일 수도 있다. 이런 상황 속에서 무조건 설계를 한다고 시간을 잡아먹는 것이 반드시 정답은 아니다. 즉, 우리는 “설계를 어떻게 해야 할까”를 고민하기 전에 “이게 정말 설계를 할만한 가치가 있나”부터 고민을 시작해야 하는 것이다.

튼튼한 설계보다 빠른 개발 속도가 중요할 때

사실 개발자로 일하다 보면 빠른 시간 안에 제품을 개발해야 하는 상황을 한번쯤은 마주치기 마련이다. 이때 빠르게 개발해야 하는 이유는 단순히 클라이언트의 요구일 수도 있고, 이제 막 시작하는 스타트업이라 빠르게 마켓 핏을 찾아야 하는 상황이거나, 혹은 정말로 회사 통장에 돈이 없어서 오늘내일하는 상황일 수도 있지만 중요한 것은 이유가 아니라 어쨌든 빨리 제품을 개발해야 한다는 것이다.

이런 상황 속에서 개발자들은 시간이 조금 들더라도 튼튼한 설계를 하고 넘어갈지, 아니면 일단 대충이라도 빠르게 만들어서 일단 배포를 할 지에 대한 고민에 빠지게 된다. 물론 개발 실력이 늘면 늘수록 (그동안 삽질하며 익힌) 짬에서 나오는 바이브가 있기 때문에 대충 설계했을 때의 코드 퀄리티 또한 점점 높아지기 마련이지만, 아직 경험이 부족한 개발자라면 정말 이해하기 힘든 코드가 나올 수도 있다.

앞서 이야기했듯이 개발자 눈에는 지금 설계를 제대로 해놓지 않으면 나중에 기술 부채가 되어 돌아올 부분들이 빤히 보인다. 게다가 장기적인 관점에서 봤을 때 설계를 계속 개판 친다면 어플리케이션의 복잡도는 점점 기하급수적으로 증가할 것이고, 그러면 나중에는 기능을 붙이고 싶어도 못 붙이는 상황도 발생할 수 있다.

여기까지 생각이 든 개발자는 결심을 한다.

"그래, 아무리 그래도 설계를 포기하는 건 좀 아닌 것 같아. 기간에 대한 협의를 해봐야겠다...!"

물론 개발자로서 이런 생각이 드는 것은 너무나도 당연하다. 하지만 중요한 것은 현재 개발을 빨리 해야 하는 지금 이 상황이 정확히 어떤 상황인지 파악을 해야 한다는 것이다. 만약 단순히 PO나 클라이언트가 성격이 급해서 개발 기간을 짧게 산정한 것이라면 당연히 협의를 해볼 만한 여지가 있겠지만, 당장 투자를 앞두고 있어서 서둘러 마켓 핏을 찾고 매출 그래프를 이쁘게 그려야 하는 등의 급박한 비즈니스 이슈가 있을 수도 있다면 이건 그렇게 좋은 판단은 아니라고 할 수 있다.

개발자가 아무리 나중을 생각하고 좋은 설계를 한다고 해도 당장 다음 달에 회사가 돈이 없어서 망한다면 결국은 사라지는 코드들이다. 결국 개발자가 회사라는 조직에 소속되어 프로그래밍을 하고 있는 이상 개발자가 생산한 산출물의 목숨줄도 결국 회사 통장의 잔고에 달려있다는 것이다.

그렇기 때문에 아무리 개발자가 프로그래밍을 주 업무로 삼는 직군이라고 해도 프로그래밍에 대해서만 생각하는 것이 아니라 항상 비즈니스적인 관점에서도 현재 만드는 기능을 바라보고, 경우에 따라서는 설계를 대충 하더라도 지금 당장 빠르게 제품을 개발해서 테스트해보고 마켓 핏을 찾아 유저의 해피 모먼트를 만들고 AMPU(Average Margin Per User)를 높이는 것에 집중하는 것이 더 효율적이라는 판단 또한 내릴 수 있어야 한다.

차라리 이런 상황이라면 어느 정도 설계를 뭉개고 빠르게 개발을 진행하되, 뭉개진 설계로 인해 발생할 수 있는 리스크를 최대한 예측하고 유저의 중요한 액션을 방해할 가능성이 있는 에러를 최대한 핸들링하거나, 혹여나 놓친 에러를 빠르게 대응할 수 있도록 Sentry나 Bugsnag 같은 에러 모니터링 솔루션을 도입하고 슬랙 같은 사내 메신저에 노티를 와장창 걸어놓는 것이 나을 수도 있다. (물론 버그 픽스는 몸으로 때워야 한다)

지워야 하는 기능을 만들 때도 있다

그리고 가끔은 지워야 하는 기능을 만들어야 하는 경우도 있을 수 있다. 이게 무슨 의미일까? 결국 새로운 기능이라는 것은 제품을 더 업그레이드해서 유저들에게 제공하기 위한 것인데, 지워야 하는 기능이라는 게 있을 수 있나?

있다. 바로 A/B 테스트를 해야 하는 상황이다.

A/B 테스트는 특정 실험군에 기존 UI/UX와 새로운 UI/UX를 함께 배포한 후
지표를 비교하고 이긴 쪽을 선택해서 남기는 개발 방법론이다. (출처: Optimizely)

예를 들어 현재 우리 서비스의 상품 결제 페이지 내의 결제 전환율이 10% 라고 생각해보자. 그래서 우리는 이 전환율을 끌어올리기 위해 결제 버튼을 더 크고 우람하게 만들고 눈에 더 잘 띄도록 #ff0000 라는 과감한 색도 추가했다. 물론 이 결정은 그냥 대충 정한 것이 아니라 PO와 UI/UX 디자이너의 인사이트와 그 외 팀원들의 엄청난 토론과 논쟁, 그리고 고민 끝에 내려진 결정이다.

자, 그러면 이제 치열한 고민 끝에 결제 버튼이 유저들의 눈에 더 잘 띄게 만들었으니 결제 전환율이 올라갈까? 정답은…

ㅇㅇ 아무도 모름

사실 어떤 기능을 만들고 유저들에게 공개했을 때 유저들이 어떻게 반응할지는 아무도 모른다. 유저는 페이지에 들어간 문구 하나만 변경되어도 갑자기 이탈해버리는 기상천외한 존재이기 때문이다. 그렇다고 아무거나 만들어서 일단 배포하자니 앞서 이야기했던 인건비나 서버비 등 금전적 리스크가 너무나도 크다.

그래서 많은 조직들은 이 리스크를 줄이는 방법으로 A/B 테스트를 선택하는 것이다. 결국 아무리 뛰어난 사람들이 모여서 하루 종일 논의를 하고 고민을 하더라도 결국은 “우리 유저는 이렇게 행동할 거야!”라고 예측하는 것에 불과하다. 즉, 제품을 배포해서 직접 유저가 사용하는 패턴을 관측하고 분석하기 전까지는 어떤 의견이든 결국 뇌피셜일 뿐이기 때문에 이런 테스트를 돌리는 것이다.

만약 테스트를 배포한 뒤 기존 화면인 Control에서 더 결제 전환율이 높다면 우리는 과감하게 새로 만든 Variant를 버리면 되고, 새로 만든 Variant가 더 전환율이 높다면 Control을 버리면 된다. 이로써 우리는 이번에 개선한 결제 버튼이 잘 작동하든 안 하든 간에 최소한의 리스크만 가져가면서 안전하게 전환율을 상승시킬 수 있다.

또한 효과적인 데이터 분석을 위해서는 변인을 최대한 통제해야 한다. 이것저것 다 바꾼 다음에 테스트를 돌려서 지표가 좋게 나왔다고 해도 우리가 바꾼 것들 중에서 정확히 무엇 때문에 유저가 이런 행동을 했는지 파악하기가 어렵다면 테스트 자체가 의미 없어지기 때문이다.

A/B 테스트를 적용할 때는 대부분의 기능은 똑같이 두고 확인하고자 하는 부분에만 집중해서 조금만 변경해보는 경우가 많다. 그렇다는 말은 A/B 테스트를 적용하기 위해 코딩을 하다 보면 Control과 Variant 간의 공통적인 로직이 많이 나올 수밖에 없다는 의미이다. 그래서 어떤 개발자들은 이 공통적인 부분을 추상화하여 효율적인 설계를 하기도 한다. 하지만 여기서 함정이 하나 있다.

(출처: Unsplash)

둘 중에 하나는 결국 지워야 한다.

사실 기존에 만들어 놓은 설계에 이 테스트를 녹이기 위해서 공통된 부분을 추상화하거나 반복되는 코드를 줄인다고 별도의 모듈로 와장창 분리한다거나 하면 오히려 테스트 기능을 지워야 할 때 신경 써야 하는 부분이 더 늘어나게 되고, 여기서 발생한 실수로 인해 오히려 예상하지 못한 버그를 만들어 버릴 수도 있다.

게다가 A/B 테스트를 하는 경우에는 정말 사소한 부분까지 동일한 경우가 많고 이런 부분들을 아무리 열심히 추상화해도 정작 테스트가 끝나고 나서 어느 한쪽을 지우고 나면 의미 없는 추상화로 남게 되는 경우도 있다. 그래서 A/B 테스트는 최대한 지우기 쉽게 만들어야 하는 것이다. 이 테스트를 위해 작성하는 코드는 계속 유지 보수해야 하는 대상이 아니라 결국 길어야 일주일 정도의 테스트가 끝나면 지워질 녀석들이다.

어차피 Git이 있으니까 마스터 브랜치에 머지했던 커밋을 그냥 리버트 하면 되지 않냐고 할 수도 있지만, 그건 기존 기능인 Control이 이겼을 때는 가능할지 몰라도, 이번에 새로 추가한 기능인 Variant가 이긴다면 리버트 또한 써먹지 못한다.

사실 이런 경우에는 추상화고 나발이고 그냥 같은 페이지를 똑같이 한 벌 복사해서 A/B 테스트 변수에 따라 /test-page/a나 /test-page/b로 랜딩 되도록 만들고, A/B 테스트 후 결과가 나오면 그냥 테스트에서 진 페이지 하나를 깔끔하게 날려버리는 것이 오히려 더 좋은 설계일 수도 있다는 것이다.

만약 이런 비즈니스 상황들을 고려하지 않고 프로그래밍만 바라보는 좁은 시야로 개발을 한다면 아무리 설계를 잘했다고 해도 오버 엔지니어링이라는 피드백만 받는 눈물 나는 상황이 발생할 수도 있다.

마치며

이번 글에서는 비즈니스와 어플리케이션 설계의 관계에 대한 이야기를 했는데, 사실 이런 내용들은 조금 경험이 많은 개발자들은 대부분 아는 내용일 것이라고 생각한다.

하지만 개발자로 일을 시작한 지 얼마 안 된 분들의 경우에는 넘치는 열정이 어플리케이션의 구조 개선이나 새롭고 효율적인 기술의 도입 같은 프로그래밍과 관련된 일에만 쏠리는 경우가 왕왕 있다. 사실 필자도 처음 개발자로 일을 시작했을 때 이런 비즈니스 적인 요소들을 전혀 고민하지 않고 레거시를 전부 리팩토링 해야 한다고 이야기했다가 조금 더 시야를 넓게 가지라는 피드백을 받기도 했었다. (부끄럽지만 당시에는 그분이 꼰대라고 생각했다…)

물론 필자도 개발자이기 때문에 변경에 열린 구조, 관심사가 명확한 모듈들, 사이드 이펙트가 없는 함수 같은 것들에 열광한다. 하지만 어찌 되었든 회사에 고용되어 수많은 이해관계자들과 내 제품을 사용하는 유저와 얽혀있는 몸이기 때문에, 현실적으로 이런 것들을 전혀 고려하지 않고 내가 하고 싶은 것들을 하기는 힘들다.

개발자가 좋은 설계와 기술 부채 청산을 중요하게 생각하는 만큼 디자이너는 UI/UX를 중요하게 생각하며 CEO는 경영을 중요하게 생각한다. 그리고 결정적으로 유저는 자신이 이 서비스를 사용하며 느끼는 경험들만 중요하게 생각한다. 이렇게 모두 다 각자 중요하게 생각하는 가치가 다르기 때문에 개발자로서 어플리케이션만 생각하는 좁은 시야를 가지면 안 된다는 것을 이 글을 통해 이야기하고 싶었다.

이상으로 <일 잘하는 개발자는 왜 비즈니스까지 신경 쓸까?> 글을 마친다.

<원문>

https://bit.ly/3xkh5dp