[INFCON 2024 참관기 - 1] 지속 성장 가능한 설계를 만들어가는 방법

작년 8월 저는 정말정말 운이좋게 치열한 경쟁을 뚫고 인프콘에 당첨되어 즐거운 시간을 보내고 왔습니다.
(교육 일정이라고 연차 대신 공가를 내준 우리 회사에 끝없는 감사를...ㅎㅎ)

정말 규모도 크고, 화려하게 꾸며져있어서 여러 가지를 듣고 배운 것 외에도 즐길거리가 많았었습니다.
사진 부스도 있어서 이렇게 인증샷도 남겨봤네요

바쁜 일정을 핑계로 인프콘 참관기 작성을 미루다 뒤늦게라도 하는 것이 아예 안하는 것 보다는 훨씬 나을 것 같아 정리하려고 합니다.
여러 연사님들의 발표를 들었는데 아래의 세 강의가 가장 기억에 남았었어요.

1. 지속 성장 가능한 설계를 만들어 가는 방법 - 김재민 연사
2. 디버깅 마인드셋 - 배휘동 연사
3. 경력이 늘 수록 CS이론이 중요해지는 이유 - 최호성 연사

하여 INFCON 2024 참관기는 총 세 편에 걸쳐 작성할 예정입니다.

먼저 이번 글 에서는 토스페이먼츠의 김재민 님이 발표하신 "지속 성장 가능한 설계를 만들어가는 방법"에 대한 내용을 정리해보았습니다.

15년차 서버 개발자이신 연사님은 현재 토스페이먼츠에서 근무하시며, '제미니의 개발실무' 유튜브 채널도 운영하고 계신다고 합니다!
저는 이미 이미 구독을 했습니다.ㅎㅎㅎㅎㅎ
제미니의 개발실무

제미니의 개발실무

 

연사님의 인프콘 발표에서도 인사이트를 많이 얻었고, 유튜브 영상에서도 인사이트를 얻었습니다.
특히 멀티플랫폼 POS의 아키텍쳐를 설계하면서, 많은 도움을 받았습니다.
제가 영향을 받은 유튜브 영상의 제목은 '헥사고날 아키텍쳐 배우지 말자'였는데요.
핵심 내용은 '은탄환은 없다', '모든 기술의 적용엔 이유가 필요하다', '기술을 위한 기술은 오버 엔지니어링으로 이어진다', '그러므로 도메인에 적합한 아키텍쳐를 고르자.'라고 이해했습니다.
때문에 자사의 레거시 서비스를 운영했을때의 경험과, 외부 의존이 많은 오프라인 결제 솔루션 특성상, 표현력이 약한 단순 계층 아키텍쳐보다는 헥사고날이 적합하다고 판단하여, 결국 영향 받은 영상의 제목과는 반대로(!) 헥사고날을 적용해 개발 중에 있습니다.
(설계에 관한 자세한 내용은 아래 수기를 참조 부탁드립니다 ㅎㅎ)

