<div id="readability-page-1" class="page"><div><p><h2 id="d0e3">유행 쫓지 않기.</h2></p><div><h2 id="389a">나만의 스타일 찾아가기</h2><div><a rel="noopener" href="/?source=post_page-----e9d965979e5e--------------------------------"><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/12000/1*KLtVvSUUSosdaw326F50lQ.jpeg" width="6000" height="4000" role="presentation"></p></div><figcaption>Photo by <a href="https://unsplash.com/@vasiliosm?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener nofollow">Vasilios Muselimis</a> on <a href="https://unsplash.com/s/photos/peace?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener nofollow">Unsplash</a></figcaption></figure><p id="a62a">우리 삶에서 유행이라는 건 언제나 존재하고 그 유행을 탈 지 말 지에 대해서는 개인이 고민해야 한다. 개발에서도 이 영역은 크게 다르지 않다, 개발하면서도 유행은 언제나 존재하고 그 유행을 따를 지 말 지는 스스로 판단해야 한다. 하지만 유행을 쫓는다는 게 무엇이고, 나만의 스타일을 찾아나선다는 게 무슨 이야기일까?</p><h2 id="6a38">소프트웨어 설계</h2><p id="5597">소프트웨어를 설계하는 데 반드시 정해진 답은 없다고 생각한다. 단발성 이벤트 페이지를 굉장히 공들여서 만들수도 있지만, 이미 정해진 템플릿을 가지고 구현할 수도 있고, 사이트 빌더를 만들어서 배포하는 방법도 존재한다.</p><p id="97a1">특정한 웹 애플리케이션을 개발할 때에도, 모든 <span id="rmm"><span id="rmm">최</span></span>적화 기법을 모든 페이지에 다 적용해야하지 않을 수도 있고, Single Page Application 으로 구현할 수도 있고, FLUX 패턴을 적용하지 않고 jQuery AJAX 로만 구현할 수도 있다.</p><p id="982b">우리가 정의하는 레거시가 ‘유행하는 기술을 사용하지 않는 것’ 처럼 되어가고 있다고 생각할 때가 종종 있는데, 내가 생각하는 레거시란 ‘더 이상 유지보수가 원활히 이루어지지 않는 곳’ 이라고 생각한다. 모두가 건드리기 싫어하는 코드가 곧 유지보수하기 어려운 코드라고 생각하기도 하고,</p><p id="f065">설계에 힘을 쓰는 건 중요하다. 어떤 서비스에서 어떤 설계가 적절할 지에 대해서 고민하는 건 분명 큰 의미가 있다. 서비스를 개발하면서 관습처럼 이어지는 여러 습관들을 조금씩 타파하고, 어떤 방식이 가장 좋은 방식일 지를 지속해서 고민하는 게 개발자로서 성장하는 데에 크게 도움이 된다.</p><p id="a498">한편 큰 그림을 볼 수도 있어야 하고, 동료들을 설득시킬 수도 있어야 한다.</p><h2 id="3591">적정 기술</h2><p id="f46e">어떤 기술은 지나치게 early stage라 사용이 어려운 경우도 있다. ealry stage 기술이 동작에 직접적으로 영향을 주는 경우라면 사용을 아예 꺼리겠지만, 내가 아직 제대로 습득하지 못하였는데 유행을 타고 있는 early stage 기술들은 사용하지 않기에는 마음에 걸리는 것들이 많다.</p><p id="992e">예를 들어, React Hooks 가 처음 나왔을 때를 생각해보자. 지금에야 대부분 Hooks를 사용하는 듯 보이지만 그 이전까지 우리는 Class 컴포넌트를 주력으로 사용해왔고, Hooks가 나오면서 Function 컴포넌트를 주력으로 사용하기 시작했다.</p><p id="41b4">여전히 많은 사람들이 Hooks가 어떻게 동작하는 지 명확하게 이해하고 있지 못한채로, Class 컴포넌트 시절부터 있던 관습을 그대로 따라가는 경우가 많다. Hook의 가장 큰 장점은 컴포넌트에서 가져야하는 상태 관리 로직을 Hook으로 추상화할 수 있다는 점이다.</p><p id="77b7">사족이 길었지만, 적정 기술이란 단어에도 여러 의미가 내포되어 있지만 적정 기술이라는 말은 <strong>‘지역 사회의 인프라 수준을 고려하여 만드는 기술 또는 그 생산물’</strong> 이라고 정의내린다.</p><p id="0e55">그러니 우리가 어떤 기술을 도입하거나 사용하고자 할 때에는, 몇가지 측면을 고려해야 한다.</p><ol><li id="3464">이 기술은 현재 안정적이며 우리 서비스에 도입하기에 문제가 없는가?</li><li id="4257">이 기술을 학습하는 데 러닝 커브는 높지 않은가?</li><li id="b366">현재 우리 조직의 기술 및 인력 구조 상 이 기술은 적합한가?</li><li id="ba9a">이 기술은 우리의 어떤 문제를 해결해주는가?</li><li id="12e5">이 기술을 사용하여 배포된 서비스가 존재하는가?</li><li id="ae5b">이 기술은 우리에게 어떤 이익을 주는가?</li><li id="7e7d">우리는 이 기술을 배울 준비가 되었는가?</li></ol><p id="7366">여러가지 고려사항을 바탕으로 그 기술을 도입하였을 때 비로소 우리가 생각했던 문제가 해결된다 생각한다. 애초에 문제가 아닌 걸 문제라고 바라봤을 수도 있고 말이다.</p><h2 id="466d">기술이 모든 문제를 해결하지 않는다.</h2><p id="f35e">기업에서 업무를 진행하면서 생기는 다양한 문제들은 기술 그 자체에서 발생하기보다 기술을 둘러싼 다양한 환경에서 발생하는 경우가 더 많다. 기술 그 자체에서 발생하는 경우도 있지만 대체로는 환경에서 발생하는 듯 보인다.</p><p id="9c2b">어떤 문제를 해결하려면 그 문제가 무엇이고, 어떻게 해결이 가능한 지를 먼저 고민해보아야 한다. ‘저 기술이 유행해보이는 데 한번 도입해볼까?’ 같은 식의 도입 흐름은 반드시 지양해야할 일이기도 하다.</p><p id="abc6">또한 자체적인 라이브러리나 프레임워크를 만들어서 운영할 수도 있으며, 그렇게 하게 되는 경우에는 채용은 조금 어려워지는 경향을 보이지만 대신 한 번 익숙해지고 나면 그 베이스를 그대로 유지할 수 있다는 장점도 있다. 서비스가 커지고 조직이 커질 때에는 조금 위험하다 생각한다.</p><h2 id="53b6">결론</h2><p id="b50b">어느 순간부터인 지 모르겠지만 굉장히 많은 개발 방법론이 다시 대두되고, 클린 코드를 바이블처럼 생각하게 되고 클린 아키텍처가 모든 문제를 해결해주는 듯 보이며 TDD를 하지 않으면 죄악이다 같은 느낌의 글들을 종종 보았다.</p><p id="6911">카테고리가 조금 다를 수는 있지만 분명히 장점이 있기 때문에 이런 기술들을 적극적으로 도입하려고 하는 것이다. 하지만 그 또한 제대로 알지 못한채로 도입하면 그저 해야하는 일이 하나 늘어나는 것 뿐이다. 혹은 이력서에 한 줄 정도 늘어나겠지.</p><p id="0f58">그래서 우리가 어떤 기술을 도입할 때에는 충분히 고려하고, 충분히 공부하고 난 뒤에 도입하는 게 적절하다고 생각했다. 그래서 이 글을 작성하게 되었다.</p></div></div>

