brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Feb 22. 2024

소프트웨어 설계 프로세스를 만들기 위한 아기 발걸음

한국의 마틴 파울러가 되기

<Tidy First?> 번역이 옵션 개념을 가르치다 후속 편을 '투자와 경제를 배우는 수요일' 연재가 아닌 '한국의 마틴 파울러가 되기' 글로 씁니다. 출발은 똑같이 번역을 위한 배경 지식 습득에서 했지만, 지난 글을 쓸 때는 번역 과정에서 다뤘던 금융 배경 지식에 대해 썼다면, 이번에는 다른 관점으로 글을 쓰고 싶기 때문이죠. 제 스타일의 글쓰기 운영을 만들어 가는 중입니다.


옵션 거래에서 시간가치와 그 중요성

암튼 시작은 두 개의 Gatekeeper[1] 중에서 구글 검색 결과로 알게 된 페이지를 열어 보았습니다. 다음 그림이 가장 먼저 저를 사로잡았습니다. 지난 글을 쓰며 배운 내재 가치가 영국말로 'Intrinsic Value'라는 점을 알아챈 이유도 있고, 'Time Decay'란 글자를 보니 시간 가치의 하락과 관련이 있겠구나 싶었습니다.

그런데 여기서 연재를 바꾼 결정을 합니다. 원문은 옵션 거래를 다룹니다. 하지만, <Tidy First?> 책도 그렇고 제 관심사도 소프트웨어 설계를 향해 있습니다. 그래서 그 관점으로 여기 나온 개념을 대입해 보고 생각을 풀어 보고 싶었습니다.[2]


소프트웨어 설계에서 최선의 선택은?

한편, 페이지에서 그림 위쪽을 보니 설명이 한글로 번역되어 있었습니다. 처음에는 '시간 가치 하락'이란 표현을 보았고, 그게 'Time Decay'를 뜻한다는 사실을 알았습니다. 다른 내용도 쭉 훑어보는데 소프트웨어 설계 관점으로 다시 읽어 보고 싶었던 옵션 하위 개념이 바로 다음 다발말[3]입니다.

5. 최선의 선택: 최선의 선택을 결정하는 것은 개별 거래자의 목표와 시장 전망에 따라 달라집니다. 거래자가 장기간에 걸쳐 기초자산의 상당한 가격 변동을 예상하는 경우, 더 높은 시간 가치를 지닌 장기 옵션이 선호될 수 있습니다. 반대로, 거래자가 더 짧은 기간 내에 가격 변동이 발생할 것으로 예상하는 경우에는 시간 가치가 낮고 날짜가 짧은 옵션이 더 적합할 수 있습니다. 각 옵션의 위험-보상 프로필을 신중하게 평가하고 이를 거래 전략에 맞추는 것이 중요합니다.

어쩌면 제가 번역을 하게 된 무의식적인 요인[4]이 지금 받은 자극일 수도 있겠습니다. Kent Beck의 글을 띄엄띄엄 읽을 때 받은 어떤 느낌이 있었습니다. 지금 보니 (번역 과정에서 정독한 내용을 토대로) 가장 강력하게 저의 성장에 영향을 주는 부분이 바로 '최선의 선택'에 대해 부족한 지식을 습득하는 일이 아닐까 싶습니다.


최선의 선택은 어떻게 하는가? 최선의 선택이란 무엇인가?

물론, 이는 지난한 연구입니다. 다행스러운 점은 <Tidy First?>를 읽고 알게 된 사실입니다. Kent Beck이 자신의 결심을 지켜 <Structured Design>의 현대적 대안을 내놓는데 거의 20년이 걸렸다는 사실입니다. 그것도 첫 작품만 내놓은 것이고, 앞으로 더 작업을 해야 한다는 것이죠. 여기서 저는 이런 일이 본질적으로 지난한 일이란 사실을 배우고 위로를 받습니다.


<기술 부채를 Code Smell로 관리할 수 있는가?>라는 질문을 던진 것이 이미 작년 7월입니다. 그리고 진도는 더디지만 그에 앞선 2월에 <개발의 시장 가치 측정을 위한 첫 발을 떼다>를 시작했고, 드디어 2024년에는 생산물(릴리스한 코드)이 버는 매출과 생산원가를 혼자서 엑셀 수준으로 측정하고 기록하고 있습니다.


제가 나름의 까닭으로 엑셀에 넣은 데이터란 열매를 만드는 일은 최봉영 선생님에 따르면 일을 통해 사람으로 사는 길이자, 어떤 사람이 되어 가는 길입니다. 여기에 더해 최근에 <인생은 순간이다>을 읽으며 김성근 감독님께 배운 내용을 대입한 그림을 소환합니다.


소프트웨어 설계 선택에 대한 프로세스를 위한 아기 발걸음

그러면 '최상의 소프트웨어 설계 선택'에 대한 나만의 프로세스를 만들 수 있겠구나 하는 기대감을 갖게 됩니다. 여기서 옵션에 대한 배경 지식과 그 위에서 배울 <Tidy First?> 내용은 아이디어가 되어서 내가 아기 발걸음을 걷게 하는 동기로 작용합니다.

인내는 '꾸역꾸역'이라는 저의 행동 양식과 지금까지 설계를 붙잡고 있는 저의 존재가 증명하고 있습니다. 지금 필요한 것은 '의도'인데, 이 부분은 <투자와 경제를 배우는 수요일> 시리즈를 써 오면서 배운 듯합니다.


'어떻게'를 찾기 전에 먼저 최선의 선택이 무엇인지부터 물어야 한다는 사실입니다. 앞서 인용한 포기말[5]에도 그 내용이 함축되어 있습니다.

최선의 선택을 결정하는 것은 개별 거래자의 목표와 시장 전망에 따라 달라집니다.

릴리스할 때 목표와 시장 전망이 정의되지 않으면 선택의 적합성을 판단할 근거가 마련되지 않습니다. 금융(혹은 투자와 경제)에 대해서 7개월 남짓 공부한 내용이 소프트웨어 설계에도 도움을 줍니다.


주석

[1] Gatekeeper란 말이 생소하신 독자들은 지난 글의 뒷부분에서 일부 지식을 얻을 수 있습니다.

[2] 지난 글 말미에 언급한 Gatekeeper의 위력에 대한 생각을 덧붙이면, 두 결과 중에 구글 바드가 제시한 것이 더 좋구나 느낀 부분은 검색 엔진보다 AI가 더 매력적으로 보이는 마케팅을 공간이었습니다. 다시 말해서, 바드에 끌려 그 결과만 보면 되는 것이었죠. 하지만, 저는 임자로서 행동했습니다. 밀려(?)난 결과도 효용성이 있나 쓱 훑어보았습니다. 그랬더니 금융 배경 지식 습득용이 아니라 소프트웨어 설계에 대한 영감을 받고 즐기면서 생각을 풀어놓는 소재로 잘 쓸 수 있었죠. 이런 작용이 바로 '임자의 살리는 힘'을 쓰는 예시입니다.

[3] 왜 다발말인지는 <언어에 대한 일반이론>에서 일부 답을 얻을 수 있습니다.

[4] 제가 번역을 결정할 때 명시적으로 떠올리고 말한 동기는 '정독'이었습니다. 하지만, 왜 정독을 해야 하는지는 그냥 느낌으로만 존재했습니다.

[5] 왜 포기말인지는 <언어에 대한 일반이론>에서 일부 답을 얻을 수 있습니다.


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

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 기준 정보 자산

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

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