「취미 프로그래밍」이 최강인 이유: 도메인 전문가 × AI를 통한 내제 개발의 설계 사상

이 기사에서 전달하는 것

자신의 업무를 개선하기 위해 스스로 VBA나 GAS를 익혀 코드를 작성하며 현장의 과제를 해결해 온 사람들이 모인 환경에서 DX(Digital Transformation) 추진 정비를 수행할 경우,

Pull Request(PR)도, 인간에 의한 코드 리뷰(Code Review)도, 정말로 필요할까요?

결론부터 말씀드리면, 도메인 지식(Domain Knowledge)을 가진 현장의 전문직이 자신들의 업무를 위해 코드를 작성하는 경우, IT 업계의 표준적인 개발 플로우(Development Flow)를 그대로 가져올 필요는 없습니다. 오히려 그것을 가져옴으로써 현장을 망가뜨릴 리스크가 더 높습니다.

그 대신, 「장인 + AI」라는 조합을 축으로 삼을 것을 제안합니다.

1. 왜 「취미 프로그래밍」이 최강인가

Zenn에 핵심을 찌르는 기사가 있습니다.

이 기사가 밝히고 있는 것은, 이 기사에서 말하는 「쓰레기 코드(Kuso Code)」——유지보수가 불가능하고 전체 구조를 이해할 수 없어, 수정이 지수 함수적으로 어려워지는 코드——가 발생하는 조건은 개인의 능력이나 도덕성의 문제가 아니라, 제도와 구조의 문제라는 점입니다.

취미 프로그래밍은 쓰레기 코드가 발생하기 어려운 구조로 되어 있습니다. 우선, 자발적으로 만들고 싶은 사람만이 만들기 때문에, 잘 이해하지 못한 채 제멋대로인 것을 계속 만들어 나가는 일은 그리 자주 일어나지 않습니다. 그리고 만든 것을 고치는 것도 자기 자신이기 때문에, 「오늘의 내가 대충 만들면, 내일의 내가 지옥을 본다」라는 현실적인 압박이 품질의 안전장치로서 작동합니다.

반면, 업무 프로그래밍에서는 조건이 역전됩니다. 잘 이해하지 못하더라도 외압에 의해 착수가 강제되고, 평가 기한이 먼저 확정되며, 책임이 분산됩니다. 만든 사람과 고치는 사람이 일치하지 않기 때문에, 「고통이 자신에게 돌아오지 않는」 구조가 됩니다. 그 결과, 쓰레기 코드는 악의의 산물이 아니라, 합리적인 선택의 집적으로서 태어납니다.

IT 업계가 도입해 온 PR이나 인간에 의한 코드 리뷰는 이러한 구조적인 문제에 대한 방어책입니다. 소유권이 분산된 집단 속에서 코드의 붕괴를 어떻게든 막기 위한 브레이크로서 기능합니다.

브레이크가 필요한 이유는, 브레이크를 밟지 않으면 폭주하는 구조로 되어 있기 때문입니다.

그렇다면, 그 구조가 처음부터 존재하지 않는 환경에서는 어떨까요?

2. 도메인 전문직의 코딩은 「취미」에 가깝다

현장의 전문직——제조, 연구, 의료, 법무, 교육, 행정 등——이 자신들의 업무를 위해 코드를 작성하는 경우, 앞서 언급한 쓰레기 코드를 낳는 전제 조건의 상당수가 처음부터 존재하지 않습니다.

소유권이 명확합니다. 자신이 현장의 과제를 해결하기 위해 작성한 툴은 자신이 계속 사용합니다. 「나중에 다른 누군가가 적당히 고쳐 쓸지도 모른다」라는 체념이 없습니다.

도메인 지식(Domain Knowledge)이 직결되어 있습니다. 「사양(Specification)을 내는 사람」과 「코드를 쓰는 사람」이 동일 인물이거나 매우 가까운 거리에 있기 때문에, IT 업계에서 자주 발생하는 「사양 전달 게임에 의한 오해」가 구조적으로 발생하기 어렵습니다.

