Developer's Experience

제가 이것저것 많이 사용해봤기에 할 수 있는 말입니다. 노이즈 캔슬링 기능이 들어간 이어폰이나 헤드폰에 너무 큰 기대를 하지 마세요. 노이즈 캔슬링의 원리는 간단합니다. 주변에서 나는 소음의 정확히 반대되는 소리를 같이 내서 소음을 상쇄시켜서 0으로 만들어주는 것입니다. 아마 푸리에 변환을 배우셨거나 뿌요뿌요를 해보셨으면 대충 이해가 가실 원리입니다. 하지만 노이즈 캔슬링에는 물리학적인 한계가 분명히 있습니다. 노이즈 캔슬링 기기들은 자체적으로 마이크를 가지고 있어서 주변 소리를 듣고 그 반대되는 소리를 생성해주는 원리를 가지고 있는데, 소음이 이어폰이나 헤드폰을 지나서 내 귀에 도달하기까지의 짧은 시간 동안 그 계산을 다 해서 상쇄시키는 것은 쉬운 일이 아니라는 것입니다. 그래서 대부분의 노이즈 캔슬링 기기들은 연속되는 소리, 그러니까 엔진 소리나 바람 소리 같은 것을 잘 제거해주지만 갑작스럽게 발생하는 소리, 그러니까 진짜 소음들은 그렇게 효과적으로 제거해주지 않습니다. 요즘 들어서 프로세서 성능들도 급격히 좋아지고 알고리즘도 많이 발전해서 성능이 많이 좋아지기는 했지만 여전히 태생적인 한계는 분명하다는 것입니다. 그러니 시끄러운 카페에서도 노이즈 캔슬링 이어폰 하나면 나만의 카페를 만들어낼 수 있을 것이라는 기대는 조금 접어두시는 것이 좋습니다. 보통 노이즈 캔슬링 효과가 극대화되는 공간은 비행기 안인데, 지금 시국엔 오래 타기 어려운 물건이므로 노이즈 캔슬링의 가치를 극대화하기 어렵습니다. 그래도 굳이 노이즈 캔슬링의 효과를 유감없이 발휘할 수 있는 공간이 있다면 바로 싱크대 앞입니다. 노이즈 캔슬링 이어폰을 끼고 설거지를 해보신 적이 있으신가요? 안 해보셨다면 한 번 시도해보시길 추천드립니다. 아마 설거지를 하는 건지 명상을 하는 건지 구분하기 어려우실 겁니다. 그러니 하루에 한 번 이상 설거지를 하는 분이라면 꼭 식기세척기를 구입하시길 바라겠습니다.

식기세척기는 설거지에 비해 처리가 매우 느립니다. 한 번 돌리려면 막 한 시간씩 걸리고 그럽니다. 설거지를 직접 하면 요리 과정에서 사고가 발생해서 냄비를 태우거나 하지 않는 이상 보통 10분 내에 끝낼 수 있는데 말이죠. 특히나 설거지는 그 대상의 양에 비례해서 시간이 정직하게 늘어나거나 줄어드는 성질을 가지고 있지만 식기세척기는 꽉 채워서 돌리나 그릇 하나만 넣어두고 돌리나 수행 시간에 큰 차이가 없습니다. 하지만 제가 식기세척기를 추천드리는 것은, 식기세척기를 사용하는 것은 대량의 설거지 대상을 한 번에 처리하는 일종의 배치(Batch) 작업의 특성을 가지고 있기 때문입니다. 식기세척기가 한 번 돌아가는 데 사용하는 자원과 에너지가 많기 때문에 보통 몇 번의 설거지 분량을 모아서 한 번에 처리하는 것이 일반적인데, 이는 두말할 것 없이 대용량 배치의 특성을 고스란히 가지고 있습니다. 적은 양의 설거지를 자주 하는 것에 비해서 집중도가 높고 자원을 몰아서 사용하기 때문에 떨어지는 효율을 상당히 끌어올릴 수 있다는 말입니다. 이게 왜 중요하냐면, 보통 요리를 준비할 때 팬에 들어가는 타이밍에 따라서 혹은 재료의 형태에 따라서 혹은 그냥 기분상의 이유로 상당히 많은 그릇을 사용하게 되는데, 식기세척기가 없다면 그 많은 그릇의 소모가 장차 내 노동력의 소모로 치환되기 때문에 새로운 조리기구를 꺼내는 것을 망설이고 자꾸 뭔가 담아두었던 곳에 다른 재료를 합치게 된다는 것입니다. 그래서 가끔 감자와 파를 같은 그릇에 담아두었다가 한 번에 부어버리는 대참사가 벌어지거나, 고기를 자른 도마에서 파를 썰거나 하는 심각한 위반이 발생할 수 있습니다. 하지만 식기세척기가 있다면 식기세척기가 수용할 수 있는 용량을 초과하지만 않는 다면 - 그래서 식기세척기는 가구 구성원의 수와 상관없이 되도록 큰 걸로 사셔야 합니다 - 작업의 수행 시간이 거의 상수 시간에 가깝기 때문에 마치 32GB 램을 가진 피씨에서 일하는 것 처럼 그릇을 아끼지 않고 요리에 집중할 수 있으며 동시에 위생도 챙기면서 안전하고 효율적으로 요리를 만들 수 있습니다. 하지만 제가 강조하고 싶은 식기세척기의 진짜 가치는 다른 부분에 있는데, 식기세척기가 열심히 돌아가고 있는 동안 인간은 다른 일을 할 수 있습니다. 설령 설거지 분량이 넘쳐나서 식기세척기를 두 번 세 번 돌려야 하는 일이 벌어지더라도 여러분은 중간에 그릇 바꿀 때 빼고는 다른 일을 할 수 있다는 것이고, 유튜브 영상을 보면서 설거지를 하는 것이 아니라 식기세척기를 돌려놓고 유튜브 영상을 볼 수 있다는 말입니다. 바꿔 말하면 그릇의 세척이라는 작업이 동기가 아닌 비동기(Asynchronous)로 이루어진다는 것입니다.

