베끼기 학습법

20대 중반, 문과, 복학생. NEXT에서 프로그래밍을 배우기 시작했을때 나의 모습이다. 그야말로 난관이었다. 한번에 쏟아지는 새로운 정보가 버거웠다. 무엇을 모르는지조차 모르는 상태가 지속돼 답답했다. 하지만 시간이 지나면서 내게 맞는 학습법을 점차 익힐 수 있었고 프로그래머로 자리잡는데 많은 도움이 됐다. 누구나 초반에 맞닥뜨리는 난관, 결국 필요한 것은 ‘자신에게 가장 맞는 학습법을 찾는 것’이다. 나에게 가장 잘 맞는 학습법은 베끼기였다.

베끼기의 시작 : 학생들을 멘붕에 빠뜨렸던 프로그래밍 과제

첫 학기가 시작하고 몇 주 지나지 않아 학생들을 멘붕에 빠뜨린 사건이 있었다. ‘자료구조와 알고리즘’ 과목의 실습 수업, 이론 수업 각각의 교수님 사이 커뮤니케이션 실수로 인해 재귀 이론을 배우지 않은 상태에서 ‘하노이의 탑’이 코딩 과제로 나온거다. 그러니까 프로그래밍을 처음 접한지 약 한 달 정도 된 상태에서 재귀의 개념도 모른채 하노이의 탑을 풀어야 했다. 당시에는 그 과제의 무시무시함을 알 길이 없었다. 주말을 보내고 과제 제출일인 월요일에 학교를 왔더니 난리도 아니었다. 문제를 풀려고 집에 안가고 주말 내내 학교에서 먹고 자고 했다는 사람들이 넘쳐났다. 잠을 거의 안 잤다는 사람도 많았고, 다들 초췌했다. 그럼에도 문제를 풀었다는 사람은 거의 없었다. 충격과 공포의 현장이었다.

나는 달랐다. 몇시간 걸리지 않아서 문제를 풀었다. 내가 아는 지식으로 몇번 시도한 뒤 구글 검색으로 해답을 찾은 것이다. 구글링 결과를 그대로 복붙한 것은 아니었고, 해답을 찾은 뒤 한줄 한줄 실행해보면서 풀이를 파악하고 혼자서도 똑같이 작성해볼 수 있을 정도로 익혔다. 그러나 학교에 왔을 때 다른 학생들은 어떻게든 직접 풀어보려고 이틀을 지새웠다니까 괜히 찔리고 내가 뭔가 잘못한 것 같았다. 편법인가 내가 너무 편한 방법으로 공부했나 싶었다. 수학문제를 풀 때 정답을 보면 실력이 늘지 않는다고 말했던 고등학교 선생님이 생각났다.

코드 베끼기 : 뇌가 절전모드일 때는 온라인 강의로 무작정 코드 따라쓰기

하루의 집중력이 소진된 저녁 시간대나 머리쓰기 싫은 날에는 온라인 강의를 들었다. 트리하우스의 유료 멤버십에 가입했고 유데미에서 유료 강좌를 구매했다. 앱 개발 강좌는 보통 이론 설명이 약간 있고 대부분은 강사가 화면에 치는 코드를 보고 따라 치면서 샘플 앱을 완성하는 형식이다. 그래서 머리가 잘 돌아가는 상태면 이런 형식의 강의는 금방 지루해진다. 온라인 강의는 약간 무념무상의 상태일때 활용하기 좋은 공부 수단인 것 같다.

딱히 집중을 하지 않고도 샘플 앱을 여러개 만들고나니 나만의 훌륭한 레퍼런스 코드가 돼있었다. 분명히 언젠가 해본적은 있는데 기억이 안날때, 내가 만들었던 샘플 앱을 열어서 코드를 찾아보고 방법을 다시 익혔다. 어찌됐든 내 손으로 직접 짰던 코드다 보니 원하는걸 빨리 찾을 수 있었고 코드를 보면 기억이 금방 되살아났다. 이렇게 몇 달에 걸쳐 모은 내 샘플 앱들은 개발을 배우기 시작한 후 거의 1년 동안 유용하게 활용됐다.

앱 베끼기 : 잘 만든 앱들을 참고해 따라 만들기

