brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Oct 25. 2023

이제 우리는 모두 프로그래머다

경영자를 위한 HBR Curation

HBR 9-10월호가 출간했고, 늘 그렇듯이 읽고 배운 내용에 대해 '자기화한 지식 기록'을 남깁니다. 이 글은 <이제 우리는 모두 프로그래머다>를 읽고 쓰는 지식 기록입니다. 기사 맨 앞의 부연 설명은 주제에 대한 빠른 이해에 도움을 줍니다.

생성형 AI를 사용하면 누구나 코딩을 할 수 있다.
기업이 이런 변화를 받아들이는 데 도움이 되는 방법은 무엇일까

일반인 개발 Citizen Development

아래 문장을 읽을 때 머릿속에서는 '노코드 현상과 무슨 차이일까?'라고 말했습니다.

일반인 개발은 직원들이 자신의 프로세스와 업무를 개선 및 효율화하고 완전히 자동화할 수 있는 새로운 시대를 열었다.

한글로 검색해 찾은 기사를 보면 큰 차이가 없는 듯도 합니다. 그리고, 영문 위키피디아에도 아직 등재된 개념은 아닙니다. 반면에 영어로 구글링 하면 화려한 결과를 확인할 수 있습니다.

무려 성공 모델까지 예쁜 이미지로 존재합니다. 시각적 유려함은 상업적이란 냄새를 풍깁니다. 많은 업체들이 여기서 돈을 벌려고 하는 듯합니다.

기업 대상 산업계의 금맥인가?

첫 페이지 결과의 화려함 속에는 제가 아는 기업들의 페이지도 있습니다. 글로벌 SaaS 기업인 SalesForce는 <Bridging the App Gap: How Citizen Development Is Changing Business>란 기사를 먼저 보았습니다. 기사에 포함된 아래 이미지를 보니 SalesForce의 솔루션도 로코드(low-code) 기능을 탑재하는 데 이미 상당한 노력을 기울이고 있을 것이란 짐작을 할 수 있습니다.

가트너의 용어 정의도 찾을 수 있었습니다.[1]

A citizen developer is an employee who creates application capabilities for consumption by themselves or others, using tools that are not actively forbidden by IT or business units. A citizen developer is a persona, not a title or targeted role. They report to a business unit or function other than IT.

일반인 개발에 대한 정의는 없고, 개발자에 대한 정의만 있다는 점도 신선하네요. 정의를 보니 직함(title)이나 역할(role)이 아니라 페르소나(persona)라고 표현한 점이 눈에 띄었습니다.

끝없는 자동화와 생산성 그리고 갈등

이렇게 찾아보고 나니 일반인 개발(Citizen Development)이라는 새로운 도전적인 개념[2]을 노코드나 로코드와 구분하는 일은 무용한 일이라 생각이 되었습니다. 노코드나 로코드는 해법의 모양새에 초점을 두었을 뿐이고 일반인 개발은 문제와 해법을 포용하는 비즈니스 기능적 관점의 정의라고 판단합니다.

한편, 실제 사례가 기사에 실렸습니다.

PwC는 '디지털 액셀러레이터digital accelerators' 프로그램이라는 일반인 개발을 위한 광범위한 프로세스를 수립했다.

역사적으로 보면 CASE 도구나 MDA 같은 자동화 시도가 제 기억 속에 있습니다. 마침 2018년에 발표했던 <소프트웨어를 모르는 대한민국 기업의 위기>라는 발표의 한 장면이 떠오릅니다. 영상의 7분 15초 경에 나오는 내용이죠.

MDA는 실패했고, Github 인수로 개발자가 생산하는 코드가 이겼다는 유명 개발자 Rod Johnson의 글을 인용한 것입니다. 과거에 그랬던 것처럼 인류는 계속해서 자동화 시도를 할 것입니다. 누군가는 말이죠. 이는 드러커가 말한 '기업의 생산성'이라는 중대 문제와 관련이 있기 때문에 기업이 존재하는 한 언제나 화제가 될 것이 틀림없습니다.

어떤 프레임으로 현상을 볼 것인가?

이 과정에서 파생하는 문제는 각자 입장에 따라 이해관계가 다르니 갈등이 생긴다는 점입니다.

