AI와 개발한 1년 — 사라진 건 없고, 달라진 건 많다
이 글은 2026년 3월에 쓴 「시니어 개발자가 AI와 6개월간 25만 라인의 시스템을 만들며 발견한 것들」 이후 무엇이 달라졌는지를 다루는 후속 시리즈의 첫 글입니다.
작년 8월 첫 커밋을 했습니다. 1년 2개월이 지난 지금, 코드는 약 44만 줄이고 커밋은 3,185개, 컨트리뷰터는 여전히 1명입니다.
이 숫자를 자랑하려는 글은 아닙니다. 코드를 AI 에이전트에게 맡길 수 있게 되면서 개발자의 가장 비싼 일이 가장 싼 일이 됐습니다. 그런데 에이전트는 아직 혼자 두면 안 됩니다. 그래서 지난 1년 동안 제가 실제로 한 일은 코드를 짜는 일이 아니라, 에이전트의 진행과 결과를 통제하고 개선하는 닫힌 작업 흐름을 만드는 일이었습니다.
이 시리즈는 그 작업 흐름에 대한 이야기입니다. 1편에서는 제가 생각하는 하네스 엔지니어링과 전체 흐름을 한 장의 지도로 보여드리고, 이어지는 다섯 편에서 각 지점을 사례와 함께 풀겠습니다.
3월 이후 8개월
올해 3월, 「시니어 개발자가 AI와 6개월간 25만 라인의 시스템을 만들며 발견한 것들」이라는 글을 썼습니다. AI는 읽었다고 착각하고, 문서는 스냅샷일 뿐이며, 규칙은 만드는 것보다 지켜지게 하는 게 어렵다는 이야기였습니다. 그 해법으로 Rule Guard, 컨텍스트 압축 시점의 훅, 에이전트 관측 도구 Baden을 소개했습니다.
그 뒤 8개월 동안 바뀐 것을 한 장에 담으면 이렇습니다. 제 리포 44개에서 하루에 바뀐 코드 줄 수를 달마다 중앙값으로 본 것입니다.
모노레포 바깥에도 이 서비스를 위해 만든 라이브러리와 도구가 여럿 있습니다. 그래픽 엔진, 수식 편집기, 다이어그램 DSL 같은 것들입니다.
규모보다 중요한 변화는 작업 흐름의 무게중심이 옮겨간 것입니다. 3월의 장치들은 모두 리포 안에 있었습니다. CLAUDE.md에 지침을 두고, Rule Guard가 규칙을 검증하고, 에이전트가 행동을 Baden에 보고했습니다.
솔직히 말하면 Baden은 그 뒤로 “모니터링이 된다” 수준에 머물렀습니다. 위반이 기록되는 건 보였지만, 그 기록을 읽고 룰을 고치는 일은 손이 많이 갔습니다. 리포는 계속 늘었고, 리포마다 들어가 기록을 감사할 시간은 부족했습니다. 룰을 세팅하고 갱신하는 일도 각 리포의 구현 에이전트에게 지침으로 맡겨두고 있었습니다. 자기 코드를 자기가 심판하지 않게 하려고 Rule Guard를 따로 세웠는데, 정작 룰 자체는 구현하는 쪽이 관리하고 있었던 셈입니다.
지금은 설계, 룰, 리뷰가 리포 밖의 격리된 환경에서 검토되고 감사됩니다. Baden에 쌓인 위반 기록은 그 감사가 읽어 가는 데이터가 됐고, 감사 결과는 룰 변경 제안이 되어 리포로 돌아옵니다. 지켜보던 구조가 고치는 구조가 됐습니다. 이 차이를 설명하려면 먼저 요즘 많이 쓰이는 말 하나를 짚어야 합니다.
하네스 엔지니어링이라는 말
올해 2월 OpenAI가 「Harness engineering」이라는 글을 냈습니다. 3명에서 7명으로 늘어난 팀이 5개월 동안 약 100만 줄을 만들었고, 사람이 직접 쓴 코드는 한 줄도 없었다는 내용입니다. 핵심 원칙은 “Humans steer. Agents execute.” 그 뒤로 하네스 엔지니어링은 업계의 공통어가 됐습니다.
제 3월 글은 그보다 3주쯤 뒤에 나왔습니다. 서로 모르는 상태였지만 닿은 결론이 꽤 비슷했습니다. 기계적으로 검사할 수 있는 건 린터와 테스트에 맡기고, 의미와 맥락은 LLM이 판단하게 층을 나눈다는 점이 대표적입니다. 저는 이걸 방향이 맞다는 신호로 받아들였습니다.
그런데 지금 통용되는 정의들을 읽다 보면 한 가지가 계속 걸립니다. 대부분 에이전트 쪽에서 출발합니다. CLAUDE.md나 AGENTS.md를 어떻게 쓸지, MCP와 스킬과 훅을 어떻게 엮을지, 서브에이전트를 어떻게 나눌지. 에이전트를 감싸는 설정과 도구를 잘 짜서 출력 품질을 높이는 기술이라는 겁니다. 틀린 말은 아닙니다. 저도 그 일을 매일 합니다.
다만 저는 출발점이 반대쪽에 있다고 생각합니다.
명제는 그대로다.
소프트웨어는 결함 없는 구조로 성장할 수 있어야 합니다. 이 명제는 AI에게 코드를 맡기든 맡기지 않든 같습니다.
소프트웨어를 이루는 것들, 즉 컨셉, 설계, 코드, 테스트, UX는 AI 이전에도 있었고 앞으로도 있을 겁니다. AI로 달라진 건 생산성, 그중에서도 코드의 생산성입니다.
일 사용자 100명짜리 게시판과 1억 명짜리 게시판을 떠올려 보면 됩니다. 둘 다 글을 쓰고, 목록을 보고, 댓글을 답니다. 기능은 같습니다. 하지만 1억 명짜리를 100명짜리처럼 만들면 1분도 버티기 어려울 겁니다. 제품을 구성하고 다루는 방법이 완전히 달라야 합니다.
코드 생산성이 폭증한 지금의 개발이 그렇습니다. 구성 요소는 그대로인데, 그걸 다루던 방법은 사람의 손 속도에 맞춰져 있었습니다. 제가 생각하는 하네스 엔지니어링은 에이전트 설정 기술이 아니라, 이 바뀐 조건에서 명제를 지키도록 개발 과정 전체를 다시 짜는 일입니다.
외부 데이터도 같은 방향을 가리킵니다. 2025년 DORA 보고서는 AI를 증폭기로 봅니다. AI 도입은 배포 처리량을 끌어올렸지만, 배포 불안정성도 함께 올랐습니다. 생산량만 늘리고 다루는 방법을 바꾸지 않으면 결함도 같이 늘어난다는 뜻입니다.
저에게 이 문제는 낯설지 않았습니다. 이전 회사에서 9년 동안 70여 명이던 개발 조직이 수백 명으로 커지는 걸 안에서 겪었습니다. 월 20개 남짓 만들던 마케팅 앱을 월 400~600개까지 만들 수 있는 빌더도 만들었습니다. 생산량이 폭증할 때 품질을 지키는 체계를 만드는 일, 지금 하는 일은 그때와 구조가 같습니다. 달라진 건 늘어난 생산량의 주인이 사람이 아니라 에이전트라는 점입니다.
닫힌 루프의 지도
제가 1년 동안 만든 작업 흐름은 한 문장으로 줄일 수 있습니다. 설계를 하고, 설계와 룰을 기반으로 구현을 시키고, 기계가 검증하고, 그 결과로 설계와 룰을 계속 고치며 제품을 키우는 닫힌 구조입니다.
루프는 두 겹입니다. 바깥 루프에서는 설계를 리포 밖에서 검토하고, 리포 안에서 구현하고, 기계가 검증하고, 그 결과가 다음 설계로 돌아갑니다. 안쪽 루프는 구현과 룰 사이를 돕니다. 구현 중에 쌓인 룰 검사와 위반 기록이 리포 밖 감사로 넘어가고, 감사가 낸 룰의 신설·개정·폐지 제안이 다시 리포로 들어갑니다. 어느 쪽이든 중요한 건 돌아가는 화살표입니다. 결과가 설계와 룰로 돌아가지 않으면, 같은 실수가 다음 PR에서 또 나옵니다.
설계는 구현 컨텍스트 밖에서 검토한다
설계안은 대개 구현 에이전트와 함께 씁니다. 코드베이스를 읽고, 제약을 확인하고, 대안을 견주며 결정을 쌓아 갑니다. 그런데 같은 세션에서 검토까지 하면, 검토는 그 결정이 만들어진 경로를 그대로 물려받습니다. 전제를 왜 택했는지 이미 알고 있으니 전제 자체를 의심하지 않고, 함께 읽은 파일만 다시 보고, 함께 버린 대안은 다시 꺼내지 않습니다. 맥락을 공유한 검토자는 사각지대도 공유합니다.
그래서 설계 검토를 구현 컨텍스트에 오염되지 않은 샌드박스로 옮겼습니다. 검토할 커밋을 고정한 스냅샷 위에서, 처음 보는 세션이 설계 문서와 코드를 읽습니다. 그리고 리포 안에만 머물지 않고 외부 레퍼런스를 충분히 찾아봅니다. 같은 문제를 다른 곳에서는 어떻게 풀었는지, 쓰려는 라이브러리의 공식 문서는 뭐라고 하는지. 해 보니 이 부분의 효과가 가장 컸습니다.
검토는 한 사람이 보고 끝나지 않습니다. 초안 검토자가 지적을 내면, 검증 검토자가 그 지적이 실제 코드와 자료에 근거하는지 다시 봅니다. 설계를 모르는 독자에게 문서만 주고 이해되는지 시험하기도 합니다. 설계 검토가 워낙 자주 일어나서 이 과정을 Assayer라는 도구로 만들었습니다. 독립된 검토는 설계안의 결함을 찾는 데서 끝나지 않았습니다. 여러 설계를 가로질러 보자 설계 사이에 반복되는 패턴이 드러났고, 저는 설계 하나가 아니라 넓은 범위를 효과적으로 내려다볼 수 있는 환경을 갖게 됐습니다.
Assayer의 설계 검토. 설계마다 결함, 결정 필요, 개선 지적이 쌓이고, 검토에서 뽑힌 카탈로그 엔트리가 함께 남습니다. 화면의 비용은 API로 환산한 비용으로 검토 크기를 가늠하기 위한 장치일 뿐이며, 실제 지출은 구독 비용입니다.
스펙 주도 개발(SDD)과 비슷해 보일 수 있지만 방향이 다릅니다. SDD가 스펙에서 코드를 만들어내는 쪽이라면, 이 검토는 설계를 코드와 바깥 세계에 비춰 확인하는 쪽입니다. 부수효과도 있었습니다. 관리되지 않던 설계 문서를 다시 만들어 검토에 넣다 보니, 설계 문서의 형태 자체를 표준화해야 한다는 걸 알게 됐습니다. 문서가 검토 루프 안에 있어야 썩지 않는다는 것 그것이 문서의 신선도를 유지할 유일한 방법이란 걸 확인할 수 있었습니다.
룰은 리포 밖에서 감사한다
3월에 만든 룰 체계는 지금도 돌고 있습니다. CERES108의 룰셋은 룰 파일 32개, 조항 615개입니다. 달라진 건 룰을 누가 돌보느냐입니다.
룰 감사는 이제 리포 밖에서 일어나고, 그 감사의 중요한 축은 구현 중에 쌓인 데이터입니다. 에이전트는 구현하는 동안 어떤 룰을 확인했고 어떤 룰을 위반했는지 Baden에 보고합니다. 예를 들어 A 프로젝트 리포의 Baden에는 룰 12개에 걸쳐 41건의 위반이 기록돼 있습니다. A 프로젝트 감사는 코드를 보기 전에 이 기록부터 조회합니다.
이 데이터에서 읽는 신호는 셋입니다. 첫째, 반복되는 위반입니다. 같은 룰이 계속 어겨진다면 그 룰이나 그 룰이 겨냥하는 구조 어딘가에 고칠 것이 있습니다. 둘째, 한 번도 읽히지 않은 룰입니다. 쓰이지 않는 룰은 존재 자체를 다시 따져봐야 합니다. 셋째, 한 번도 위반되지 않은 룰입니다. 100% 지켜지는 룰은 잘 만든 룰일 수도 있지만, 모델이 이미 충분히 학습한 패턴이라 룰이 없어도 지켜졌을 가능성도 큽니다. 그렇다면 그 룰은 가치 없이 매번 토큰만 쓰고 있는 것이고, 폐지 후보가 됩니다.
감사는 이 신호와 코드를 함께 보고 룰을 새로 만들거나, 고치거나, 없애자고 제안합니다. 제안은 리포 쪽에 전달되고, 리포의 응답을 받아 다시 판정합니다. 지적은 모두 장부에 남아 다음 감사에서 실제로 반영됐는지 확인됩니다. A 프로젝트 리포를 깊게 감사했을 때는 HIGH 8건, MEDIUM 26건의 지적과 함께 새 룰 6개, 개정 13개가 나왔습니다.
여러 리포의 룰을 한곳에서 보게 되자 다른 것도 보였습니다. 프로젝트마다 표현은 달라도 의도가 같은 조항이 많았습니다. 이걸 의도 단위로 묶은 표준 룰이 지금 274개입니다.
Get Kim, min tae’s stories in your inbox
Join Medium for free to get updates from this writer.
그리고 룰도 낡습니다. 룰에 적힌 “이 API는 이렇게 동작한다” 같은 사실 주장은 라이브러리 버전이 바뀌면 틀린 말이 됩니다. 틀린 룰을 잘 지키는 에이전트는 틀린 코드를 성실하게 만듭니다. 그래서 표준 룰의 사실 주장은 웹의 1차 자료로 판정해 기록하고, 룰 본문이 바뀌면 그 판정도 낡은 것으로 표시되게 했습니다. 룰이 낡지 않게 하려면 룰을 쓰는 방식부터 달라야 해서, 룰 작성에도 규범을 따로 정해 두었습니다. 그중 핵심은 이렇습니다.
- 룰에는 규범과 원리만 쓴다. 위반 건수나 “현재 적용됨” 같은 현황은 쓰지 않습니다. 상태가 바뀌는 순간 룰이 거짓이 되기 때문입니다. 현황은 이행 목록에 따로 두고, 룰은 그것을 가리키기만 합니다.
- 예외는 열거하지 않고 판정 기준으로 쓴다. 예외 목록은 화이트리스트로 읽힙니다. 목록에 없는 새 항목은 정당해도 위반이 되고, 사라진 항목은 없는 것을 가리킵니다. 무엇이 예외를 만드는지를 쓰면 새 항목도 같은 기준으로 판정할 수 있습니다.
- 근거는 분포가 아니다. “리포 대부분이 이렇게 한다”는 근거가 될 수 없습니다. 관례는 정하는 것이지 세는 것이 아니고, 다수가 뒤집히면 근거도 함께 무너집니다.
- 트리거는 위반 지점에 닿아야 한다. 파일 경로나 코드 패턴으로 룰을 불러오는 트리거가 이미 룰을 지킨 코드에만 걸리면, 정작 위반하는 코드에서는 룰이 로드되지 않습니다. 트리거는 위반 코드에서 로드되는지를 기준으로 고릅니다.
룰을 지키게 하는 것만큼, 룰이 맞는지 확인하는 것도 루프의 일입니다.
“기계가 검증한다”는 무엇인가
OpenAI 글에 대해 Thoughtworks의 Birgitta Böckeler가 남긴 비판이 있습니다. 하네스 이야기는 많은데 기능과 동작을 검증하는 이야기는 빠져 있다는 겁니다. 제 루프에서 검증은 한 겹이 아니라 층으로 나뉩니다.
결정적인 검사
타입 검사, 린트, 정적 분석, 자동화된 테스트입니다. 3월 글에서도 말했듯 이건 AI 시대에도 가장 기본적인 안전망이고, 에이전트가 “됐다”고 말하는 것보다 먼저 믿는 근거입니다.
룰 검증
정적 분석이 잡지 못하는 의미와 맥락의 규칙을 LLM이 판정합니다. 위에서 말한 대로, 그 기록은 리포 밖에서 감사됩니다.
격리된 리뷰
PR도 구현한 에이전트의 컨텍스트를 물려받지 않은 세션이 리뷰합니다. AI 리뷰를 써 본 분이라면 아실 겁니다. 고쳐서 다시 올리면 또 새 지적이 나오고, 회차가 끝나지 않습니다. 리뷰가 앞 회차를 기억하지 못하기 때문입니다.
그래서 PR마다 지적 장부를 둡니다. 다음 회차는 새 코드를 보기 전에 장부의 지적부터 하나씩 결말을 냅니다. 해결됐는지, 반박이 타당한지, 의견이 갈리는지. 이 판단은 작성자의 답글을 열기 전에 코드만 보고 먼저 내립니다. 답글의 설명에 끌려가지 않기 위해서입니다. 그리고 고치지 않은 코드에서는 심각한 문제만 새로 지적하게 합니다. 이 두 가지가 있어야 리뷰가 수렴합니다.
머지 뒤의 관찰
리뷰는 머지 전의 코드를 봅니다. 그런데 바이브 코딩에서 더 무서운 건 에이전트가 기존 코드를 얼마나 망가뜨리는지입니다. 그래서 머지 뒤에는 코드 자체보다 한 층 위의 윤곽을 봅니다. 주로 보는 지표는 둘입니다.
- 머지된 코드의 생존율
- 디렉토리, 파일, 함수의 복잡도 증가 추이
한 리포의 최근 90일 평균을 보면, 머지까지 걸린 시간 중 에이전트가 실제로 일한 시간은 약 31%였고, 약 19%는 첫 리뷰를 기다린 시간이었습니다. 머지된 에이전트 코드가 얼마나 살아남는지는 연구도 있지만, 결론이 엇갈립니다. PR 약 11만 개를 분석한 연구는 에이전트가 쓴 줄이 사람이 쓴 줄보다 덜 살아남는다고 했고, PR 5,171개를 분석한 다른 연구는 오히려 더 오래 살아남는다고 했습니다. 그래서 연구의 평균에 기대기보다, 내 리포에서 내 에이전트가 만든 코드를 직접 보는 게 맞다고 생각합니다.
머지 전 3시간은 열기 전 작업, 첫 리뷰 대기, 리뷰 왕복으로 나뉘고, 머지 뒤에는 시간이 아니라 이후 변경이 이 코드를 얼마나 지웠는지를 봅니다. 머지 1주 뒤 이 PR이 추가한 줄의 93%, 24일째인 지금 92%가 남아 있습니다.
복잡도는 생존율과 짝으로 봅니다. 생존율이 코드가 버티는지를 말해준다면, 복잡도는 코드가 어떻게 자라는지를 말해줍니다. 복잡도가 계속 오른다면 에이전트가 기존 코드를 찾아 쓰지 않고 비슷한 코드를 새로 만들고 있다는, 중복의 신호일 수 있습니다. 중복 코드는 그 자리에서는 잘 동작해서 리뷰를 통과하기 쉽습니다. 머지 뒤의 윤곽을 봐야 보이는 이유입니다. 그래서 복잡도는 파일 단위만이 아니라 함수 단위로도 추적하고, 크게 뛴 지점이 보이면 그 버전의 diff로 들어가 무엇이 늘었는지 살펴봅니다.
함수 하나의 복잡도 이력입니다. 오른쪽 위는 함수의 복잡도 추이, 아래는 버전마다 복잡도가 얼마나 변했는지이고, 한 버전을 고르면 왼쪽에 그 diff가 열립니다. 이 층들을 꿰는 원칙은 하나입니다. 에이전트의 자기 보고를 근거로 쓰지 않는다는 것.
이건 제 느낌만이 아닙니다. Cursor가 올해 6월 공개한 분석에서, SWE-bench Pro에서 해결된 것으로 집계된 문제의 상당수는 에이전트가 직접 고친 게 아니라 이미 있는 수정을 찾아온 것이었습니다. 실행 환경을 봉인하자 해결률이 87.1%에서 73.0%로 떨어졌습니다. 에이전트는 결과를 보고하는 데 능숙하고, 그 보고가 사실인지는 따로 확인해야 합니다.
그래서 “읽었다”는 이벤트 기록에서 실제로 읽은 범위로 셉니다. 리뷰어가 판정의 근거로 든 파일을 실제로 열지 않았다면, 러너는 그 판정을 “확인 못 함”으로 내립니다. “고쳤다”는 다음 회차에 코드로 확인합니다. Baden의 위반 보고도 마찬가지로, 감사는 그 보고를 단서로 삼을 뿐 판정은 코드를 읽고 내립니다. 판단은 에이전트에게 맡기되, 세고 비교하는 일은 러너가 합니다. 3월 글의 “AI는 읽었다고 착각한다”에 대한, 지금의 구조적인 답입니다.
사람의 자리
코드를 맡기면 사람은 무엇을 할까요? 제가 머문 곳은 두 군데입니다.
첫째는 스펙입니다. CERES108에는 시각화 종류만 약 1만 가지가 있습니다. 이걸 담은 두 저장소는 합쳐서 180만 줄이 넘습니다. 본체 구조는 단순하고, 종류마다 비슷한 패턴의 코드가 반복되어 줄 수가 많아진 생성 코드입니다. 그런데 생성에 걸린 시간은 약 2주일이었고, 그 생성 스펙을 정하는 데 3~4개월의 시행착오가 들었습니다. 사람의 시간은 코드에서 스펙으로 옮겨갔습니다.
스펙을 원본으로 삼는 방식에는 우려도 있습니다. 모델 기반 개발(MDD)의 경직성과 LLM의 비결정성을 함께 떠안을 수 있다는 것입니다. 제 경험에서 얻은 결론은 답은 조건부입니다. 영역이 좁고, 스펙이 시행착오로 충분히 다듬어지면 스펙이 원본이 되는 방식은 작동합니다. 다만 그 다듬는 시간은 줄지 않았고, 그게 지금 사람의 몫입니다.
둘째는 저 자신의 성장입니다. 바이브 코딩의 장점은 모르는 기술도 쓸 수 있다는 것입니다. 하지만 모르는 채로 두면 안 됩니다. 만들어졌다고 알게 된 것은 아니기 때문입니다.
업계도 이 문제를 압니다. Anthropic의 실험에서는 처음 보는 라이브러리를 AI와 함께 쓴 개발자들이 손으로 짠 개발자들보다 이해도 퀴즈 점수가 낮았습니다. 코드의 양과 사람이 이해하는 양 사이에 벌어지는 이 격차를 이해 부채라고 부르기도 합니다. 도구들의 대응은 대개 세션 안에서 설명해 주는 방식입니다. 지금 짜는 코드가 왜 이렇게 됐는지를 그 자리에서 알려주는 것이죠.
저는 세션 밖에 쌓는 쪽을 택했습니다. 설계 검토, PR 리뷰, 룰 감사를 하는 동안 패턴과 문제와 기술을 뽑아냅니다. 여러 프로젝트에서 나온 같은 패턴은 하나로 합치고, 같은 문제를 다르게 푼 해법끼리 묶고, 그 해법이 그 상황에 맞았는지 다시 점검합니다. 지금은 정리된 패턴 299개, 문제 문서 46개, 기술 929개가 쌓였습니다.
그리고 에이전트가 주행하는 동안의 무료한 시간을, 이제 저는 이걸 읽으며 보냅니다. 받아 적는 읽기가 아니라, 같은 문제의 다른 해법을 나란히 놓고 이번 선택이 맞았는지 따져보는 읽기입니다. 특별한 깨달음의 한 순간보다 이 일상이 중요하다고 생각합니다.
이 카탈로그가 저 한 사람에게만 쓸모 있는 건 아닙니다. 팀이라면 팀, 회사라면 회사 멤버를 키울 양분이 됩니다. 그리고 기계가 쓰기 때문에, 사람이 쓰던 문서와 달리 코드와 함께 갱신되며 썩지 않는 길을 만들 수 있습니다.
제품이 아니라 컨셉을
이 시리즈에는 제가 만든 도구가 계속 등장합니다. 도구를 만들라고 권하려는 건 아닙니다. 그러나 제품을 만들 때 그 제품에 맞는 도구를 직접 만들어야 하는 경우가 있습니다. 게임 스튜디오와 3D 애니메이션 스튜디오가 그랬고, 넷플릭스가 공개한 도구들도 넷플릭스를 운영하려고 만든 것이었습니다. 리액트도 그렇게 나왔습니다. 대부분의 회사와 개발자는 공개된 도구의 소비자에 머뭅니다. 해법이 떠오르지 않거나, 떠올라도 구현 비용이 너무 높았기 때문입니다.
그 비용이 AI로 크게 내려갔습니다. 발 사이즈가 7.25인데 7이나 7.5를 신고 불편을 참을 이유가 없어졌습니다. 그래서 제가 공유하고 싶은 건 제품이 아니라 컨셉입니다. 공감한다면 자신과 자기 조직에 맞는 도구를 빠르게 만들고 안착시키시길 권합니다.
열린 질문 하나
답을 찾지 못한 질문이 하나 있습니다.
저는 이제 코드를 거의 직접 보지 않습니다. 구조와 인터페이스와 알고리즘을 관찰하고 검수할 뿐입니다. 그렇다면 코드의 형태도 사람이 아니라 기계가 유지보수하기 좋은 쪽으로 바뀌어야 하지 않을까요. 문서가 기계가 읽기 편한 마크다운으로 옮겨갔듯 말입니다.
3월 글에서 Prompteer 문법이 계속 Handlebars로 끌려가던 일을 썼습니다. 학습 데이터의 중력입니다. 기계가 다루기 좋은 코드는 이런 중력과 어떻게 지내야 할까요. 이름은 어떻게 짓고, 파일은 어떻게 나누고, 추상화는 어디까지 해야 할까요. 업계에도 실천 팁은 있지만 이론은 아직 없습니다. 저 역시도 계속 찾는 중입니다. 이 시리즈를 쓰는 동안 계속 붙들고 있을 질문입니다.
