프로그래밍이 꼭 그런 것만을 말하지는 않습니다

안영회2024년 10월 14일About 1 min

프로그래밍이 꼭 그런 것만을 말하지는 않습니다 관련

몇 달 전에 썼던 <의사소통이 즐거운 개발자의 3가지 능력>이 인기 글이 되었습니다. 무엇보다 많은 분들이 의사소통에 대해 관심을 가지고 있다는 사실이 반가웠습니다. 저 역시, 최근에 설계에 관한 글을 썼는데, 이를 두고 지인들과 대화를 나누는 과정에서 인식의 다양성을 느끼는 동시에 의사소통의 중요성을 깨달을 수 있었습니다. 특히 자신이 익숙한 경험이나 지식을 대할 때, 다른 사람의 인식과 경험을 내게 익숙한 대로 판단하거나 걸러내지 않고 그대로 받아들일 수 있다면 사고의 폭을 넓힐 수 있다는 생각이 들었습니다. 개발자의 의사소통에 대해 더 확장해 얘기해 보고자 이런 경험과 관련이 있거나 연상되는 사건을 추려서 글로 엮어 보았습니다.

몇 달 전에 썼던 <의사소통이 즐거운 개발자의 3가지 능력>이 인기 글이 되었습니다. 무엇보다 많은 분들이 의사소통에 대해 관심을 가지고 있다는 사실이 반가웠습니다. 저 역시 최근에 설계에 관한 글을 썼는데, 이를 두고 지인들과 대화를 나누는 과정에서 인식의 다양성을 느끼는 동시에 의사소통의 중요성을 깨달을 수 있었습니다.

특히 자신이 익숙한 경험이나 지식을 대할 때, 다른 사람의 인식과 경험을 내게 익숙한 대로 판단하거나 걸러내지 않고 그대로 받아들일 수 있다면 사고의 폭을 넓힐 수 있다는 생각이 들었습니다. 개발자의 의사소통에 대해 더 확장해 얘기해 보고자, 이런 경험과 관련이 있거나 연상되는 사건을 추려서 글로 엮어 보았습니다.

프로그래밍의 다면적 특성을 보자

첫 번째로 떠올릴 수 있는 사건을 보겠습니다. 이제 막 프로그래밍을 배우는 분들에게 알고리즘(Algorithm)을 설명할 일이 있었습니다. 이를 준비하다 보니 제가 처음 알고리즘을 공부할 때와 지금은 그 쓰임새가 많이 달라졌다는 생각이 들었습니다. 가령, 플로우 차트 같은 표기법만으로 프로그래밍의 할 일을 써 내려갔던 일은 먼 옛날의 일이 되었습니다.

지금은 UI와 기능을 함께 표기하는 기획서가 널리 쓰입니다. 하지만, 그 문서 어디에도 알고리즘이란 표현을 쓰지는 않죠. 흔히 말하는 UI 디자이너나 프론트 개발자를 고려한 내용과 표기법이 쓰입니다. 그러나, 이 방식으로 잘 쓰인 기획서 역시 부족함이 있습니다. 눈에 보이는 화면 이면에서 작용하는 규칙을 담지 않는 경우가 자주 있다는 것입니다. 그도 그럴 것이 기획서가 알고리즘을 나타내는 문서는 아니니까요.

이러한 변천사에 따라 생길 수밖에 없는 간극을 어떻게 전할까 고민하다가 만들어낸 그림이 있습니다.

나중에 설명을 추가해서 <프로그래밍의 다면적 특성 (@graypool)>이라는 이름의 글을 인터넷에 올리기도 했습니다. 여기에는 프로그래밍의 사회적 쓰임과 적용 범위가 달라지면서 펼쳐진 다양한 양상이 담겨 있습니다.

프로그래밍에는, 제작 위탁을 받았다고 하더라도 자기 손으로 무언가 만드는 프로그래머라는 사람이 있기에 필연적으로 창작적 측면이 존재합니다. 동시에 사람이 읽는 것이 아니라 컴퓨터가 결과물을 읽어 들여서 수행하기 때문에 엄격한 규칙성이 존재하기도 하죠. 더불어 개발을 의뢰하는 사람이 있기에 경제성 측면이 생겨났고, 산업에 영향을 끼치면서 기업 형태의 조직적인 협업이 또 프로그래밍을 바라보는 관점이 되었습니다.