앱스토어 1위를 하게 해준 보안카드 위젯 앱도 베끼는 것으로 시작했다. 다만 앱 하나를 그대로 베낀 것은 아니었다. 여러 앱에서 마음에 드는 부분들을 가져왔다. 특히 UI/UX적인 부분에서는 애플 기본 앱이나 잘 만든 다른 앱을 보고 따라했다. 예를 들어 알림센터에서 보안카드를 조회하는 화면을 만들때는 위젯을 지원하는 계산기 앱을 여러 개 깔아보고 제일 나은 키패드 UI를 가져왔다. 잘 만든 앱을 따라 만들다보면 나만의 아이디어가 생겨나기도 하고 혼자서는 생각해내지 못했을 방법으로 개발을 하면서 실력이 는다.

베끼기와 찰떡 궁합 : 응용하고 반복하기

다행스럽게도 시간이 흐를수록 나의 코딩 실력은 꾸준히 늘었다. 모범 답안(best practice)을 찾아보고 필요하면 베낀뒤 나의 것으로 만들었다. 베끼기는 나와 잘 맞는 학습법이었다. 애초에 엉덩이가 무겁지 못한 측면도 있고 새로운걸 배울 때 앞선 사람들이 개척해놓은 최적의 방법을 따라하거나 나보다 잘하는 사람을 보고 모방하는 방식으로 초기 지식을 습득해왔다는걸 깨달았다. 가령 어떤 게임을 처음 시작할 때도 직접 삽질하기보다는 공략을 찾아보고, 잘하는 게이머의 영상을 보고 따라하면서 익히는게 더 재밌었다. 중요한건 처음에는 그렇게 베껴서 따라하더라도 패턴을 발견하고 원리를 파악한 이후부터는 금세 응용해 나만의 방식을 찾아낸다. 프로그래밍도 다르지 않다. 패턴이 있다. ‘소프트웨어 디자인 패턴’ 이라는게 존재하듯 특정 문제를 푸는 방법을 익히면 그걸 약간 응용해서 다른 문제도 풀 수 있게 되는 것 같다.

프로그래밍은 운동을 배우는 것과 비슷한 측면이 있어서 머리로는 이해했어도 직접 손으로 반복해서 훈련하지 않으면 내 것이 될 수 없다. 금방 까먹고 스스로 할 수 없는 상태가 지속된다. 무념무상으로 따라했던 온라인 강의지만 반복하다보니 강의를 따라 만든 앱이 20개가 넘어있었다. 사실 샘플 앱도 두어개 정도 만들고 나면 그 다음부터는 중복되는 내용이 많다. 스토리보드에서 뷰컨트롤러를 만들고 클래스를 만들어서 지정해주고 IBOutlet/IBAction을 연결하는걸 수도 없이 반복하게 된다. 하지만 이렇게 여러번 반복을 하다보니 언젠가부터는 눈보다 손이 먼저 움직이기 시작했다. 강사보다 빨리 개발을 끝내고 영상이 나를 따라잡기를 기다리던 순간은 쾌감있었다. 처음에는 보고 베끼는 것이었지만 반복하다보니 나의 근육 기억이 됐다.

🥑 현업 생존 전략 1 : 잘하는 사람이 개발하는 모습 따라하기

‘베끼기 학습법’은 현업에 와서도 자연스럽게 나의 성장 방법으로 자리잡았다. 그래서 첫 직장에서 옆자리에 앉은 사수님이 본인 개발하는 모습을 지켜보게 해주셨던 것이 너무 좋았고 나에게는 행운이었다. IDE에서 창을 왔다갔다 하는 모습, 소스 파일을 열었다가 닫는 방식, 자주 사용되는 단축키, 디버깅 툴은 어떻게 쓰는지, 코드를 작성하거나 고치다가 막혔을때 어떻게 헤쳐나가는지 그런 행동을 보고 따라하면서 엄청 많이 배웠다.

또 Xcode에서는 소스 파일을 생성한 사람의 아이디가 주석으로 남게 되는데 멘토님 아이디로 프로젝트 전체 검색을 돌려서 멘토님이 작성한 코드를 모으고 따라해볼 만한 코드가 없을까 찾아보고 이리저리 뜯어보면서 공부했다. 그러면서 습득한 지식이나 발견한 새로운 패턴이 내 기존의 것들과 융합이 되기도 하고 대체되기도 하면서 배움이 일어났다.

🥑 현업 생존 전략 2 : 회고 노트 만들기

