brunch

매거진 나 요즘 이런 책 읽어

라이킷 10 댓글 2

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 백미진 Mijin Baek Mar 21. 2017

The Nature of SW Development

간결하게, 가치있게, 하나씩 완성하기

이 책이 나오고 출판사에서 선물을 받았다.

현업에서 애자일을 시도하고, 실험하고, 계속하기 때문이라는 이유가 가장 컸을 것이다.

심플한 표지 사이로 론 제프리스(Ron Jeffries)라는 이름이 눈에 띈다.

Agile Manifesto에도 참여했고, XP(Extreme Programming) 창시자 중 한 명인 그 사람.

최근에 우연히 Agile Manifesto에 참여한 사람들이 직/간접적으로 관련된 책을 접할 일이 생기고 있다. 신기하고 또 재밌는 우연이다.

목차를 보니 무려 Part 1의 제목에 "가치"라는 단어가 나온다.

접해본 사람은 알겠지만, 소프트웨어 개발에 있어 가치(value)라는 단어가 나오면 과장을 조금 보태 100% 애자일과 관련된 내용이다. 가치 다음으로 많이 나오는 단어가 피처(feature)지 아마...

추정은 위험해

추정에 대해서는 항상 말이 많다. 정확한 추정이란 것이 있을 수 있는지도 잘 모르겠다.

다만 혼자 일하는 게 아닌 이상, 플래닝을 하는 그 순간에 '어떤 일을 해야하는지, 이 일을 하는데 얼마나 걸리겠다' 정도는 하고 넘어가야 2주 동안 동료 누구와 어떤 일이 엮이는지, 이게 얼마나 걸리는지 예상을 할 수 있다. 그 후엔 실제 일을 해서 결과물을 내놓는 데 최선을 다하는 게 좋을 것 같다. 변수는 언제든 생기게 마련이고, 특히 필드 이슈를 같이 봐야 하는 조직에서는 추정은 의미를 갖기 힘드니까.

다만 관리자가 추정을 너무 정확히 하려고 하면 팀원들은 침해받는다는 느낌이 들기 때문에 추정치를 보수적으로 잡을 수밖에 없다.

과욕은 금물

1년짜리 프로젝트의 1년 치 계획을 한 번에 세운다는 게 가능한 걸까?

아주 촘촘하게 잘 계획을 세운다고 해도 시장이 어떻게 변화할지 모르고, 더 좋은 기술이 매일같이 쏟아지고 프로젝트 멤버에게 어떤 상황이 발생할지 모르는 노릇이다. 앞으로 변화할 수 있는 상황에 대한 변수는 예측이 불가능한데, 미리 세운 계획대로만 하면 1년 뒤에 이 프로젝트는 정말 성공할 수 있을까?

애자일은 대기업에서도 관심을 많이 두는데, 요즘엔 특히 자동차 회사에서 핫하다. 이유는 "변화에 유연하게"라는 말 때문이라고 생각한다.

5년 이상의 장기 프로젝트로 진행하는 자동차 업계에서는 프로젝트가 진행되는 5년이란 시간 동안 변화하는 요구사항을 반영하고 싶어 할 것이다. 그래서 아무 때나 요구사항을 바꾸고 싶어서 애자일을 원한다.

사실 그게 무엇이든 내가 어떤 입장에 서 있느냐에 따라 해석하기 나름일 것이다. "변화에 유연하게"라는 말 또한 마찬가지다. 협력업체에 일을 주는 기업 입장이라면 처음에 범위를 잘 못 잡은 요구사항, 당장 개발할 때가 되니 이제서야 군데군데 빠진 것이 눈에 보이는 요구사항을 더 채워 넣고 싶을 것이고, 개발자라면 일정에 배포하려고 보니 처음에 계획했던 것은 도저히 무리라고 판단되는 순간 요구사항을 빼고 싶겠지.

내가 어떤 쪽의 입장에 서 있든, 프로젝트를 하려면 큰 그림을 그리는 계획은 꼭 필요하다.

우리가 어디로 가야 하는지 방향이 되어줄 테니까.

다만 각각을 어떻게 처리해나갈지는 상황이 반영되어야 한다. 1년짜리 계획은 그 시점의 상황에 맞춰진 계획이다. 애자일에서 말하는 "변화에 유연하게"라는 말은, 큰 틀을 잡아둔 기조 하에서 디테일한 내용이 시시각각 변하는 상황에 융통성 있게 대처할 수 있다는 뜻으로 해석해야 한다.

