<div id="readability-page-1" class="page"><div><p><h2 id="48bd">개발자는 비즈니스를 알아야 할까?</h2></p><div><h2 id="4164">개발만 잘하면 되는 거 아닌가요?</h2><div><a rel="noopener" href="/?source=post_page-----6380436b0de9--------------------------------"><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/8048/1*Ba-HZ_4ZXOEu1ycITlMgpA.jpeg" width="4024" height="5030" role="presentation"></p></div><figcaption>Photo by <a href="https://unsplash.com/@surface?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener nofollow">Surface</a> on <a href="https://unsplash.com/s/photos/business?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener nofollow">Unsplash</a></figcaption></figure><p id="78b8">언젠가 Product Manager 로 일을 하게 된 경험이 있었는데 그 때 처음으로 하나의 조직이 동작하기 위해서는 얼마나 많은 일이 수행되어야하는가를 알게 되었다. 조직이 유지되는 것 만으로도 회사에서 많은 리소스를 투자하고 있다라는 걸 알았기도 하고, 그를 위해서 얼마나 많은 비용을 사용해야하는가에 대해서도 새삼 느꼈었다.</p><p id="683e">개발자로서 좋은 제품을 만든다는 데에도 여러 철학이 녹아진다. 초창기 제품을 만들 때에는 탄탄함보다는 속도를 우선하는 경우도 존재하지만, 언젠가 이후에 생길 문제를 미리 대비해서 탄탄함을 우선하는 경우도 존재한다. 가장 좋은 건 빠르게 탄탄히 만드는 거지만 그건 사실상 성배에 가깝다.</p><p id="5287">그러니 개발자가 비즈니스를 알아야한<span id="rmm"><span id="rmm">다</span></span>는 건, 당신이 어느정도 레벨업하기 위해서 필요하다에 가깝다고 생각한다. 완전한 주니어 때부터 비즈니스를 알아야할 필요는 없지만, 비즈니스를 아는 개발자와 모르는 개발자는 완전히 다르다. 그렇기 때문에 비즈니스를 알아야한다에 가깝다.</p><h2 id="215f">적정 기술</h2><p id="dd97">모든 제품에 무조건 맞는 테크 스택이란 존재하지 않는다. 어떤 제품을 만드느냐에 따라서 테크 스택도 바뀔 수 있어야 하고, 가장 적절한 형태의 기술을 고를 수 있어야 한다. 문제는 개발자가 어떤 테크 스택을 고르더라도 결국 산출물이 나오기는 한다는 점이다.</p><p id="eb8c">React로 개발을 하던, Angular로 개발을 하던, Vanilla JS로 개발을 하던 산출물은 분명히 나온다. 그 속도가 다르거나, 의도했던 대로 동작하지 않거나 하는 경우가 생길 뿐이다. 그렇기 때문에 레퍼런스를 많이 찾아보는 것이라 생각한다. 그러니 우리 제품이 추구하는 방향에 따라서 우리가 선택 가능한 가장 적절한 기술을 지속하여 고민하고 찾아야 한다.</p><p id="42dc">예를 들어, 몸 담았던 조직에서는 Editor를 개발하였는데 React에서 contenteditable 속성을 사용하면 re-render가 제대로 안되는 이슈가 발생했다. 이런 경우에, Notion 같은 블록형 에디터를 만들면 해결이 가능한 영역이었지만 우리가 생각하는 에디터는 블록형 에디터가 아니었다.</p><p id="a4e9">그랬을 때에 우리가 결정할 수 있는 사항은 라이브러리 없이 개발하는 것도 존재하고, jQuery 같은 도구를 사용하는 방법도 존재하고, 이미 구현된 기술을 가져다가 쓰는 방법도 존재한다. 그러니 어떤 경우라도 항상 존재하는 정답이 있는 것이 아닌 것이다.</p><p id="8eec">조직에서 기술을 선택할 때에는 언제나 비즈니스가 우선되어야 한다. 적정한 제품 출시 시점이 언제인 지, 우리가 사용할 수 있는 자산은 어느정도인 지가 명확해졌을 때 비로소 기술을 선택할 수 있게 된다.</p><h2 id="1196">무엇이 시장에 큰 영향을 줄 수 있을까?</h2><p id="f002">비즈니스를 알아야하는 또 다른 이유는 우리가 만드는 제품이 시장에 영향을 줄 수 있을 지에 대해서 판가름 할 때에 개발자의 기술 역량이 무엇보다 중요해지는 경우가 많기 때문이다.</p><p id="16e0">비즈니스에서 원하는 요구사항 중 내 개발 실력이 부족해서 구현이 어려운 것도 있을 것이고, 반대로 비즈니스에서 별도로 요구하지는 않았지만 내가 생각하기에 제품에 들어가면 우리 고객들이 좋아할 거 같은 기능이 있을 수도 있다.</p><p id="8eb4">새로운 기능을 구현하기 위해서 들어가는 시간이 상당히 길 때, 리팩토링을 고려해볼 수도 있고 그럴 때에 비즈니스를 설득시키는 과정 또한 필요하다. 새로운 기능을 구현하면서 리팩토링을 동시에 하는 행위는 어렵다라는 걸 설득시킬 수 있어야 한다.</p><p id="c352">우리는 정확히 모르는 미래에 대해서 지속해서 고민하고 연구하여 가장 적절한 솔루션을 찾아내야하는 직업이다. 그러니 우리가 고려해야 하는 건, 개발을 잘하는 것도 중요하지만 그 이상으로 우리 제품이 어느 선에 있어야 가장 잘 될 것인가에 대해서도 지속하여 고민하는 것이다.</p><p id="8b08">그럴 때에 비로소 조직원으로서 제품을 이끌어나갈 수 있다고 생각한다.</p><h2 id="84ea">비즈니스의 노예가 되어서는 안된다</h2><p id="dc86">돈을 버는 행위도 당연히 중요하지만 돈을 벌기 위한 수단에만 집중하는 것도 옳다고는 생각하지 못한다. 제품에는 지속해서 새로운 임팩트가 주어져야하고, 그 게 수익으로 이어진다면 가장 좋겠지만 예상치 못한 순간에 수익으로 이어지는 경우도 존재한다.</p><p id="e87d">제품팀에서 생각하는 개선 방향과, 비즈니스에서 생각하는 개선 방향이 다를 수도 있다. 그럴 때에는 언제나 서로가 서로의 방향성에 대해서 토론하고 논의하여 가장 적절한 방향을 찾을 수 있게 하는 것이 중요하다 생각한다.</p><p id="bc7e">예를 들어 이미지 삽입이라는 기능을 구현해야한다고 했을 때, 비즈니스와 제품 둘 다 해당 기능이 중요하다고 인지할 수 있다. 그러나 예를 들어 에디터를 구현해야한다고 했을 때에는 비즈니스와 제품의 인식 상태가 조금은 다를 수도 있다. 에디터는 들어가는 리소스에 대비했을 때 산출물이 상대적으로 적게 나오는 편이고, 대체재도 많기 때문이다. 하지만 제품에서는 에디터를 자체적으로 구현하는 게 더 의미있다고 판단할 수도 있다.</p><p id="95b4">그러니 이런 방향을 지속해서 고민하되, 결코 비즈니스가 정하는 것만이 정답이 되어서는 안된다고 생각한다.</p><h2 id="13d1">더 나은 제품을 위해</h2><p id="0776">우리가 이런 고민을 해나가는 모든 이유는 결국 더 나은 제품을 만들고 그로 인해 더 나은 가치를 창출하기 위해서다. 더 많이 커뮤니케이션 하고, 서로가 생각하는 좋은 제품에 대해서 지속해서 고민하고 같이 만들어나갈 수 있을 때에 비로소 좋은 제품이 나온다 생각한다.</p></div></div>