2024.12.16 - [아키텍쳐 설계 경험/헥사고날 아키텍쳐 설계 도전기] - [신입 개발자의 첫 번째 아키텍쳐 설계 도전기 - #1] 레거시 아키텍처의 문제점 분석

[신입 개발자의 첫 번째 아키텍쳐 설계 도전기 - #1] 레거시 아키텍처의 문제점 분석

 

서두가 참 길었는데요 ㅋㅌㅋㅌ 그럼 연사님의 발표 내용 정리를 시작해 보겠습니다.

들어가며: 설계란 무엇인가?

많은 개발자들이 설계라고 하면 DDD, MSA, Hexagonal Architecture, OOP, FP 등 다양한 아키텍처 패턴들을 떠올립니다.
그러나 실제 개발 과정에서 설계는 다음과 같은 순환적인 과정의 일부입니다.

1. 요구사항 분석
2. 계획
3. 설계
4. 구현
5. 테스트
6. 운영

각 단계마다 문서화(계획서, 요구사항 분석서, 설계서, 코드, 테스트 보고서)가 수반됩니다.

역설적인 제안: 설계를 하지 않는 것

연사님은 "설계를 잘하는 방법은 설계를 하지 않는 것"이라는 역설적인 제안을 하셨습니다.
이는 과도한 설계나 너무 이른 설계가 오히려 소프트웨어의 성장을 방해할 수 있다는 점을 지적한 것입니다.

구현 중심의 접근: 개념과 격벽

대신 제안하신 방법은 '구현' 중심의 접근법입니다. 크게 두 가지 요소에 집중합니다.

1. 개념(Concept) 잡기

개념은 비즈니스 도메인에서 다루는 핵심 요소들입니다. 예를 들어 웹툰 서비스의 경우:

• 작품
• 결제
• 구매/연재
• 작가
• 리뷰
• 포인트
• 만료
• 소장

등이 주요 개념이 될 수 있습니다.

2. 격벽(Boundary) 세우기

격벽은 개념들 사이의 경계를 명확히 하는 것입니다. DDD의 Aggregate Boundary와 유사한 개념이라고 생각 되었습니다.
격벽은 개념 간의 참조와 의존성을 제어합니다.

실제 사례를 통한 이해

사례 1: 대출 시스템

대출 시스템에서 다음과 같은 개념들이 도출될 수 있습니다:

• 대출
• 신청
• 실행
• 상환

여기서 중요한 점들:

• 상환 실패는 상태이지 개념이 아님
• 연체는 상환과 같은 레벨의 새로운 개념으로 부각됨
• 하나의 개념이 너무 많이 사용되면 분리를 검토해야 함

사례 2: 커머스 시스템

커머스 시스템의 경우:

• 상품
• 외부 연동사
• 전시
• 주문/결제

여기서의 교훈:

• 모든 것이 핵심 개념이 되진 않음 (예: 외부 연동사는 2급 개념)
• 개념에도 계층이 존재함
• 개념 영역을 분리할 수 있음

소프트웨어는 Soft 해야 한다

연사님은 다음과 같은 중요한 포인트들을 강조하셨습니다.

인정해야 할 것들

• 요구사항은 계속 변한다
• 완벽한 설계란 없다
• 소프트웨어는 말 그대로 'Soft'해야 한다

피해야 할 것들

• "요구사항이 완벽해야 설계 가능해요"
• "우리 설계에서 그건 개발 못해요"
• "설계해봐야 개발 일정이 나옵니다"

항상 상기할 것들

• 성급한 설계는 모든 것을 망가뜨린다
• 과도한 설계는 모든 것을 망가뜨린다
• 설계는 필요한 만큼만 하자

결론: 지속 성장 가능한 설계의 3단계

최종적으로 지속 성장 가능한 설계를 위한 3단계를 제시하셨습니다:

1. 개념을 잡고
2. 격벽을 세우고
3. 구현을 채워나가며 설계를 완성한다

"누구나 그럴듯한 계획을 가지고 있다. 맞기 전까지는..." - 마이크 타이슨 -
위의 유명한 명언이 좋은 설계를 만들어가는 방법을 잘 나타낸다고 합니다.
완벽한 설계를 추구하기보다는 실제 구현을 통해 검증하고 발전시켜 나가는 것이 중요하다는 뜻이겠죠!

마무리

이 발표를 통해 설계는 한 번에 완성되는 것이 아니라, 구현을 통해 점진적으로 발전시켜 나가야 하는 것임을 배웠습니다.
특히 개념과 격벽이라는 두 가지 핵심 요소를 중심으로 접근하는 방법은 저에게 매우 실용적인 인사이트를 줬습니다.
다음 글은 배휘동 연사님의 디버깅 마인드셋 발표에 대해 정리해볼 예정 입니다.