프로그래밍을 배우는 와중에 반복적으로 좌절감이 찾아올 때가 있었다. 분명 여러번 했었던 건데도 다시 하려고 하면 기억이 잘 안나고 손이 키보드에서 잘 안 움직였다. 하는 방법을 다시 찾아보려고 해도 어디서부터 찾아봐야 하는지조차 기억이 안났다. 그래서 언젠가부터 회고 노트를 쓰기 시작했다. 처음에는 자유 형식으로 쓰기 시작했는데 쓰다보니 일정한 포맷을 갖추기 시작했다. (1) 하려고 했던 것, (2) 해결한 방법, (3) 새로 배운점 혹은 잘 안되고 막혔던 것 을 기록했다. 코드가 많이 들어갔는데 코드도 다 손으로 썼다. 공책을 첫 장부터 쓰기 시작해서 마지막 장까지 다 쓴 건 살면서 처음이었던 것 같다. 샘플 앱과 마찬가지로 이 공부용 회고 노트도 거의 1년 동안 너덜너덜해질 정도로 자주 들춰봤다. 그만큼 프로그래밍 처음 배울때는 단번에 익혀지는게 거의 없고 똑같은걸 수십번 반복해봐야 겨우 내 것으로 소화가 된다.

프로그래밍 공부할 때 회고 노트의 도움을 굉장히 많이 받았기 때문에 현업에 와서도 이어서 했다. 업무를 하면서 새로 배운 것, 특히 처음에는 막혔다가 해결한 것을 중점적으로 기록했다. 공부용 노트와 마찬가지로 업무용 회고 노트도 들춰볼 일이 자주 생겼다. 근데 문득 돌이켜보니 2년차부터는 회고 노트를 안쓰게 됐다. 다시 시작해볼지 고민을 해봐야겠다.

‏‏‎마치며

마지막으로 프로그래밍의 재미를 찾는게 장기적인 동기부여 차원에서 큰 도움이 된다. 1년 정도 개발을 배운 시점에 슬럼프가 찾아왔다. 수업에서 시키는 것들은 얼추 할만한거 같은데, 왠지 재미가 없었다. 없친대 덮친 격으로 html/css를 하다가 개발을 영영 포기할 뻔한 순간까지 갔었다. NEXT를 계속 다닐 것인지, 포기하고 대학교로 돌아갈 것인지 선택의 기로에 있었다.

다행히 모바일 앱 개발을 접하고 나서 상황이 바꼈다. 앱 개발은 흥미진진했고, 때마침 창업 전공이 새로 생겨서 마음 맞는 친구들과 팀을 만들어서 ‘무엇’을 만들지부터 같이 정하면서 개발하는 과정이 너무 즐거웠다. 뭐가 재밌는지도 사람마다 다를 것이다. 특히 초심자들은 본인의 흥미과 호기심을 자극하는 개발 분야를 찾아서 재밌게 개발을 배울 수 있기를 응원한다.

이 글의 초안을 읽어준 조소현, 류성두 님에게 고마움을 전합니다.

Tags: learning to program, mooc, next institute  

[번역] 초짜가 된 기분

원문: Paul Graham의 Being a Noob

어렸을 때는 나이가 들면 모든걸 알게 되겠지 생각했다. 막상 내가 나이 들어 보니 전혀 그렇지 않다.

요새 여러 방면에서 초짜가 된 기분이 자주 든다. 창업자들과 얘기를 나누면 그 분야에 대해 전혀 모르겠고, 읽는 책의 주제는 생소하고, 새로운 나라에 가보면 당최 일이 어떻게 돌아가는지 모르겠다.

초짜로 돌아간 기분은 썩 달갑지 않다. 초짜라는 단어도 별로 좋은 뜻이 아니다. 그런데 오늘, 초짜가 되는 것에 담긴 긍정적인 의미를 깨달았다. 가까이서 봤을때는 초짜처럼 보일지언정, 멀리서 보면 덜 초짜라는 것이다.

예를 들어 당신이 고향을 떠나 머나먼나라로 여행을 떠난다면 처음에는 낯선 곳에서 자신이 더 바보같고 어색하고 이방인처럼 느껴질 것이다. 그러나 막상 가보면 고향에 남았을 때보다 훨씬 많은걸 보고 배울수 있다. 그러니 초짜가 되는 것과 무지(無知)는 음의 상관관계이다.