Stories by 조은, Eun Cho on Medium

choeun

개발만 잘하면 되는 거 아닌가요?
언젠가 Product Manager 로 일을 하게 된 경험이 있었는데 그 때 처음으로 하나의 조직이 동작하기 위해서는 얼마나 많은 일이 수행되어야하는가를 알게 되었다. 조직이 유지되는 것 만으로도 회사에서 많은 리소스를 투자하고 있다라는 걸 알았기도 하고, 그를 위해서 얼마나 많은 비용을 사용해야하는가에 대해서도 새삼 느꼈었다.
개발자로서 좋은 제품을 만든다는 데에도 여러 철학이 녹아진다. 초창기 제품을 만들 때에는 탄탄함보다는 속도를 우선하는 경우도 존재하지만, 언젠가 이후에 생길 문제를 미리 대비해서 탄탄함을 우선하는 경우도 존재한다. 가장 좋은 건 빠르게 탄탄히 만드는 거지만 그건 사실상 성배에 가깝다.
그러니 개발자가 비즈니스를 알아야한다는 건, 당신이 어느정도 레벨업하기 위해서 필요하다에 가깝다고 생각한다. 완전한 주니어 때부터 비즈니스를 알아야할 필요는 없지만, 비즈니스를 아는 개발자와 모르는 개발자는 완전히 다르다. 그렇기 때문에 비즈니스를 알아야한다에 가깝다.
적정 기술
모든 제품에 무조건 맞는 테크 스택이란 존재하지 않는다. 어떤 제품을 만드느냐에 따라서 테크 스택도 바뀔 수 있어야 하고, 가장 적절한 형태의 기술을 고를 수 있어야 한다. 문제는 개발자가 어떤 테크 스택을 고르더라도 결국 산출물이 나오기는 한다는 점이다.
React로 개발을 하던, Angular로 개발을 하던, Vanilla JS로 개발을 하던 산출물은 분명히 나온다. 그 속도가 다르거나, 의도했던 대로 동작하지 않거나 하는 경우가 생길 뿐이다. 그렇기 때문에 레퍼런스를 많이 찾아보는 것이라 생각한다. 그러니 우리 제품이 추구하는 방향에 따라서 우리가 선택 가능한 가장 적절한 기술을 지속하여 고민하고 찾아야 한다.
예를 들어, 몸 담았던 조직에서는 Editor를 개발하였는데 React에서 contenteditable 속성을 사용하면 re-render가 제대로 안되는 이슈가 발생했다. 이런 경우에, Notion 같은 블록형 에디터를 만들면 해결이 가능한 영역이었지만 우리가 생각하는 에디터는 블록형 에디터가 아니었다.
그랬을 때에 우리가 결정할 수 있는 사항은 라이브러리 없이 개발하는 것도 존재하고, jQuery 같은 도구를 사용하는 방법도 존재하고, 이미 구현된 기술을 가져다가 쓰는 방법도 존재한다. 그러니 어떤 경우라도 항상 존재하는 정답이 있는 것이 아닌 것이다.
조직에서 기술을 선택할 때에는 언제나 비즈니스가 우선되어야 한다. 적정한 제품 출시 시점이 언제인 지, 우리가 사용할 수 있는 자산은 어느정도인 지가 명확해졌을 때 비로소 기술을 선택할 수 있게 된다.
무엇이 시장에 큰 영향을 줄 수 있을까?
비즈니스를 알아야하는 또 다른 이유는 우리가 만드는 제품이 시장에 영향을 줄 수 있을 지에 대해서 판가름 할 때에 개발자의 기술 역량이 무엇보다 중요해지는 경우가 많기 때문이다.
비즈니스에서 원하는 요구사항 중 내 개발 실력이 부족해서 구현이 어려운 것도 있을 것이고, 반대로 비즈니스에서 별도로 요구하지는 않았지만 내가 생각하기에 제품에 들어가면 우리 고객들이 좋아할 거 같은 기능이 있을 수도 있다.
새로운 기능을 구현하기 위해서 들어가는 시간이 상당히 길 때, 리팩토링을 고려해볼 수도 있고 그럴 때에 비즈니스를 설득시키는 과정 또한 필요하다. 새로운 기능을 구현하면서 리팩토링을 동시에 하는 행위는 어렵다라는 걸 설득시킬 수 있어야 한다.
우리는 정확히 모르는 미래에 대해서 지속해서 고민하고 연구하여 가장 적절한 솔루션을 찾아내야하는 직업이다. 그러니 우리가 고려해야 하는 건, 개발을 잘하는 것도 중요하지만 그 이상으로 우리 제품이 어느 선에 있어야 가장 잘 될 것인가에 대해서도 지속하여 고민하는 것이다.
그럴 때에 비로소 조직원으로서 제품을 이끌어나갈 수 있다고 생각한다.
비즈니스의 노예가 되어서는 안된다
돈을 버는 행위도 당연히 중요하지만 돈을 벌기 위한 수단에만 집중하는 것도 옳다고는 생각하지 못한다. 제품에는 지속해서 새로운 임팩트가 주어져야하고, 그 게 수익으로 이어진다면 가장 좋겠지만 예상치 못한 순간에 수익으로 이어지는 경우도 존재한다.
제품팀에서 생각하는 개선 방향과, 비즈니스에서 생각하는 개선 방향이 다를 수도 있다. 그럴 때에는 언제나 서로가 서로의 방향성에 대해서 토론하고 논의하여 가장 적절한 방향을 찾을 수 있게 하는 것이 중요하다 생각한다.
예를 들어 이미지 삽입이라는 기능을 구현해야한다고 했을 때, 비즈니스와 제품 둘 다 해당 기능이 중요하다고 인지할 수 있다. 그러나 예를 들어 에디터를 구현해야한다고 했을 때에는 비즈니스와 제품의 인식 상태가 조금은 다를 수도 있다. 에디터는 들어가는 리소스에 대비했을 때 산출물이 상대적으로 적게 나오는 편이고, 대체재도 많기 때문이다. 하지만 제품에서는 에디터를 자체적으로 구현하는 게 더 의미있다고 판단할 수도 있다.
그러니 이런 방향을 지속해서 고민하되, 결코 비즈니스가 정하는 것만이 정답이 되어서는 안된다고 생각한다.
더 나은 제품을 위해
우리가 이런 고민을 해나가는 모든 이유는 결국 더 나은 제품을 만들고 그로 인해 더 나은 가치를 창출하기 위해서다. 더 많이 커뮤니케이션 하고, 서로가 생각하는 좋은 제품에 대해서 지속해서 고민하고 같이 만들어나갈 수 있을 때에 비로소 좋은 제품이 나온다 생각한다.

개발자는 비즈니스를 알아야 할까?

댓글