작은 소규모 개발팀에게 지켜야 할 것들 중 매번 중요하다고 여겨지는 말이다. 일단 작동하게 하는 것이, 완벽을 추구하는 것보다 낫다. 그럴듯하다. 정말 그럴듯하다. 흔히들 얘기하는 Quick and Dirty와도 일맥상통하는 얘기다.

이런 이야기가 나오는 이유는 품질에 신경을 쓰다 마켓을 놓치는 경우가 허다하기 때문이다. 프로그래머가 신경 쓰는 보통의 품질, Clean Code는 사실 사용자로서는 중요하지 않을 수도 있다. 코드 품질에 신경 쓸 시간에 사용자 동태를 살피는 게 더 중요할 수 있다. 그런 의미에서 나온 이야기이다. 린 스타트업이란 단어의 의미에도 잘 들어맞는 내용일 거다.

그런데 내가 경험한 바로는 대부분의 Dirty Code는 작동하지 않는다. (작동하는 것처럼 보일 수는 있다.) 다시 말해, Quick and Dirty가 되는 경우는 없다. 초반에 코드가 설익을 수는 있어도 그 코드가 작동할 때쯤 되면 최소한 어느 정도는 체계가 잡혀있게 된다.

Dirty Code는 일단 대충 구현해 놓고, 나중에 Clean Code로 바꾸겠다는 그런 의미다. 다시 말해, Dirty Code는 미래에서 빌려 온 빚이다. 그런 코드를 남발하면 결국 미래에 할 일을 늘리는 꼴이다. 마치, 방학 마지막에 과제 몰아치는 학생처럼, 공부 안 하다가 시험 전날에 밤새는 학생처럼 지금 할 일을 나중으로 미루는 것이다. 그리고 그런 학생들은 성실하게, 그리고 미리미리 공부한 학생을 이기기 어렵다.

그러니까 Dirty 하게 코드 짜지 말자. 될 수 있으면, Clean Code 짜도록 노력하자. Clean Code와 잘 작성된 테스트 케이스는 결국 개발 속도를 빠르게 한다.

아마 이 글이 꽤 도움이 될 것이다. 나와 완벽히 같은 의견은 아니지만, 참고할 만한 부분이 많다. 이 글의 몇몇 표현은 저 글에서 가져왔다.

위의 언급한 프로젝트들에 대해서, 지금 나는 내가 처한 상황에서는 온 힘을 다하고 있다고 얘기할 수 있다. 시간도 하루에 6~7시간씩은 투자하고 있고 가능하면 프로젝트에 대해서 고민을 계속하고 있으며, 코딩 이외의 문서화뿐 아니라 신규 기술 도입 검토 등에도 신경을 쓰고 있다. 프로젝트들에 치여서 학교 과제도 제대로 못 내고 있는 상황이다.

다른 사람들도 이랬으면, 좋겠는데 다른 사람들은 그렇게 해주지 않는 것 같다. 학교 프로젝트는 학점에 관심이 없는 모양이고, 더 놀랍게도 다른 프로젝트는 페이를 받음에도 작업의 진척이 더디다. (목표의 10% 정도?) 이런저런 핑계가 있을 수 있겠지만, 프로젝트에서 어떤 한 축을 담당해 RnR 분배가 되었을 때는 책임감을 가지고 열심히 해야 한다. RnR이 괜히 Role and Responsibility가 아니다. 책임도 서로에게 지우는 것이다.

팀의 Responsibility 균형이 깨지게 되는 순간, 팀은 게을러진다. 책임감을 갖고 열심히 하지 않아도 되는 거면, 다들 열심히 하지 않는다. 왜냐하면, 책임은 가지면 불편한 것이기 때문이다. 가지면 불편하니까, 다들 가지지 않으려고 한다. 다른 사람에게 넘기려고 한다. 그리고 그렇게 되면, 아무도 책임을 지지 않으려고 한다. 게 중 착한 사람 한 명 걸리면, 그냥 덤터기 쓰는 거다. 조별과제가 망하는 이유도 뭐 그런 거지.

아마추어와 프로의 차이가 어디서 오는 것이냐고 물으면, 나는 망설이지 않고 돈을 받는 것과 받지 않는 것의 차이라고 얘기한다. 실력이나 그런 게 중요한 게 아니다. 그런 요소는 같은 프로들 내에서도 천차만별로 차이가 나고 프로보다 뛰어난 아마추어도 널렸다. 하지만 프로는 최소한 받은 돈 만큼의 가치를 돈을 준 사람에게 제공해야한다. 그렇게 못 하면 그에 따른 책임을 져야 한다. 그게 프로다. 아니면 아마추어이고.

프로라고 하면서, 아마추어 같이 일하는 사람들을 이제는 그만 만났으면 좋겠다. 이런 생각을 하니, 예전에 어리석게 굴어 프로주제에 아마추어처럼 땡깡부린 나를 상대해야만 했던 사람들에게 미안한 마음도 들고.