가끔 무언가를 기획하거나 개선시켜야 할 때 마법처럼 쓸 수 있는 키워드가 바로 비동기입니다. 세상만사에 비동기를 붙이시면 바로 혁신적인 모양새의 아이디어를 만들어내실 수 있습니다. 어떤 작업을 동기화된 형태로 처리한다는 말은 작업을 시작하면 끝나서 결과가 나올 때까지, 혹은 설정한 타임아웃이 지날 때까지 기다린다는 말입니다. 예를 들어서 모임 일정을 잡는다고 했을 때 A에게 언제가 괜찮냐고 물어보고, 대답을 받고 다시 B에게 언제가 괜찮냐고 물어보고 아 그 시간은 A가 안 된다고 했는데 다른 시간은 안 되냐 그래 그 시간이면 되겠다고 대답을 받고 또 C에게 같은 질문을 반복했는데 하루가 지나도 답이 없으면 그냥 무시하고 D에게 물어보고 이런 식으로 처리를 하면 동기화된 처리방식이라고 할 수 있습니다. 확실하지만 비효율적입니다. 반면에 단톡방에 A, B, C, D를 모아 두고 언제가 괜찮냐 안 되는 날은 언제냐라고 물어보고 대충 다른 일을 하고 있다가 모든 사람이 대답하면 그때 답변들을 취합해서 일정을 정하면 비동기화된 처리방식이라고 할 수 있습니다. 결과를 취합할 때 좀 머리를 써야 하기는 하지만 효율적입니다. 세상에는 생각보다 동기화된 형태로 처리되는 일들이 많은데, 예를 들어서 몇 년 전까지만 해도 커피 한 잔을 사려면 가서 주문을 하고 커피가 나올 때까지 기다려야 했습니다. 요즘에도 크게 다르지는 않지만, 앱을 통해서 주문을 하고 일을 하고 있다가 커피가 나왔다는 알림이 오면 그때 커피를 받아올 수도 있습니다. 어떤 나라는 택배를 받을때 꼭 수령자에게 직접 전달해야 해서 배달원 한 명이 하루에 배송할 수 있는 택배의 숫자가 극히 적어지는 문제가 있었다고 합니다. 만약 택배를 문앞이나 소화전이나 보관소 등등의 장소에 배송하고 수령자가 필요할 때 가져갈 수 있도록 했다면 효율이 엄청나게 늘었겠지요. 가만히 생각해보시면 요즘 세상이 많이 바뀌었다 싶은 것들 중 상당수가 동기로 처리하고 있던 것을 비동기로 처리하고 있음을 아실 수 있을 겁니다. 그러니 아이디어가 떠오르지 않을 때는 어떻게든 비동기를 욱여넣어 보시는 것을 추천드립니다.