당사자 의식이 높습니다. 자신이 만든 툴로 현장의 업무가 돌아가기 때문에, 작동하지 않으면 자신이 곤란해집니다. 품질에 대한 동기부여는 외부로부터의 강제가 아니라 내부로부터 나옵니다.

이 상태는 쓰레기 코드를 낳는 구조의 대척점입니다. 바꿔 말하면, 업무의 맥락이면서도 「취미 프로그래밍」이 가진 최상의 특성을 구조로서 갖추고 있습니다.

IT 업계의 표준적인 PR 플로우가 지키고자 하는 것 중, 코드의 질이나 사양의 정합성은 이 환경에서는 다른 경로를 통해 자연스럽게 담보됩니다. 참고로, 속인화(Personification) 방지에 대해서는 제6절에서 다룹니다.

3. 인간이 리뷰하는 입장에 서면 어떤 일이 일어나는가

그렇다고는 해도, 「품질을 높이기 위해 코드 리뷰를 도입하자」라는 제안은 얼핏 합리적으로 보입니다. 왜 그것이 현장에 녹아들지 못하는 걸까요?

인간이 「감사하는 측」의 입장에 놓이게 되면 심리적인 변화가 일어나기 쉽습니다. 타인의 코드에 「지적할 권한」을 가진 순간, 본래의 목적인 품질 향상보다 「지적할 수 있다는 것」 자체가 목적화되기 쉽습니다.

이는 IT 업계의 「마사카리(Masakari, 도끼) 문화」로 이야기되는 현상——정론이라는 이름의 도끼로 상대를 때려눕히는 듯한 고압적인 리뷰——뿐만이 아닙니다. 보다 일상적인 레벨에서도 일어납니다. 버그도 무엇도 아닌 「취향의 작성 방식」 강요, 트집 잡기식 지적, 자신이 더 상위에 있음을 무의식적으로 보여주려는 행동 등이 그것입니다. 이는 특정 인간이 나쁜 것이 아니라, 구조가 인간의 그러한 성질을 끌어내는 것입니다.

비 IT 업계의 현장에서 자발적으로 코드를 작성하게 된 사람들의 팀에, 갑자기 「누군가가 감사(Audit)하는 메커니즘」을 도입하면 어떤 일이 벌어질까요? 심리적 안전성(Psychological Safety)이 손상되고, 코드를 내놓는 것 자체에 위축됩니다. 어렵게 길러온 장인의 당사자 의식과 자부심이 외부로부터의 감사 분위기에 의해 식어버립니다.

그래서 인간에 의한 리뷰에 의존하지 않는 품질 확보 수단으로서, 제4절에서 AI 리뷰를 소개합니다.

4. 개발자 본인 이외의 사람에 의한 최종 리뷰가 불필요한 이유: 「사양의 정답」을 누가 알고 있는가

IT 업계에서 코드 리뷰(Code Review)가 필요한 핵심 이유는 사실 「사양(Specification)의 오해를 방지하는 것」에 있습니다.

코딩의 세계에는 품질 확보를 위한 관문이 여러 개 존재합니다.

「제1관문」으로서, 구문 오류(Syntax Error)나 포맷을 자동으로 체크하는 툴이 예전부터 존재해 왔습니다.

「제2관문」으로서, 최근 이용 가능해진 LLM(대규모 언어 모델)에 의한 리뷰가 있습니다.

다만, 버그의 대부분은 구문 오류나 단순한 실수가 아닙니다. 「A의 조건일 때는 B의 처리를 해야 하는데, C로 되어 있다」와 같이, 도메인 지식(Domain Knowledge)이 얽힌 사양의 오해에서 발생합니다. 이러한 버그는 정적 분석 툴(Static Analysis Tool)로는 검출할 수 없습니다.

