<div id="readability-page-1" class="page"><div id="skip-nav"><p><time>08.11.2020</time> — <a href="/tags/삶">삶</a>, <a href="/tags/회고">회고</a> — <span>1 min read</span></p><section><p>10월은 앱 릴리즈 프로젝트로 정신없이 지나갔다.</p><h3>9월의 기술적 도전: A Bridge Too Far</h3><div data-language=""><pre data-linenumber="true"><code><p><span>1</span><span>“…I think we might be going a bridge too far.” - Lt. Gen. Frederick Browning</span></p></code></pre></div><p><a href="https://en.wikipedia.org/wiki/Operation_Market_Garden#Debate_on_Allied_strategy_and_tactics">마켓 가든 작전</a>의 실패를 그린 영화 “<a href="https://en.wikipedia.org/wiki/A_Bridge_Too_Far_(film)">머나먼 다리(A Bridge Too Far)</a>”가 떠올랐다. 너무 많은 목표를 한번에 달성하려고 할 때 생기는 문제. 그리고 그 목표가 모두 달성되어야 의미가 있는 계획을 세울 때 생기는 문제.</p><p>앱을 만들면서 이것도 하고, 저것도 같이하고, 같은 목표들을 세우면서 리스크가 너무 많아졌다. 각각의 목표의 완성도가 서로에게 영향을 주면서 전반적으로 혼란스러운 결과를 만들게 되었다. 앱 릴리즈 이후 2주동안 혼란을 커버해야 했다. 역시 하나의 목표만 세우고 그것만 잘해야한다.</p><h3>소프트웨어 엔지니어링은 건축이 아니다</h3><p>‘클린 아키텍처’, ‘실용주의 프로그래머’, ‘소프트웨어 장인정신’에서 공통적으로 말하고 있는 점은, 소프트웨어는 건축이라기보다는 정원 가꾸기(gardening, 원예)라는 것이다.</p><p>흔히 소프트웨어 프로젝트에 대한 무리한 요구사항의 변경을 “건물 3cm 옆으로 옮기기”라고 비유하는데(재미있게도 이런 비유는 외국도 마찬가지인듯), 원래 소프트웨어는 그런게 되야하는 영역이다. 소프트웨어가 건축이라고 생각하면 이런 잘못된 생각의 경향(소프트웨어는 바꾸기 어렵다)을 갖게 된다.</p><p>첫 아이폰 발표 키노트가 떠올랐다. 풀스크린, 멀티터치 디스플레이에 소프트웨어 키보드를 탑재하면서 잡스가 말하길 “제품을 내놓고 6개월 뒤에 다른 좋은 아이디어가 생각나면 어떡할 건가요? 돌아다니면서 이미 판매된 기기들에 일일이 버튼을 달고 다닐 수도 없잖아요!” </p><h3>단점의 극복</h3><p>위대한 작곡가는 자신의 재능으로부터 탄생하는 것이 아니라, 자신의 단점을 극복하면서 탄생한다는 이야기를 들었다.</p><p>베토벤은 멜로디를 너무 못 썼다. 베토벤의 어릴적 작곡 선생이었던 하이든은 그런 점에서 베토벤을 평가절하하기도. 그래서 베토벤은 곡을 구조적으로 썼다. 구조적으로 곡을 쓰면 선율을 못 다뤄도 괜찮기 때문이다. 그렇게 베토벤은 구조적인 작곡으로 전설이 되었다. (교향곡 5번의 1악장은 ‘빠바바밤’ 만으로 이루어져있다: <a href="https://www.youtube.com/watch?v=6fsDkAa9VtM">베토벤 교향곡 제5번 「운명」 (카라얀) - YouTube</a>)</p><p>내 단점을 극복한다면서, 단순히 그 단점의 ‘개선’을 하고 있는 것은 아닌지 돌이켜보게 되었다.</p><h3>이해관계의 충돌</h3><p>요즘 청계천 자전거도로를 공사하고 있다. 원래 차도 분리형 자전거도로(차도의 일부를 떼어내서 자전거도로로 만든 것)였는데, 인도 분리형 자전거도로(인도의 일부를 떼어내서 자전거도로로 만든 것)로 고치고 있는 것. 자전거도로를 빼고 보면 차도가 줄어들고 인도가 늘어나는 것이라고 할 수 있다. 이 변화로 어떤 결과를 바라는 것일까?</p><p>매일 이 길을 자전거로 출퇴근하는 내 입장에선 개악이라고 할 수 있다. 어차피 제한속도 30km/h인 차도라서 인도보다 차도가 더 편하기 때문. 아마 가끔씩 따릉이를 타는 사람, 걷는 사람, 차 타는 사람 모두 이 공사에 대한 생각이 다를 것이다. 어떤 과정으로 의사결정이 이루어진 것일지 궁금해졌다.</p><h3>CHS</h3><iframe width="560" height="315" src="https://www.youtube.com/embed/Gx4kct5aXN4" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe></section></div></div>

Minimal Blog - @lekoarts/gatsby-theme-minimal-blog

Minsik Kim