제가 그래서 제가 처음 '개발자들을 위한 뭔가를 만들기 위한 기획안을 써서 가져와 봐라'라는 업무 지시를 받았을 때, 업무를 날로 먹기 위해서 개발자들이 동기화된 방식으로 처리하고 있는 일이 뭐가 있을까를 고민했던 것은 자연스러운 흐름이라고 볼 수 있었을 겁니다. 그리고 놀랍게도 개발자들은 별로 동기화된 방식으로 일처리를 하지 않는다는 사실을 알게 되어서 머리가 복잡해졌습니다. 일감을 할당받고 진행상황을 업데이트하는 것, 중간에 뭔가를 돌려놓고 결과를 받아서 처리하는 것, 누가 도와달라고 했을 때 도움이나 피드백을 주는 것, 필수적으로 받아야 하는 교육을 틀어놓고 다른 일을 하는 것 등등 보통 자신이 중요하다고 생각하는 하나의 일을 제외한 다른 것들은 별도의 스레드에서 돌리면서 결과만 확인하려고 하는 성향이 있었다는 것이지요. 그래서 '개발자들을 위한 뭔가'를 기획하기 위해서 '개발자들'이 무엇인가에 대해서 진지하게 고민해야 하는 상황이 되어버렸습니다.

물론 저는 파트타임으로 기획도 하고, 아키텍트 업무도 하고, 컨설팅도 하고, 강사를 할 때도 있고 마트에서 장을 보는 업무를 수행할 때도 있지만 기본적으로는 개발자로 공부하고 일한 기간과 경험이 압도적으로 길고, 항상 개발자의 정체성을 강하게 가지고 있습니다. 그 정체성이 어찌나 강하던지 몇 년 전에 대학생들에게 멘토링을 겸한 강연을 할 기회가 있었는데, 무대에 올라가자마자 '제가 어떤 직무를 대표해서 여기에 올라왔을 것 같아요?'라고 물어봤을 때 무슨 아이돌 응원법만큼이나 일치된 목소리로 '개발이요!'라는 대답을 받았을 정도입니다. 사람은 그 인생이 얼굴에 담긴다고 하는데 아마 저도 그랬나 봅니다. 솔직히 아마추어 경력 포함 28년, 프로만 쳐도 10년 경력이니까 인생의 가장 많은 부분을 개발자로 살았다고 볼수도 있으니까요. 그래서 저는 기획자의 정체성을 빌어서 '개발자들이 원하는 것이 뭐야?'라고 개발자의 정체성을 가진 저에게 재귀적으로 물어봤고, '제발 뭔가 만드려고 하지 말고 그냥 가만히 있어'라는 대답을 스스로에게 받을 수 있었습니다. 많은 경력을 가진 개발자답게 저는 즉시 종료 조건을 설정했습니다. 윗분들에게 '별로 답이 나오지 않으니 드롭하는 것이 좋겠다'는 의견을 드린 것입니다. 하지만 모든 사람에게는 거창한 계획이 있는 법이었고, 그것은 법인에게도 예외는 아닌지라 과제는 드롭되지 않았고 저에게 커다란 숙제를 안겨주었습니다.

제가 곤란했던 것은 개발자들을 일반화시키는 것은 거의 불가능하다는 사실을 알고 있었기 때문입니다. 예를 들어서 개발자들은 뭔지 모를 개발자 유머를 자기들끼리 돌려보고 막 지네끼리 좋아하는 느낌이 있는데, 제 경험으로 그건 딱 5년 차 정도까지이고, 그 이후에는 코드를 가지고 뭘 표현하거나 웃기려고 하지도 않습니다. 뭔가 체크무늬 옷을 많이 입는다는 소리를 듣기도 한 것 같은데, 논문 소재가 궁했던 시절의 제가 대충 눈으로 세어본 결과 개발팀 사무실의 체크무늬 비중은 2호선 객차의 체크무늬 비율보다 결코 높지 않았습니다. 오히려 체크무늬 옷을 입는 것을 꺼려하는 경향이 있는 게 아닐까 하는 생각이 들 정도였습니다. 개발자들은 커피를 좋아하고 많이 마신다는 인식도 있는데 일단 저도 커피를 하루에 3~4잔 밖에 마시지 않을 정도로 별로 좋아하지 않을뿐더러 단체 주문을 할때면 온갖 에이드에 과일쥬스에 버블티에, 주문하기 죄송할 정도로 다양한 종류의 음료 주문이 들어오곤 합니다. 가끔 개발자들은 자기만의 세계가 있어서 그것을 침범하면 안 되고 어쩌고 하는 식의 열변을 토하던 부장님이 계셨는데, 저는 아직도 그 자기만의 세계라는 것이 무엇인지 깨닫지 못했습니다. 아마도 제가 개발자의 열반에 도달하지 못한 것이거나 그런 것이 없거나 둘 중 하나겠지요. 딱히 정치적인 성향이 편중되는 경향을 찾을 수도 없었고, 외모나 외형도 가지각색, 일을 처리하는 성향도 다양했고, 성격도 물 같은 사람 바람 같은 사람 불 같은 사람 등등 다양했습니다. 딱히 '개발자'라는 집단을 구분해서 일반화시키는 것이 어려웠다는 말입니다.