근데 새로운 분야에서 초보가 돼보는 것이 실제로 우리에게 좋은 거라면, 우리는 왜 그 느낌이 싫은걸까? 그런 거부감이 대체 어떤 진화론적 의미가 있는걸까?

내 생각에 초짜가 된 기분을 느끼는 원인은 두 종류가 있다. 무지할 때와 새로운 것을 시도할 때. 내가 초짜일 때 느끼는 불편함은 우리의 뇌가 ‘어서 빨리 상황을 좀 파악해봐’라고 명령하는 것이다. 인류의 역사를 돌이켜 봤을때 옛날에는 주변 상황을 빨리 파악해서 위험으로부터 벗어나는게 생존에 유리했다. 수렵/채집 생활을 하던 인류도 자신의 인생은 복잡하다고 생각했겠지만 오늘날만큼 주변 상황이 빠르게 바뀌지는 않았다. 어느날 갑자기 암호화폐를 어떻게 받아들여야 할지 결정할 일은 없었다. 그러니 옛날에는 새로운 문제를 발견하는 능력보다는 당장의 배고픔을 해결하는 편이 생존에 유리했다. 식량이 부족했던 시대에 배고픔을 경계했던 것 때문에 인간은 초짜가 된 느낌을 경계하게 된 것이다.

이제는 도리어 식량이 넘쳐나서 문제인 시대에, 배고픔을 두려워하는건 엉뚱하다. 초짜가 된 느낌을 두려워하는 것도 마찬가지다.

새로운 걸 시도할때는 처음엔 불편한 느낌도 들고 우스갯거리가 될 것 같은 두려움이 들기도 한다. 하지만 당신이 초짜가 된 느낌을 자주 느낄수록, 더 좋다.

Tags: being a noob, paul graham  

자연의 코드

지난주 하루는 퇴근하고 넥스트 스승님들이 계신 코드스쿼드에 방문해서 프로그래밍을 배우고 있는 분들과 공부법, 취업, 면접 등등 나의 경험을 공유하고 잡담도 하고 질문도 받는 시간을 가졌다. 질의응답을 하던 와중에 내가 ‘자연의 코드’라는 단어를 사용했다. 네이버 핵데이에 멘토로 여러 번 참여하면서 멘티 분들의 코드를 봤을때 그렇게 느꼈다는 말이었다. (핵데이 멘티들 중에 인턴 합격한 사람도 있고 못한 사람도 있지만 결국 대부분 취업도 잘했고, 비록 아깝게 면접에 떨어진 분들도 결코 실력이 떨어지지 않는다. 그들이 개발을 못한다는 말이 아님). 그랬는데 어떤 분이 ‘자연의 코드’가 어떤 의미인지 더 자세히 말해달라고 했고, 즉흥적으로 내뱉은 단어인 탓에 설명이 좀 부족했던 것 같다. 그래서 이 글을 통해 다시 정리해봤다.

코드 생김새

멘토님의 표현을 빌리자면, “코드를 읽지 않고 생긴 윤곽만 봐도 기본이 안된 코드는 걸러낼 수 있다”. 소스코드를 딱 열어보면 정리가 필요해보인다는 느낌이 드는 경우가 있다. 그 이유는 거창한게 아니라 줄바꿈, 띄어쓰기, 메서드나 프로퍼티의 순서 등이 일관성이 없기 때문이다. 코드도 글의 일종이고 결국 사람이 그걸 읽는다. 글이 적절한 크기의 문단으로 나뉘어져 있고 논리적인 흐름이 일관되면 읽기 수월한 것처럼 코드도 시각적으로 보이는 생김새/윤곽이 가독성에 영향을 준다. 예를 들어,

👇 삐쭉삐쭉한 코드 예시

func doSomething() {

  let blah = ...
  for item in items {
    print(item.name)

  }


}
var myData: [String: Data]

private func somethingElse() -> String {
  return "Hello World"
}
func justDoIt() {
  // whatever..
}

👇 그나마 정돈된 코드 예시

var myData: [String: Data]

func doSomething() {
  let blah = ...

  for item in items {
    print(item.name)
  }
}

func justDoIt() {
  // whatever..
}

private func somethingElse() -> String {
  return "Hello World"
}

개발자마다 선호하는 줄바꿈 스타일이 다르긴 하지만, 최소한 하나의 파일 내에서는 일관성을 지키는게 좋다. 코드의 생김새가 들쭉날쭉하면 코드를 해석할 때 들어가는 시각적인 부하가 커져서 눈도 아프다. 물론 핵데이니까 시간이 부족해서 평소보다 정리를 더 못한 것일 수도 있다. 나도 멘토님에게 처절한 코드 리뷰를 받았었다. 엔터 하나도 목적없이 허투루 치지 말라고.

또한 메서드나 프로퍼티 선언 순서도 정리의 대상이 될 수 있다. 가장 흔한 정렬 방법은 IBOutlet과 프로퍼티를 먼저 선언하고 메서드를 그 뒤에 이어서 선언하는 방식일 것이다(프로퍼티 - 메서드 순). 하지만 멘토님께서 클래스 내부 코드의 순서를 통해서도 개발자의 의도를 담을 수 있다고 알려주셨다. 개발자가 소스파일을 열어보는 이유는 그 클래스가 무슨 일을 하고 이걸 어떻게 사용하는지 알기 위해서일 것이다. 그래서 클래스에 대해 알고 싶은 사람이 가장 먼저 알아야 할 public 프로퍼티나 메서드가 맨 위에 있으면 파일을 열자마자 바로 보이기 때문에 쉽고 빠르게 정체를 파악할 수 있다. 만약 내부 동작까지 궁금하다면 점점 스크롤을 내려가면서 private 프로퍼티나 메서드를 참고하면 된다(public - private 순). 멘토님에게서 이런 리뷰를 받고 나서 고민해보고 오랫동안 이렇게 저렇게 시도해보면서 나름의 규칙을 정립하게 되었다. 그래서 나는 public 프로퍼티 - public 메서드 - private 메서드 - private 프로퍼티/IBOutlet 순으로 코드를 정리한다(샘플 앱 참고). IBOutlet이나 프로퍼티가 맨 밑에 있는 것이 처음에는 어색하기도 했지만, public 프로퍼티/메서드를 맨 위에 두는 장점을 살리면서 시각적으로도 정돈된 윤곽을 유지할 수 있다. 동료들도 딱히 거부감을 표현하지 않아서 고수하고 있다. 새로 가게 될 팀에서는 어떨런지. 이것도 정답은 없다. 자신의 기준을 세우고, 일관성 있게 적용하면 될 것 같다.

잘못된/생소한 구조

핵데이 멘토링하면서 상속을 잘못 쓴 코드를 많이 봤다. 객체 지향 프로그래밍을 처음 배울때 코드 재사용을 위해 상속을 사용한다고 배우기도 했고, 예제를 여러 개 보다보면 상속이 객체 지향 프로그래밍의 정점인 것처럼 느껴지기도 한다. 하지만 알고 보니 객체 지향 프로그래밍에서 가장 어려운 것이 상속이었다. 오죽하면 ‘상속을 잘 쓰는 방법은 상속을 쓰지 않는 것이다’라는 우스갯소리도 있고 상속보다는 구성(Composition over inheritance)이라는 OOP 원칙도 존재한다.

다음으로 자주 보는 것은 생소한 객체 간 정보 전달 방식(inter-object communication)이다. iOS 에서는 객체 간 정보를 전달할 때 쓰는 몇 가지 패턴이 있다. Delegate 패턴, NotificationCenter, Key-Value Observing, Closure를 전달하는 방법 등 네 가지 정도 사용할 수 있다. 정확한 코드는 기억이 안나지만 특이한 방법으로 데이터를 주고 받는 코드를 본 적이 있다. 당장에 원하는대로 작동은 할 수 있지만 iOS 컨포넌트들과 어울리지 않으면 나중에 코드 수정이 필요할 때 문제가 생길 수 있고 무엇보다 다른 iOS 개발자가 봤을 때 불필요하게 해석이 오래 걸리게 된다.

Human Interface Guidelines 위배