따라서, 같은 단어로 ‘프로그램’, 혹은 ‘앱’이나 ‘어플’을 말하더라도 전혀 다른 관점으로 자신이 바라보는 바를 말하는 일이 벌어집니다. 입장이 다른 사람이 이러한 이야기를 할 때 그가 프로그램을 말하는 맥락을 추리해 보면 자신과는 다른 경험과 관심을 가진 사람의 관점을 얻을 기회가 될 수 있습니다.

하지만, 직업 현장에서는 이들 서로 다른 관점이 포용적인 소통보다는 도리어 소모적인 갈등으로 비화하는 경우를 더 많이 봅니다. ‘프로그래밍’을 둘러싼 문제를 다루면서 한쪽의 시각만 강조하고, 다른 쪽의 입장을 무시하는 사람들을 만나는 것이죠. 상대의 입장에 대해 공감을 하지 못하더니 이내 서로의 감정에 상처를 주거나 중요하지 않은 시시비비를 가리는 형국이 되기도 합니다. 게다가 다투는 두 사람이 한 조직에 있다면 사실상 한 배를 탄 경우인데 말이죠.

AI로 인해 급격하게 바뀌고 있는 산업 환경

최근, 인공지능이 산업 전반에 영향을 끼치고 있는데, 프로그래밍 영역에 있어서도 마찬가지입니다. 글을 쓰는 시점 즈음에 인터넷 교보문고에서 ‘컴퓨터/IT’ 분야 일간 베스트 20에는 인공지능 관련 서적이 네 권 있습니다. 자격증 관련 서적이 반이라서 이를 거르면 무려 40%를 차지합니다.

이런 상황에서 앞서 소개한 프로그래밍의 다면적 특성을 어떻게 활용할 수 있을까요? 또 하나의 일화를 기준으로 이야기해 보겠습니다. 제가 번역한 책에 대한 인터뷰를 한 일이 있습니다. 이때 AI의 ‘코딩 자동화’에 관한 질문을 받은 일이 있었습니다.

<출처: <FontIcon icon="fa-brands fa-youtube"/>한빛미디어 유튜브> — <출처: 한빛미디어 유튜브>

앞서 소개한 네 가지 관점으로 AI의 코딩 자동화를 해석해 보겠습니다. 창작적 측면에서는 외로운 작업에 동반자가 생겼다고 느낄 수도 있을 것 같습니다. 최근 회사 동료가 인공지능이 작성한 코드가 자신의 코딩 스타일까지 모방해서 깜짝 놀랐다고 말한 적이 있습니다. 머지않은 미래에 인공지능에게 명령을 줄 때 음성까지 활용하게 된다면 더더욱 ‘동반자’ 같은 느낌을 받을 수 있겠죠.

‘동반자’라고 하면 협업 관점과 연결하지 않을 수 없습니다. 서로 동반자일 때는 협업이지만 의견이 부딪치면 프로그래밍 과정이 고스란히 갈등이 됩니다. 열심히 개발하는 개발자일수록 코딩 스타일을 무시하거나 조직 문화를 해치며 개인행동을 하는 동료들을 받아들이지 못하는 경향도 종종 보게 되는데요. 인공지능은 개발자들을 이 문제에서 벗어나게 해 주는 것일까요?

경제성 측면으로도 살펴볼 수 있습니다. 얼마 전 유튜브 추천으로 본 <손석희 질문들> 영상의 한 장면을 인용할 수 있습니다. 영상에 등장한 황석영 작가는 챗GPT를 써보니 박사학위 받은 사람 10명을 두고 일하는 거 같다고 했습니다.

