해결책을 여러 개 마련하세요.
모든 상황에서 완벽한 단 한 가지 방법은 과학자들이 찾는 수식에만 있습니다.
그 수식을 현실에서 구현할 때 주어진 환경에 따라서 다양한 해결 방법이 있습니다.
소프트웨어 엔지니어 분야는 다른 엔지니어링 분야보다 더 다양하고 유연한 해결 방법을 만들 수 있습니다.
소프트웨어 개발 환경 자체가 유연하기도 하고, 실행하는 환경도 물리적으로 다른 여러 환경을 시뮬레이션할 수 있기 때문입니다.
옛 직장에서 대용량 통신 시스템의 설계 리뷰를 수행한 적이 있습니다.
저는 프로토콜 규칙에 맞춰서 통신 신호를 주고받으면서 상위 응용 계층 모듈로 전달하는 모듈을 담당했습니다.
동료는 응용 계층에서 시나리오에 따라 다양한 흐름을 제어하는 모듈을 담당했습니다.
팀장은 서로 역할 분배와 고가용성(High Availability) 모듈과 장애 시 다른 모듈로 제어를 넘기는 기능을 담당했습니다.
서로 담당하는 모듈을 설계하고 시스템 통합을 고려하면서 설계 리뷰를 진행했습니다.
당시 설계한 대용량 서버 하나는 상위-하위 서비스 모듈이 한 세트로 배포되고, 총 5대가 분산 처리하고 1대는 예비 서버로 대기했습니다.
설계 리뷰를 하면서 하드웨어 리소스 분배와 통신 방식에서 치열한 의견 대립을 주고받았습니다.
어느 하나의 모듈이 더 거대해질 수 없지만 서로의 역할을 고려하지 않고 기준을 정하기도 전에 자신이 설계한 모듈에 대한 의견만 강조했기 때문입니다.
당시 설계 리뷰는 일주일 동안 이어지다가 몇 가지 실험을 통해서 서버의 CPU 사용량이 70%를 넘지 않는 수준에서 메모리 한계를 측정해 기준을 정하는 것으로 합의를 했습니다.
익숙한 환경에서만 모든 것을 해결하려고 들면 사고의 폭이 좁아집니다.
소프트웨어 엔지니어에게는 사고의 유연성이 중요합니다.
기준이 달라지면 소프트웨어 설계나 운영 방식이 달라질 수 있기 때문입니다.
다양한 분야 전문가와 함께 일하는 다학제적 환경에 놓이게 되면 익숙한 사고 방식이 다른 분야에서는 닫혀버린 사고방식일 수도 있다는 걸 깨닫게 됩니다.
코드 리뷰뿐만 아니라 설계 리뷰처럼 동료들의 다른 의견을 듣는 것은 유연한 사고를 기르는 데 도움이 됩니다.
리뷰 과정에서 나와 다른 의견이라서 남을 설득한다는 핑계로 혹은 잘잘못을 가리거나 논리적으로 독소 가득한 표현을 써서 상대를 이겨야 하는 건 아닙니다.
함께 실험을 해보거나 서로 납득할 수 있는 기준을 정해보길 추천합니다.
소프트웨어 분야가 발전이 빠른 데는 오픈 소스 문화가 보여준 유연한 사고방식에 있습니다.
오픈 소스 문화는 의사들처럼 경험을 공유하고, 과학자들처럼 코드를 공유하고, 공유한 코드를 개선하거나 기여합니다.
작은 프로젝트가 거대한 오픈 소스 프로젝트로 금방 성장합니다.
오픈 소스 문화가 가지는 가장 큰 장점은 다른 사람과 공유한다는 점입니다.
소스 코드를 공유한다는 것보다 공유하는 과정에서 사고방식, 의사소통, 설득과 토론이 더 중요합니다.
오픈 소스에는 코드를 가져다 쓰는 것을 포함하여, 기여하고 서로를 인정하는 문화가 포함됩니다.
오픈 소스는 대부분 읽고 사용할 수 있지만, 생각보다 다양한 라이선스 정책이 있습니다.
GPL처럼 기존의 코드 일부를 사용하는 코드는 무조건 전체 코드를 공개해야 하는 철학적인 라이선스도 있습니다.
MIT나 아파치처럼 더 유연하고 사용하기 자유로운 라이선스도 있습니다.
구글, 페이스북, 애플, 마이크로소프트처럼 큰 회사들 직원들도 오픈 소스에 기여하고, 비즈니스를 확장합니다.
오픈 소스를 기반으로 하기 때문에 무료로 배포하는 리눅스라는 운영체제를 가지고 사업을 하는 레드헷 같은 회사도 있습니다.
이처럼 소프트웨어와 공유 문화는 분리해서 생각하기 어렵습니다.
오픈 소스는 거창해보이지만, 공유하기 시작과 실천은 어렵지 않습니다.
습득한 지식을 블로그에 공유하는 건 어떤가요?
이때 참고한 코드를 그대로 복붙해서는 내 것이 되지 않습니다.
개구리를 만들어보라고 말씀드렸습니다. 개구리를 완성하지 못하더라도 직접 만들면서 학습한 코드를 공유하면 다른 사람에게 도움이 될 겁니다.
참고로 문제 해결에 고심하는 친구나 동료에게 내 코드를 그대로 공유해주는 것은 좋지 않습니다.
코드는 생각 과정이 생략된 여러 해결 방법 중에 하나일 뿐입니다.
사소한 실수부터 차곡차곡 경험해야 결과로 만들어지는 코드가 자신의 것이 됩니다.
친구에게 고기를 주지 말고 고기를 낚는 방법을 알려줍시다.
특히 프로그래밍 연습이 충분히 되어 있지 않아서 정말 어디부터 작업을 시작할지 모르겠다면 무조건 따라 하기 단계가 필요할 수 있습니다.
학습 과정에서 따라 하기가 나쁜 것은 아닙니다만 반복하다 보면 (실제로는 잘하지 못하는데) 자기 스스로 잘한다는 함정에 빠질 수 있어서 위험합니다.
따라 하기가 필요하다면 다른 사람 코드를 눈으로 읽으면서 머릿속으로만 구조화를 시도한 후에, 백지에 자기만의 방식으로 작성해보기 바랍니다.
오픈 소스 프로젝트가 아니더라도 여러 해결 방법을 공유하기 좋은 곳으로 개발자 커뮤니티가 있습니다.
저는 10대부터 개발자 커뮤니티에 참여해왔습니다.
PC통신 시절에서 많은 분이 시간을 투자해서 어렵게 자료를 찾아서 공부하고 아무런 대가 없이 공유했습니다.
인터넷이 발달하고 1인 블로그 시대가 되었지만, 여전히 다른 사람에게 긍정적인 에너지를 전달하는 사람들이 부족합니다.
많은 개발자를 만나고 나니 커뮤니티에 가입하는 사람을 두 가지 유형으로 분류할 수 있게 되었습니다.
첫 번째는 해결해야 하는 문제가 있거나 필요에 의해서 학습할 게 있는, 즉 목표가 명확한 사람이 가장 많습니다.
이런 부류의 사람은 자신의 목표를 달성하고 나면 금방 사라집니다.
두 번째는 해보고 싶은 게 있어서 스스로 성장하는 사람입니다.
드물지만 꾸준히 성장하면서 커뮤니티 사람들에게도 영향을 줍니다.
이런 분들을 만나면 에너지를 받고 영향을 받기 때문에 행운입니다.
이렇게 성장하던 분 중에서 일부는 커뮤니티 리더가 됩니다.
커뮤니티가 계속되도록 울타리를 만들고 모두가 성장하도록 영향력을 발휘합니다.
모든 개발자가 커뮤니티 리더가 될 필요는 없지만, 다른 사람에게 영향을 주며 성장하는 개발자가 더 많아지길 바랍니다.
8편에서 소개할 원칙은 ‘배포하기 그리고 다음 버전 준비하기’입니다.
★ 더 나은 개발자로 성장을 꿈꾼다면
★ 먼저 헤쳐온 테크 리더들의 원칙에서 해답을 찾아보세요
“나도 테크 리더가 될 수 있을까? 어떻게 선배 개발자들처럼 성장할 수 있을까? 3년 10년 후에도 개발자로 살아갈 수 있을까? 팀워크는 도대체 어떻게 맞춰야 하는 걸까?”
개발자로 살아가면서 하루에도 천 번을 되묻는 물음에 마켓컬리, 레몬트리, 카카오, 코드스쿼드, 무신사, 몰로코, 데이블, 인프런, 패스트캠퍼스 테크 리더 9명이 답합니다.
지금까지 만나 볼 수 없었던 생존과 성장의 원칙에서 자신만의 해답을 찾아보세요.
김정
소프트웨어 교육 기업 코드스쿼드 대표로 모바일 iOS 마스터를 담당합니다. 케텔 시절 비파툴, 델마당 개발자 커뮤니티를 시작해서 취미 맥개발자 커뮤니티 OSXDev를 거쳐 레츠스위프트 커 뮤니티 운영진으로 끊임없이 살아가는 중입니다.