Stories by 조은, Eun Cho on Medium

choeun

나만의 스타일 찾아가기
우리 삶에서 유행이라는 건 언제나 존재하고 그 유행을 탈 지 말 지에 대해서는 개인이 고민해야 한다. 개발에서도 이 영역은 크게 다르지 않다, 개발하면서도 유행은 언제나 존재하고 그 유행을 따를 지 말 지는 스스로 판단해야 한다. 하지만 유행을 쫓는다는 게 무엇이고, 나만의 스타일을 찾아나선다는 게 무슨 이야기일까?
소프트웨어 설계
소프트웨어를 설계하는 데 반드시 정해진 답은 없다고 생각한다. 단발성 이벤트 페이지를 굉장히 공들여서 만들수도 있지만, 이미 정해진 템플릿을 가지고 구현할 수도 있고, 사이트 빌더를 만들어서 배포하는 방법도 존재한다.
특정한 웹 애플리케이션을 개발할 때에도, 모든 최적화 기법을 모든 페이지에 다 적용해야하지 않을 수도 있고, Single Page Application 으로 구현할 수도 있고, FLUX 패턴을 적용하지 않고 jQuery AJAX 로만 구현할 수도 있다.
우리가 정의하는 레거시가 ‘유행하는 기술을 사용하지 않는 것’ 처럼 되어가고 있다고 생각할 때가 종종 있는데, 내가 생각하는 레거시란 ‘더 이상 유지보수가 원활히 이루어지지 않는 곳’ 이라고 생각한다. 모두가 건드리기 싫어하는 코드가 곧 유지보수하기 어려운 코드라고 생각하기도 하고,
설계에 힘을 쓰는 건 중요하다. 어떤 서비스에서 어떤 설계가 적절할 지에 대해서 고민하는 건 분명 큰 의미가 있다. 서비스를 개발하면서 관습처럼 이어지는 여러 습관들을 조금씩 타파하고, 어떤 방식이 가장 좋은 방식일 지를 지속해서 고민하는 게 개발자로서 성장하는 데에 크게 도움이 된다.
한편 큰 그림을 볼 수도 있어야 하고, 동료들을 설득시킬 수도 있어야 한다.
적정 기술
어떤 기술은 지나치게 early stage라 사용이 어려운 경우도 있다. ealry stage 기술이 동작에 직접적으로 영향을 주는 경우라면 사용을 아예 꺼리겠지만, 내가 아직 제대로 습득하지 못하였는데 유행을 타고 있는 early stage 기술들은 사용하지 않기에는 마음에 걸리는 것들이 많다.
예를 들어, React Hooks 가 처음 나왔을 때를 생각해보자. 지금에야 대부분 Hooks를 사용하는 듯 보이지만 그 이전까지 우리는 Class 컴포넌트를 주력으로 사용해왔고, Hooks가 나오면서 Function 컴포넌트를 주력으로 사용하기 시작했다.
여전히 많은 사람들이 Hooks가 어떻게 동작하는 지 명확하게 이해하고 있지 못한채로, Class 컴포넌트 시절부터 있던 관습을 그대로 따라가는 경우가 많다. Hook의 가장 큰 장점은 컴포넌트에서 가져야하는 상태 관리 로직을 Hook으로 추상화할 수 있다는 점이다.
사족이 길었지만, 적정 기술이란 단어에도 여러 의미가 내포되어 있지만 적정 기술이라는 말은 ‘지역 사회의 인프라 수준을 고려하여 만드는 기술 또는 그 생산물’ 이라고 정의내린다.
그러니 우리가 어떤 기술을 도입하거나 사용하고자 할 때에는, 몇가지 측면을 고려해야 한다.
이 기술은 현재 안정적이며 우리 서비스에 도입하기에 문제가 없는가?
이 기술을 학습하는 데 러닝 커브는 높지 않은가?
현재 우리 조직의 기술 및 인력 구조 상 이 기술은 적합한가?
이 기술은 우리의 어떤 문제를 해결해주는가?
이 기술을 사용하여 배포된 서비스가 존재하는가?
이 기술은 우리에게 어떤 이익을 주는가?
우리는 이 기술을 배울 준비가 되었는가?
여러가지 고려사항을 바탕으로 그 기술을 도입하였을 때 비로소 우리가 생각했던 문제가 해결된다 생각한다. 애초에 문제가 아닌 걸 문제라고 바라봤을 수도 있고 말이다.
기술이 모든 문제를 해결하지 않는다.
기업에서 업무를 진행하면서 생기는 다양한 문제들은 기술 그 자체에서 발생하기보다 기술을 둘러싼 다양한 환경에서 발생하는 경우가 더 많다. 기술 그 자체에서 발생하는 경우도 있지만 대체로는 환경에서 발생하는 듯 보인다.
어떤 문제를 해결하려면 그 문제가 무엇이고, 어떻게 해결이 가능한 지를 먼저 고민해보아야 한다. ‘저 기술이 유행해보이는 데 한번 도입해볼까?’ 같은 식의 도입 흐름은 반드시 지양해야할 일이기도 하다.
또한 자체적인 라이브러리나 프레임워크를 만들어서 운영할 수도 있으며, 그렇게 하게 되는 경우에는 채용은 조금 어려워지는 경향을 보이지만 대신 한 번 익숙해지고 나면 그 베이스를 그대로 유지할 수 있다는 장점도 있다. 서비스가 커지고 조직이 커질 때에는 조금 위험하다 생각한다.
결론
어느 순간부터인 지 모르겠지만 굉장히 많은 개발 방법론이 다시 대두되고, 클린 코드를 바이블처럼 생각하게 되고 클린 아키텍처가 모든 문제를 해결해주는 듯 보이며 TDD를 하지 않으면 죄악이다 같은 느낌의 글들을 종종 보았다.
카테고리가 조금 다를 수는 있지만 분명히 장점이 있기 때문에 이런 기술들을 적극적으로 도입하려고 하는 것이다. 하지만 그 또한 제대로 알지 못한채로 도입하면 그저 해야하는 일이 하나 늘어나는 것 뿐이다. 혹은 이력서에 한 줄 정도 늘어나겠지.
그래서 우리가 어떤 기술을 도입할 때에는 충분히 고려하고, 충분히 공부하고 난 뒤에 도입하는 게 적절하다고 생각했다. 그래서 이 글을 작성하게 되었다.

유행 쫓지 않기.

댓글