10월은 앱 릴리즈 프로젝트로 정신없이 지나갔다.
9월의 기술적 도전: A Bridge Too Far
.css-l84w3r{background-color:rgba(107,70,193,0.2);border:none;color:var(--theme-ui-colors-gray-2,#edf2f7);cursor:pointer;font-size:14px;font-family:"IBM Plex Sans",-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Helvetica Neue",Arial,"Noto Sans",sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";-webkit-letter-spacing:0.025rem;-moz-letter-spacing:0.025rem;-ms-letter-spacing:0.025rem;letter-spacing:0.025rem;-webkit-transition:default;transition:default;position:absolute;top:0;right:0;z-index:1;border-radius:0 0 0 0.25rem;padding:0.25rem 0.6rem;}@media screen and (min-width:640px){.css-l84w3r{font-size:14px;}}@media screen and (min-width:768px){.css-l84w3r{font-size:16px;}}.css-l84w3r[disabled]{cursor:not-allowed;}.css-l84w3r:not([disabled]):hover{background-color:var(--theme-ui-colors-primary,#6b46c1);color:var(--theme-ui-colors-white,#fff);}Copy.css-1gy8470{border:0;-webkit-clip:rect(0,0,0,0);clip:rect(0,0,0,0);height:1px;margin:-1px;overflow:hidden;padding:0;position:absolute;white-space:nowrap;width:1px;}copy code to clipboard
1“…I think we might be going a bridge too far.” - Lt. Gen. Frederick Browning
마켓 가든 작전의 실패를 그린 영화 “머나먼 다리(A Bridge Too Far)”가 떠올랐다. 너무 많은 목표를 한번에 달성하려고 할 때 생기는 문제. 그리고 그 목표가 모두 달성되어야 의미가 있는 계획을 세울 때 생기는 문제.
앱을 만들면서 이것도 하고, 저것도 같이하고, 같은 목표들을 세우면서 리스크가 너무 많아졌다. 각각의 목표의 완성도가 서로에게 영향을 주면서 전반적으로 혼란스러운 결과를 만들게 되었다. 앱 릴리즈 이후 2주동안 혼란을 커버해야 했다. 역시 하나의 목표만 세우고 그것만 잘해야한다.
소프트웨어 엔지니어링은 건축이 아니다
‘클린 아키텍처’, ‘실용주의 프로그래머’, ‘소프트웨어 장인정신’에서 공통적으로 말하고 있는 점은, 소프트웨어는 건축이라기보다는 정원 가꾸기(gardening, 원예)라는 것이다.
흔히 소프트웨어 프로젝트에 대한 무리한 요구사항의 변경을 “건물 3cm 옆으로 옮기기”라고 비유하는데(재미있게도 이런 비유는 외국도 마찬가지인듯), 원래 소프트웨어는 그런게 되야하는 영역이다. 소프트웨어가 건축이라고 생각하면 이런 잘못된 생각의 경향(소프트웨어는 바꾸기 어렵다)을 갖게 된다.
첫 아이폰 발표 키노트가 떠올랐다. 풀스크린, 멀티터치 디스플레이에 소프트웨어 키보드를 탑재하면서 잡스가 말하길 “제품을 내놓고 6개월 뒤에 다른 좋은 아이디어가 생각나면 어떡할 건가요? 돌아다니면서 이미 판매된 기기들에 일일이 버튼을 달고 다닐 수도 없잖아요!” 
단점의 극복
위대한 작곡가는 자신의 재능으로부터 탄생하는 것이 아니라, 자신의 단점을 극복하면서 탄생한다는 이야기를 들었다.
베토벤은 멜로디를 너무 못 썼다. 베토벤의 어릴적 작곡 선생이었던 하이든은 그런 점에서 베토벤을 평가절하하기도. 그래서 베토벤은 곡을 구조적으로 썼다. 구조적으로 곡을 쓰면 선율을 못 다뤄도 괜찮기 때문이다. 그렇게 베토벤은 구조적인 작곡으로 전설이 되었다. (교향곡 5번의 1악장은 ‘빠바바밤’ 만으로 이루어져있다: 베토벤 교향곡 제5번 「운명」 (카라얀) - YouTube)
내 단점을 극복한다면서, 단순히 그 단점의 ‘개선’을 하고 있는 것은 아닌지 돌이켜보게 되었다.
이해관계의 충돌
요즘 청계천 자전거도로를 공사하고 있다. 원래 차도 분리형 자전거도로(차도의 일부를 떼어내서 자전거도로로 만든 것)였는데, 인도 분리형 자전거도로(인도의 일부를 떼어내서 자전거도로로 만든 것)로 고치고 있는 것. 자전거도로를 빼고 보면 차도가 줄어들고 인도가 늘어나는 것이라고 할 수 있다. 이 변화로 어떤 결과를 바라는 것일까?
매일 이 길을 자전거로 출퇴근하는 내 입장에선 개악이라고 할 수 있다. 어차피 제한속도 30km/h인 차도라서 인도보다 차도가 더 편하기 때문. 아마 가끔씩 따릉이를 타는 사람, 걷는 사람, 차 타는 사람 모두 이 공사에 대한 생각이 다를 것이다. 어떤 과정으로 의사결정이 이루어진 것일지 궁금해졌다.
CHS

2020년 10월 회고

댓글