그렇기에 「제3관문」으로서 사양을 이해하고 있는 인간의 눈이 필요해 왔습니다.

하지만 도메인 전문가가 자신의 현장을 위해 코드를 작성하는 경우, 사양의 정답을 누구보다 잘 알고 있는 것은 리뷰어가 아니라, 도메인을 깊이 이해하고 있는 개발자 본인입니다.

따라서 IT 업계의 문맥에서 사양의 타당성을 확인하기 위해 필수적이라고 여겨지는 인간에 의한 「제3관문」은, 이 환경에서는 원래 불필요합니다. 필요한 것은 제1·제2관문뿐이며, 이것들을 자동화할 수 있는 환경만 구축할 수 있다면 업계 표준의 중후한 PR(Pull Request) 플로우가 지키고자 했던 것의 대부분을 커버할 수 있습니다.

다음 절에서는 이 제1·제2관문의 정비를 구체적으로 제시합니다.

5. 「장인 + AI」를 위한 환경 정비

제1관문: 텍스트화와 버전 관리의 로컬화

Excel 매크로(VBA를 포함한 .xlsm 파일)나 Google Apps Script(GAS)는 지금까지 바이너리 또는 웹 에디터로서 관리되어 왔습니다. 이 상태로는 Git으로 차이(Diff)를 낼 수 없기 때문에 변경 이력을 추적할 수 없으며, AI에게 코드를 전달하여 해석을 요청하거나 사양을 지정하여 코드를 작성하게 할 수도 없습니다.

이 제약을 해소하는 것이 텍스트화 툴입니다.

이렇게 텍스트화된 코드를 Git으로 로컬 관리합니다. 중요한 것은 Git을 「타인과 공유·감시하기 위한 장소」로 사용하는 것이 아니라, 「자신의 작업 이력을 안전하게 보관하고 언제든 되돌릴 수 있도록 하기 위한 도구」로 사용하는 것입니다.

제2관문: AI를 에디터에 심기

중앙의 PR 시스템에서 AI를 구동하는 것이 아니라, 각자의 IDE(VS Code 등)에서 코드를 작성하는 바로 그 순간에 AI와 대화(Wall-hitting)합니다. 타인에게 지적받으면 기분이 좋지 않지만, AI가 지적하는 것이라면 순순히 고칠 수 있습니다.

AI는 감정을 가지지 않습니다. 거드름을 피우지도 않고, 「왜 이런 식으로 작성했어?」라는 압박도 없이, 담담하게 「여기에 문제가 있을 가능성이 있습니다」, 「이렇게 다시 쓰면 읽기 쉽습니다」라고 알려줍니다. 타인에게 버그를 발견되어 창피를 당하기 전에, AI와 1대 1로 대화하며 다듬은 뒤 현장에 투입할 수 있습니다.

장인의 자부심이 지켜진 채로 코드의 품질이 올라갑니다. 이것이 「제2관문의 로컬화」가 가진 최대의 메리트입니다.

6. GitHub를 「지식의 차트(Knowledge Chart)」로 사용하기

조직에서 이 메커니즘을 운영하기 위해서는 아직 필요한 것이 있습니다. 그것은 지속성의 담보입니다. 하지만 GitHub와 최신 LLM을 결합함으로써 해결할 수 있습니다.

먼저, GitHub Organization 안에 리포지토리(Repository)를 공유해 둠으로써 담당자가 바뀌어도 이어서 시작할 수 있습니다. 하지만 중요한 것은 이 리포지토리를 「전원이 상호 간에 감시·평가하는 장소」로 사용하지 않는 것입니다.

기본적인 구조는 단순해도 상관없습니다. 하나의 리포지토리를 한 사람이 전담하여 키워 나갑니다. GitHub는 그 백업이자 다음 세대로 넘겨주는 바톤입니다.

