소프트웨어 장인

산드로 만쿠소 지음 | 권오인 옮김 길벗출판사

책가게 사이트의 알고리즘에 추천 책으로 떴는데, 개발자 사이에서도 많이들 권장도서로 알려진 책인가보다. 개인적으로 한가지 속은 것은 ‘로버트 C.마틴 시리즈’라고 묶어 소개해서 저자가 당연히 밥아저씨인 줄 알고 샀는데, 그렇지 않았다는 거… 그냥 추천사를 썼다.

‘장인’이라는 칭호는 단순 전문가 이상의 어떤 의미를 지니는 단어로 다가온다. 직업이 아니라 삶이나 영혼을 동반한 듯한 의미로써 말이다. 이 책에서도 단순히 기술 수준이 높다고 ‘장인’은 아니고 윤리의식, 동료의식, 문제를 대하는 태도 등이 종합된 IT업종의 완성형 인간으로 ‘장인’을 소개한다.

장인은 일종의 삶의 철학이다. 우리의 삶 전체에 걸쳐서 최선을 다해 역량을 마스터할 과업으로 소프트웨어 개발을 선택한 것이다. 항상 최고의 코드를 만들도록 다른 것들을 희생해서라도계속해서 배우고 남을 도우리라는 각오를 하는 것이다. (중략) … 일생에 걸친 헌신과도 같다.

음… 누군가는 사도신경이나 국기에 대한 맹세와 비슷하다고 생각할 수도 있겠다.

좋은 얘기 많고 많지만, 몇가지 인상에 남은 것을 정리한다.

동기부여

저자는 일찍부터 일생의 목표를 확실하게 정해두고 차근차근 달성해 온 듯 싶다. 브라질에 대해 상식 이상으로 어떤 나라인지는 정확히 모르나 축구 외에도 하위층에서 상위층으로 올라갈 수 있는 사다리로써 IT라는 직종이 가능했던 듯 싶다.

저자는 상위 계층으로 올라가기 위한 도구로 IT라는 직업을 선택한 것이고 이를 위해 최선을 다하다보니 ‘장인’이라는 위치에 다다르게 된 것인지, 아니면 그게 아니었어도 IT라는 직종이 적성에 맞아서 ‘장인’을 추구하게 된 것인지, 둘 다 맞아 떨어진 것인지 책을 통해서는 정확히 파악하기는 힘들다.

개인적으로도 ‘장인’이든 뭐든 우선 본인의 삶의 방향이나 목적이 중요한 것 같다. 즉, 동기가 있어야 한다고 생각한다. 그것이 지적 호기심, 경쟁우위, 존경, 혹은 생계 수단이든 간에 말이다.

회사 생활을 하다보면 같은 개발자이지만 일을 대하는 태도는 다 다르다. 여기에 천편일률적인 기준을 적용하기는 힘들다. 종교가 지배하는 중세시대도 아니고 잘 살아보세를 외치는 산업화 시대도 아니지 않은가. 누군가는 단순히 요구기능을 구현하고 정해진 임금을 받으면 되는 일이고, 누군가는 무언가를 더 알아간다는 재미와 함께 관련된 배경 지식까지도 배울 기회로 삼으면서 코드를 갈고 닦아 놓는다. 맡겨진 일을 뚝딱 끝내고 work & life balance에 맞게 여가를 충분히 다른 일에 즐기는 사람이 있는가 하면, 업무가 끝나고도 관련된 지식을 알아가는데 힘쓰는 사람이 있다.

어떤 것이 옳은가라는 문제는 아니다. 그냥 내 인생을 어디에 좀 더 투자해서 뭘 조금 더 잘 해볼 것인가 라는 선택의 문제이다. 저자는 ‘장인’이라면 조금 더 삶의 목적이 해당분야에 맞춰져 있어야 하고 투자가 이루어져야 한다고 얘기하는 것으로 해석된다.