이미 제 주변에는 주니어 개발자를 키워 일할 바에는 인공지능에게 일을 시키는 편이 좋다고 주장하는 개발자들이 다수 있습니다. 이에 대해서 여러분 입장은 어떤가요? 여운을 조금 남긴 상태에서 인공지능에 대한 이야기는 그만하고 다른 관점에서 이야기를 조금 더 이어가겠습니다.

프로그래밍을 하는 소중한 나

당연하게도 인공지능 기술이 모든 가치를 변하게 하는 것은 아닙니다. 제가 인터뷰 때 받았던 질문, “AI 도구를 활용한 코딩 자동화에 대해 어떻게 생각하는지”에 대한 의견을 ‘객체지향 프로그래밍’을 중요하게 생각하는 지인에게 물은 일이 있습니다. 그의 답변은 정말 인상적이었습니다. 인터뷰를 글로 남기고 싶은 충동이 들 정도였죠. (아쉽게도 그가 허락하지 않았습니다.)

그는 “우리가 즉, 개발팀의 구성원들이 매일 가꾸고 만지는 코드에 대한 문제는 단순히 인공지능이 생산한 코드에 맡길 일이 아니”라는 듯 말했습니다. 마치 정성을 다해 작물을 가꾼 후에 결과를 기다리는 ‘농부의 마음’이 떠올랐습니다.

이번에는 제가 다시 그의 입장을 대변해서도 앞선 관점들에 대해 견해를 말할 수 있습니다. 창작적 측면에서 직업적 뿌듯함과 자신감을 가지려면 코드를 직접 통제하는 느낌이 중요할 수 있습니다. 그래서 중요한 부분에 대해서는 시간을 들이고 생각을 담아 직접 코드를 만드는 일을 택하고자 합니다.

다만, 시간이 부족할 때는 중요하지 않거나 개인적 관심이 떨어지는 부분을 인공지능에 맡길 수 있습니다. 하지만, 그러한 요청은 협업이라고 느끼기보다는 그저 내 일을 일부 덜어주는 로봇 비서처럼 느끼는 것이죠.

내 코드가 소중한 것처럼 소중하게 자기 코드를 다루는 인간 동료와 협업하는 일은 또 다른 보람으로 인공지능 협업과 견줄 수 없는 일입니다. 물론 이 문장들은 그저 상상의 산물이고, 이상적인 상황을 꿈꾸면 쓴 글이긴 합니다.

소프트웨어 프로덕트 정의에 유용한 소통 스킬

마지막으로 프로덕트 관리자로 커리어를 넓혀 가고 있는 주니어 개발자의 경험담을 소재로 이야기를 이어가 봅니다. 그는 제게 이렇게 말했습니다.

“Event page 내 image, video 등만을 보여주는 tab을 신설하고 싶다는 요구사항이었는데요. 처음에는 단순하게 ImageTab으로 구성했더라구요. 그래서 Tab이라는 개념을 빼고, Event에 종속적인 media를 제공하는 것이니 EventMedia라는 개념으로 만드는 게 어떨지 제안하고 그렇게 결정됐습니다.”

듣다 보니 추상적인 사고 훈련이 잘된 개발자가 비즈니스 담당자와 소통을 잘 끌어가는 사례라는 생각이 들었습니다. 아무튼 이렇게 사고 훈련이 된 개발자라면 비즈니스 필요성을 논하는 이와 대화를 할 때, 상대가 생각하지 못하는 가능성에 대해 더 많은 제안을 할 수 있습니다.

예를 들어 볼까요? EventMedia라고 표현한 개념을 활용해 이미지와 비디오를 포괄하는 개념으로 소통한 것인데요. 그 과정에서 탭(tab)이라는 UI 요소와 그 안에 들어갈 내용(사용자가 즐길 미디어)을 구분한 것이죠. 관심사의 분리라는 설계 원칙^[1]을 활용했다고 할 수 있습니다. 그런 원칙을 찾아서 익히지 않더라도 개발자라면 다층적(multi-layered) 아키텍처 활용이나 포토샵의 레이어 적용 따위의 경험을 통해 은연중에 사고 훈련을 하는 경우도 존재할 수 있습니다.

