코드의 당위성

코드의 당위성

 1. 당위성

 회사내 후배개발자들에게 코딩관련 조언을 할때 자주하는 쓰는 단어가 '당위성'이다.
 '당(當) : 당연하다. 마주하다. 해당의, ...'
 '위(爲) : 하다. 되다, 위하다.'
 '성(性) : 성품, 성질'
 '당위성'란 당연히 가저야할 성질이라고 말할 수 있다.

2. 왜? 유명한 라이브러리 코드랑 내 코드는 뭔가 다를까?

  프로그래밍에서도 당위성이 매우 중요하다는 사실은 OOP를 어느정도 이해하고 클래스와 클래스를 넘나들며 라이브러리 코드를 작성할 때 즘 감이 좀 오기 시작했다. 내가 반복작업하는 일들을 객체지향을 이용하니 수월하게 라이브러리화 할 수 있었고 그것을 반복 사용하여 프로그래밍을 하니 정말 효과가 탁월하였다.

 특히 SI 프로젝트 프리렌서를 하러 가면 대한민구의 대다수 선배개발자 PM이나 규모가 크면 PL은 코딩표준이라는 문서를 작성하여 프로젝트 문서에는 넣어두지만 코드를 어떻게 짜는 것에는 다들 관심이 없었다. 그래서 다른 개발자들은 그저 단위 화면에 자신의 코드를 일부를 수정하며 복붙하며 개발을 하였고, 나는 기능만 작동하면 되는지를 물은 후 해야되는 과업을 쭉 리뷰하고 반복적인 요소가 있는 경우는 라이브러리 소스를 만들어서 개발을 하였다. 정말 찍어내듯이 개발하는 조회프로그램 같은 경우에는 SQL에 문제만 없으면 하루에 10~20개를 찍어내는 것에도 문제가 없었다.

 그런데 나의 코드에는 문제가 있었다. 우리가 사용하는 언어의 기본 프레임워크의 라이브러리의 메서드나 변수명과는 사뭇다른 이름. 그리고 사용법도 복잡성이 있었다. 리펙토링을 해보면 클래스 소스들을 넘나들면서 이곳 저곳 수정하다 어쩔때는 멘붕이 온기도 하였다.

 내가 짠 코드와 유능한 사람이 개발한 코드가 뭐가 다를까? 여러가지가 있지만 내 코드는 난잡했다. 사용을 하기 위해서 자바라이브러리들이 취하는 형식을 취한 것이 아니라. 이걸 생성하고 시작한도 알려주고 변수로 어떤 값을 넘겨주면 처리가 된다든지...

 여튼 내가 만든 라이브러리를 사용하는 코드는 유능한 개발자들이 만든 라이브러리를 사용하는 코드랑은 다른 방식으로 사용을 해야되는 경우가 많았다. 내부로직에서도 이런 저런 사유들이 코드에 들어가고 범용적이지 않다보니 눈물없이 읽을 수 없는 라디오 사연처럼 구구절절 했다.

3. 스타크래프트에서 배우는 당위성

 스타크래프트 게임을 너무 좋아했다. 요즘은 잘하지 않고 유튜브를 보기만 하는데, 여러가지 유행에 따른 전략이 있지만 테란 플레이어와 저그 플레이어가 게임을 한다고 치자. 저그 플레이어가 공중유닛 뮤탈을 뽑을 것 같은 건물을 짓고 있다면 나는 본진에는 터렛으로 방어를 할지 마린에 벙커를 지어서 방어를 할지 선택을 해야된다. 이 시점에 내가 저그의 저글링을 대량 학살하기 좋은 파이어벳을 뽑는다면 공중유닛에 공격이 불가능 하기 때문에 이길 가능성이 떨어질 것이다.

 이런 원리는 바둑, 체스, 당구 등 내가 아는 대부분의 게임이나 운동등에서 적용 된다. 즉 상대의 포지션이 이렇게 나오면 내가 선택할 수 있는 것들이 게임 자체에 있는 모든 선택가능 수 만큼이 아니라 몇가지에서 제한 된다는 것이다. 왜나하면 이런 포지션에서는 몇가지에서 선택을 할 수 밖에 없는 당위성이 생기기 때문이다.

4. 프로그래밍에 있는 당위성

 개발도구를 열면 하얀 도화지와 같이 어떤 코드를 넣어도 문법에 문제가 발생하지 않으면 컴파일은 통과가 된다. 그리고 우리가 해결해야되는 문제점을 해결하기도 한다. 하지만 어떤 방식으로 문제를 해결한다고 해서 모두 문제를 잘 해결했다고 하지 않는다.

 특히 코드를 다시 읽어야되는 상황이 지속적으로 발생하기 때문에 코드의 구조가 이런 당위성에 기반하지 않고 그냥 냅다 후드려 갈겨 놓은 코드라면 다시 읽는데 상당히 문제가 발생한다. 메서드 이름을 GetXXX이라고 지어두고 그 안에서 예측되지 않는 결과를 리턴하고 예측되지 않는 처리를 하는 코드를 넣어두 문제가 발생했다고 치자. 여기저기를 뒤지다 뒤지다. 한치의 의심도 하지 않는 GetXXX 코드를 지나고나니 뭔가 예측되지 않는 상황이 발생한 것을 발견했다고 보자. 안을 들여다보니 반환행위 말고도 다른 행위를 하고 있는 코드가 버그의 원이였다면, 앞으로 GetXXX를 작성했는 사람의 코드를 믿을 수 있을까? 분명히 다음부터 버그가 발생하며 모든 소스코드를 뒤지며 돌아다녀야 하는 불신이 쌓이게 될 것이다.

 첫직장에서 고생한 경험 중에 사용자 화면에서 코드를 선택하고 나면 어디선가 예측되지 않는 처리가 이루어졌는데, 코드를찾기 위한 버튼클릭 이벤트 주변을 아무리 디버깅에서 찾아도 그 처리부분을 찾을 수 없었다. 그런데 현실에서는 계속 문제가 발생하고 있었다. 반나절을 찾았던 기억이 있다. 문제는 버튼의 Exit 이벤트에 이벤트가 그 처리부분이 걸려있었다. 당시 델파이 버튼 컴포넌트의 이벤트는 클릭 뿐만이 아니라 매우 많은 이벤트를 작성할 수 있었지만 어느누구도 클릭 이외의 이벤트에 비지니스로직을 걸꺼라고 생각하지 않았다.

 버튼에 많은 이벤트가 있지만 통상적으로 추정이 되지 않는 예측되지 않는 이벤트에는 로직을 작성하면 안되는 것이다. 이벤트가 있다고 다 작성을 해야되는 것이 아니라. 혼란을 불러올 가능성이 있는 행위를 하지 않고 예측이 가능한 당위성이 있는 곳에 코드를 작성해야 모두가 신뢰하며 개발을 할 수 있다.

 내가 작성하는 코드가 유능한 개발자가 작성한 코드보다 사용하기 어려운 방향으로 가고 있다면 아마 당위성이 문제일 확률이 높다. 당위성은 내가 창조하고 추구하고 연구할 필요가 없다. 우리가 흔히 보는 라이브러리들이 쓰는 메서드명이나 작동순서등을 따라서 개발을 하면 된다. 그러면 모두가 당연히 있을 것이라고 생각하는 성질에 나의 코드가 실행될 것이도 예측가능한 소프트웨어개 될 가능성이 높다.