뻔뻔한블로그

Topic 3 소프트웨어 엔트로피

소프트웨어의 무질서도가 증가할 때 우리는 이를 '소프트웨어의 부패'라고 한다. 

이를 보다 그 정적인 표현인 '기술 부채'라고 부르기도 한다. 은연중에 언제 가는 갚을 수 있다는 뉘앙스를 풍기면서 말이다. 하지만 아마 갚지는 않을 것이다.  미래에 시간을 당겨다 쓰는 느낌이랄까..? 

여기서 말하기를 소프트웨어가 부패하는 데에는  많은 요소가 관여되는데 가장 중요한 것은 프로젝트에서 발생하는 심리학적 혹은 문화적 요소라고 한다. 이 심리는 이미 쓰레기가 넘치는 코드에 내 쓰레기 하나 더 버리는 건 괜찮다는 생각을 갖기 쉽다는 내용이다. 결국 이런 부정적인 생각은 팀원들에게 퍼져 악순환이 된다.

말하기를 깨진 창문을 내버려 두지마라

나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라, 적절히 고칠 시간이 없다면 일단 판자로 덮는 것만이라도 하라. 더 이상 손상을 예방하기 위해 "아직 구현되지 않았음"이라는 메시지라도 표현하자. 그 조치로 관리되고 있다는 것을 알리자. 

공감이 많이 됐다. 쉽고 빠르게 구현하기 위해 작성했던 코드들이 나중에 유지보수가 불가능한 코드가 되어 개선 작업이 힘들었던 경험. 이미 깔끔하지 않은 코드 위에 깔끔하지 않은 코드 한 줄 추가하기에는 쉽지만, 누가 봐도 잘 정돈된 코드 위에는 조금 더 신경 써서 코드를 작성하려 했던 경험.

우선, 망가트리지 말자

문제를 해결하기 위해 부가적인 피해를 일으키지 마라. 깨진 창문은 하나라도 충분하다.

정확한 확신 없이는 오히려 건들지 말자.

당장 부패한 코드를 작성하지 말자. 미래에도 바꾸지 않는다.

나는 첫 번째 회사에서 2년 정도 경력을 쌓고 현재 직장인 이곳으로 이직을 했다. 좋은 프로젝트를 개발부터 출시까지 했다. 지금도 많은 것들을 경험하면서 배우고 있다. 내가 이 책을 처음 읽게 된 계기는 당시 팀장님과 첫 면담에 이런저런 얘기를 주고받았고, 짧은 시간이었지만 정말 배울 점이 많다고 생각했다. 그리고, 서점에서 이 책을 사주셨다. 사실 나는 프로그래밍이란 책은 언어문법이나 패턴정도의 책들만 몇 권 봤었지, 이런 종류의 책은 처음이었다.

이 책을 처음 읽을때는 이해하지 못하는 부분이 많아, 그냥 가볍게 읽었었다. 그 당시에 내년에 다시 한번 읽어봐야겠다'라는 생각을 했고, 올해 이 책을 다시 읽기 시작했다.  확실히 작년에 읽었을때 느끼지 못했던 것들이 있었다. 물론 지금도 저자가 예시를 드는 내용이며, 용어며.. 생소하고 이해하지 못하는 게 많다. (그럼 1년, 2년 후에는 점차 이해하는 부분들이 많지 않을까?) 이번에는 책의 내용들을 체득화하기 위해 내용을 정리하고, 내 생각들을 포스팅을 해보고 싶었다.

Topic 1 당신의 인생이다.

당신의 인생이다. 당신의, 당신이 사는, 당신이 만드는 인생이 있다. 

첫 번째 주제부터 확 와닿았다. 이 책에서 말하는 '불만 많은 개발자'를 얘기가 나는데. 공감이 됐다. 대학교를 다닐 때나, 학원에 다니며 공부하고 있을 때 불만이 많은 친구들이 꼭 있었다... 책에서 말하기를 이런 사람들은 변화를 귀찮아 피하고, 내가 발전하지 못하는 이유를 회사가 교육을 시켜주지 않는다고 투덜댄다고 한다. 내가 느끼기에도 이런 사람들은 무슨 어떠한 상황이 주어져도 불만을 갖으며, 그 이유를 동료 탓, 회사 탓으로 핑계를 댄다. 원하는 게 있으면 요구를 하고 내가 바꿀 수 없는 상황이라면 차라리 회사를 옮기는 것이 맞다.(근데 아마 이것도 귀찮아할 것이다.)

