336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
예전에 데브피아라는 개발자 커뮤니티를 자주 다녔다. 한 때 데브피아의 게시물을 빠짐없이 읽었는데, 당시 Visual C++포럼에서 활동하는 개발자들이 자주 하던 얘기 중 하나는 빌드 수행하고 30분 정도 커피 마시러 간다는 것이었다. 당시 규모가 큰 환경의 빌드 환경은 경험해본적이 없었기 때문에 그냥 왠지 모르게 멋져 보였다. 당시엔 이런 환경이 괴롭다는 것은 미처 알지 못했던 것이다. 그후 몇 년이 지났다. 웹개발을 하며 나도 비슷한 경험을 하게 되었다. 소스의 어떤 부분을 고친 후 결과를 확인하는 데 최소 1분 이상 걸리는 환경에서 일하게 된 것이다. 소스를 고치면 컴파일을 해야했고, 로컬의 웹서버도 재시작 해야했다. 내가 원하는 만큼 개발이 빠르게 되지 않는다는 생각이 들었고 답답했다. 집중력도 떨어지기 시작했고, 시간이 아까웠다. 

1. 피드백 속도와 생산성

지금 생각해보면 이는 피드백 속도와 관련된 문제였다. 어떤 개발자든 수많은 시행착오를 통해 결론에 도달한다. 개발을 하는 과정을 떠올려보자. 처음엔 대게 무언가 잘못 된 코드를 작성한다. 얼마 후 코드가 잘못된 것을 인지한다. 곧 코드를 고친다. 또 잘못 된 점을 인지한다. 또 고친다. 만족할 때까지 반복한다. 이렇게 개발자는 목적을 달성하기까지 시행착오를 반복한다. 여기서 주목할 점은 코드를 작성하고 문제를 인지할 때까지 얼마만큼의 시간이 걸리냐이다. 어떤 기능을 개발하는 데 100번의 시행착오를 겪었다고 가정해보자. 이 때 내가 웹개발을 했을 때처럼 시행착오의 1분이 걸렸다면 원인을 유추해서 수정하는 시간을 빼고도 100분이 소요되었다는 것을 알 수 있다. 하지만 만약 10초가 걸렸다면? 1000초이다. 분으로 환산하면 약 17분 정도이다. 이처럼 피드백 속도가 빨리지면 빨라질수록 시행착오에 드는 시간을 줄어든다. 시행착오에 드는 시간이 줄어든다는 것은 개발 생산성이 높아진다는 것을 의미한다.

2. 트렌드에서 읽을 수 있는 빠른 피드백의 중요성

최근 스크럼, TDD, 지속적 통합 등이 많이 언급된다. 이들은 각자의 영역에서 추구하는 바가 있다. 하지만 공통적으로 '피드백'을 강조한다. 

스크럼의 주요실천방안 중 하나는 스프린트(Sprint, 반복주기와 비슷한 개념)이다. 2주 혹은 3주 정도의 간격으로 데모 가능한 형태의 목표를 정한 후 스프린트를 진행한다. 2주 혹은 3주 정도 후 스린린트가 끝났을 때 관계자를 모아 데모를 한다. 만약 무엇인가 잘못되어 가고 있다면 관계자의 피드백이 있을테고, 팀은 잘못된 방향을 시정할 수 있게된다. 만약 이런 스프린트가 없다면 어떤 일이 발생할까? 많은 개발자가 한번씩 경험했을 법한 일이 발생한다. 오픈 전에 의사결정자가 와서 방향 자체가 잘못 되었다며 뒤집는 것이다. 스크럼의 다른 실천방안 중 하나는 일일회의이다. 오전에 개발 관계자들이 잠시 모인다. 돌아가며 어제 한일, 오늘 할일, 이슈를 간단히 얘기한다. 일일회의를 하는 이유는 여러 가지가 있지만 그 중 하나는 피드백 때문이다. 예로 신입사원이 쉬운 일을 어렵게 하고 있거나, 각기 다른 개발자가 같은 기능을 각자 개발하는 등의 낭비를 미리 알고 이에 대처할 수 있게 된다. 

TDD는 어떤 면에서 FDD(Feedback Driven Development)이라고 불러도 손색이 없을만큼 피드백이 중요한 역할을 한다. TDD는 테스트를 먼저 작성하고 개발을 하는 것이다. TDD를 하면 엄청난 양의 피드백을 조기에 받을 수 있다. 우선 테스트를 통해 개발하는 대상을 미리 사용해보기 때문에 API 사용성에 대해 미리 알 수 있다. 나중에 다 만들어 놓고 나서 사용성이 떨어지는 부분을 수정해야겠다는 마음이 들 때 이미 많은 파일에서 사용하고 있어 수정이 어려운 때를 예방해 주는 것이다. 또 디자인에 대해서도 미리 고민할 수 있게 된다. 예를 들어 테스트를 하다 보니 의존성이 너무 많다는 것을 알게될지도 모른다. 의존성이 많다는 것은 추상화 수준에 문제가 있다는 신호로 볼 수 있다. 또한 코드 상에 존재하는 결함을 즉시 알게된다. 따라서 TDD로 개발을 하면 결함을 조기에 고칠 수 있게 된다. 

지속적 통합 역시 피드백이 중요한 역할을 한다. 머지 지옥이라는 말이 있다. 두 명의 개발자가 별도의 브랜치에서 약 3달 간 작업했다. 이때 3달 동안 작업한 것을 다시 Trunk로 합치려고 한다. 두 사람이 중복으로 수정한 부분이 많다. 그것을 오류없이 잘 머지하려 하려면 정말 지옥을 경험하는 것처럼 힘들다. 그래서 머지 지옥이다. 지속적 통합의 취지는 이런 일을 예방하자는 데 있다. 실천방법은 가능한 미리 통합하는 것이다. 위 두 명의 개발자가 지속적 통합을 시도했더라면 어땠을까? 아마 최소 하루에 한번씩 서로 커밋하고 업데이트를 하면서 작업했을 것이다. 'A 파일 어제 네가 수정했네, 네가 만든 코드 기반을 활용해서 내가 추가로 작업하면 될 것 같아.', '어제 우리 작업한 것 충돌난 것 같아. 함께 살펴보자.'  개발 중에는 이를 낭비라고 생각할 수도 있겠지만 시간이 지난 후 현명한 판단임을 알게될 것이다. 

3. 천공카드 시절의 개발자

그렇다면 피드백 속도는 근래에서야 중요해진 개념일까? 그렇지 않은 것 같다. 오래 전 천공카드로 개발하던 시절에도 피드백 속도와의 싸움이 있었다. 당시 개발자에게 요구되는 능력 중 첫째는 인내력이었다고 한다. 왜냐하면 천공카드에 구멍을 뚫어 무엇가를 실행했는데 만약 실패하면 다시 천공카드를 뚫어야 했기 때문이다. 지금은 코드를 고치고 테스트를 돌리면 내가 작성한 코드가 잘 동작하는지 여부를 금방 알 수 있다. 하지만 천공카드 시절에는 시행착오란 기다림을 뜻했을 것이고, 개발시간은 훨씬 더 오래걸렸을 것이다.

천공카드 시절 후 수십년이 지났다. 그럼에도 피드백 속도가 지금도 이렇게 중요한 것을 보면 이는 소프트웨어 개발에 있어 본질적 요소 중 하나인 것 같다. 시류에 밀접한 어떤 것이든 금방 사라져간다는 사실에 비추어 볼 때 더욱 그렇다는 확신이 든다. 피드백 속도를 빠르게 하자라는 전제는 예전에 썼던 나누어 해결하기 처럼 소프트웨어 개발을 뛰어넘어 일상의 문제에까지 광범위하게 적용될 수 있을 것 같다. 

4. 빠른 피드백 관점의 사고