문득 몇 년 전에 또 다른 '개발자를 위한 뭔가'를 만들 때, 디자이너들이 자신들은 사용자 경험에 전문성을 가지고 있어서 개발자들을 위한 경험을 설계하고 기획하는 것이 어렵다는 말을 듣고 뭔가 살짝 이상한 기분이 들었던 기억이 떠올랐습니다. '개발도구의 사용자가 개발자니까 개발자도 사용자 아닌가요? 그러니까 개발자 is-a 사용자 관계가 성립하니까 사용자 경험은 개발자 경험의 일반화된 형태라는 이행적 관계도 참이 된다고요!'라고 반론을 하려다가 뭔가 찔리는 기분이 들어서 참았던 기억도 생각났습니다. 가끔 어려운 상황에서 일을 하다가 뭔가 무시되면 안 될 것들이 무시되는 상황에서 인권 운동을 펼치고 싶은 마음이 굴뚝같았던 때도 있었지만 그때 주장하고 싶었던 것은 수면시간 보장이나 이동권 제한의 해제와 같은 보편적인 사람의 권리이지 굳이 '개발자의 권리'라고 할만한 것은 없었으니까요. 그래서 '개발자를 위한 뭔가'를 만드려고 하지 말고 '직장인을 위한 뭔가'를 만드려고 하는 것이 좀 더 생각의 폭이 넓어지지 않을까라는 생각을 했습니다.

그래서 저는 기획서를 이리저리 만들고, 수정_수정_추가_최종_의견반영_수정_최종_리뷰완료_수정_최종.pptx 파일을 만들고 최종적인 컨펌을 받았을 때, 이제 만들어야 되는 기획안에 대해서 아무런 감정도 들지 않았습니다. 와, 이걸 다 만들면 진짜 쓸만하겠다 라든지 이 아이디어는 대박이다라든지 이건 우리에게 꼭 필요한 거야 뭐 이런 감정이 모두 지워진 기획안이 완성되었거든요. 물론 개발자라는 집단을 일반화시키는 것은 어렵기 때문에 보편적으로 모든 개발자에게 도움이 될만한 것들을 만들어서 제공하는 것도 쉽지 않다. 차라리 개발자들이 도움을 요청할 때 그것에 비동기적으로 반응해서 필요한 걸 만들어주는 쪽이 좋지 않을까?라는 의심과 그럼에도 불구하고 뭐라도 만들어야 했던 상황들이 복합적으로 작용해서 의욕을 상당히 떨어뜨린 결과물이라고 볼 수도 있겠고, 기획이라는 것을 위해 응당 해야 하는 것들을 하지 못하고 순전히 개인의 경험에 기대어서, 책상에 앉아서 혼자서 사고 실험을 통해 결론을 내야 했던 상황, 그러니까 이렇게 하면 안 되는 것을 알면서도 이렇게 해야만 했던 상황에 대한 짜증의 결과물일지도, 그걸 몇 달 동안 계속 새로운 기획서를 만들어서 리뷰를 받고, 그나마 초반에 있었던 아이디어들이 사라지는 모습을 보면서 정체성을 잃어가는 스스로에 대한 반영일지도 모르겠다는 생각을 했습니다. 그래서 저는 4달 동안 11번 새로 만들고 그 몇 배의 수정을 거쳐서 겨우 컨펌을 받은 기획서가 개발 시작 직전에 드롭되고 며칠 동안 고생해서 써놓은 사용자 스토리를 모두 폐기하고 새로운 사람들의 새로운 기획안으로 진행하겠다는 말을 들었을 때도 아무 감정 없이 그 사실을 받아들일 수 있었습니다.

그래서 저는 새로운 기획서가 완성될 동안 개발환경을 세팅하고, 쓸만한 오픈소스를 검색하고, 공통 모듈을 만드는 등의 소일거리를 하면서 점점 제 정체성을 찾아갔습니다. 그리고 새로운 기획서가 완성되었다는 콜백이 들어오고 제가 만들어야 되는 것들이 분명해지자 비로소 뭔가 일을 할 수 있겠구나라는 기분이 들었습니다. 이미 무의미하게 지나가버린 시간들이 너무 많았고, 덕분에 남은 개발기간과 분량의 압박이 어마어마했지만 사실 그런 경험은 너무나 일상적인 모습이라 오히려 편안한 기분이 들었습니다. 그냥 좀 더 집중하면 되지 않을까 라는 생각을 하면서 별다른 기대없이 노이즈 캔슬링 이어폰을 끼고 주변 소음을 대충 차단하면서 첫 번째 화면을 만들었습니다.