그리고 당연히 ‘사람’이라면 아마도 ‘장인’이 인생의 최종 목적은 아닐 것이다.

Agile 개발 방법론

agile의 목표는 빠른 피드백이다. 방금 구현한 작은 유닛에 대한 피드백에서부터, 중간 제품에 대한 고객의 피드백까지 빠르게 피드백 받아 수정을 거치는 과정을 최대한 많이 반복해서 소프트웨어 품질을 확보한다.

유행처럼 번졌다. 이거 안하면 구석기 취급받는다. 그런데 해도 구석기를 못 벗어나는 수가 있다.

첫째로 개발자의 문제가 있다. 그렇다. 방법론을 수행하는 절차가 중요한 것이 아니다. 안하고 싶은 사람에게는 무슨 방법론을 들이 밀어도 부정적인 반응과 함께 안돼는 이유가 있고, 잘하고 싶은 사람에게는 어떤 방법론이든 그 나름의 장점을 살려서 좋은 방향으로 진행한다. 또한 개발자의 역량은 agile을 하고 안하고 와는 별개의 문제라는 것이다. 물론 페어프로그래밍을 하면 역량이 전파되는 경향이 있긴 하지만 그것도 촉진재일 뿐이지 역량 향상의 주요 수단은 아니라고 생각한다. 개인 과외시간은 아니지 않은가. 최악의 경우 그냥 다른 사람의 완료 목록에 도움을 주는 것으로 끝나는 경우도 있다. 소프트웨어의 품질에 영향을 주는 인자는 개발 방법론보다는 개발자의 역량이 더 크다고 생각한다.

두번째, 관리자의 문제가 있다. 나의 예전 보스 중 한명은 애자일을 소개하는 자리에서 메니페스토 중 ‘방대한 문서 작업보다는 동작하는 소프트웨어를’ 딱 여기까지 듣고 자리를 박차고 나가버렸다. 내가 소개하는 사람이 아니어서 다행이었을 뿐이다. 현실은 폭포수 모델로 진행하는 것이 보고에 더 적합한 조직문화를 가진 회사들이 많다. 보고가 뭐 대수냐라고 할 수 있다. 그러나 보고 자체가 누군가의 목숨 줄일 수도 있고, 그게 나랑 무슨 상관이라고 생각했던 말단 개발자에게까지 결국 칼이 닿는 수가 없지 않다. 백로그와 번다운차트 외에도 무수히 많은 보고자료를 만들어야 하는 조직문화의 관리자라면 agile을 그리 좋아하지 않는다.

초기부터 큰 설계 vs 최소 요구 만족(MVP)을 통한 점진적인 개발

설계에 대한 측면에 대해 시간이 지나도 계속 의문인 점은 있다. 좋은 소프트웨어의 한 측면인 ‘변화하는 요구사항을 수용할 수 있는 능력’이 과연 최소 요구 사항을 만족하는 과정을 반복하면서 그때그때 수용가능한가. 아니면 적어도 비기능 품질요구를 만족할 수 있는 큰 그림(설계)을 두고 시작하는 더 나은가.

저자는 물론 agile의 열렬한 추종자이기에 전자를 추구한다. 그리고 개인적으로 불필요한 섣부른 과잉 설계(BDUF: big design up-front)나 과잉 엔지니어링을 한 적이 없지 않다. 이것이 개인적인 호기심 때문에 적용해 본 것도 있고, 진짜 그런 일이 벌어질 것이라 예상한 것이 틀린 경우가 있지만 말이다.

그러나 반대로 최소 요구 만족을 통해 점진적인 개발을 한 경우에는 현재 중간중간에 현재 구조에서는 넘을 수 없는 벽을 만나 뒤집어야 하는 경우를 몇번이나 만난 적도 있다는 것이다. 물론 모듈화가 잘 되어 있다면 새로운 구조에 요소요소 잘 끼워 넣는 것이 비교적 수월하다만, 누군가에겐 맨날 뒤집는 사람처럼 보인다. 혹시 agile이 만연화 되어있는 사회라면 시선이 바뀌려나.