소수 직원들만 알거나 개발한 직원이 회사를 떠난 지 오래된 일반인 개발 시스템에 의존하게 될 수 있다. 이런 '회색gray IT'의 폭발적 증가와 고장 난 기술 시스템의 재작업 비용은 기업 전반에 중요한 문제다. 적절한 통제와 지침이 없으면 광범위한 일반인 개발이 혼란을 초래할 수 있다.

그럴듯한 지적이지만, 그럴듯하기만 할 뿐인 전혀 실용적이지 않은 지적입니다. <기술 부채는 무엇인가?>에서 썼듯이 개발자에 의존하는 시스템도 '고장 난 기술 시스템의 재작업 비용'을 엄청나게 만들어 내고 있습니다. 아직 둘을 비교할 수 없는 상황에서 기존의 문제는 내버려 두고 새로 생길 일의 문제만 언급하는 것은 프레임 한계입니다. 다시 말해, 자기 관심사만 보는 일이죠.

새로운 개발자 유형의 출현

한편, 기사는 다섯 가지 작업에 대해 조업합니다. 먼저 모집 혹은 채용 관점을 담은 일반인 개발자 모집 및 분류입니다.

예를 들어 존슨앤드존슨은 논리적 사고, 기술 역량, 학습에 대한 적성, 규칙을 기반에 둔 업무 경험을 갖춘 사람을 찾는다고 말한다.

프로그래머가 아닌 일반인 개발자에 적합한 프로필이라고 할 수 있습니다. 그리고 다음 단락에 밑줄을 치며 기사 여백에 'New 개발자 유형'이라고 썼는데 굉장히 끌리는 분류입니다.

일반인 개발자의 유형은 역할에 따라 다양하다. 개선과 변화의 기회를 발견하는 스카우트, 새롭고 더 나은 업무 방식을 개발하는 디자이너나 건축가, 프로세스 개선을 제공하는 애플리케이션을 구축하는 개발자나 자동화 전문가, 이전 및 신규 프로세스의 상태를 연구, 분석, 보고하는 데이터과학자나 분석가 등이 포함된다.

백엔드/프론트나 자바/닷넷/파이썬 개발자 같이 기술이나 솔루션 중심의 분류에 비해 생산성의 어떤 측면을 지향하느냐에 초점을 맞춰진 분류나 작명은 목적 지향적이란 점에서 훨씬 더 매력적으로 다가옵니다. 컬리 박성철 님과 인터뷰할 때 들었던 '해커'란 표현도 떠올랐습니다.

안전한 데이터 접근과 사용을 위한 기업 IT 아키텍처

두 번째는 개발자 교육 및 인증에 대한 부분입니다. 오랜 아키텍트 경험은 아래 문단을 보고 여러 가지를 준비(?)하게 만듭니다.

이렇게 개발된 시스템은 일반적으로 기존 트랜젝션 시스템에서 데이터를 연결, 변경 또는 추출 및 분석하기 때문에 개발자는 일반적으로 안전한 데이터에 대한 접근과 그 사용을 위해 기업 IT 아키텍처 및 지침에 대한 이해가 필요하다.

당장은 최근 있었던 페북 대화가 떠올랐습니다. <multi-architecture 마이그레이션에 대한 3단계 접근 방식>이란 글은 제목만 보았는데 HBR 기사가 말하는 상황으로 변모할 때 필연적으로 고려할 문제와 비슷한 패턴을 다루는 해법입니다.[3]

좀 더 관련성이 보장된 글은 제가 쓴 <Strangler Fig 패턴과 점진적 IT 투자>입니다. 하지만, 이는 시스템 구성 측면에서 아키텍트 관점일 뿐입니다. 기사가 언급한 '안전한 데이터에 대한 접근과 그 사용을 위해 기업 IT 아키텍처 및 지침'에서 아키텍처만 다룬 것이죠.

안전한 데이터 접근과 사용을 위한 기업 IT 지침

지침을 만드는 일에서 제가 본 최고의 샘플은 위챗 미니프로그램 개발자 환경입니다. 한국에서는 아직 그만한 예를 찾아보지 못했습니다.

하지만, 완전한 지침이 구축되기 이전이라면 교육으로 보완해야 합니다.

