소프트웨어 개발은 결과적으로 문제를 해결하는 코드를 만드는 겁니다.
코드를 만들지 못하면 실패한 것처럼 생각합니다.
결과를 지향하다 보니 작성한 코드가 전부인 것으로 착각합니다.
하지만 한번 구현한 코드가 성패를 가르는 것도, 전부인 것도 아닙니다.
나를 업그레이드하려면 결과를 향하면서도 그 과정을 기록하는 습관을 갖추어야 합니다.
그림을 보면 출발점과 목적지만 같을 뿐 과정은 다릅니다.
똑같은 주제를 공부해도 학습 과정이 다르고, 같은 알고리즘 문제를 풀어도 해결 과정이 다르기 마련입니다.
따라서 결과만으로 판단하면 안 됩니다.
요즘에는 프로그래머 채용 과정에 코딩 테스트를 많이 활용합니다.
코딩 테스트 플랫폼까지 있어서 문제를 작성하고 테스트 케이스를 통과하는 점수를 쉽게 평가할 수 있습니다.
이런 코딩 테스트 점수는 철저하게 평가 통과용으로 작성한 코드에 대한 점수일 뿐입니다.
채용을 담당하는 지인을 비롯해 저 역시 코딩 테스트 점수가 실무 역량과 상관관계가 적다고 생각합니다.
그래서 코딩 테스트는 최소 프로그래밍 역량을 확인하는 수준이 바람직하다고 생각합니다.
함께 일하기 적합한 사람인가 확인하는 가장 좋은 방법은 말 그대로 같이 일해보는 겁니다.
같이 일해보기는 제출한 코드의 점수로 평가하는 코딩 테스트보다 복잡합니다.
대화를 통해서, 협업을 통해서, 의사결정 과정에서 정성적인 평가가 포함되기 때문입니다.
현업에서도 같이 일하는 사람들의 동료 평가를 매우 중요하게 생각하는 회사가 많아지고 있습니다.
문제 해결 과정에서 만든 결과물에는 문제 해결 코드뿐만 아니라 개발 과정에서 이루어지는 가정, 추론, 논리적인 판단, 비교, 분류, 설득, 전달 과정이 포함되어야 합니다.
모든 것을 코드로 표현하지 않아도 됩니다. 요구사항 분석, 설계부터 테스트, 코드 리뷰 과정, 이슈 관리, 협업 과정 전체가 소프트웨어 개발 과정입니다.
그렇기 때문에 소프트웨어는 코드가 전부가 아닙니다.
코드가 중요하다고 생각하던 시절에는 당연히 코드만 저장해두고 다른 자료를 보관해두지 않았습니다.
부끄럽지만 제 경험을 하나 털어놓겠습니다.
스위프트(Swift) 언어에서 표준 입력 readline() 함수가 동기로만 동작하는데 비동기 방식으로 사용할 일이 생겼습니다.
비동기 방식 표준 입력 함수를 누군가 만들어놓지 않았을까 싶어서 구글에 검색했습니다.
고맙게도 누군가 구현한 코드와 예제를 깃허브 gist 사이트에 올려놓은 것을 찾았습니다.
링크를 눌러서 들어가봤더니 놀랍게도 2년 전에 바로 내가 작성한 코드였습니다. 과정을 전혀 기록하지 않고 코드만 기록해놓고 잊어버린 겁니다.
경험이 늘어나고 경력이 쌓일수록 시야가 넓어집니다.
뒤집어서 말하자면, 시간이 지날수록 개발 과정에서 경험하는 범위가 넓어져야 하고, 개발 측면뿐만 아니라 다양한 관점을 바라볼 수 있도록 시야를 넓혀야 합니다.
코딩 테스트처럼 주어진 시간에 빠르게 동작하는 정답을 찾기보다는 시야를 넓게 해서 다양한 기준에서 과정을 자주 되돌아볼 줄 알아야 합니다.
그러려면 목표가 어디로 움직였는지, 스스로 어디를 향하는지 방향을 빠르게 인지하는 게 중요합니다.
그리고 방향이 바뀔 때마다 과정을 기록해보세요.
결과만 있는 기록과 다르게 과정을 기록하면 메타 인지 관점에서 자신을 돌아보는 데 매우 도움이 됩니다.
개발 과정에서는 주로 혼자서 결정하고, 방향이 달라지는 것을 인지하지 못하기 때문에 과정을 기록하기 어렵습니다.
과정을 기록하는 도구는 아니지만, 과정에서 변화를 인지하도록 도와주는 방식으로 내비게이터와 드라이버가 함께 작업하는 짝 프로그래밍이 있습니다.
짝 프로그래밍은 혼자서 방향을 판단하고 결정한 흐름을 의도해서 끊습니다.
내비게이터는 사막에서 하는 레이싱 경기에서 지도를 보고 길을 안내하는 것처럼 방향을 살피고 의사결정을 하고 안전하게 운행하도록 지시합니다.
드라이버는 내비게이터가 설명하고, 안내하는 방향대로 제대로 가고 있는지 확인하면서 직접 운전합니다.
두 명이 다른 역할을 번갈아가면서 문제 하나를 해결합니다.
이렇게 일부러 역할을 나눠서 함께 문제를 해결하려면 과정이 매우 중요합니다.
내비게이터는 자신이 알고 있는 방향성과 맥락과, 무엇을 집중해서 해결할지를 설명해야 합니다.
드라이버는 내비게이터의 설명을 듣고 아바타처럼 조정당하는 게 아닙니다.
드라이버도 적극 참여하면서 설명을 이해한 것이 올바른지 질문하기도 하고, 타당한가 반문하기도 하고, 다른 의견을 제시해도 됩니다.
다른 의견이라고 해서 무작정 반대하거나 우기라는 게 아닙니다.
이미 알고 있는 것을 풀어서 설명하고, 주장할 때는 타당한 근거를 제시하고, 주장이 맞는지 구현해보고 테스트 케이스로 확인도 합니다.
짝 프로그래밍 흐름에서 중요한 것은 공유하는 코드가 아니라, 과정을 기록하고 주고받는 맥락 그 자체입니다.
내가 개발 과정에서 어떤 생각을 하고, 어떤 방향을 생각하고, 어떤 의도로 개발하게 되는지 알고 싶다면 짝 프로그래밍을 추천합니다.
6편에서 소개할 원칙은 ‘의도한 실수를 반복하면서 작은 부분을 개선하기’입니다.
★ 더 나은 개발자로 성장을 꿈꾼다면
★ 먼저 헤쳐온 테크 리더들의 원칙에서 해답을 찾아보세요
“나도 테크 리더가 될 수 있을까? 어떻게 선배 개발자들처럼 성장할 수 있을까? 3년 10년 후에도 개발자로 살아갈 수 있을까? 팀워크는 도대체 어떻게 맞춰야 하는 걸까?”
개발자로 살아가면서 하루에도 천 번을 되묻는 물음에 마켓컬리, 레몬트리, 카카오, 코드스쿼드, 무신사, 몰로코, 데이블, 인프런, 패스트캠퍼스 테크 리더 9명이 답합니다.
지금까지 만나 볼 수 없었던 생존과 성장의 원칙에서 자신만의 해답을 찾아보세요.
김정
소프트웨어 교육 기업 코드스쿼드 대표로 모바일 iOS 마스터를 담당합니다. 케텔 시절 비파툴, 델마당 개발자 커뮤니티를 시작해서 취미 맥개발자 커뮤니티 OSXDev를 거쳐 레츠스위프트 커 뮤니티 운영진으로 끊임없이 살아가는 중입니다.
