다시 한번 인프콘 2024 - 세션 후기 1 : 지속 성장 가능한 설계를 만들어 가는 법

작년에는 인프콘을 듣고나서 꽤 나중에 블로그 글을 작성했지만 이번에는 잊기 전에 올해 인프콘 후기 글을 작성해보려고 합니다.

올해 들은 첫번째 세션이자 가장 좋았던 세션인 지속 성장 가능한 설계를 만들어 가는 법 세션을 정리해보려고 합니다.

발표는 15년차 개발자이신 토스 페이먼츠 김재민님께서 해주셨습니다.

(사실 연차를 듣고 나서 부터 기대가 됐습니다.)

설계를 잘 하는법

설계를 잘하는 방법을 가장 먼저 요약을 해주셨는데

바로 설계를 하지 않는 것 이라고합니다.

 

그래서 세션에서는 설계에 대한 얘기보다는 구현을 강조하셨습니다.

그리고 구현을 잘 하기 위해서 개념과 격벽이라는 메인 키워드를 이해할 필요가 있습니다.

 

개념과 격벽

개념이란 특정 시스템이나 소프트웨어의 기능, 역할 또는 객체를 이해하기 위한 기본적인 아이디어나 추상화라고 정의할 수 있을것 같습니다. (따로 구체적인 정의는 없었으나 제가 이렇게 정의를 해봤습니다.)

예컨데 웹툰이라는 키워드를 들으면 아래와 같은 개념들이 생각날 수 있죠.

Figure 1. 웹툰 키워드를 듣고 생각나는 개념들

PD, 작가, 랭킹, 연재, 작품, 추천, 찜, 리뷰, 구매 결제, 포인트, 소장, 만료등이 있을 수 있죠.

그런 개념들 중 일부를 그룹화 (파란색 상자) 할 수 있고, 개념이 교집합 (초록색 상자) 으로 묶일수도 있으며 , 개념 그룹(빨간색 상자)으로 묶을수도 있습니다.

 

그런 개념들을 정리하기 위해서 격벽을 세울 수 있다고 합니다.

아래와 같이 격벽을 세워 볼 수 있겠습니다.

Figure 2. 웹툰에 대해 정의한 개념들에 격벽을 세웠습니다.

위와 같은 격벽들을 세웠음에도 불구하고 개념과 흐름을 강조하지는 못하는것 같습니다.

 

개념도 방화벽과 같은 격벽을 세우고 통제 해야한다고 합니다.

Figure 3. 개념에 격벽을 세우고 흐름을 통제했습니다.

이렇게 보다보니 의문이 듭니다.

이렇게 하는게 설계인거 아닌가?

하지만 구현을 할때 개념과 격벽을 세운 것일 뿐 설계와는 다르다고합니다.

(저도 이 부분은 정확하게 이해하지는 못했습니다.)

 

그래서 개념에 격벽을 잘 세우고 흐름을 통제하면 특정 위치에 대해서 수정을 하면 그와 관련된 코드만 수정되어야합니다.

하지만, 그러지 못한 경우 아래와 같이 하나의 변경에 의해서 많은 코드들이 변경이 생기게 되죠.

아래의 예시는 웹툰의 포인트 코드를 수정한 경우에 격벽을 잘못 세워 다른 코드에 변경점이 많이 생긴 경우를 보여줍니다.

(위의 격벽대로라면 포인트 변경점에 의해서 구매쪽만 변경이 생겼어야 할 것 같습니다.)

Figure 4. 웹툰의 Point 코드를 수정했으나 많은 변경점이 생겨버린 모습

 

그래서 개념과 격벽을 조금 더 잘 이해 해 보고자 토스페이먼츠의 실제 사례를 설명해주셨습니다.

 

개념과 격벽 활용의 실제사례

대출로 보는 개념과 격벽 활용

그림에서 네모 상자를 개념, 마름모를 행위로 정의했습니다.

Figure 5. 대출의 개념에서 3개의 행위를 도출했습니다.

대출의 개념에서 신청/실행/상환의 행위를 도출 할 수 있을것같습니다.

그러면 아래와 같은 코드처럼 작성을 할 수 있겠죠.

대출의 예시로 만들어본 코드

 

이 상황에서 대출에 대해서 코드의 변경점이 생기면 아래와 같이 4개의 파일에 동시에 변경점이 생길 수 있습니다.

대출의 코드변경에 모두 영향을 받은 대출 행위 코드들

 

