brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 May 16. 2022

진화하는 혹은 오래 사는 시스템 만들기

도메인 스토리텔링 연구 No. 18

<시스템 릴리즈와 아키텍처의 관계>편에 달린 지인인 백명석님 댓글 덕분에 창발적 설계에 대해 찾아보았다.

2009년 컨설팅 사업부를 이끌 때 롤모델이었던 회사가 소트웍스(ThoughtWorks)였는데, 그 회사의 컨설턴트인 Neal Ford의 글을 한편 읽었는데, 생각이 나와 매우 비슷했다.


먼저 설계할 필요가 없다

10년도 더 지난 일이라 기억에 오류가 많을 듯하여 구글링을 해보니 2009년에 내가 읽은 글은 IBM DW에 올라온 글인 듯하다. 진화적인(Evolutionary) 아키텍처와 Emergent 설계가 제목이다. Emergent는 우리 말로 무엇일까?


암튼, 애자일이 막 보급되던 시점이지만 여전히 설계를 미리 하고 개발을 이후에 하는 공정이 주류를 이뤘다. 그래서 먼저 설계를 (과하게) 할 필요가 없다는 주장을 담은 글이다. 지금 보면 너무나 당연한 글이지만, 10 여년 사이에 엄청난 변화가 있었다. (영어 듣기가 되는 분은 Emergent Design by Neal Ford 를 들으시면 빠르게 개요를 이해할 수 있을지도 모른다.)


소트웍스에서는 Building Evolutionary Architectures라는 제목으로 2017년 책도 출간했다. 긴 시간 기술 영업에 사용한 (그들에겐) 중요 개념일 듯하다.


일단, 명석님의 풀이부터 보면 TDD와 리팩터링으로 설계를 하는 방법일 수 있다. 직관이나 조사에 의해 미리 설계하는 일을 자제한다는 측면에서 충분히 훌륭한 수행법에 대한 설명이 될 수 있다.


진화라는 말은 왜 쓰는가?

책을 읽어 보지 않고 답을 하려고 한다. 나는 저자(들)의 생각이 궁금한게 아니라 내가 20년 이상 이 업계에 있으면서 확신한 바에 대해 쓰려고 한다. 진화를 키워드로 구글링을 하면 다음과 같은 결과를 얻을 수 있다.

생물에 대한 이야기가 아니고 우리가 만드는 소프트웨어 혹은 시스템에 대한 이야기인데, 왜 진화를 말하는가?


나는 인간이 진화의 산물인 만큼 인간이 만들어내는 도구 역시 진화의 틀을 벗어날 수 없다고 믿는다. (우리도 자연의 일부일 뿐이다.) 그렇다면 우리가 만드는 시스템(프로그램이나 소프트웨어보다는 시스템이 내가 말하려는 대상에 조금 더 어울린다.)도 진화를 피할 수 없다. 흔히 쓰는 말로 시장의 평가를 받게 되어 있다.


생존하려면 사용자와 고객의 인정을 받아야 한다. 쉽게 말해 자주 쓰여야 하고, 돈이 지불되어야 살아 남을 수 있다. 생물학의 진화와 똑같지 않은가!


일단 릴리즈를 해라

아래 그림은 10년전, 대기업에서 최고 경영자에게 IT혁신에 대해 설명할 때 대표 이미지로 차용한 그림이다. 애초에는 유럽 DevOps 커뮤니티에서 인용한 것이지만, 나는 최고 경영자에게 잦은 비즈니스 피드백이 시스템 구축에 필수적인 작업임을 보여주려고 이를 사용했다.


2016년에 중국에 가서 북경의념과기유한공사의 변화를 이끌 때(일명 노아의 방주 프로젝트) 나는 이를 더 강화시켜서 매주 코드 변경을 가지고 주간회의를 하고, 한달에 한번은 반드시 시장 릴리즈를 한다는 규칙을 개발조직의 가장 중요한 목표로 삼았다.


바로 거기서 우리가 진화할 수 있는 기회가 생긴다. 릴리즈 후에 생기는 모든 피드백을 배움과 생존의 기회로 삼아야 한다. 실제로 그 효과는 놀라웠다. 아쉽게도 비즈니스 효과를 맛보는 경영자가 없어 사업적으로는 실패했지만, 리눅스 명령어조차 모르던 중국 엔지니어들이 수백개의 서비스로 운영되는 마이크로 서비스 운영을 거뜬히 해내는 데 걸린 시간이 2년이었다. 진화는 바로 그런 것이다. 시스템도 진화되고, 조직도 진화되고 사람들은 성장한다.


그걸 믿지 못하고 자기의 실력이나 시장에 대한 이해(혹은 편향)을 믿고 설계하는 일은 어리섞은 일이다.


<프로젝트에서 제품으로> 에서도 강조

<소프트웨어를 제품으로 만드는 길>을 쓸 때 즈음 우연히 발견한 책 <프로젝트에서 제품으로> 120쪽에 있는 아래 내용을 인용하며 글을 마친다.

아키텍처 계층 분리를 좀 더 개선하는 것과 같은 소프트웨어 아키텍처만을 위한 작업은 피해야 한다. 이는 각 플로우 아이템의 흐름이 소프트웨어 아키텍처를 형성해야 한다는 의미미다.

플로우 아이템이란 말은 좀 생소한데, 반드시 비즈니스 가치를 전달하는 흐름과 연관이 있어야 한다는 말이다.



지난 도메인 스토리텔링 연구

1. 실전 도메인 스토리텔링 첫 시도

2. 도메인 스토리텔링은 무엇인가?

3. 도메인이 무엇인가요?

4. 설계서가 아니라 의사소통

5. 동료의 도메인 스토리텔링 활용

6. 도메인 스토리로 대화하기

7. 도메인 스토리로 비즈니스 규칙 발견하기

8. 도메인 스토리텔링에 문법 입히기

9. Work Objects란 무엇인가?

10. 개발자와 현장 사람들의 거리를 좁혀라

11. 도메인 스토리에서 참여와 비전을 이끌어내기

12. 초점 주변의 이야기까지 스토리 텔링하기

13. 도메인 스토리텔링으로 UX 개선하기

14. 도메인 스토리의 적절한 구도

15. 도메인 스토리와 개인 업무의 이중 구조

16. 스토리텔링보다 문서가 익숙한 사람과 협업하기

17. 시스템 릴리즈와 아키텍처의 관계

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari