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

코드 생김새

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

👇 삐쭉삐쭉한 코드 예시

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를 안하고 아래 깔려 있는 뷰컨의 새로운 인스턴스를 만들어서 또다시 모달로 띄우는 플로우를 본 적이 있다.

마무리

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

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

자산 = 부채 + 자본

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

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

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

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

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

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

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

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

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

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

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

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

경영 ≈ 개발

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

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

시리 응답이 웰케 애잔하냐...

배경

올해 초 젠킨스 CI 서버 구축을 처음 해봤고, 그걸 계기로 자동화에 관심이 생겨 일 년 동안 틈틈이 팀 내 배포/개발 프로세스를 개선시켜왔다. 사실 관심이 생겼다는 말은 빈약한 표현이고 나는 내가 이 정도로 의미없는 반복 작업을 싫어하는 사람인줄 몰랐다. 아무 생각없이 할 수 있는 반복 작업도 가끔씩하면 정신 건강에 좋다고 생각했었다. 하지만 개발 프로세스에 녹아있던 수작업이 하기 싫어서 어떻게든 자동화할 방법을 찾아서 팀원들을 설득하고 바꿔버렸다. 그리하여 여러 사람의 손을 거쳐야했던 반복적이고 귀찮은 작업을 대부분 자동화했고, 이제는 시리도 우리 앱을 배포할 수 있을 정도로 간단해졌다.

사전 준비

일단은 당연하게도 앱 배포 단계가 자동화되어 있어야 한다. 팀마다 다르겠지만 보통 앱 배포는 최소한 버전업, 빌드, dSYM 처리(크래시 수집 툴에 업로드)를 해야하고 앱스토어용으로 스크린샷 생성하거나 사내 배포용 엔터프라이즈 앱이라면 빌드 결과물을 사내 인프라에 업로드하는 등의 일련의 작업이 있다.

배포 자동화에 큰 도움이 된 것이 fastlane이다. 가독성 좋은 API를 써서 빌드 스크립트를 쉽게 만들 수 있다. 오픈소스 플랫폼이라 여러 사람들이 만든 다양한 플러그인도 있어서 안되는 것이 거의 없다. 특히, xcconfig 파일을 수정할 수도 있고 git 작업도 쉽게 할 수 있고 필요에 따라서는 쉘 스크립트를 추가할 수도 있다. 도입하고 나면 fastlane 명령어 한 줄만으로 배포를 할 수 있게 된다.

그리고 빌드 서버가 필요하다. 요즘은 클라우드 기반 CI 서비스가 많다. 개발자 컨퍼런스를 가봐도 CI 서비스를 하는 스타트업에서 꼭 부스를 운영하고 홍보한다. travis-ci, circleci, bitrise 등이 있지만 이 글에서는 자체 서버를 구축해야하는 무료 CI 인 Jenkins를 기준으로 설명한다.

시리 숏컷 연동

사실 시리를 연동하는 단계는 가장 쉬운 단계이다. CI 서버를 통해 배포를 자동화하는 “사전 준비”에 99%의 시간과 노력이 들어간다. 실제로도 프로세스 자동화는 1년 내내 작업했고 시리 연동은 반나절 밖에 안걸렸다. 가장 이상적으로는 젠킨스 job의 Build Now 버튼만 클릭하면 앱이 배포되는 것이다.

배포 시나리오가 완성되면, 젠킨스 job의 설정에 들어가서 Build Trigger에서 Trigger builds remotely를 체크하고 토큰 값을 지정해준다.

그러면 이제부터 http://JENKINS_URL/job/JOB_NAME/build?token=TOKEN_NAME으로 POST를 날려주기만 하면 배포가 실행된다. 하지만 이대로는 http 통신할 때 젠킨스 서버 authentication을 처리해줘야 하는데 귀찮다면 Build Authorization Token Root 플러그인을 사용하면 위에 지정해준 토큰만으로 접근할 수 있다.

이렇게 젠킨스 플러그인까지 설치해줬다면 아래 명령어를 터미널에 입력하면 배포가 시작된다.

> curl -X POST http://JENKINS_URL/buildByToken/build?job=JOB_NAME&token=TOKEN_NAME

여기까지만 해줘도 배포가 훨씬 덜 귀찮은 작업이 됐다. 하지만 시리 숏컷이 처음 나왔을때부터 시리한테 배포를 시켜보는 것이 로망이었기 때문에 한 단계 더 가봤다. 아이폰에서 시리 숏컷(단축어) 앱을 실행하여 숏컷을 하나 생성한다. 아래처럼 Get Contents of URL 에다가 배포 URL을 넣고 POST를 선택해주고 내가 원하는 명령어를 입력해주면 끝이다.

느낀점

시리 숏컷 연동 자체는 엄청 쉬웠지만 하고나니 일년 동안 꾸준히 개발 프로세스를 자동화하고 개선해온 것에 대한 결실을 맺은 기분이었다. 만약 배포 프로세스가 올해 초의 상태였다면 시리 배포는 너무 멀거나 불가능하게 느껴졌을 것이다. 레츠스위프트 판교 1차 모임에서 전수열 발표자님이 ‘처음부터 의존성이 완벽하게 주입된 코드를 짜야겠다고 생각하지 말고 어제보다 조금이라도 더 나은 상태로 만들면 된다’고 했던 말이 인상 깊었다. 그런데 시리까지 연동하고 나니 그 경험을 조금이나마 해본 것 같다. 자동화하기 좋은 방식으로 프로세스를 바꾸고, 하나씩 조금씩 자동화를 해서 어제보다 조금 덜 귀찮게 만들다보니 여기까지 올 수 있었던 것 같다.

시리 숏컷도 처음 써봤는데 상상 이상으로 잘 만들어져 있어서 놀라웠다. 간단한 인터페이스로 할 수 있는 일이 무궁무진하다. 심지어 if문, 반복문, 변수 할당, 사용자 인풋 받기, 얼럿 띄우기 등등이 가능해서 흡사 앱 개발처럼 느껴진다. 친구한테 알려주니 우스갯소리로 스크래치말고 시리 숏컷으로 프로그래밍 배워야하는거 아니냐고 그랬는데 정말 불가능한 일도 아닌거 같다. 때마침 긱뉴스에서 No Code is New Programming라는 글을 읽게 되었는데, API가 정말 고도화되면 맨 마지막 단계에서는 코드 없는 인터페이스가 탄생한다는 것이고 이게 프로그래밍의 미래 모습이라는 것이다. 시리 숏컷이 이런 개념에 포함되는게 아닌가 싶다. 글이 배포 자동화로 시작해서 시리 숏컷 찬양으로 끝나게 되었는데, 시리 숏컷이 단순히 내 아이폰에 있는 앱을 실행시켜주는게 다가 아니라 여러 API(앱)를 코드 없이 조합할 수 있게 해준다는 것에 큰 영감을 얻게 되었다.

"알겠습니다.."가 너무 애잔하여 응답을 바꿨다.