[미스트] 개발이든 계발이든 하나라도 잘하고 싶다

'어떤 일 하세요?'라는 질문을 받으면 '저는 프로그래밍하는 개발자예요'라며 손가락으로 타자치는 시늉을 한다. 그 뒤 개발자는 정확히 뭐해요라는 질문은 받을 때마다 대답이 고민스럽다.

이참에 개발로 하루를 바삐 보내던 시기를 공유해보려 한다. 참고로 나의 하루가 모든 개발자의 하루는 아니다. 이쪽도 필드나 사내 정책에 따라 사용하는 툴도 분위기도 천지 차이다.

내 자리엔 모니터 3개, PC는 2대가 놓여있다. 개발용 PC에는 Linux라는 OS가 깔려있는데 윈도우나 맥과는 다른 어설픈 견고함이 있다. 출근하면 업무용 사내 메일과 메신저를 확인하고 지난밤 별일 없었다 싶으면 개발업무를 진행한다.

개발업무는 협업 툴로 시작해서 협업 툴로 끝난다고 해도 과언이 아니다. 여러 개발자들이 한 프로젝트를 같이 할 수 있는 건 이런 툴을 통해 각자의 진행 상황 및 문제점을 공유하기 때문이다. 업무 효율성에 직접적인 영향을 미치는 만큼 트렌드에 맞게 새로운 툴들이 나왔다 사라졌다 한다. 구글의 파도를 타다 보면 어떤 홍익인간 같은 마음인지 '10 Best XXX Tool'이라는 제목으로 매해 개발도구를 정리한 글도 심심찮게 보인다. 타 개발집단에 만나면 뭘 개발하는가만큼 '거긴 뭐 써요?'라고 질문하는 게 관례다.

개발 과정은 팀의 분위기를 가늠할 수 있는 척도이면서도 어려운 문제다. 어떤 방식이 소프트웨어 개발에 적합하냐는 예나 지금이나 논쟁의 이슈다. 정석적인 방식들이 존재하긴 한다. 폭포수, 프로토타입, 나선형, V자형, 애자일 기법.

우리 회사를 포함한 많은 회사는 애자일(Agile)을 지향한다. 가장 트렌디하다 간주하는 애자일은 전통적인 형태의 폭포수(Waterfall) 방식의 문제점을 보완한다. 폭포수은 계획 → 설계 → 구현 각 단계를 끝내고 다음으로 넘어가는 계획 기반 개발방식이다.

하지만 만들다 보면 이 길이 아닌가벼하는 일이 허다하다. 그러니 요구사항을 유연하게 반영할 수 있도록 각 단계를 짧게 여러 번 반복해 만들어보자!라는 기조에 기반한게 애자일이다.

2001년 작성된 애자일 선언문. 내용보단 방법론에 대한 고민이 있음을 밀하고 싶다

애자일이 이상적인 방법론 같지만, 문제가 없는 건 아니다. 경험상 전체 요구사항을 명확히 정립되지 않으면 각자 업무를 할당하기도 쉽지 않다. 어차피 고칠 거라고 하지만 일단 해보자 식으로 가다 보면 나중에 그냥 다 고쳐버려야 하는 경우도 생길 수 있다. 진짜 문제는 현실 업무에선 결국 이런저런 이유로 문제 있는 초기 모델을 그대로 가져가는 상황이 발생한다는 것이다. 의사결정이 유연한 팀에서 힘을 발휘할 방법인데 이런 조직이 얼마나 될까 싶다.

코딩은 무엇을 누가 어떻게 만들지 수많은 조사와 계획을 거친 후에 시작된다.

여담이지만 보통 코딩한다 프로그래밍한다는 큰 차이 없이 쓰임에도 묘하게 er을 붙여 코더세요? 프로그래머세요? 라고 묻는 건 어감이 아주 다르다. 코더에는 왠지 부정적인 뉘앙스가 묻어있다. 인터넷에도 코더와 프로그래머를 나누는 기준이 무엇인가? 논쟁 글이 많다. 대략 정리하자면 코더는 단순 반복적인 코드 생산을 하며 아키텍처 관점의 분석이 부족하다고 말한다. '나는?'이란 질문에 왠지 숙연해지는 대목이다. 이 밖에도 여러 호칭이 있지만, 개인적으로 가장 선호하는 표현은 개발자다. 발명가처럼 새로운 무언갈 만들어낼 수 있는 사람이라는 느낌이 들기 때문이다.