이 시점(현재 경력)에서 이런 글을 작성하는데 시간을 쓰는 것보다, 자료구조 공부 또는 알고리즘 문제를 한 문제 더 푸는 것이 더 좋다고 생각도 했지만 하지만 이렇게 나의 생각을 한 번쯤은 정리해보고 싶은 생각이 들었다. 

좋은 코드를 작성하는 방법은 무엇일까?

좋은 코드란? 좋은 코드는 빠르게 읽히고 유지보수가 쉬우며 수정사항이 있을 때 몇 개의 함수 호출로 원하는 기능을 수정/추가가 가능한 코드일 것이다.

하지만 기업에서 많은 사람들의 협업을 통해 업무가 진행되는 프로그램에서 이런 코드는 현실적으로는 힘들어 보인다.

버그를 수정할 때는 현재 수정하려는 부분에서 코드들의 한 줄 한 줄 의미를 파악해야 하며 수정했을 때 발생할 사이드 이펙트에 관해서도 꼼꼼히 살펴야 한다. 이 코드는 그럴 것이다~ 또는 누군가가 작성한 함수의 이름만 믿고 그런 기능을 하는 함수겠지 하는 생각으로 대충 리딩하고 버그를 수정하다 보면 나중에 크게 데일수 있다.. 그렇기 때문에 우리는 좋은 코드를 작성하려고 노력해야 한다.

이런 좋은 코드들이 나중에 프로그램이 실제로 서비스됐을 때 버그 수정에서도 빠르게 수정이 됐었고, 그 좋은 코 드위에서 작업을 할 때도 그렇지 않은 코드보다 훨씬 시간이 감축됐다. (어느 위치에, 어느 함수에 있어야 할 기능이 딱딱 있었다.)

좋은 코드를 작성하는 방법은 주어진 상황에 맞는 판단하여 작성하는 코드가 아닐까 한다. 

서비스하려는 프로그램을 만들다 보면 당연히 현재 코드가 실제 서비스됐을 때 새로운 기능은 쉽게 수정/추가/제거가 가능한지, 발생 가능한 이슈들을 예상하며 만들게 된다. 이러한 코드 작성은 당연히 시간이 많이 소요된다.

근데, 이 상황에서도 우리가 지향하는 좋은코드로 작성하는 게 맞을까?

예를 들어, 나에게 업무가 할당됐다. 그 업무는 이틀 안에 3가지 프로토타입을 발표하고 그중에서 선택받은 프로그램으로 본격적인 개발을 하기로 했다. 

그런데 미래 확작성을 고려한 베이스 코드부터 여러 기능을 미리 만들어 놓고 유지보수도 생각하면서 개발하다 설계과정에서부터 많은 시간이 소요돼 기한 내에 업무를 처리하지 못할 수 있다. 정작 결국에 사용하지 않을 코드나 기능을 만드는데 시간을 쓴 것이다. 그렇다면 코드로만 봤을 때 좋은 코드일 수는 있어도 좋은 코드 작성방법에서는 맞지 않는다고 생각한다. 

당연히 프로토타입을 만드는 과정에서도 수정사항과 여러 이슈가 발생할 수 있다.

말하고 싶은것은 작성하려는 상황에서 개발 속도와 그 상황에 어느 정도 예상되는 유지보수성까지만 살려 적절하게 작성하는 것이다.

시간이 돈으로 연관되는 이런 상황에서 이 두 개의 중점을 잡기는 힘들다. 업무를 하면서 이런 판단을 해야 할 일들이 많았고 또, 그 판단 결과가 만족스럽지 않은 적이 많았다. 이런 판단을 하려고 노력하다 보면 이 경험들이 점차 좋은 판단력을 얻어지지 않을까 생각한다.