업무가 너무 복잡해서 어디서부터 어떻게 개발해야 할지 모르겠어요.

필자가 전자 상거래 회사에 입사한지 얼마 되지 않았을 때 매일 같이 야근하던 개발자가 한 말이다. 업무가 복잡하다니 무슨 말인지 감이 잘 오는 독자도 있으리라. 필자 역시 아래 말을 듣기 전까지는 감이 오질 않았다.

오늘은 주문 24단계 중 10단계를 설명하겠습니다. - 어느 개발자가 업무 설명하기 전에 한 말

24단계 중에 10단계라니!!! 그리고 그는 복잡한 업무 규칙들을 설명하기 시작했다. 분명히 우리말인데 이해할 수 없는 외국어를 만난 느낌이었다. 주문서 화면에 사용 가능한 쿠폰을 보여 주는 작은 화면을 개발한 적이 있었는데 이 작은 화면을 개발하기 위해 업무 전문가에게 무려 1주일에 걸쳐 업무 설명을 들어야 했다. 사실 이런 개발의 대부분은 흔히 말하는 비즈니스 로직을 구현하는 것이다. 사용자에게는 작은 화면일 뿐이지만 그 뒤에서는 복잡한 업무 규칙(정책, 제약 등등)들이 연결된 수많은 단계가 존재한다. 화면은 빙산의 일각 일 뿐이다. 따라서 비지니스 로직을 구현하기 위해서는 업무의 대한 이해가 필수적이다.

소프트웨어의 본질은 해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다. 그 밖의 매우 중요하다 할 수 있는 기능도 모두 이러한 기본적인 목적을 뒷받침하는 데 불과하다. - 도메인 주도 설계

이미지 출처 : https://magazine-k.tistory.com/723

어떻게 하면 복잡한 업무를 빠르게 파악할 수 있을까?

가장 좋은 방법은 업무를 잘 아는 사람(업무 전문가)이 하나하나 설명해 주는 것일 테지만 만나기 어려울 뿐만 아니라 만나더라도 매우 바쁠 가능성이 농후하다. 또한 업무 설명을 들어도 막상 개발하기 어려운데 그 이유는 업무와 코드를 연결할 수 있어야 개발이 가능한데 복잡한 업무만큼이나 코드 역시 복잡하고 대부분 코드에 도메인이 잘 드러나 있지 않아 연결하기 쉽지 않다.

필자가 처음 복잡한 업무를 맡았을 때 옆에 업무 전문가가 있었지만 그 역시 매우 바빴다. 즉, 그가 나에게 사용할 시간이 적었다. 시간이라는 제한된 자원에서 복잡한 업무를 빠르게 파악하기 위해서는 효율적으로 질문할 필요가 있었다. 맥락 없는 모호한 질문에는 명확하고 정확하게 답변해 주기 어려운 법이다. 맥락을 먼저 파악한 후에 구체적으로 질문해야 원하는 것을 얻을 수 있다.

필자가 시도한 방법은 전체 코드 빠르게 훑어서 맥락을 파악하고 코드와 연결하여 구체적인 질문으로 복잡한 업무를 파악하는 것이었다. 왜 코드였을까? 업무는 코드로 구현된다. 즉 코드는 업무의 구현체이기 때문이다.

이 글은 필자가 사용한 코드 분석 방법을 기록한 것이다.

SQ3R(Survey, Question, Read, Recite, and Review)

새로운 프로젝트에 참여할 때였다. 프로젝트는 TypeScript/Angular를 사용하고 있었는데 당시에 필자는 둘 다 해본적이 없었다. 그렇다고 사정을 이해해 달라고 할 수는 없다. 당장 개발해야 했다. 빠르게 학습해야 했다.

