brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Feb 02. 2024

코드 정돈과 시스템 규모 리팩터링 사이

한국의 마틴 파울러가 되기

아침에 제가 좋아하는 조영호 님이 무신사에서 이룬 업적을 페북으로 알렸습니다. 순식간에 여러 가지 생각이 났습니다.

뒤엉킨 살타래처럼 덩어리로 올라온 생각을 풀며 글을 씁니다.


MSA가 먼저가 아니라 비즈니스와 사람이 먼저다

먼저 2016년 중국에서 했던 진한 경험이 떠오르지 않을 수 없었습니다. 당시 CTO 역할을 하시던 김형준 이사님이 9개월을 지켜보고 써 두신 소중한 기록이 있습니다.

'소중한'이란 형용사를 덧붙인 이유가 있습니다. 2016년에는 옆에 계시지 않았는 데도 마치 함께 한 사람처럼 알아주셔서 너무 고마웠습니다. 절대자에게 위로를 받는 듯한 느낌이랄까요? 처음 이 글을 읽었을 때는 그런 느낌이 들었다고 기억합니다. 위로에 더하여 다른 사람에게는 이렇게 보이는구나 하는 점도 흥미로워서 두고두고 읽었던 것 같습니다.


개인적인 감상과 별개로, 흥미로운 일이 벌어졌습니다. 김이사 님의 글 때문인지, 아무튼 확인할 길 없는 이유로 소문이 나서 한국의 대형 커머스 기업 두 곳에서 연락이 왔습니다. 중국에 상주하는 중이라 일을 맡을 수 없는 형편이었지만, 그들의 이야기를 듣고 싶어서 두 곳 모두와 만났습니다. 하지만, 추진하는 리더는 비즈니스와 사람(개발자와 기획자)을 우선하는 것이 아니라 기술을 목표로 두었습니다. 그래서 함께 하기 어렵다고 판단했습니다.


이런 제가 조영호 님 페이스북에서 다음 문장을 볼 때 반갑지 않을 수 없었습니다. 김칫국을 마시는 것일 수도 있지만, 여하튼 그는 MSA를 먼저 목표로 제시하지 않은 것은 분명합니다.

과제를 진행하는 동안 몇 가지 이유로 MSA라는 용어를 사용하지 않았는데 이제는 마무리되는 시점이다 보니 동료분들이 해오신 일들을 MSA 전환이라는 기술적인 관점에서 정리하고 회사 내에 공유하는 게 좋겠다는 생각이 들어 오늘부터 자료를 만들기 시작했다.


코드 정돈과 시스템 규모 리팩터링

두 번째로 제가 <Tidy First?>를 번역하면서 배운 지식과 중국에서의 경험이 섞여서 새로운 아이디어를 샘솟게 했습니다.

그 느낌을 그림으로 표현하고 싶었습니다. 저는 먼저 두 개의 축을 잡았습니다. 수포자를 벗어나려는 나의 지난한 노력과 잣대를 차리는 습관이 작동한 것입니다. 가로는 교류 범위라고 지었습니다. 혼자 개발하느냐 여럿이 협업하느냐의 문제죠. 일단, Kent Beck이 다루는 코드 정돈(tydings)은 개인 차원에서 '거울 속의 나(man in the mirror)'와 함께 시작합니다.

오래전에 마이클 잭슨은 노래를 통해 세상을 바꾸려고 해도 일단 나부터 바뀌라고 했습니다. 우리 회사 시스템을 바꿀 때도 마찬가지입니다. 답이 없다고 느끼는 레거시라고 해도 마찬가지죠. 내면에서 흘러나오는 욕망을 바깥에 말해 봐야 소용없습니다.


지식 노동의 특징은 유기체로 지식을 함께 다루기

이쯤 되자 2017년 읽었던 부자 아빠 이야기 6권에서 골리앗이 다윗 안의 거인을 꺼냈다는 표현이 저를 찾아옵니다. 내가 꼭 풀어야 할 문제라고 혼자 느끼는 문제가 제가 즉흥적으로 그린 그림에 있습니다. 아님 말고 하는 마음으로 '한국의 마틴 파울러 되기'라는 말을 했는데, 실제 그렇게 되어 가고 있는 모양이란 생각도 (진지하게) 합니다.


(생각 쓰기) 충동을 다스리고 오늘 할 일로 돌아가야 합니다. 그런데, 독자님들께 느끼실 '중간에 잘리는 느낌'을 완화하기 위해 '마치며'를 씁니다.

저는 아키텍처 현대화를 MSA 도입으로 생각하는 인간 소외적 발상에 반대합니다. 그리고, 비즈니스와 별개로 진행하는 Silo식의 분업에도 반대합니다. 그럼 어떻게 해야 하는지에 대해 <Strangler Fig 패턴과 점진적 IT 투자> 정도의 글로만 설명할 수 있었습니다.


주류 경영자 입장에서 보면 답답한 설명입니다. 그래서 어떻게 해야 할까 한참 고민을 했습니다. <기술 부채를 Code Smell로 관리할 수 있는가?>와 같은 밑바닥부터 경험해서 지식을 쌓아 볼까도 생각했습니다. 그러다가 최근에 글을 고치는 과정에서 피터 드러커가 말하는 지식 노동의 특징을 발견했습니다. 코딩과 글쓰기는 너무나도 닮아 있었습니다.


다만, 프로세스가 강조되는 현대 기업 활동과 출판업은 너무 거리가 동떨어져 있습니다. 그래서, 피터 드러커가 말하는 지식 노동의 원형으로 프로세스가 널리 퍼져 있는 일이 소프트웨어 개발이란 사실을 깨달았습니다. 여기서 두 가지 방향으로 생각을 발전시킬 수 있는데, 이에 대해서는 다음에 계기가 되면 새로운 글로 만나 뵙겠습니다.


지난 한국의 마틴 파울러가 되기 연재

1. 현실과 시스템의 불일치, 그리고 UX의 역할

2. 대상과 조건 그리고 자기 속도에 부합하는 조건 만들기

3. Code Smells 비유와 기술 부채

4. 기술 부채를 Code Smell로 관리할 수 있는가?

5. 형상 구성단위로 TestCase 유용할까?

6. 설계 요소의 사분면

7. 입자와 파동의 이중성을 소프트웨어 설계에 응용하기

8. 즉흥적으로 그린 그림에 입자와 파동 이중성 적용하기

9. 소프트웨어 설계에서 입자의 응용

10. 소프트웨어 설계에서 파동의 응용

11. 설계란 무엇인가 IV Part.1

12. 설계란 무엇인가 IV Part.2

13. 설계는 변화에 대한 준비인가?

14. 대상이 되는 사태의 주요 내용을 한 장에 담다

15. 스윔레인으로 경계와 상호작용 드러내기

16. 짝 프로그래밍처럼 함께 설계하기

17. 짝 모델링으로 탄생한 상태도 초안

18. 동료의 상태도를 검토하기

19. 분산 환경 무결성 문제와 상태도 연결하기

20. 후배 덕분에 한 번 더 생각하는 객체 지향

21. 소프트웨어 설계와 간접 연결성 그리고 모듈화

22. 기능을 무시한 디자인 그리고 소비자 관점의 기능 정의

23. 콘텐츠성 정보 자산 vs 기준 정보 자산

작가의 이전글 한계를 없애는 방법을 실천해 보자
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari