Page history of 프로그래머에게 필요한 피드백

수십년 동안 전문가가 안되는 비결에 따르면, 믿을 수 있는 직관이 형성되려면 유효성과 피드백이 갖춰져야 한다고 한다. 믿을 수 있는 직관이 형성된다는 것은 곧 전문가가 된다는 이야기. 그렇다면 소프트웨어 개발자에게 필요한 유효성과 피드백은 무엇일까? 유효성 이야기는 조금 어렵고 복잡하므로 다음으로 넘기고 피드백을 보자. 프로그래머는 어떤 피드백을 받아야 전문가로 발전하는데 도움이 될까?

아마 많은 사람이 피드백 하면 상사나 동료로부터 잘했다 못했다 이야기를 듣는 것을 먼저 떠올릴지 모른다. 하지만 이건 다들 알다시피 답이 아니다. 상사나 동료가 정확한 판단을 내린다는 보장이 없기 때문이다. 드라이퍼스 모델에 따르면 전문가의 수는 극히 적고 대부분 초보자, 고급 입문자, 중급자에 머물러 있다. 그렇다면 상사나 동료도 전문가일 확률은 아주 낮다. 그렇다면 상사나 동료의 피드백은 비전문가의 피드백이며 그것이 정확한 의견일 가능성은 낮다. 또, 전문가라고 해서 꼭 자신이 왜 잘하는지를 알고 있는 것은 아니기 때문에 전문가 역시 좋은 피드백을 준다는 보장은 없다. 물론, 상사나 동료의 피드백에도 진실은 담겨 있다. 하지만 그것은 전체의 진실이 아니라 일부의 진실이고 열심히 듣되 스스로 판단해야 하는 종류의 피드백이다. 어찌되었건, 전문가로 가는 길과는 크게 상관이 없다.

잠시, 반대로 피드백이 아주 좋은 분야를 생각해보자. 어떤 분야가 있을까? 탁월한_조직이_빠지기_쉬운_5가지_함정에 한 가지 예가 나온다. 스포츠. 스포츠에는 점수와 승패라는 명확한 피드백이 있다. 1:1 경기일수록 피드백은 더 명확하다. 이런 분야일수록 전문가와 비전문가의 차이는 엄청나다. 투자한 시간에 어느 정도 비례해서 실력이 올라가기 때문에 취미로 하는 사람이 프로를 이길 가능성은 거의 없다. 하지만 프로그래머는 어떤가? 낮에는 바쁘게 환자를 치료하면서 밤에 백신을 만든 안철수는 다른 프로그래머들보다 훨씬 빨리 바이러스 대비책을 내놓았다. 수많은 프로그래머들을 제치고 한 고등학생이 한국 앱스토어에서 짱먹었다. 18세 브라질 청소년이 리눅스 커널 메인테이너가 되고, 입사 1년차가 7년 경력 사원보다 높은 성과를 내곤 하는 것이 프로그래머다. 프로그래머들이 프로 바둑기사만큼 전문성을 발전시킬 수 있었다면 이런 일은 일어나지 않을 것이다.

반대로 이야기하면 프로그래머에도 자신의 성과에 대한 명확한 지표가 있다면 더 전문성을 높여갈 수 있다. 탁월한_조직이_빠지기_쉬운_5가지_함정에서 스포츠의 예를 든 이유도 기업이 성과를 내기 위해서 성과를 평가할 수 있는 지표가 필요하다는 이야기를 하기 위함이었다. 프로그래머 역시 그런 지표가 필요하다. 내가 참여한 프로젝트가 얼마나 돈을 벌었는지, 얼마나 많은 사람에게 도움을 주는지, 혹은 얼마나 돈을 절약했는지 등등. 혹은 적어도 이 프로젝트가 납기 안에 잘 끝났는지라도 봐야 한다.

이렇게 성과 측면에서 평가할 때 TheGoal에서 지적하는 부분 최적화를 피해야 함은 물론이다. 나는 완벽하게 프로그래밍했는데 기획이 잘못되서 서비스가 망했어. 이건 제대로 된 평가가 아니다. 프로젝트 성공에 대한 책임은 모두가 같이 지는 것이다. 내가 더 빨리 프로그래밍해줬으면 기획자가 더 빨리 잘못을 인지하고 수정할 수 있지는 않았을까? 이런 질문을 해봐야 한다. 굳이 성과로 회사가 돈을 얼마 벌었는가까지 봐야 하는 이유도 그런 측면이 강하다. 나라는 틀을 벗어나 프로젝트라는 컨텍스트에서 나의 역할을 평가해야 한다.

그렇다고 서비스가 망했으니 우린 모두 루저야...라고 생각할 필요는 없다. 개인의 책임과 권한의 한계가 있기 때문에 프로젝트의 성공 여부가 전적으로 내 성과랑 연결되는 것은 물론 아니다. 때때로 사람들은 프로젝트가 성공하면 자기 역할이 컸다고 생각하면서, 실패하면 자기 권한으로는 어쩔 수 없었다고 말한다. 자연스러운 심리지만 이런 피드백으로는 전문가가 될 수 없다. 성공한 프로젝트의 팀원이었던 사람을 비싼 돈 주고 스카웃해왔는데 잘 못해내는 경우를 우리는 얼마나 많이 봐왔는가. 그게 바로 내가 될 수도 있는 것이다.

예를 들어 이런 식의 평가라면 괜찮은 피드백이 될 수 있을 것이다. 이 프로젝트가 망했는데, 내가 맡은 부분은 제대로 개발했지만 다른 동료들이 맡은 부분이 제대로 안되는 걸 알면서도 팀장에게 이야기해서 대책을 마련하질 않았어. 내가 그런 사실을 미리 팀장에게 알려주고 다른 사람을 도울 수 있었다면 좀더 나은 결과가 나왔을 꺼야. 혹은 이럴 수도 있다. 이 프로젝트는 대박이 났지만 사실 나 때문에 대박 난 건 아니야. 이 서비스는 플래시 컨텐츠 때문에 대박난 건데 난 웹개발 부분만 맡았으니까. 성공한 프로젝트에 참여한 것은 자랑스럽지만 내 성과로 자랑할 프로젝트는 아니야.

그런데, 이 최종 성과라는 측면도 중요하긴 하지만 프로그래머에게 직접적인 피드백은 아니다. 많은 변수와 맥락을 고려해서 깊이 생각해야 알 수 있는 것이다. 이보다 조금 더 쉽게 얻을 수 있는 피드백이 있다.

그건 바로 제대로 돌아가게 만드는 것이다. 프로그래머라면 당연히 이 정도는 해내야 하는 거 아니냐고? 나도 그런 줄 알았다. 품질이라든가, 버그라든가, 그런 이야기를 하는 게 아니다. 그냥 기능이 동작하게 만드는 것, 그걸 못하는 사람도 많다. 프로그래머라면 코드가 지저분하든 어떻든 일단 기능이 돌아가게 만드는 것은 할 줄 알고 볼 일이다. 그게 되고 나서 코드도 정리하고 버그도 잡고 품질도 생각하는 것이다. 내가 이 프로젝트에서 필요한 기능을 제대로 만들어 내고 있는가. 이것이 일차적인 피드백이다.

물론, 이것은 너무 낮은 목표다. 이 피드백을 받아본 결과 제대로 못하는 것 같다면 프로그래머를 그만둬야 하는지도 모른다. 여기에 한 가지가 더 필요하다. XP에서는 간혹 프로그래머의 목표로 clean code that works를 제시한다.(물론 여기서 이야기하는 목표는 미시적인 목표다.) 하지만 여기서 clean code는 정확히 말하면 목표가 아니라 수단이다. 왜 clean code가 필요한가? 미학? 유지보수를 잘하기 위해서? 남들이 알아보기 쉬운 코드가 좋은 코드니까?

내가 생각하는 답은 더 빨리 개발하기 위해서다. that works를 달성한다는 전제 하에, 더 빨리 개발을 해낼 수 없다면 clean code는 무의미하다. 여기서 더 빨리의 스케일은 1시간 이상이다. 1시간 이내라면 clean code 없이 막 짜도 더 빨리 뭔가를 달성할 수 있다. 하지만 1시간을 넘어가도록 지저분한 코드를 그대로 놔두고 있다면 이미 속도가 느려진 상태일 것이다. 뭐, 1시간은 사람에 따라 차이가 있을 수도 있다고 치자. 엄청나게 똑똑한 사람이라면 1시간 정도의 컨텍스트는 아무렇지 않게 머리에 담을 수 있을지 모른다. 그래도 하루가 넘어가면 어떨까? 아침에 출근하면 어제 코드가 생생하게 그대로 머리에 컨텍스트로 들어오는가? 좋다, 당신은 똑똑한 편이다. 그렇다면 일주일은 어떤가? 한 달은? 스케일이 커질수록 clean code 없이 개발 속도는 낼 수 없다. 아마 평범한 사람이라면 하루를 크게 안 넘어가는 선에서 리팩토링이 필요해질 것이다. 단지 필요하다고 느끼지 못하는 것 뿐.

결국 필요한 피드백은 내가 얼마나 빨리 개발하고 있는가이다. 여기에는 상대 평가도 필요하다. 하지만 대개의 프로그래머는 이런 식이다. 프로그래머가 어려운 기능을 구현하는 모습을 상상해보자. 처음 개발을 시작하고 처음에는 진도가 좀 나가는 것 같다가 막힌다. 이리저리 삽질을 해보지만 잘 안된다. 야근도 해가면서 월요일부터 끙끙 머리 싸매고 열심히 개발하다가 금요일, 드디어 완료했다! 프로그래머는 완료한 기쁨에 휩싸인다. 역시 난 해냈어. 난 훌륭한 프로그래머야. that works에 대한 피드백은 확실하게 챙긴다. 하지만, 비슷한 기능을 다른 프로그래머는 이틀 만에 완료했었다는 사실과 비교해보지 않는다.

아마 대부분의 프로그래머가 생각하는 피드백은 돌아가게 만든다 수준에서 멈출 것이다. 돌아가게만 만들면 난 잘한 것이다. 그래서, 전문가로 가는 성장도 여기서 멈춘다. 프로게이머가 겪는 패배를 프로그래머는 겪지 않는다. 기한 내에 못 마치면 일정이 무리한 것이니까 내 잘못은 아니야.

꼭 다른 사람과 비교해야 하는 것은 아니다. 중요한 것은 정량적으로 측정해보는 것이다. 측정이 불가능하다고? 측정이 정확할 필요는 없다. 흔히 정량적인 측정이라고 하면 정확한 수치가 나와야 하는 것으로 생각하는데, 사실 우리가 자로 재는 것조차도 정확한 수치는 안 나온다. 자의 오차, 눈의 오차 등등으로 오차 범위란 게 있다. 단지 이런 문제는 그 오차 범위가 훨씬 더 클 뿐이다. 그래도 여전히 우리는 판단할 수 있을 만큼의 숫자를 뽑아낼 수 있다.

예를 들면 난 이런 식으로 비교해본 적이 있다. 권한 프레임웍을 만드는데 NHN에서 할 때는 개발에 2주 가량 걸렸고 적용하는데 1주 정도 더 걸렸다. 비슷한 수준의 프레임웍을 이슈 트래커를 만들 때 django로 개발했는데 사흘 정도 페어로 완료했고, 올해 초 자원봉사 커뮤니티를 만들 때는 하루 만에 만들었다. 각기 디테일도 다르고 언어도, 프레임웍도, 환경도, 프로젝트도 다르지만 어느 정도 비슷한 부분을 뽑아내서 비교할 수 있다. 물론, 같은 부분을 한 것이기 때문에 반복 효과가 있어서 이게 곧 실력의 향상은 아니라는 점도 감안해야 한다. 이처럼 다양한 오차 요인이 있지만 대략적인 측정은 가능하다.

어쨋든 돌아가게 만든다는 전제 하에 얼마나 빨리 개발할 수 있느냐는 개발자의 능력에 있어 가장 중요한 척도이며, 이것에 대한 피드백을 계속 받아야 전문가로 성장해갈 수 있다.

하지만, 난 여기서 조금 더 과격한 주장을 하고자 한다. 사실 돌아가게 만든다는 말은 여러 가지로 해석할 수 있다. 품질에 대한 척도는 사람마다 다르기 때문에 이 정도면 기능은 돌아가잖아를 보고 또 어떤 사람은 뭐 이거 제대로 쓸 수가 없잖아라고 말하기도 한다. 그럼 어느 정도 품질을 기준으로 빨리 해야 할까?

난 여기에 품질과 상관 없이 무조건 빨리 하는 게 장땡이라고 말하고 싶다. 중요한 건 최종 릴리스 때 버그 없게 나가는 것이지 매 순간순간 버그가 없어야 하는 것은 아니다. 빨리 개발하면 그만큼 빨리 버그를 발견하고 더 빨리 버그를 고칠 수 있다. 개발자가 꼼꼼히 살펴본다고 모든 버그를 발견할 수 있는 것도 아니다. 그런데 품질을 높이기 위해 신경쓰다보면 고객에게 중요한 기능을 릴리스하는 것이 늦어진다. 프로젝트 진행 중에는 대부분의 고객이 버그보다 필요한 기능이 빨리 구현되는 것을 중시한다. 그래야 그 기능이 고객에게 맞는 기능인지 아닌지를 볼 수 있기 때문이다. 완벽하게 개발해놓고 고객한데 쨘! 하고 보여줬는데 나 이거 필요 없어하는 상황을 맞이한다고 상상해보라. 그보다는 버그가 있는 상태에서 고객과 소통하는 이득이 훨씬 클 것이다.