의료 현장이나 제조업의 장인 세계에서 차트나 시공 기록이 남는 것처럼, 코드의 변경 이력이 쌓여갑니다. 「왜 이 기능이 추가되었는가」의 경위도 커밋 메시지(Commit Message)나 변경 차이(Diff)로서 남게 됩니다.

담당자가 바뀌었을 때, 후임자는 그 코드를 그대로 AI에게 읽히며 "이 도구가 무엇을 하고 있는지 해설해줘"라고 부탁할 수 있습니다. 과거의 "타인이 작성한 코드는 해독 불가능"했던 시대와는 달리, LLM이 우수한 번역자이자 해독자로서 기능합니다. 속인화(Individualization) 리스크는 현대에 들어 과거보다 훨씬 낮아졌습니다.

7. 육성이 필요할 때는 「전문직형 OJT」를 그대로 사용한다

자발적으로 성장하는 사람뿐만 아니라, 새로운 멤버를 육성해야 할 필요가 생겼을 때 IT 업계의 중후한 리뷰(Review) 문화를 도입할 필요는 없습니다.

의료·제조·법률 등 많은 전문직 현장에는 「기간 한정의 동행 → 자립」이라는 육성 프레임워크가 뿌리내려 있습니다. 숙련자가 되기 전까지만 선배가 옆에서 도와주고, 자립한 후에는 자신의 책임하에 움직입니다. 이 프레임워크를 개발에도 그대로 사용할 수 있습니다.

견습 기간: 교육 담당자가 옆에서 설계 방식이나 업무 플로우(Flow)와 코드의 대응 관계를 전달합니다. 단, 구문 오류(Syntax Error) 수정과 같은 기초적인 사항은 AI에게 물어보게 하고, 선배는 "이 업무 흐름을 도구로 어떻게 표현할 것인가"라는 대국적인 상담 상대 역할에 전념합니다. -
자립 후: 자신만의 리포지토리(Repository)를 갖고, AI를 파트너 삼아 독립독보적인 장인으로서 움직입니다.

많은 현장에서 발생하고 있는, 교육 담당자의 부담이 너무 커서 육성 제도가 붕괴되는 문제를 AI를 통한 「기초 교육의 외주화」로 대폭 경감할 수 있습니다.

마치며: 현장에 주권을 되찾다

IT 업계의 표준적인 PR(Pull Request) 플로우는 스킬의 편차가 있는 대량의 엔지니어를 중앙집권적으로 통제하기 위해 만들어진 메커니즘입니다. 분업을 통해 소유권이 분산된 환경에서 코드의 붕괴를 막는 브레이크로서 기능합니다.

그 메커니즘을, 쓰레기 코드(Kuso-code)를 낳는 구조적 조건이 처음부터 존재하지 않는 현장에 수입할 필요는 없습니다. 오히려 장인의 당사자 의식과 자부심을 식게 만들 리스크가 더 큽니다.

한편, 일본의 많은 조직에서는 업무 시스템 개발을 시스템 벤더(System Vendor)에 외주 주는 방식이 오랫동안 지속되어 왔습니다. 그 구조가 만들어내기 쉬운 것은 도메인 지식(Domain Knowledge)과 기술의 단절, "납품하면 끝"이라는 당사자 의식의 희박함, 그리고 현장에 맞지 않는 시스템입니다.

현장의 전문직이 자신들의 과제를 이해하고, 스스로 코드를 작성하여 해결해 나가는 내제(In-house) 접근 방식은 이러한 구조에 대한 반전입니다.

「장인 + AI」라는 조합으로 최고의 환경(devkit이나 IDE)과 최상의 무기(AI)만을 갖추어 두고, 나머지는 각자의 자율성에 맡깁니다. 그것이 인간관계의 스트레스를 유발하지 않으면서 품질을 높이고, 현장에 주권을 되찾아오는 가장 성공 확률이 높은 방법이라고 생각합니다.

VBA 개발 환경의 텍스트화에 대해서는 xlsm_devkit 기사도 참조해 주세요.

Discussion