개발 시 문제가 생기면 일단 오류 문구를 긁어 구글에서 검색한다. 개발자 직군의 특징중 하나는 공유성이라 생각한다. 내가 생각한 아이디어는 이미 존재하듯 내가 겪은 문제는 이미 다른 개발자들이 겪고 해결하여 커뮤니티에 정리해 둔 경우가 많다. vote 시스템을 통해 일종의 좋아요, 싫어요를 표현하기도 한다. 이런 개발자 커뮤니티를 통해 일면식도 없는 전 세계 개발자들을 나의 든든한 지원군으로 둘 수 있다.

지원군을 믿고 개발과 오류를 찾는 디버깅 과정에 진입하면 어느 순간 나만의 세계에 빨려드는 기분이 든다. 대체 뭐가 문제야 싶은 순간도 많은데 정말 찜찜한 경우는 오류가 발생했다 나지 않는 일명 '하이젠버그(Heisenbug)'를 직면할 때다. 불확정성의 원리를 발견한 물리학자 Heisenberg의 이름에서 유래된 표현인데 누가 시작한 말인지 참 잘도 지었다 싶다. 보통 타이밍 이슈로 발생한 버그가 이런 경우로 이땐 감각적으로 오류지점을 느껴야 한다. 개발이란 게 논리로 무장된 것 같지만 때론 직관이 절실하다.

하이젠버그를 직면한 개발자

요샌 기술 자료를 찾을 때 Youtube도 많이 활용한다. 그럼 굴지의 회사 출신 개발자들이 발표하는 영상을 보게 된다. 대개 개발자들의 발표는 수려함과는 거리가 있다. 영어권 출신이 아닌 사람이 많다 보니 자막이 절실한 경우도 있고 시연 과정에서 가벼운 오타나 창을 잘못 키는 실수로 '웁스!'를 연발하기도 한다. 하지만 서로 그 맘 안다는 식으로 기다려주고 시연이 성공하면 휘슬을 불어준다. 그런 모습을 보면 나도 모르게 미소가 난다.

이런 잔잔한 재미가 있지만 누가 개발자라는 직업을 추천하냐 물으면 바로 대답을 못 하겠다. 이보다 평균 페이밴드가 높은 직업도 너무 많고 사회적 지위가 높은 직업도 아니다. 타고났구나 싶을 정도의 잘하는 사람, 대학생 훨씬 이전부터 내공을 쌓아온 사람들이 넘쳐난다. 부푼 꿈을 안고 취직해도 꿈꾸던 개발자의 모습이 아닐 가능성이 높다. 나도 현재 내 업무에 대한 회의감이 하루에도 몇 번씩 오간다.

개발자에 대한 수요만큼 공급도 빠르게 증가한다. 그 무리 사이에서 내 강점은 뭘까. 앞으로 뭘 배워야 할까 막막하다. 이쯤이면 개발자가 아니라 계속 자기 계발해야 하는 계발자가 맞는 표현이지 않나 싶다.

하지만 '저는 개발자예요'라고 할 때 괜스레 발가락이 오그라들면서도 마음이 싱숭생숭해진다. 언젠가 온 나라 개발자들 틈에 끼여 어쭙잖은 영어로 대화하고 있진 않을까. 카페 옆자리 누군가가 내가 만든 서비스를 쓰고 있는 걸 보게 되진 않을까. 기대하게 된다.

고등학생 시절, 프로그래머는 맨날 컴퓨터 앞에 앉아 일하는 지루한 직업이라 생각했다. 하지만 지금 난 배달 앱 하나 쓸 때도 점심시간 트래픽이 어떻게 처리될까 궁금해하고 시골 과수원을 지나가면 여기 뭐 하나 돌려볼 만한 프로그램 없나 생각한다. 이 일을 하며 더 넓은 세계를 알게 되었으니 10년 뒤에 어디서 무슨 생각을 하고 있을까 궁금하다.

개발자로서 나는 부족한 부분이 많지만 방법론과 협업 툴들이 나온다는 건 그 만큼 분업과 협업이 필요한 분야란 의미일 것이다. 그 안에서 내가 할 수 있는 일이 있을 것이라 믿는다.

별 하나는 빛날 뿐이지만 별자리가 되면 이야기가 생기고 은하수는 감동을 준다. 은하수의 일부로써 세상에 도움이 되는 일을 하고 싶다면 이 업은 지루할 틈이 없는 곳이라 생각한다.