물론, 품질을 깎아 먹은 결과로 전체적인 프로젝트가 더 느려져서는 안된다. 하나하나의 개별 작업이 빨라야 하는 것 뿐 아니라 프로젝트 전체가 빨리 끝나야 하는 것이다. 더 빨리 프로젝트를 끝내기 위해 품질을 지키려 한다면 그것은 OK다. 다만, 정말로 그 품질을 지키는 것이 프로젝트를 빨리 끝내는데 도움이 되는지 심각하게 고민해봐야 할 것이다.

TDD니 리팩터링이니 각종 기법들의 목표는 모두 더 빨리 프로젝트를 완료하는 것이다. 간혹 XP 비판론자에게서 이런 이야기를 듣는다. clean code니 뭐니 상관 없이 빨리 만들어내기만 하면 되는 것 아닌가. TDD가 추구해야 할 그 무엇은 아니지 않은가. 맞는 말이지만 허수아비 공격이다. XP에서는 clean code 자체를 추구하지는 않는다. TDD가 생산성을 높여주지 못한다면 뭐하러 TDD를 하겠는가? 리팩토링이 시간 낭비이고 프로젝트를 느려지게 만든다면 리팩토링 할 필요 없다. 이런 것들이 다 실제로 생산성을 높여줄 수 있을 때만 해야 하는 것이다.

얼마 전에 이런 질문도 받은 적이 있다. 아니 어떻게 그렇게 빨리 개발했는데 모듈화까지 이렇게 다 하셨어요? 저는 그냥 막 짜는데. 비슷한 맥락이다. clean code니까 빨리 개발할 수 있는 것이다. 머릿속에 100라인 짜리 메서드를 담아야 한다면 빨리 개발하기는 힘들 것이다.

아마도 이런 오해가 나오는 것은 실제로 clean code를 추구하느라 느리게 개발하는 사람이 있기 때문일 것이다. 사실 애자일 커뮤니티에 이런 사람이 많이 보인다. 역시 얼마나에 대한 피드백이 부족한 경우다. 자신이 얼마나 빨리 개발하는지에 대한 피드백을 받지 못하니까 열심히 clean code의 극한을 추구하는 것이다. 게다가 짧은 기간 동안은 자신이 느리더라도 길게보면 자신이 더 빠를 것이라고 생각하는 경우도 있다. 역시 장기간에 걸친 얼마나 빨리 개발하는가에 대한 피드백이 없었기 때문이다.

정리하면, 프로그래머가 생각해야 할 피드백은 크게 세 가지다. 내가 참여한 프로젝트가 성공했는가. 내가 개발한 기능은 제대로 동작하는가. 나의 개발 속도는 얼마나 빠른가. 성장을 위해 가장 중요한 것은 세번째이다. 보다시피 다른 누군가가 말로 줄 수 있는 피드백이 아니다. 내가 직접 판단하고 평가해야 하는 것이다. 물론, 팀 차원에서 이런 피드백을 할 수 있다면 더 좋을 것이다.

슬램덩크의 강백호는 누구보다 눈부시게 성장한다. 그런데, 잘 생각해보면 강백호의 학습 환경은 환상적이다. 백호가 거친 플레이를 하면 심판이 피드백을 주고 수비에 실패하면 상대편 공격수는 강백호만 노려서 공격한다. 백호가 슛 성공률이 낮으니까 쉬운 슛 찬스를 그냥 내준다. 최종 성과는 팀의 승패로 다가온다. 훌륭한 피드백 환경이다. 강백호의 강한 승부욕은 피드백에 더 민감하게 만든다. 그리고 그런 피드백을 받을 때마다 스스로 고민하기도 하지만 옆에서 코치해줄 안선생님과 채치수, 한나가 있다. 롤모델 서태웅도 있다. 이런 환경에서 성장을 못한다면 그게 더 이상할 것이다.

프로그래머도 좋은 피드백만으로 전문가가 되는 것은 아닐 것이다. 본인의 성장 의지도 필요하고 피드백에서 알아낸 상관 관계에서 인과 관계를 분석해 줄 수 있는 코치(혹은 본인의 분석력)도 필요하다. 피드백은 전문가로 가는 길의 첫걸음 정도로 생각하면 될 것이다.

블로그 / 소프트웨어 개발