애초에 계획 없이 시작해서 되는대로 진행한다는 말이 아니라고..

바퀴벌레같은 버그

일하면서 DoD(Definition of Done)라는 말을 자주 쓴다. 내가 만든 코드의 완료 조건은 반드시 테스트 케이스여야 한다고 말한다.

간혹 테스트는 QE의 일이니 개발자는 코드를 생성하는 일에만 집중하겠다고 하는 사람들을 마주친다.

"그럼 너님이 만든 코드가 제대로 만들어졌는지, 요구사항대로 완성됐는지는 어떻게 알 수 있죠?"

가끔 몇 달이 걸려도 해결되지 않는 버그를 마주할 때가 있다. 일단 눈에 보이는 현상은 고쳤는데 근본 원인을 찾지 못해 같은 곳에서 비슷한 이슈가 계속 생긴다. 혹은 서로 다른 곳에서 다른 현상을 유발하지만 알고 보니 사실은 원인이 한가지였던 경우도 있었다.

개발자로 생활할 때 실제로 겪었던 일이다. 난 개발하면서 제품 출시도 함께 했는데, 출시한 후에 절대로 발생해서는 안 되는 현상이 나와서 사유서 같은 것들을 써낸 적이 여러 번 있다. 내가 개발하던 프로그램은 서버와 연결한 이후 실시간으로 동기를 맞춰야 했는데, 갑자기 계정이 사라지거나, 계정이 삭제됐다 생성됐다를 반복하는 현상이 드물게 발생했다.

어느날 갑자기 어이없이 나오는 그 버그들이 알고 보니 우리 프로그램의 아주 큰 설계를 잡아주고 있는 단 한 줄의 코드 때문이라는 걸 알았을 때는 정말 황당했다. 게다가 그 코드는 우리 팀의 제일 시니어 개발자가 아주 처음에 전체 구조를 잡으면서 짜놨던 코드였기 때문에 더 그랬다.

내가 만들어놓은 코드가 어디에 영향을 주는지 모르니 어떤 이슈가 나올지 장담할 수 없고, 그래서 근본 원인은 고치지도 못하고 그저 구멍 막기 식으로 땜질한다. 정말 놀랍기 짝이 없지만, 현실에서 일어나고 있다.

개발자가 만드는 테스트 케이스는 내가 만드는 코드가 어디까지 영향을 미치는지, 설계가 잘 되었는지 확인하는 과정을 담고 있다. 그러니까 코드의 동작을 확인하는 테스트 케이스는 개발자가 만들어서 코드를 만들어내는 동안에 끊임없이 확인하고 또 검증해야 한다. 내가 만든 코드니까..

있으면 좋은 것 말고

대학교 때 전화번호부에 거의 1,000명 가까이 있었다. 그때는 바깥 활동을 많이 했고, 때 되면 안부 인사할 사람도 많았는데 어느 순간 도저히 관리가 안 돼서 정리를 하기로 마음 먹었다. 지울 번호를 어떻게 골라야 하나 하고 한참을 보다가 두 가지 방법을 썼다.

1. 앞으로 연락할 것 같은 사람들

2. 집에 조사가 있을 때 연락할 사람들

처음엔 1번으로 시도했다. 지운 전화번호가 거의 없었다.

몇 달이 지나도 여전히 전화번호부가 거슬렸다. 내가 뭐라고 이렇게 저장된 번호가 많지 싶었다.

그래서 이번엔 2번을 시도했다. 꽤 많은 번호를 지웠다. (업무용 전화번호부를 아웃룩에 따로 만들었다) 남아있는 번호는 관리할 정도가 됐다.

그게 무엇이든 챙겨야할 것의 개수가 많아지면 각각에 쓸 수 있는 관심은 분산되어 적어진다. 그래서 정말 중요한 것/꼭 필요한 것과 그렇지 않은 것을 구분하는 과정이 꼭 필요하다.

꼭 필요한 것 리스트에, 있으면 좋을 것 같은 것을 계속 쌓다 보면 전화번호부를 지우지 못하는 것과 같다.

코어한 것을 살리면서 곁가지 중 필요 없는 것을 지워내는 연습을 계속해야 한다.

프로젝트 시작에 하는 완벽한 설계, 그런 게 있나?