이렇게 개발 과정에서 익힌 사고 능력은 소통 과정에서도 효과를 발휘할 수 있는데요. 복잡한 프로그래밍 문제에 대해 모르는 비즈니스 담당자에게 가능성을 제안하거나 제약을 알려 주어 올바른 방향으로 소프트웨어 프로덕트를 정의하도록 도울 수 있습니다.

다시 앞서 인용한 사례를 보면 이미지와 비디오를 추상화한 EventMedia가 등장합니다. 이렇게 추상화를 하면 필연적으로 실체화(realization)의 여지가 생겨납니다. 무슨 말이냐고요? 앱 따위의 소프트웨어 프로덕트로 실제 구현을 해야 할 경우, 다시 구체적인 사항을 결정해야 한다는 말입니다.

그렇게 되면 다시 개발자의 경험이 빛을 발할 수 있습니다. 예를 들어 다음과 같은 질문을 만들어 내는 일은 경험 있는 개발자에게는 아주 생소한 일은 아닙니다.

“그렇다면, event마다 미디어는 이미지 하나 혹은 묶음 하나이거나 비디오 하나 혹은 묶음 하나로 설정할까요?”

여기에 더하여 프로그래밍 용어를 넣지 않고, 비즈니스 담당자와 해당 문제에 대해 대화를 할 수 있다면 분명 이를 팀의 시너지라고 부를 수 있겠죠. 이렇게 할 수 있으려면 프로그래밍을 보는 관점이 ‘내가 접하는 화면이나 코드’에서 벗어날 수 있어야 합니다.

협업의 중요성과 개취 인정의 필요성

이미 세계 증시를 이끌어가는 기업은 모두 테크 기업입니다. 말 그대로 프로그래밍을 활용하는 수준을 넘어서서 프로그래밍으로 인간 삶 전반에서 더 많은 가치를 창출하는 방향을 연구하고 실현하고 있는 회사들이죠. 국내만 보아도 ‘네카라쿠배’라는 말이 생겼다는 그 자체가 인터넷 기업의 성장을 명확하게 드러내고 있습니다.

이런 현실을 고려하면 프로그래밍을 경제적 측면에서 보자는 이야기는 뻔한 소리에 그칩니다. 그런데 이처럼 거대 가치를 창출하다 보니 프로그래밍을 개인의 창작이나 실력 발휘 측면에서 보는 관점은 약해지기 시작합니다. 점점 더 협업이 중요해지죠.

협업은 물론 프로그래밍 실력도 중요하지만, 인간관계 활동의 중요성이 부각되게 합니다. 저 역시 많은 사람과 협업하는 과정에서 과거에는 몰랐던 다른 사람의 인식과 경험을 인정하는 태도를 익혔습니다. 제 말로는 이를 ‘개취 인정’이라고 하는데요. 이를 늦게 깨달은 것은, 과거에 제가 회사에서 일할 때 개인 취향을 제한하거나 무시하는 문화 속에서 살았던 탓이 아닌가 싶습니다.

반면에 지금은 적극적으로 개취 인정을 했을 때 생산성이 높아질 수 있는 그런 시대가 되었습니다.

마치며

사실 뚜렷한 결론을 갖고 쓰기 시작한 글은 아닙니다. <의사소통이 즐거운 개발자의 3가지 능력>의 인기를 보고 후속작을 하나 더 써보자고 했던 것이죠. 그랬더니 생산성을 위해서 자동화보다는 두 가지 새로운 역량이 필요하다는 것을 깨달았습니다.

하나는 인공지능 활용이고 다른 하나는 바로 개취 인정을 하는 일입니다. 개성이 생산성에 중요한 요소가 되고, 의사소통에 있어서도 각자의 개성과 취향을 인정하는 일이 협업의 생산성에 지대한 영향을 끼친다는 사실을 깨달은 것이죠. 이를 전해보고자 했습니다.

프로그래밍이 꼭 그런 것만을 말하지는 않습니다

자세한 이야기는 <비즈니스 소통에서 관심사의 분리와 일반화의 효과 (@graypool)>에 담겨 있습니다. ↩︎