<div id="readability-page-1" class="page"><div>서비스 개발을 하다보면, 느끼는 것들이 참 많다. 물론 서비스 개발뿐 아니라, 모든 개발들이 다 그렇겠지만, 레거시들에서의 서비스 운영, 신규 플랫폼 환경에서의 서비스 운영 등 쉬운 상황들이 보통은 없다.
대다수, 레거시 코드들을 보다가 가끔 현타가 올때가 있다. 도대체 왜 이 스펙은 여기에 있는건지? 진짜로 동작해야 하는 스펙인건지?
예전에 없어져야 할 스펙인데 왜 제거가 되지 않았던 것인지..하는 수 많은 고민들과 스트레스들이 가끔씩 나에게 큰 불편감을 안겨주기도 했다. (생각해보면, 나도 누군가에게는 같을 수 있다는 것을 망각 했다.)
레거시 코드를 유지보수를 하면서 어려움은 새 코드를 예쁘게 넣는게 쉽지 않다는 어떤 괴리감이 늘 고달프게 하는 것 같다.
내가 본 건, 클린 코드, 리팩토링 등 다양한 가이드 서적들이 있는데, 막상 적용하기는 겁난다. 무엇을 바꾼다는게 오래 된 레거시는 굉장히 큰 두려움이 된다. (관리 된지 몇년 지난 코드들은 거의 버그가 스펙일 수 있기 때문이다.)
서비스 장애라는 것도 개발자에겐 늘 따라다니는 두려움의 존재이나, 나는 무의식적으로는 개발자가 장애를 두려워해서는 좋은 서비스가 나올 수 없다라는 생각을 한다.
장애는 어떤 지점에서든지 발생 할 수 있고, 늘 장애유발 포인트들은 존재한다. 그 포인트들에서 벗어나려면, 개발자가 취해야 할 행동은 무엇일까? 늘 고민하면서도 쉽게 두려움에서 벗어나기는 어렵다.
그렇게 내가 서비스 개발자로 일하면서 느낀 바는, 결국, 오늘의 코드는 내일의 레거시다.
레거시를 잘 운용하려면, 일단 코드를 클린하게 짜는 것보다 실제 사라진 스펙이 코드에 존재 하지 않도록 하는게 더 중요하다는 생각이다.
결론적으로 기술부채를 갚는 것도 중요하나 비즈니스 스펙 제거를 잘 하는게 더 중요하다.
이 부분을 소홀히 하면, 나중에 개발자가 뭘 지울 수 있는 건지 모른다. 그렇게 일 하면서 이러한 일들로 인하여 스트레스를 받으며 일하곤 했는데, 늘 관심 가지고 있던 개발자분의 트윗을 보고 생각이 바뀌게 되었다.
<a href="https://twitter.com/asbubam/status/1479074937654882310">https://twitter.com/asbubam/status/1479074937654882310</a>
<figure id="og_1641742576108" contenteditable="false" data-ke-type="opengraph" data-ke-align="alignCenter" data-og-type="article" data-og-title="asbubam on Twitter" data-og-description="“오래된 테라폼 코드를 정리하다 '그래. 이 코드도 사연이 있어 여기까지 왔겠지.' 하고 생각하니 마음이 조금 편안해졌다.”" data-og-host="twitter.com" data-og-source-url="https://twitter.com/asbubam/status/1479074937654882310" data-og-url="https://twitter.com/asbubam/status/1479074937654882310" data-og-image="https://scrap.kakaocdn.net/dn/blkLpl/hyM2W2KsRn/oQOYxwnc2EM8wCiVlpm5y1/img.jpg?width=400&amp;height=400&amp;face=176_86_249_165"><a href="https://twitter.com/asbubam/status/1479074937654882310" target="_blank" rel="noopener" data-source-url="https://twitter.com/asbubam/status/1479074937654882310">

<div>
asbubam on Twitter
“오래된 테라폼 코드를 정리하다 '그래. 이 코드도 사연이 있어 여기까지 왔겠지.' 하고 생각하니 마음이 조금 편안해졌다.”
twitter.com
</div>
</a><img src="https://scrap.kakaocdn.net/dn/blkLpl/hyM2W2KsRn/oQOYxwnc2EM8wCiVlpm5y1/img.jpg?width=400&amp;height=400&amp;face=176_86_249_165"></figure>
내가 집중 해야 할 관점은 “코드의 사연”이란 부분이지, 이게 왜 아직도 남아 있냐?에 대한것이 아니였구나.
결국, 마음을 편하게 하는데는 관점을 조금 다르게 하는 생각의 전환 훈련이 중요하다.
각자의 개발자들에서 오는 코드들에도 사연이 있고, 나한테 왔다면 응당 그 사연이 있는 코드를 올바르게 현시점에 맞춰서 바꿔 주는 작업이 중요하구나 생각하게 되었다.
그렇다면, 모든 문제가 쉽게 해결 되고, 마음도 가벼워진다는 것을 깨닫게 되었다. 그리고 코드도 더 깔끔해지고, 다음 사람이 오더라도 그 사람의 마음도 더 편해지겠구나.
</div></div>

Seungdols Company

seungdols

서비스 개발을 하다보면, 느끼는 것들이 참 많다. 물론 서비스 개발뿐 아니라, 모든 개발들이 다 그렇겠지만, 레거시들에서의 서비스 운영, 신규 플랫폼 환경에서의 서비스 운영 등 쉬운 상황들이 보통은 없다. 대다수, 레거시 코드들을 보다가 가끔 현타가 올때가 있다. 도대체 왜 이 스펙은 여기에 있는건지? 진짜로 동작해야 하는 스펙인건지? 예전에 없어져야 할 스펙인데 왜 제거가 되지 않았던 것인지..하는 수 많은 고민들과 스트레스들이 가끔씩 나에게 큰 ..

코드의 사연

댓글