가장 먼저 서점에서 TypeScript로 쓰인 Angular 책을 샀다. 그리고 책 전체를 대강 최대한 빠르게 읽었다.(예제 코드 역시 타이핑하지 않고 대강 읽었다) 책을 다 읽는 데는 1주일이 체 걸리지 않았고 TypeScript/Angular가 대강 무엇인지, 어떤 것을 할 수 있는지 감이 왔다. 그다음으로 바로 필요한 기능을 개발하기 시작했다. 중간중간 막이는 부분은 책 일부를 찾아서 자세히 보며 해결했다. 그 결과 매우 빠르게 개발에 필요한 지식만을 습득할 수 있었으며 일정에 무리 없이 개발할 수 있었다.

사실 이 방법은 SQ3R이라는 독서법을 응용한 것이다.

이미지 출처 : https://www.metodes.lv/en/methods-and-tools/active-reading-5-steps-strategy

1. Survey

맥락을 파악하는 단계로 구체적인 기능 개발이라는 목적의식을 가지고 책을 대강 빠르게 훑는다.

2. Question

구체적인 기능을 실제로 개발을 하면서 막히는 부분을 확인한다.

3. Read, Recite, Review

막이는 부분만 기술된 부분을 찾아 자세히 읽으며 해결한다.

프로그래밍 언어를 모두 알아야 코딩할 수 있는 것이 아니다. 일부만 사용한다. 그 이유는 바로 쓰임새에 있다. 앞서 언급한 ‘개발해야 하는 구체적인 기능’이 바로 쓰임새다. 세부적으로 모두 잘 알 필요는 없는 것이다. 쓰임새로 의도적으로 학습을 한다면 필요한 것만 빠르게 학습할 수 있다. 업무도 마찬가지이다. 모든 업무를 다 알아야 개발할 수 있는 것은 아니다.

코드 추상화와 하향식 분해

앞서 언급한 SQ3R을 응용하여 업무 코드를 분석해 보자.

복잡한 코드를 분석할 때 핵심은 코드의 세부사항에 빠지지 않고 윤곽(의도)을 파악하는 것이다. 전통적으로 객체 지향 프로그래밍에서는 복잡성을 다룰 때 추상화를 사용해 왔다.

추상화란 어떤 양상, 세부사항, 구조를 좀 더 명확하게 이해하기 위해서 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법이다. - 오브젝트 268 쪽

예전에 안영회 님으로부터 파워포인트를 사용한 코드 추상화 방법을 배운 적이 있다. 방법은 아래와 같다.

1. 유의미한 코드 블록을 캡처한다.
2. 새로운 슬라이드를 만들고 붙인다.
3. 슬라이드 위에 제목으로 순서와 코드 의도를 적는다. 의문점이 있다면 같이 적는다.
4. 1-3 번을 반복한다.

세세한 코드에 빠지지 않고 슬라이드 1장 단위로 계속 추상화해 나간다. 이 작업이 끝나면 슬라이드 제목만을 따서 마인드 맵으로 연결하면 전체적인 지도를 얻을 수 있다.

지금까지 SQ3R의 Survey를 한 것이다.

책은 기본적으로 구조화가 잘 되어 있기 때문에 색인 페이지만 보면 무엇을 다루고 있는지 그 위치가 어디인지 쉽게 알 수 있다. 하지만 코드는 그렇지 않다. 위의 작업은 책의 색인 페이지를 만드는 과정과 비슷하다고 볼 수 있다.

코드 세부사항을 ‘의도적으로 생략하거나 감춤’으로써 전체 윤곽을 파악한다. 이 과정에서 업무 흐름이 보이고 중복도 보이고 의문감도 생긴다. 결국 대강 감이 온다.

그다음으로 기능 개발이라는 쓰임새로 마인드 맵과 PPT를 번갈아 보면서 구체적인 질문을 한다. SQ3R의 3R(Read, Recite, Review)을 시도하는 것이다.

마치며

‘분할하고 정복하라’ 복잡성을 다룰 때 자주 마주치는 말이다. 하지만 때로는 어떻게 분할해야 할지 감이 오지 않을 때가 있다. 필자는 위와 같은 방법으로 다른 사람들 보다 상대적으로 빨리 복잡한 업무를 파악하고 개발할 수 있었다.