앞에 두 개에 비해서는 비중이 낮지만 iOS 개발자라면 HIG를 잘 알아야 한다고 생각한다. 핵데이 특성상 디자이너나 기획자 없이 개발자 본인이 앱의 UI/UX를 신경써야 하는데, 가끔씩 기묘한 플로우를 맞닥뜨릴 때가 있었다. 예를 들어 뷰컨트롤러 간의 이동은 크게 모달과 푸시 두 가지가 있는데 상황에 맞게 적절히 써줘야한다. 만약에 뷰컨트롤러를 모달로 띄웠다면 모달 작업이 끝난 후에는 해당 뷰컨트롤러를 dismiss 해줘서 원래 있던 뷰컨트롤러로 돌아가야한다. 그런데 모달 작업이 끝난 후 dismiss를 안하고 아래 깔려 있는 뷰컨의 새로운 인스턴스를 만들어서 또다시 모달로 띄우는 플로우를 본 적이 있다.

마무리

거창한 개발 지식도 아니고 엄청난 내공이 담긴 내용도 아니고, 단지 신입 개발자보다 고작 한 단계 앞에 있는 개발자가 올챙이적 시절을 돌이켜보며 쓴 글이다.

Tags: ios, swift, readable code  

기술 부채도 자산인 이유

경영학과 전공자라면 반드시 들어야 하는 수업이 있다. 회계원리와 재무관리. 나는 이쪽 수업이 너무 재미 없어서 필수 과목만 최소한으로 수강했다. 비록 암기했던 것들은 다 사라졌지만 중요한 하나는 남아있다.

자산 = 부채 + 자본

기업은 소유하고 있는 경제적 자원을 관리하기 위해 재무상태표를 작성한다. 재무상태표란 간단히 말하자면 회사의 가계부라고 볼 수 있다. 다만 들어온 돈(수입)과 나간 돈(지출)만 기록하는 가계부와는 달리 재무상태표는 복식부기 방식으로 기록한다. 복식부기란 거래가 발생했을 때 상호대응 되는 두 개 항목을 동시에 기입하는 방식이다. 상태표의 왼쪽에는 자산에 해당하는 항목, 오른쪽에는 부채와 자본에 해당하는 항목을 기록한다. 그래서 항상 왼쪽의 총합과 오른쪽의 총합이 같게 유지되어야 한다. 따라서 회계적인 관점에서 보면 언제나 자산 = 부채 + 자본 이라는 등식이 성립한다.

기술 부채에 대한 생각이 바뀌다

기술 부채란 뭘까? 일명 스파게티 코드라고 부르는 구조화되어 있지 않은 코드 형태, 기능 수정이나 추가가 힘든 코드, 영향 범위를 파악하기 힘든 사이드 이펙트를 내재하고 있는 부분 등을 보면 개발자는 기술 부채가 있다고 느낀다. 이럴 때 보통 “기술 부채를 갚아야 한다”, “기술 부채가 너무 쌓였다”, “올해는 기술 부채를 좀 청산하자” 등의 표현을 사용한다. 이런 말을 종종 듣다보니 기술 부채는 무조건 없애거나 줄여야 하는 나쁜 대상으로만 인식하고 있었다.

그러던 어느날 팀원이 공유해준 블로그에서 ‘기술 부채가 발생하면서 남는 리소스를 다른 곳에 투자할 수 있다’는 문장을 봤다. 그때 회계 수업에서 배웠던 자산 = 부채 + 자본 등식이 생각났다. 부채에는 자산의 측면도 있다는걸 잊고 있었다. 그렇다면 기술 부채에도 자산의 측면이 있을까란 궁금증이 생겼다. 있다면 과연 어떤 종류의 자산일까. 그건 바로 시간이 아닐까란 생각을 했다.

부채가 무조건 나쁘기만 한 건 아니라는 마인드

현실 세계에서 부채가 없는 회사는 거의 없다. 그리고 더 중요한 사실은 부채가 없다는 것이 썩 좋기만 한 것도 아니라는 점이다. 회사에게 자산이란 생산 활동(돈 벌기)에 도움이 되는 것들을 의미한다. 자산이 많아야 생산도 많이 할 수 있다. 그래서 일반적으로 기업은 적절히 부채를 늘려 자산을 늘린다. 예를 들어 은행에서 대출을 받거나 회사채를 발행하여 현금을 확보한다. 물론 골목 가게처럼 규모가 작은 사업체는 빚이 아예 없을 수도 있다. 하지만 그런만큼 성장성도 낮다. 성장하기 위해 부채를 적절히 사용하면 좋은 것이다.