모든 것이 범용적이어야 한다는 생각에서 출발하다보면 어느 부분에서 수정이 필요할지 모르기 때문에 모든 부분에서 추상화(복잡도 증대)를 적용하여 복잡도가 증대된다. 이에 반해 실용적인 접근 방법은 실제로 필요한 상황이 생겼을 때만 추상화하여 주어진 문제에만 특정된 코드로 먼저 솔루션을 찾은 후 나중에 필요한 상황이 생겼을 때 범용화하는 방식을 취한다.

이게 양측 다 극단으로 가면 문제 아닌가 싶다. 요즘은 마이크로서비스 패턴을 적용해서 뒤집고 뒤집어도 파장이 크지 않게 할 수 있지만 말이다.

상아탑 아키텍트와 소프트웨어 장인(저자)의 논쟁

저자는 ‘상아탑 아키텍트’는 개발 일정과 최종 개발 산출물에는 책임을 지지 않고 한 발 물러서 있다가 프로젝트가 잘되면 자기 설계가 잘 된 것이고 프로젝트가 잘 못 되면 개발자에게 책임을 전가하는 관료주의적인 존재로 묘사한다.

문제 상황의 예시는 이렇다.

아키텍트가 명시한 기술 스택을 사용하지 않고 모듈 내부에 저자가 더 낫다고 판단한 기술을 적용했다.

과장해서 표현한다면 이런 행동의 근거는 소프트웨어 장인은 ‘나중에 이슈가 나오면 어차피 책임질 사람도 개발자이고, 수습하기 위해 야근할 사람도 개발자이다. 죽으면 죽었지 안되는 꼴은 못본다.’ 라는 책임감으로 미연에 이슈를 방지하기 위함이라는 것이다.

아무리 외부 인터페이스에 영향을 미치지 않는 모듈 내부의 구현이라 하지만 아키텍트와 상의없이 개발자(저자)가 정하여 적용했다. 그리고 결정 사항에 대한 근거를 따로 남기지 않았고 논쟁이 벌어지고 나서야 자초지종을 따져묻는 아키텍트에게 그제서야 근거를 얘기했다.

저자는 이는 내부 모듈 구현의 문제이고 개발자의 영역이라고 주장하지만, 설계를 담당하는 아키텍트가 모듈 내부에 어떤 기술을 적용했는지 파악했다는 것 자체가 이미 뭔가 비기능(품질속성)적인 측면으로 외부로 드러났다는 반증이 아닐까. 그렇게 무책임한 ‘상아탑 아키텍트’가 그 사실을 어떻게 알았을까 말이다.

분명 아키텍트의 역할 중 과제에 적용될 기술 스택을 결정하는 역할이 있고, 규모가 큰 과제에서는 기술 표준화가 어느 수준까지는 필요하다는 사실을 저자도 모르는 바가 아니나, 그것을 뒤집을 만큼의 근거였는지 별다른 설명이 없다. 자칫 항상 반대편에 서는 오만한 슈퍼 개발자인 것은 아닌지 오해의 소지가 있다.

상대가 ‘상아탑 아키텍트’ 곧 절대로 훌륭하지 않은 아키텍트라는 전제와 어떤 극단적인 상황을 예시로 하여 훌륭한 장인정신을 가진 개발자를 강조하고자 한 것이겠지만, 그래도 별로 동의가 되지 않는 부분이다. 차라리 맘대로 적용하기 전에 아키텍트와 협의를 먼저 하는 것이 서로의 역할을 침해하지 않고 과제를 진행하는 방향이 아니었을까.

끝까지 외부로 노출되지 않았으면(안 걸렸으면) 몰라도 아무래도 이건 방어를 가장한 과도한 선제 공격인 것 같다.