이렇게 보니 하나의 변경점에 생각보다 많은 파일이 변경된거 같기도 합니다.

그래서 개념과 행위를 다시 검토를 해보기로했습니다.

신청/실행/상환에 대해서는 원래 행위라고 생각을 했는데 모두 개념으로 정리 할 수 있을것 같습니다.

신청/실행/상환을 모두 개념으로 상향시켰습니다.

그리고 그 흐름은 아래와 같은 화살표로 이루어집니다.

신청->실행->대출->상환 순으로 개념이 구성됩니다.

이를 코드화 하면 아래와 같이 정리됩니다.

대출을 4개의 개념으로 나눴을 때 서로 영향을 덜 받게 됩니다.

이렇게 코드를 나누게되면 대출(Loan)의 변경점에 따른 코드 변경이 적어질 수 있습니다.

그러면 이제 대출중에서도 상환의 개념에 대해서 조금 더 고민 해 보겠습니다.

 

상환을 더 세분화 해보자면 결과를 상환 성공/ 상환 실패로 나눌 수 있습니다.

그리고 상환 실패 이후에 상환 재시도/ 추가이자 납부로 나눌 수도 있죠.

 

그러면 위의 그림의 코드가 아래와 같이 변경 될 수 있습니다.

상환 재시도, 추가이자 납부 코드가 생겼습니다.

뭔가 코드가 또 상환 실패에 대해서 많이 늘어나는 것으로 생각되어서 개념을 조금 더 살펴보았습니다.

격벽을 세우고 다시 그려보겠습니다.

상환 실패의 개념에 다시 격벽을 세워봤습니다.

격벽을 잘 그어보면 상환 실패와 상환 재시도/추가 이자 사이에는 격벽이 생깁니다.

상환 실패시에는 상환 실패의 역할은 종료 된 것이고 그 이후에 다른 작업의 역할로 상환 재시도/추가 이자 납부가 생긴 것이지 상환 실패와 저 둘은 사실은 개념적으로 연결 되지는 않은 것이죠.

 

그래서 새로운 연체 개념을 추가했습니다.

상환 재시도와 추가 이자가 연체 개념에 포함된다고 생각이 들었습니다.

따라서, 개념을 연체 납부와 연체 이자로 이름을 변경했습니다.

아래와 같이 그려볼 수 있습니다.

연체의 개념을 추가하고 연체 납부와 연체 이자로 이름을 추가했습니다.

이렇게 변경하면 코드는 아래와 같이 연체 개념으로 분리가 됩니다.

연체의 개념으로 코드를 분리했습니다.

또한 참고해야 할 사항은 상태는 개념이 아니라는 점이 있습니다. (별도 설명은 포함하지 못했습니다.)

개념에 상태가 존재하는 것이라고 합니다.

 

이와 같은 코드 작업으로 아래와 같은 교훈을 얻을 수 있습니다.

대출의 사례로 본 개념과 격벽의 교훈

대출의 사례로 본 개념과 격벽 활용 교훈

1. 하나의 개념이 많이 쓰이면 분리를 검토하자

2. 상태에 의해 개념이 생기면 격벽을 세워보자

3. 상태와 행위를 개념으로 착각할 수 있다.

 

커머스로 보는 개념과 격벽 활용

커머스의 예시에서는 상품의 개념을 살펴보려고 합니다.

 

상품과 외부 연동사들을 나눌 수 있고 상품에 대한 정보는 모두 외부 연동사(판매 업체라고 보면 될거같습니다)로 부터 옵니다.

커머스의 상품 개념

이렇게 개념들을 나눠봤을때 코드가 아래와 같이 반영됩니다.

커머스의 상품 개념에서 코드를 작성해본 예시

 

개념이 너무 많아지면 개념이 계층을 나누게 됩니다.

개념도 개념 나름의 중요도가 서로 다른 법이죠.

가장 중요한것은 1급 개념 그 다음은 2급 개념, 3급 개념 등등 이런식이죠.

 

또한, 개념이 없는 영역도 존재합니다.

쉽게는 우리의 프로그램이 아닌 경우가 그 경우입니다.

따라서, 위에서 언급한 외부 연동사는 이런 관점에서 개념이라고 할 수 없습니다.

또, 모니터링, 테스팅 등이 개념이 아닌 것에 속합니다.

개념의 계층과 개념이 아닌 것들

 

그래서 전체적인 플로우를 그림으로 그려보면 아래와 같이 

수정 및 정제영역 (초록색)

개념영역 (파란색)

이 탄생합니다.

 