개발할 때 분석-설계-개발-테스트의 일련의 과정으로 프로젝트 계획을 짜는 사람들을 많이 봤다. 일단 간단한 단어 하나로 표현되고, 액티비티 위주로 나누는 게 쉬우니까. 그 후엔 프로젝트의 가장 첫 단계인 '설계'를 완벽하게 하려고 꽤 많은 시간을 할애한다. 아키텍트 역할을 전담으로 하는 사람을 두기도 한다.

과연 완벽한 설계라는 게 있을 수 있을까?

왜 코드는 만들면서 또 바꾸고 바꾸면서 설계를 그렇게 할 생각을 안 하는 거지?

애자일, 참 쉽죠?

Agile Manifesto에 쓰여 있는 몇 줄의 선언문과 몇 가지 원칙이 고작인 방법. 그래서 애자일은 소프트웨어 개발 영역에선 늘 관심의 대상이다. 다만 "잘되더라"고 말하는 사람을 잘 보진 못한 것 같다.

다이어트를 할 때와 운동해서 복근을 만들 때를 떠올리면 비슷할 것 같다.

여자 연예인 누가 살을 빼서 예뻐져서 나오면 '연예인 누가 시도해서 성공한 다이어트 비법!!'이라는 기사가 줄줄이 올라온다. 남자 연예인 누가 초콜릿 복근을 어떻게 만들었다는 기사도 잔뜩이다. 열어보면 어떤 운동을 어떻게 얼마나 했는지, 뭘 어떻게 먹어야 하는지 자세하게 쓰여 있는 글들이 넘쳐난다.

우리는 그걸 몰라서 여태껏 살을 못 빼고 복근이 안생겼던 것인가???!!

다른 예로는, 자기계발서가 적당하겠다.

유명한 누가 이런 방법을 써서 자기가 성공했다고 책에 썼다. 그 책을 사서 읽고 그대로 따라 하는 청년들이, 직장인들이 많다. 되게 당연한 말이 쓰여 있다.

가장 쉬운 몇 가지 원칙이지만 그걸 꾸준히 시도하고, 연마하고 발전시켜나가는 것이 어렵다. 참 어렵다.

설계와 코드는 리팩토링을 통해 늘 정리정돈을 해서 바퀴벌레 같은 버그가 숨어 있지 않게 해야 한다는 걸 알지만, 늘 일정에 쫓긴다는 이유로 코드를 만들어내는 일에만 급급하다. 그래서 리팩토링은 꿈도 못 꾼다. 이 많은 걸 다 뜯어 고치려니 엄두가 안 난다...

혹시 급해서 막 만들어뒀고, 그 상태로 이미 커졌다면 한 번에 다 뜯어고칠 생각일랑 접어 버리고 일단 내가 지금 보고 있는 바로 그 코드 주변부터 정리를 시작해 보자.

생각은 누구나 다 한다. 빨리 시작하는 것이 중요하다.

더 큰 범위로 애자일 확장하기

애자일의 다양한 프랙티스는 작은 것부터 시작하고, 일단 시도해본 뒤에 그다음을 얘기한다.

그래서 두 명이 하는 Pair Programming, 7-9명 정도가 하는 Scrum 등 작은 규모에서 하는 프랙티스가 많은데, 지금 소프트웨어 업계는 너무 커져서 수천 명의 인원이 투입되기도 한다. 그래서 애자일은 여러 가지 파생도 생겼고, 돈을 벌려는 컨설턴트도 많아졌다.

하지만 중요한 건, 시작 자체가 간결했고 누구나 쉽게 따라 할 수 있는 기본적인 방법에서 시작한 것이기에 어떤 변화를 겪었든지 여전히 쉽고 간결해야 한다는 것이다.

테스트를 통해 협업하기

개발한 코드에 테스트 코드를 함께 넣어두면 누군가 그 코드를 건드렸을 때 쉽게 변화를 알아챌 수 있다. 또, 누군가 코드를 고쳐야 할 때 테스트 코드를 보면 이 코드가 왜 존재하는지 원작자를 찾지 않아도 쉽게 알 수 있다. 개발하려는 요구사항이 테스트 코드로 작성된 것이니까 말이다.

개발자 중엔 사람과 말로 소통하는 것보다 코드로 소통하는 것을 선호하는 사람들이 많으니 말을 하기 귀찮다면 테스트 코드를 잘 작성해 보자.