각 역할들에게 의미있는 표현

회의를 하다보면 혹은 누군가의 귀를 기울이게 하려면, 상대에게 맞는 용어들을 사용해야 한다. 나에게 의미있는 것들이 상대에게는 별다른 의미가 없는 것일 수도 있다는 점을 개발자들이 흔히 간과하기 쉽다는 점이다.

수집된 데이터 좀 지워달라는 고객의 요구를 검토중이라고 관리자에게 보고하는 자리에서 MongDB의 다큐먼트가 어쩌구 해봤자다. 그냥 관리자에게 본인의 기술적인 전문성을 의도적으로 보여주려는 의도가 있다거나 혹은 기술적인 부분은 참견하지 말라는 의도가 없다면 말이다.

물론 누군가 비지니스 영역과 개발영역 사이에서 통역을 해주는 역할을 맡은 사람이 있을 수도 있지만, 항상 상대가 누구인지에 따라 표현해야 한다.

우선 상위 관리자일 수록 아래 용어로 표현해야 한다.

생산성 향상 / 비용 절감 / 매출 증대 / 일정 준수 / 버그 감소 / 예측 가능한 개발 속도 / 비즈니스 요구사항 충족

만약 사용하는 프레임워크를 바꾼다고 하면, 무슨 ‘기능적인 장점이 더 있다’ 라는 표현보다는 ‘교체 비용이 얼마이지만 그로 인한 기대 효과가 얼마이다.’라고 금액으로 환산해서 얘기하는 것이 낫다는 것이다.

좋은 품질의 SW에 대해서도 역할에 따라 다르게 생각한다.

개발자에게 좋은 SW는 좋은(단순한) 설계, 변수나 함수의 네이밍, 의미 있고 가독성 높은 테스트 코드, 중복이 없고 장황하지 않은 코드이다. 제품 관리자에게 좋은 SW는 요구사항을 모두 만족하고, 버그가 없고, 일정을 준수하는 것이다. 최종 고객에게 좋은 SW는 상용 환경하에서 돈을 벌거나, 돈을 절약하거나, 매출을 지켜주는 것이다.

디자인패턴(GoF)

패턴을 처음 접한 것이 학부4학년이던가. 그 후로 패턴을 적용 안하면 뭔가 이상한 시절을 보냈던 것 같다. 어느샌가 패턴에 크게 얽메이지는 않게 되었는데 좋게 말하면 체화되서 그런 것이고 나쁘게 말하면 그냥 뚝딱 구현한거다.

이 책에서 디자인 패턴에 대해 단점인 측면을 얘기하는 부분은 과잉 엔지니어링에다가 복잡한 솔루션을 유도할 수 있으며 코드가 범용화될 수록 더 복잡한 구조를 유발할 수 있다는 점이다.

비범한 개발자

유명 외식사업 CEO가 어렵다고 알려진 요리를 세상 쉽게 뚝딱 만들어 내면서 레시피를 알려준다거나, 무인도에 간 쉐프가 주어진 재료와 제한된 도구를 가지고 그럴듯한 음식을 만들어 낸다거나 하는 것들을 보면 많은 생각들이 든다.

기본기, 숙달

어려운 문제를 단순하고 우아한 방법으로 풀어내는 것이 비범한 개발자이다. 요구사항을 충족하는 가장 단순한 코드를 만들고, 경험이 적은 개발자가 이해하는 데 아무런 문제가 없도록 한다.

심미적이고 재기 넘치는 코딩은 그냥 재미로만 하자. 시간에 쫓길 때 딱 보고 이해 안되면 나도 모르게 중얼거리는 뭐 그런 거 다 있지 않나.

기교 넘치는 코딩의 제일 그럴 듯한 핑계는 성능이다. 그러나 짠 사람이 제일 잘 알지 않은가. 거기가 bottle neck이 아니라는 것을…