최소한 조직의 누군가가 어떤 애플리케이션이 개발됐는지, 누가 개발했는지, 애플리케이션의 용도가 무엇인지, 엔터프라이즈 등급으로 인증됐는지 여부를 추적해야 한다.

경력이 지긋한 개발자라면 과거에 프로그램이나 함수 상단에 붙이던 개발자 주석이 떠오를 수도 있겠습니다. 저처럼 말이죠.

일발인 개발 인프라 구축과 커뮤니티

세 번째는 일반인 개발 인프라 구축에 대한 내용입니다. 앱스토어와 같은 '피처 스토어feature sotre(재사용 가능한 다양한 기능의 저장소)'도 언급합니다. 하지만, 이러한 솔루션 구축 방법 이전에 중점을 둘 부분을 다음과 같이 제시합니다.

일반인 개발자의 영향을 개선하기 위한 중요한 요건 중 하나는 사업 단위가 소유한 생산 환경에 솔루션을 연결하는 것이다.

이전 HBR 기사에서 비롯한 <비허가형 기업 만들어가기>나 <진격을 위한 비허가형 기업> 내용도 떠오릅니다.

네 번째는 커뮤니티 학습 강화인데, 이는 앞서 살펴본 일반인 개발 인프라 구축의 일환으로 볼 수도 있을 듯합니다.

커뮤니티는 문제가 발생했을 때 해결책을 제시하거나 사람들이 개발을 포기하지 않도록 지지해 줄 수 있다.

마지막 다섯 번째는 자동화로 창출된 가치를 관리할 준비입니다.

일반인 개발이 창출하는 가치를 제대로 측정하지 않는다면 여기에 대한 투자에 의문을 제기하는 목소리가 나올 가능성이 높다. <중략> 금전적으로 가치를 평가하기 어렵다. <중략> 가장 쉬운 측정 방법은 이전에 사람이 수행하던 작업이 일반인 개발자 자동화를 통해 절약된 시간을 측정하는 것이며 필자가 관찰하거나 협력한 여러 회사는 누적 절약 시간을 수백만 분으로 계산했다.

<개발의 시장 가치 측정을 위한 첫 발을 떼다>와 <프로그램의 가치 측정과 새로운 제조 회계를 위한 여정> 등에서 야심 차게 도전했지만 아직은 결과를 내지 못하고 있는 문제네요. 이 기회를 빌어 반성하고, 꾸역꾸역을 실천하고자 합니다.

마치며

요즘 실력 있는 개발자 부족은 쉽게 확인할 수 있습니다.

디지털 혁신은 이미 거의 모든 조직에 필요하며 이를 구현하기 위한 자격을 갖춘 전문가는 앞으로도 계속 부족할 것이다. 결국 일반인 개발자가 이런 노력의 주요 엔진이 될 수 있다.

이를 고려하면 저자들의 이야기가 조금 더 와닿습니다. 그리고 다음 내용을 읽어 보면 마윈이 말한 IT에서 DT로의 전환이란 표현을 떠올립니다.

기계 학습 운영 시스템은 이미 ML 모델에 대한 지속적인 거버넌스와 알고리즘 정확도를 갖고 있으며 다른 유형의 일반인 개발 기술에 대해서도 관련 시스템이 등장할 가능성이 높다.

주석

[1] 정의 중에서 하나의 단락만 인용했습니다. 필요한 분이 있을 수 있어서 DeepL 번역 결과도 추가합니다.

시민 개발자는 IT 또는 비즈니스 부서에서 적극적으로 금지하지 않는 도구를 사용하여 자신 또는 다른 사람이 사용할 수 있는 애플리케이션 기능을 만드는 직원을 말합니다. 시민 개발자는 직책이나 대상 역할이 아니라 하나의 페르소나입니다. 이들은 IT가 아닌 다른 사업부나 부서에 보고합니다.

[2] 도전적인이라고 표현한 이유는 <경쟁하지 말고, 독점을 창조하라>의 마인드를 가진 일부가 창조하려는 개념이라는 뜻에서 붙인 수사입니다.

[3] HBR 기사와는 맥락이 다르니 꼭 부합한다는 의미는 아닙니다. 출처를 보니 클라우드 네이티브 진영에 치우친 내용일 가능성도 있습니다.