ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • (일기) 코드를 어떻게 잘 짜볼까?
    카테고리 없음 2023. 5. 26. 02:54

    회사라는 곳에서 개발을 대략 2016년부터 했으니까, 벌써 개발자로 7-8년은 일한 것 같다.

    처음 코딩을 배울때는 Visual Studio를 열어서 hello world 치는 것도 버벅였는데, 다뤄본 언어도 몇 개 되는 것 같고 프론트엔드니 백엔드니 회사에서 필요로 하는건 가리지 않고 해본 것 같다. 물론 아직 더 경험해야 할게 많지만...

    그런데 아직도 어떻게 하면 더 코드를 잘 짤까? 라던지, 어떤 코드가 좋은 코드일까? 같은 기본적인 질문을 해보곤 한다.

    물론 답은 구하지 못했고, 앞으로도 구할 수 있을지는 모르겠지만 적어도 아 이런걸 하면 좋구나 하는 것들을 쌓이는 것 같다.

    어떤게 있을까, 사람들에게 잘 짠 코드는 어떤거에요? 물어보면 엄청 다양한 답이 나올 것 같다. 그 사람의 개발 영역에 따라서도, 연차에 따라서도, 심지어는 소속된 회사에 따라서도 아마 생각하는게 다르지 않을까 싶기도하고..

    그나마 내가 지금까지 일하면서 느낀 이렇게 하면 더 좋겠다 싶은 것들은 다음과 같다.

     

    개발 영역에 대해 잘 공부하자
    코딩에 집중하다 보면 내가 무슨 개발을 하고 있는지 잊어버릴때가 종종 있다. 여기서 무슨 개발이란, 프론트엔드나 백엔드..가 아니라 내가 블록체인이라는 영역에서 개발을 하고 있는건지, 또는 금융 서비스를 만들고 있는건지와 같은 것들이 있을것이다.

    어떤 분들은 이걸 보고 당연한거 아냐..? 라고 생각하겠지만 이 간단한걸 생각 안하고 열심히 1년 넘는 기간을 삽질했던 기억이 있다. 내가 잘 모르는 분야, 심지어는 관심이 없는 영역에서 열심히 개발을 하고, 어느 순간 뒤돌아보니 남아있는것은 삽질을 하다 만 땅만 보이는 느낌이었다.

    그래서 그 때의 나로 돌아가거나, 또는 누군가가 어떤 회사에서 일을 하는게 좋을지 물어본다면 나는 자신있게 님이 좋아하는 분야를 다루는 회사에서 개발을 하라고 추천할 것 같다. 게임을 좋아하면 게임, 아니면 OPGG같은 곳도 좋을 거고, 옷을 좋아한다면 무신사 같은 곳도 좋을 것 같고.. 물론 취업이 쉬운건 아니지만^^

    이게 중요하다고 느낀 이유는 혼자 개발하는게 아니어서 그런 것 같다. 내가 개발하는 영역(영어로는 도메인이라고 하는 것 같더라)에 대한 관심이 없으면 장기적인 서비스 빌딩이 좀 어려운 것 같다.

     

    테스트하자
    나는 유닛 테스트를 굉장히 좋아한다. 

    나도 그렇고, 내가 만나본 많은 개발자 친구들은 서비스 초기에 굉장히 의욕적이다. New project를 클릭하고 npm init을 한다던지 할 때는 머리속으로 이미 구조도 많이 생각해두고, 아 이번엔 진짜 맛있는 코드 짜봐야지 하는 생각이 가득찬다.

    그렇게 개발 한 몇 주 하다보면 코드 양도 많아지고, 어 이거 그거 아닌데요? 아니면 이거 요구사항이 좀 바뀌어서.. 디자인이 바뀌어서.. 기능이 바뀌어서.. 등등 코드 수정도 많아지고, 그러면 어느샌가 다들 아...코드 맛없는데.. 이런 상황에 많이 직면하는 것 같다. 물론 저년차의 개발자들끼리 모여서 개발하면 이런 현상은 더 심해지는 것 같고, 삼성전자에 3년 정도 근무했었는데 거기서도 내내 리팩토링 해야된다고 외칠 정도로 코드 퀄리티를 만족시키는 건 쉽지 않은 것 같았다.(물론 삼성에 은둔 고수들 진짜 엄청 많다. 안드로이드 초창기부터 한우물만 파온 괴물 책임/수석님, 아키텍트 분들 존경합니다 아직도...)

    그렇게 비대해진 코드는 이런저런 오류들이 필연적으로 발생하게 되고, 안그래도 일 많아 죽겠는데 이슈까지 터지면 그 코드를 더 맛있게 짤 생각보다는 일단 어떻게든 해결하려고 애쓰게되는 것 같다. 그러면 코드는 또 맛이 없어지고 무한루프에 빠지면서 아 다음엔 이렇게 안해야지, 생각만 하다가 또 다음 프로젝트때 같은 일 반복ㅋ

    물론 이런 악순환을 극복할 마스터 피스를 찾은 건 아니다. 소프트웨어 공학 첫 시간에 No silver bullet이라는 명언을 배우지 않는가? 소프트웨어에서 어떤 문제든 드라마틱하게 해결해주는 마법의 도구는 존재하지 않는다고 생각한다. 마찬가지로 나는 절대적으로 좋은 코드 또한 찾기 어렵다고 생각한다. 왜냐하면, 사람마다 저마다의 기준이 다 다르기도 하고, 우리는 엔지니어지 과학자가 아니기 때문이다. 프로그램을 만들다보면 A를 희생하고 B를 챙기는 등의 일이 자주 발생하는데, 실력있는 개발자는 거기서 조금 더 합리적인 결정을 내릴 수 있는게 중요하다고 생각한다.

    그나마 내가 아 이런거 좀 하면 좋다고 생각한게 다양한 테스트 도구를 이용하는 것이다. 프로그램을 "잘" 만드려면 프로그램을 구성하는 구성요소들이 잘 분리되는게 중요하다고 생각한다. 요건 개인적으로 생각해본 내용인데,

    맞물려 돌아가는 톱니바퀴가 50개 정도 있다고 생각해보자. 중간에 한 톱니바퀴에 이가 빠지면, 그것과 이어진 톱니바퀴들이 제대로 돌아가지 않게 되고 결국 전체의 시스템이 잘 동작하지 않게 될 것이라고 생각했다. 프로그램은 결국 그 프로그램을 사용하는 사용자 입장에서 동작하는 것이 중요하기 때문에, 우리가 프로그램을 만들 때 중요한 것은 그 프로그램의 가용성이라고 생각한다. (물론 지금은... 앞으로 얼마든지 바뀔 수 있다고 생각함)

    그러니까 저 톱니바퀴의 예 처럼 중간에 한 구성요소가 망가진다고 전체 시스템이 망가지는 상황을 최대한 방지하는게 중요하다고 생각한다. 그 과정에서 코드가 이쁘거나, 숏코딩, 변수 이름 잘 짓기 등은 어느새 우선순위에서 많이 밀려났다. 물론 안 중요하다는 건 아니다. 코드를 짤 거면 이왕이면 가독성 좋게 잘 짜는것도 중요함.

    그러나 코드를 짜다보면 커플링이나 구성요소 간의 강한 결합(톱니바퀴처럼)은 어쩔 수 없이 발생하는 경우도 많기 때문에 예외 케이스를 꼼꼼히 살펴보고 정상적인 동작의 케이스들도 최대한 테스트해보는게 중요하다고 생각한다. 그것을 위한 도구가 유닛테스트.

    예전에 대기업에서 인공지능 비서 앱을 만들거나, 블록체인 회사에서 앱체인도 만들어보고 블록체인 웹서비스를 만들면서도 이런 테스트 도구들은 유용하게 사용하고 있다. 앱을 만들 때는 주로 사용자의 발화를 서버에서 처리해서 앱에서 띄워줄 데이터를 내려줬는데, 가짜 데이터를 만들어서 UI로 뿌려주기 전 데이터를 파싱한다던지, 서버에서 에러 응답을 내려 준다고 가정하고 예외 처리가 잘 되는지 테스트를 해봤었다. 그리고 좀 더 나가서 UI 테스트 케이스도 작성해서 젠킨스를 이용해서 원격으로 스마트폰에 터치 이벤트를 발생시키며 원하는 결과가 나오는지도 테스트했었다. (예전에 안드로이드 개발자 행사에서 발표도 했었는데, https://speakerdeck.com/boohyunsik/unit-testbuteo-ui-testggaji 칭찬도 받았었다ㅎㅎ 뿌듯)

    블록체인 관련 분야에서도 유닛테스트는 언제나 도움이 된다. 특히 블록체인은 데이터를 이상하게 뿌려주는(...) 경우가 많다고 생각하는데 인코딩 데이터도 많고 16진수로 뿌려주는 경우도 많아서 이런 경우에 체인을 직접 돌려보면서 테스트 하거나, 웹 서비스인 경우 로그찍어가면서 브라우져에서 불편하게 확인하며 개발하는 것 보다는 유닛테스트로 디코딩도 해보고 10진수 변화도 해보면서 개발하면 확실히 생산성이 는다.

    이런 테스트 도구들이 가용성에만 도움을 주는 것은 아니다. 클린 코드나 이펙티브 자바 같은 바이블들을 공부하다보면 함수는 최대한 가볍게(단일 책임 원칙), 하나의 역할만 해라.. 이런 얘기들을 많이 보게 되는데 사실 이거 지키는게 그렇게 쉽지 않다. 그런데 테스트를 잘 작성하면, 프로그램에 핵심적인 로직들을 가볍게 작성할 수 있게 되는 것 같다. 왜냐하면 유닛테스트는 프로젝트 빌드를 해서 실행하는게 아니라 그 함수 조각만 실행하기 때문에, 만약 함수가 여러 외부 변수나 전역 변수등에 의존하게 되면 테스트를 하기 굉장히 어려워지기 때문이다. 그래서 자연스럽게 함수가 커지는 걸 기피하게 된다(...)

    아직 TDD나 이런거 까지 다 겪어보진 않았지만, 테스트는 확실히 프로그램이 잘 동작하게 만드는데 도움이 된다.

     

    야밤에 오랜만에 블로그나 하나 써볼까 하다가 종종 혼자 생각해보던걸 써봤는데, 쓰고보니 테스트 예찬글 같네.. 그렇다고 뭐 이것도 마법의 도구라는건 아닙니다..^^ 그래도 개인적으로는 더 좋은 코드를 작성하는데 위 두 가지 사항이 도움이 많이 된다고 생각하여 써봤습니당. 어설픈 글이라도 읽어주신다면 감사드리고.. 비슷한 고민을 하시는 분들이 계시다면 댓글도 많이 남겨주세요ㅎㅎ

    댓글

Designed by Tistory.