회사를 개발팀으로 치환해봐도 비슷하다. 개인 프로젝트가 아닌 이상 현실적으로 기술 부채를 만들지 않고 개발을 할 순 없다. 촉박한 마감일에 맞춰 개발을 하다보면 기술 부채가 쌓이게 되는데, 그 대신 사업적인 성과를 낼 수 있게 된다. 보통 연휴 기간에 매출이 높기 때문에 기술 부채가 생기더라도 연휴 시작 전에 출시하는 것이 좋을 것이다. 또한 확장의 시기에는 경쟁자보다 먼저 시장에 진입해 사용자를 확보하기 위해 빠르게 개발하는게 성장에 더 좋을 수 있다. 이런식으로 기술 부채를 짊어지는 대신 시간을 벌 수 있고, 그 시간으로 매출을 내거나 양적 성장을 이룰 수 있다.

스파게티 코드를 보면 찌푸려졌었고 어떻게든 빨리 없애야하는 나쁘기만한 존재라고 생각했다. 하지만 자산의 측면도 있다고 생각하니 적절한 관리감독이 필요한 대상으로 인식하기 시작했다. 다만 남이 진 부채를 내가 대신 상환하고 있는 느낌이 들 때도 있다. 또 그러나 내가 만든 기술 부채도 다른 누군가가 갚고 있겠지.

기술 부채는 어떻게 관리해야 하지?

“측정할 수 없는 것은 관리할 수 없다” - 피터 드러커

그렇다고 무작정 기술 부채를 늘리기만 할 수도 없다. 기술 부채를 갚지 않고 늘리기만 하면 팀 전체의 개발 속도가 느려지고 좀비처럼 되살아나는 버그로 인해 사용자와 개발자 모두 고통 받게 된다. 개발 생산성이 낮아지면 결국 사업도 부정적인 영향을 받는다. 다만 금융 부채와 기술 부채의 가장 큰 차이점은 기술 부채는 세는 단위가 없기 때문에 정확한 양을 알 수 없다는 점일 것이다. 근데 피터 드러커는 측정할 수 없는 것은 관리할 수 없다고 했다. 기술 부채를 관리하고 싶다면 어떻게든 수치로 나타내야 한다.

엉클밥은 애자일 포인트를 제시했다. 개발 업무별로 각각 예상되는 투입 리소스에 따라 포인트를 부여하고, 개발팀이 총 몇 포인트만큼의 일을 완료하는지 스프린트 단위로 그 추이를 보는 것이다. 스프린트마다 쌓는 포인트가 점점 줄기 시작하면 기술 부채로 인해 개발 속도가 느려지는 것이므로 코드 리팩토링을 해서 기술 부채를 청산해야할 타이밍이라고 한다. 애자일 포인트는 기술 부채로 인해 야기되는 개발 속도 저하를 추적하는 간접적인 지표인 것 같다. 좀 더 직접적으로는 코드 정적 분석을 통해 도출하는 지표들도 있다. 반복되는 코드가 얼마나 많은지, 클래스/프레임워크 간의 디펜던시가 얼마나 복잡한지 등등. 어떤 것을 쓰든 정답은 없으므로 아마도 상황에 맞게, 팀에 맞게 써야하지 않을까 싶다. 아직 관련 경험이 부족하여 상상만 할 뿐이다.

경영 ≈ 개발

기술 부채에 대해 부정적인 말만 듣다보니 무작정 안좋은 것이라고만 생각했었는데 기술 부채를 회계적인 부채랑 비교해보니 조금 다르게 바라보게 됐다. 또한 기업을 경영하는 것과 개발 팀을 운영하는 것이 비슷한 점이 많아 보인다. 부채 없이 사업을 할 순 없지만 부채가 너무 많이 쌓여서 상환하지 못하면 파산한다. 마찬가지로 기술 부채 없는 개발팀은 존재하지 않지만, 제대로 관리하지 못하면 주저 앉는다. 버그 투성이 프로그램 때문에 사용자가 고통받을 수도 있고 사용자가(또는 지친 개발자마저) 아예 떠나버릴 수도 있다. 도저히 부채 청산이 안되면 코드를 전부 버리고 아예 처음부터 다시 개발해야 할 수도 있다. 결국 경영이든 개발이든 부채를 잘 관리해서 조직에 유익한 방향으로 활용하는 것이 중요하다는 생각이 든다.

이 글의 초안을 읽어준 조소현, 김결에게 고마움을 전합니다.

Tags: technical debt