난 생산성에 문제가 있다고 있을 때 피드백 관점으로 문제를 바라보고 사고해본다. 즉 피드백 속도를 향상시킬 수 있는 방법이 없는지를 살펴보는 것이다. 꽤 많은 상황에서 피드백 속도의 향상이 생산성 향상이라는 결과로 이어진다. 작년 특정 팀에 가서 짝 프로그래밍을 통해 재현하기 어려운 버그를 함께 수정한적이 있다. 그때 팀의 개발자는 문제재현을 하지 못하고 있었다. 개발자는 문제재현을 하기 위해 의심되는 코드 부분에 로그를 넣은 후 컴파일 하고 톰켓을 재시작한 후 웹브라우저에서 여러 상황을 만들어보고 있었다. 컴파일을 하고 톰켓을 재시작 하는 데 몇 분의 시간이 소요됐고, 개발자는 시행착오를 1회 겪는데 최소 몇 분씩 사용하고 있었다. 문제가 쉽제 재현되지 않았기 때문에 많은 시간을 소요하고 있었던 것이다. 난 이를 보고 피드백 속도에 문제가 있다고 판단했다. 즉시 JUnit을 이용하여 문제를 재현해볼 수 있는 테스트를 만들었다. 테스트를 만든 후 우리는 입력값을 빠르게 변경하며 기존보다 훨씬 더 빠른 속도로 시행착오를 겪기 시작했다. 얼마 후 우리가 만든 테스트가 실패했고, 이는 문제재현에 성공한 것이었다. 코드를 수정하여 테스트를 성공하게 만들었고 문제가 해결되었다. 내게 이 경험은 매우 인상 깊었는데 피드백을 의식적으로 인지하고 이를 제어했기 때문이다. 

5. 그렇다면 빠른 피드백이 정말 좋기만 한것인가?

지금까지 말한 부분에 근거해 내 머리에 자리잡은 강력한 전제 중 하나는 '빠른 피드백은 생산성을 높여준다.' 것이다. 과연 소프트웨어 세계의 절대적 진리가 있는지 갸우뚱 하는 가운데서도 이 전제만큼은 크게 의심하지 않았다. 여러 경험을 통해서 자주 증명됐고 확신은 커져만 갔다. 하지만 불완전함을 의미하는 인간이 개입되면 이는 옳지 않은 전제가 될 수도 있다.

어떤 개발자가 있다. 개발자에게 개발에 도움이 되는 정보를 5분마다 준다. 개발자가 과연 일을 잘할 수 있을까? 아닐 것이다. 개발자는 일에 집중할 수 없을 것이고 아무일도 하지 못할 것이다. 이는 개발자가 인간이기 때문에 생기는 일이다. 소프트웨어 역사에서 수도 없이 증명되었듯이 논리적으로 올바른 것이 인간이 개입하는 순간 더이상 올바르지 않게 된다. 난 폭포수 개발방법론의 가장 큰 실패원인은 인간의 불완전성을 신중히 고려하지 않았기 때문이라고 믿는다. 따라서 빠른 피드백이 좋다라는 전제에 따른 사고도 좋지만 항상 그 안에 있는 인간에 대한 신중한 고려가 필요하다고 생각한다. 

6. 이 전제는 20년 후에도 사랑받을 것 같다.

소프트웨어 산업은 다른 산업에 비해 변화가 극심하다. 즉, 과도기를 지나고 있는 것이다. 몇달 전 극찬과 조명을 받았던 그 무엇이 오늘 이 순간 전혀 조명받지 못하는 것이 그리 놀랄 일도 아니다. 새로운 프레임웍이 수도없이 나온다. 그 자신의 범위 내에서 지식을 쏟아낸다. 하지만 그 지식 많은 부분은 어느 순간부터 중요하지 않은 지식이 된다. 하지만 이런 지식과는 달리 빠른 피드백은 20년 후에도 여전히 개발자에게 사랑받는 전제로 남아있지 않을까라는 생각이 든다. 난 이를 소프트웨어 본질적 요소라고 생각하며, 지나가는 무엇이 아닌 이런 본질적 요소를 찾는 것은 개발자로써 큰 즐거움 중 하나인 것 같다.

WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

,