수정 및 정제영역(초록), 개념영역(파랑)으로 나눈 격벽과 코드들

따라서, 외부연동사와 관련된 것들은 우리의 개념이 아니니 우리의 코드로써 관리를 할 수 없는 것이고 외부 연동되는 DB를 통해서 관리를 하는게 합리적으로 보여집니다.

 

커머스의 예시를 통해서 아래와 같은 교훈을 얻을 수 있겠습니다.

 

커머스의 사례로 본 개념과 격벽 활용 교훈

1. 개념에도 계층이 있다.

2. 모든 것이 개념이 되진 않는다.

3. 개념 영역을 분리 할 수 있다.

 

그리고 마지막으로 설계에 대해서 언급을 하셨습니다.

 

설계란 무엇인가

소프트웨어와 하드웨어의 차이는 얼마나 변경이 쉬운지에 따라 다르다고합니다.

따라서, 소프트웨어는 설계를 변경할 수 있어야하는 것입니다.

롯데 타워를 다 지어놓고 10cm 이동하는것 보다는 소프트웨어를 변경하는게 당연히 쉬워야 하며 변경이 어렵지 않아야합니다.

설계는 개념과 격벽을 활용한 구현 + 테스트를 통한 증명 및 피드백이라는 결론입니다.

 

그리고 아래의 3가지를 강조했습니다.

인정해야 하는 것

1. 요구사항은 계속 변한다.

2. 완벽한 설계란 없다.

3. Software는 Soft해야한다.

 

하지 말아야 하는 것

1. 요구사항이 완벽해야 설계가 가능하다고 하는것

2. 우리의 설계에서 그 기능은 개발하지 못한다는것

3. 설계를 해봐야 개발 일정이 나온다는 것

 

상기해야 하는 것

1. 성급한 설계는 모든것을 망가뜨린다는 점

2. 과도한 설계는 모든것을 망가뜨린다는 점

초당 100건 처리가 필요한 서비스에 10만건 짜리 서비스로 설계하면 안됨

3. 설계는 필요한 만큼만 해야한다는 점

과한 설계는 오히려 위의 하지 말아야 하는 것을 하는 원인이 될 수 있음

 

위의 교훈들에 따라서 기존에 분석 -> 설계 -> 구현과 같이 개발한 방식을 개념과 격벽을 활용해서 지속적으로 구현해 보는것을 추천하셨습니다.

지속 성장 가능한 설계를 만들어가는 방법

 

후기

세션을 들으면서 너무 좋았습니다.

과장인지는 모르겠으나 저는 이런 세션을 듣기 위해서 인프콘에 참여하고 싶었습니다.

최근에 코드를 너무 많이 작성하면서 뭔가 내가 잘못하고 있는것은 아닌지 변경에 열려있는 코드를 작성하는게 맞는것인지에 대해 고민을 많이 하게 되었는데요.

설계를 하면서 어렴풋이 이렇게는 하면 안되고 이렇게 해야지 라는 고민은 하고 있긴하지만
발표자분 처럼 이렇게 명확하게 설명은 할 수 없었습니다.

세션을 통해서 "그럴 때는 개념과 격벽이라는 키워드를 들면서 이렇게 코드를 작성하고 설계 하면 된다"라고 명확한 해답을 받은 느낌이 들었습니다.

물론 설계를 하지 않고 개념과 격벽을 가지고 구현을 하라는 것의 의미는 완전히 이해하지는 못했습니다만 앞으로 있을 개발에서 이를 적용 해 보면서 발표자 분께서 해주셨던 의도를 더 정확하게 파악하는 시간을 가져보려고 합니다.

세션을 들으면서 이런 좋은 예시와 단어들로 이렇게 설명을 잘 할 수 있구나 감탄을 많이했습니다.

최근 1년간 많은 성장을 했다고 느꼈기에 건방지게도 나도 좀 잘하는데? 라고 생각했던 제 자신을 반성하고 아직 부족한게 많음을 알게 된 세션이었습니다.

 

또한, 마지막에 강조한 3개의 항목들에 대해서 또 다시 상기 할 수 있게 되어 좋았습니다.

 

(추가) 관련해서 참고할 만한 글이 있어 링크를 첨부합니다.

[인프콘 후기] 2024 INFCON

"발주처의 완벽한 SW설계는 없다"…변경 수요 가능한 SW설계방법이 중요

골빈해커 / 소프트웨어 개발시 설계부터 잘해야한다는 말을 나는 반대... | 커리어리