지난 몇 년간 에이전트형 코딩으로 일하면서, 35년간 손으로 직접 프로그래밍할 때보다 내가 쓰는 언어·시스템·도구에 대해 더 많이 배웠음
시스템·기법·접근을 결정하는 능력은 여전히 내가 도구보다 훨씬 낫지만, 이 도구들은 잡다한 세부사항을 많이 아는 아주 박식한 인턴 같음. 경험은 적고 실수도 열정적으로 하지만, 적어도 초반에는 피드백을 받아들이며 행동으로 옮김. 다만 완전히 이해하고 내재화한 것이 아니라 자주 잊어버림
작업하는 모든 것을 전부 알아야 한다는 주장은 매우 순진함. 둘 이상 팀에서 일하면 완전히 이해하지 못하는 부분이 많고, 오래된 코드베이스라면 거의 모든 부분이 낯설 수 있음. 수십 년간 쌓인 거대한 단일 저장소에서는 모두가 당신을 전문가로 보는 부분조차 제대로 이해하고 있으면 운이 좋은 편임
이런 주장을 하는 사람들은 대체로 매우 주니어이거나, 거의 혼자 일하거나, 한 프로젝트를 20년 붙잡고 있었던 것처럼 느껴짐. 팀이나 큰 조직에서 일하는 누구도 코드베이스 전체를 안다고 말할 수 없고, 에이전트형 프로그래밍을 하는 사람도 마찬가지임. 그래도 에이전트에게 질문하면 답을 받을 수 있고, 평생 남의 코드를 읽어온 입장에서 LLM이 쓴 코드도 읽을 수 있음. 나쁜 코드를 기계가 썼든 사람이 썼든 전혀 신경 쓰이지 않고, 적어도 기계는 내 피드백을 받아 행동으로 옮김
보통 모든 것, 심지어 대부분을 알 필요가 없다는 건 맞지만, 내가 작업하는 프로젝트나 시스템에 대해 필요한 것은 빠르게 찾아내고 이해할 수 있어야 함
사소한 문제라도 저수준 언어, 어셈블리, 덜 흔한 알고리즘, 네트워크 프로토콜 같은 추가 기술이 필요해지는 순간 해결하지 못해 멈춰버린 소프트웨어 팀을 많이 봤음
반대로 본 것을 해석할 능력이 없어서가 아니라, 독점 라이브러리나 독점 운영체제처럼 블랙박스인 것을 써서 내부를 파고들 수 없고 실제 동작을 확인할 방법이 없어 막히기도 함
그래서 아주 드물게만 필요하더라도, 작업하는 모든 것에 대해 전부 알아낼 수 있는 환경은 항상 가능해야 한다고 봄
35년 경력이 있으니 새 지식을 얻는 학습 능력과 일반적인 틀이 이미 쌓여 있고, 에이전트형 코딩을 보조 도구로 쓰는 법도 알고 있음. 오늘 시작하는 주니어들은 그게 없어서 에이전트형 코딩에 과하게 의존하고, 자신이 모르는 게 뭔지도 모름
이 글은 “작업하는 모든 것을 전부 알아야 한다”고 말하는 게 아니라, 코드를 쓰는 능력과 코드를 효과적으로 읽는 능력이 본질적으로 연결돼 있다고 말하는 것임
동의함. 모래가 트랜지스터가 되는 과정이나 어셈블리를 몰라도 잘 일하고 있으니, 나도 전체 스택을 전부 아는 건 아님
중요한 건 시스템의 나머지를 배우는 걸 두려워하지 않고, 색인을 유지하는 것임
무엇보다 어떤 것이든 빠르게 파악할 수 있어야 함. 그래야 넓게 다룰 수 있음. 필요할 때는 깊이 파고들고, 필요할 때는 높은 수준에서 훑어보는 식으로 문제에 맞는 적절한 수준을 잡아야 함
오래전 대학에서는 컴퓨터과학 전공자에게 공학 전반을 가르쳤음. “화학공학이나 아날로그 제어 시스템을 언제 알아야 하죠?”라고 묻자, “쓸 일은 없을 것이다. 다만 코딩할 만큼 빠르게 파악하고 나중에 잊으면 된다. 우리는 튼튼한 기반을 주는 것이다”라고 답했음
이건 큰 코드베이스 안에서도 그대로 적용됨
여기서 문제는, 어떤 의미에서는 코드를 쓴 에이전트와 그 코드에 대한 질문에 답하는 에이전트가 같은 에이전트가 아니라는 것임. 원래 에이전트가 추론 과정을 남기지 않았다면 대체로 막막해짐
git-ai [0] 같은 도구는 LLM 세션을 캡처하고 각 파일 편집을 특정 에이전트 동작과 연결하며, 에이전트가 특정 코드 조각에 대해 그 주변 대화, 즉 사용자가 무엇을 프롬프트했는지, 그 코드를 만든 LLM의 추론이 무엇이었는지 등을 조회하게 해줌. 균형을 바꿀 수 있지만 아직 널리 쓰이지는 않음
[0] https://usegitai.com/
25년 이상 된 시니어 개발자로서 최근 “5분만 들어와 줄 수 있나요”라는 식으로 회의에 던져졌는데, 중간에 아무 맥락 없이 끌려 들어가는 이런 회의를 정말 싫어함
질문이 소개도 없이 빠르게 쏟아졌고, 수십 개 중 하나인 외부 연동에 관한 내용이었음. 더 나쁘게도 그쪽은 우리와 다른 자체 용어를 씀
이 연동들을 만들 때 모델에 크게 의존했기 때문에 질문을 이해하는 데 매우 힘들었음. 극도로 지루한 작업이었고, 외부의 두꺼운 명세가 제공된 상태였음
모델을 쓰지 않았다면 10배 시간을 들여도 이런 연동은 아마 완성되지 못했을 거라는 생각은 여전히 긍정적임. 하지만 이제는 이런 불편한 순간이 다시 생기지 않도록 “아하” 포인트들을 다시 문서화할지 신중히 생각하고 있음
회의에서 이렇게 무지하고 창피하다고 느낀 적이 없었고, 할 수 있는 말은 “그건 확인해서 답하겠습니다, 이것도요, 저것도요”뿐이었음 인지 부채는 정말 현실이고, 개인적으로는 기술 부채보다 더 아픔. 기술 부채는 팀 전체가 공유하지만 인지 부채는 개인적이며, 그걸 만든 사람이 바로 나였다면 더 잘 알고 있어야 함
앞으로는 “이건 무엇인가”, “저건 무엇인가” 식의 5분짜리 플래시카드형 Markdown 용어 목록을 만들지 않으면 일이 끝난 게 아니라고 볼 것임
이건 의사들이 흔히 불평하는 상황과 비슷함. 환자가 와서 어떤 약 처방만 필요하다고 하지만, 좋은 의사들은 전체 상황을 제대로 이해하기 전에는 약도 조언도 주지 않는 경우가 많음
시니어 개발자라면 마음에 들지 않는 행동에 제동을 걸어야 하는 사람임. 권한이 있음. “흥미로운 질문이네요. 제 관점을 말하려면 맥락이 더 필요합니다. 시스템 아키텍처를 간단히 설명해 주시거나, 이 접근으로 실제 어떤 문제를 풀려는지 설명해 주실 수 있나요?”라고 하면 됨
어떤 직장이어야 회의 중간에 끌려 들어가 맥락도 없이 기술 질문을 쏟아붓고, 그 자리에서 답하기를 기대하는지 궁금함. 많은 사람이 피하고 싶어 할 테니 알려주면 좋겠음
그런 대우를 받았을 때 “이 질문에 제대로 답하려면 문서와 코드를 검토해야 합니다”는 완전히 괜찮고, 꽤 외교적인 답변임
자존심 내려놓고 신경 쓰지 않아도 됨. 도구를 썼고, 쓰지 않았다면 더 곤란했을 것임. “모르겠네요, AI에 물어보겠습니다”라고 하면 간단함
생성된 코드에서 문제를 찾으려면 개발자가 신경을 써야 함. 많은 개발자들, 특히 대기업 개발자들은 이미 일에서 상당히 빠져 있고, 가능한 최소 노력으로 티켓을 닫고 책임을 넘길 방법만 찾고 있음
그런 개발자들은 능력이 있더라도 에이전트가 놓친 문제를 찾을 만큼 생성된 코드를 이해하려고 노력하지 않을 것임. 특히 지금 같은 AI 주도 속도 열풍 속에서는 더 그렇다
맞음. 생성된 코드는 인간 작성자의 정신 모델에 기대는 모든 의미적 기대를 어기기 때문에 읽기가 더 어려움
생성된 코드는 언어적으로는 그럴듯하지만, 흔한 관용구를 자신도 모르게 incoherent하게 흉내 내는 경우가 많아서 실제 버그가 정상적인 인간, 심지어 나쁜 프로그래머도 떠올리기 힘든 방식으로 우연히 숨겨질 수 있음
LLM에는 내부 평가가 없으므로 리뷰어는 이를 감안해 줄 단위로 평가하고, LLM이 애초에 갖고 있지 않았던 숨은 근거와 암묵지를 처음부터 다시 세워야 함. 그러다 비문제에 끌려가 값비싼 시간을 소모하기도 함
이 시점에서는 처음부터 작성하는 것보다 투자가 더 커지는 경우가 많음
큰 회사에서는 예외도 있지만, 많은 팀의 많은 개발자들이 신경 쓰는 것 자체로 처벌받기도 함
어떤 사람들은 큰형님이 정크푸드를 팔고, 그다음 살 빼는 “해결책”을 판다고 말함
어쩌면 지금 회사들은 정크 AI를 사고 있고, 다음 단계에서는 그 “해결책”을 약속받는 중일지도 모름. 자본주의는 정확히 예상대로 작동하고 있음
이 글은 조금 핵심을 비껴간 것 같음
AI를 많이 쓰면 기술 손실은 있음
하지만 방 안의 어색한 코끼리를 인정하고 싶음. AI는 사람들을 너무 빠르게 만들고 있음. 빠른 산출 자체가 나쁘다는 뜻이 아니라, 코드를 만들어낸 전체 이해와 경험보다 빠른 산출물과 코드가 앞서고 있다는 뜻임. 깊은 지식으로 안전한 결정을 하며 만드는 사람보다, 사업 가치를 말하려는 사람에게 보상을 주고 있음
AI는 좋고 좋은 해결책도 만들 수 있지만, 궁극적으로 자신이 뭘 하는지 모르며 최선의 경우에도 강한 조율자가 필요함
우리는 사업 주도 개발의 오물탕에 있고, 나쁜 결정에 대해 충분히 가혹한 평판상 처벌이 돌아가지 않고 있음
기술 손실은 현실임. 하지만 나는 말 그대로 10년 동안 상사들에게 기술 손실을 불평해 왔음. 그래서 AI는 내게 문제 중 하나일 뿐임. 어떤 이유에서인지 매년 코딩을 점점 덜 하게 됐음
다시 말해 기술 손실이 그렇게 큰 문제인지 확신하지 못하겠음. 그냥 우리 일의 성격이 바뀌고 있다는 신호일 수도 있음. C++ 표준을 줄줄 외우고 수백 가지 기능을 올바르게 쓰는 능력보다 좋은 아키텍처를 아는 능력이 더 높게 평가되는 시대가 될지도 모름
전반적으로 동의하지만, 냉혹한 진실은 대부분의 기업 우선순위가 늘 대략적이고 허술한 사업 주도 개발이었다는 것임. 인간 중심의 엔지니어링 과정은 그 철학의 최악의 결과를 우연히 막아준 견제 장치였지, 의도적으로 마련된 장치가 아니었음
“너무 빠르다”는 것의 또 다른 측면은 우리 문제들의 순서를 바꾼다는 점임
일반적인 개발에서는 “정말 이걸 만들고 싶은가”, “이렇게 하면 뭐가 잘못될 수 있는가”를 더 오가며 따지는 편이고, 이상적으로는 PR 승인이나 병합·배포 전에 함. 그 일부가 “나중에 누가 불평하는지 보자”로 옮겨가고 있음. 말하듯이 예방 1온스가 치료 1파운드보다 낫다는 것임
사업 주도 정부가 사업 주도 규칙을 쓰는 사업 주도 세계에서, 성공을 최적화하고 싶다면 대안이 무엇인지 모르겠음
기업만 그러는 것도 아님. 오픈소스 프로젝트에서도 겉보기에는 괜찮지만 자잘한 버그가 천 개쯤 들어 있는 큰 PR이 병합되는 걸 자주 봄. 치명적이지는 않아도 충분히 짜증나는 것들임
게다가 그 코드는 해당 프로젝트의 관용적인 C++가 아니었고, LLM은 이미 있는 API를 완전히 무시했음. 고칠 수는 있고 메인테이너가 잡았어야 하지만, 생성되는 코드의 양 때문에 모두가 너무 많은 에너지를 써야 함
이런 블로그 글들은 의심할 여지 없이 AI 도움을 받아 쓰였을 텐데, 여기와 인터넷 곳곳에서 수년째 댓글 주제가 되어 왔음. 기술 위축은 심각한 우려이고, 2022년부터 AI에 회의적인 모두가 반복해서 말해왔지만, 어떤 사람들과 어떤 곳은 그냥 신경 쓰지 않는 것 같음
어느 시점부터 코드에 대한 통찰 없이 쓰레기 기계 레버만 당기고 있다면, 상사가 왜 연봉 5만 달러 이상을 받아야 하느냐고 묻는 것도 정당할 수 있음
더 빠르게 가려고 AI를 쓰는 건 잘못된 것을 최적화하는 것임. 내가 일한 모든 곳에서 기능을 구현하는 데 필요한 다른 모든 일에 비해 “코드 작성” 자체가 가장 적은 시간을 차지했음
하루면 코딩할 수 있는 기능을 보자. 먼저 회사가 쓰는 Agile이든 Waterfall이든 계획 의식을 통해 모든 걸 계획하고, 작업을 쪼개고, JIRA 티켓을 만들고, 누가 할지 정해야 함. 이것만 며칠 또는 몇 주가 걸릴 수 있음. 그다음 제안 설계를 담은 설계 문서를 쓰고 동료·팀원 리뷰를 받아야 하며, 실질적인 기능이라면 또 한 주가 걸림. 여러 팀이 관련되면 그 팀들의 동의와 설계 합의를 받아야 하니 한 주를 더하자. 어떤 곳에서는 작업 시작 승인이 필요하고, 승인자의 일정과 가용성에 따라 며칠이 더 걸림
그런 다음 하루 동안 코드를 쓰고 테스트를 통과시킴
그다음 코드 리뷰가 있고, 팀과 많은 왕복을 하며 여러 번 반복하고 추가 리뷰를 받을 수 있음. 또 며칠 또는 몇 주가 감. 더 큰 회사라면 법무, 개인정보, 성능, 접근성, QA 같은 다른 부서의 온갖 리뷰를 통과해야 함. 병렬로 하더라도 보수적으로 2주를 더하자. 마지막으로 스테이징에 올리고 내부 도그푸더 사이에서 어느 정도 숙성 시간을 가져야 작동에 자신이 생김. 1주 추가. 이제 스테이징에서 프로덕션으로 올릴 준비가 됐지만, 진지한 회사라면 아무것도 바로 100% 프로덕션에 보내지 않음. 천천히 비율을 올리고, 롤백이 필요할 경우를 대비해 피드백과 지표를 확인해야 함. 전체 출시까지 또 2주가 걸릴 수 있음
그러면 설계부터 출시까지 두 달쯤 걸린 기능에서, 우리는 하루 걸린 부분을 5분으로 줄이려고 난리 치는 셈임
이 소프트웨어 엔지니어링 격언이 떠오름
소프트웨어를 만들 때, 그것이 문제에 대한 이해의 스냅샷임을 기억해야 함. 그것은 모두에게, 미래의 자신에게도, 접근 방식과 명료함, 그리고 당면한 문제에 대한 해법의 적절성을 말해줌. 그러니 무엇을 말할지 현명하게 선택해야 함
설계부터 출시까지 두 달 걸린 기능에서 하루짜리 부분을 5분으로 줄이려 애쓴다는 표현은 잘 짚었음
모델은 이제 의존성 업데이트, 빌드·배포 스크립트, 단위 테스트 같은 지루한 작업을 거의 완전히 자동화하는 데 매우 뛰어남. 예전에는 며칠 걸리던 일이 이제 몇 분 걸릴 수 있고, 여기서는 쉽게 50배 속도 향상이 가능함
이런 일은 안정된 회사에서 모든 엔지니어의 일상 중 작지 않은 부분이었음. “플랫폼 엔지니어링”이든 뭐라 부르든 이 영역은 죽었음
또 위험과 노력 대비 보상이 맞지 않아 시도하지 않았을 기술적으로 위험한 아이디어들이 이제 손에 닿음. 단순히 “더 빨리 가기”라기보다, 무언가를 시험해 볼 수 있는 속도가 엔지니어링 과정의 성격 자체를 바꿈
설명한 모든 프로세스는 소프트웨어 엔지니어가 코드를 쓰는 시간을 극대화하기 위해 존재함[0]. 기업에서 소프트웨어 엔지니어는 가장 비싼 직원들 중 하나이고, 그들의 시간이 낭비되는 것은 손익에 의미가 있기 때문에 이런 프로세스를 둠
소프트웨어 엔지니어가 충분히 싸지면 이런 프로세스의 많은 필요성이 사라짐. 이미 이런 프로세스를 가진 회사들은 그런 관료제를 깨기가 극도로 어렵기 때문에 곤란하겠지만, 애초에 그런 프로세스가 없거나 제거할 수 있는 회사들은 상당한 경쟁 우위를 갖게 됨
새 소식은 아님. 스타트업은 항상 실행 속도로 기존 기업과 경쟁해 왔음. 새로워진 건 그 속도를 더 오래 유지할 수 있는 능력임
법무, 개인정보, 성능, 접근성, QA 같은 리뷰도 모두 표적 안에 있음. 회사가 이런 리뷰에 따른 법적 책임을 외부 제공자에게 넘길 수 있다면 그렇게 할 것임
[0] 이 프로세스의 상당 부분이 결국 시간을 아끼려던 바로 그 직원들에게 떠넘겨진다는 아이러니는 일단 무시하자
어떤 회사에서 일하느냐에 아주 많이 달려 있음. 예를 들어 스타트업을 이런 식으로 운영할 수는 없음
모든 회사가 그렇게 일하지는 않음
빅테크에는 그런 허세 섞인 절차가 많지만, 작은 회사들은 빠르고 거칠게 움직일 수 있음
코드 품질은 결국 당신에게 달려 있음
에이전트와 반복해서 작업해, 자신이 직접 썼을 때와 똑같은 품질의 코드가 될 때까지 다듬는 걸 막는 건 없음
내 기준의 코드 품질을 목표로 한다면, 그냥 내가 직접 쓰는 편이 더 빠르고 덜 답답했음
나는 내 코드 품질을 원하는 게 아니라 AGI 코드 품질을 원함. 그렇게 약속받았고, 제트팩과 하늘을 나는 자동차도 약속받았음
그래서 이런 글들이 이해되지 않고, 인간 게으름에 대한 사례 연구처럼 느껴짐. 좋은 결과를 원한다면 결과를 리뷰하고 반복하면 됨. 좋은 기반을 원한다면 그 기반을 직접 쓰면 되고, 나중에는 그 기반이 LLM이 나쁜 코드를 쓰는 것을 상당히 크게 막아줌
이런 글들은 꽤 답답함. 다만 작성자가 말한 토큰 비용은 현실이고 위험임
막는 건 없지만, 애초에 직접 쓰는 것보다 느림. AI 생산성 향상은 신화임
내 경험상 거기까지 AI를 달래가며 끌고 가는 데 같은 시간이나 더 긴 시간이 걸림. 특히 더 빠르다는 증거도 없다면, LLM을 중간자에 끼워 넣기보다 직접 쓰고 어떻게 동작하는지 아는 편이 낫다
AI 도구는 접근법을 브레인스토밍하고 가끔 코드를 생성하는 데 쓰지만, 실제 타이핑은 내가 직접 함. 그러면 시간이 지나며 메커니즘과 프로그래밍 언어를 잊을 가능성이 줄어듦
나도 대부분은 구현 계획을 요청하되, 코드는 최소화하거나 아예 코드 없이, 또는 의사코드로 달라고 하고 실제 코드는 직접 작성함. 오픈소스 작업에서는 내가 즐기는 핵심이 직접 코드를 쓰는 것이기 때문임
솔직히 전체가 LLM에게 코드를 쓰게 프롬프트하고 리뷰하는 일뿐이라면 오픈소스 메인테이너를 굳이 할 것 같지 않음. 전혀 충족감이 없어 보임
실제 유급 직업이라면 LLM 사용 방식이 어떻게 달라질지는 궁금함. 내가 소프트웨어 개발자인 이유는 이 기술 자체를 사랑하기 때문임. 만드는 행위, 뇌를 써서 아이디어를 코드로 바꾸는 행위를 좋아함. 그냥 LLM에 프롬프트하는 일이라면 그 직업을 계속할지 모르겠음. 적어도 전직을 알아보기 시작할 것 같음
쓸 수 있는 접근 중 하나는 절대 코드를 대신 쓰지 말라고 요청하는 것임. 그러면 설명을 강제하게 되고, 이후 직접 코딩해 그 아이디어를 시도하면서 더 잘 이해하게 됨
유지보수해야 하는 코드에서는 이 방식을 씀. 그래도 모델이 틀린 정보를 많이 섞기 때문에 가끔 당함. 보통 과거에는 맞았지만 지금은 틀린 내용임
버려도 되는 스크립트나 검증이 쉬운 스크립트는 생성하게 하지만, 과도한 설계나 모든 경계 사례를 잡으려는 시도는 피하라고 요청함. 스크립트에서는 실패한 단계가 그대로 드러나도록 오류가 나게 두는 편이 더 이해하기 좋기 때문임
PowerShell처럼 읽기 어렵다고 느끼는 언어는 피하고, 화면 안에 들어올 만큼 짧아서 전부 읽고 이해할 수 있는 것을 생성하는 편을 선호함. Python, Bash, Batch가 내가 주로 쓰는 스크립트 언어임
나도 시스템 프롬프트에 전체 해법이나 코드를 절대 주지 말라고 설정해 뒀음. 그래서 질문하면 짧은 10줄 예제나 의사코드 정도를 내놓음. 이쪽이 훨씬 추론하기 쉬움
AI 제안의 50% 이상은 여전히 거절함. 너무 평범하거나, 이유 없이 코드를 옮기거나, 때로는 그냥 틀리기 때문임
AI가 잊어버린 건 무엇이든 다시 알려줄 수 있다면, 잊는 게 왜 중요하겠음
웃긴 점은 이 기술이 둘 중 하나라는 것임
전문성 없이 위임은 할 수 있지만 틀렸거나 아예 불가능한지 알 수 없는 관리자용 기술이거나, 전문성은 있지만 그 전문성을 점점 잃게 될 코더용 기술임
그래서 다음 분기까지의 VC와 주주 말고는 누구를 위한 건지 잘 모르겠음
약간 주제에서 벗어나지만, 글에서 Spec Driven Development가 미래라고 말하는 게 웃김
기술적으로는 우리가 Waterfall을 하던 시절 이미 그렇게 했음. 좋은 문서가 있던 시절이 조금 그립기도 함. 지난 10년, 어쩌면 그 이상 동안은 한 줄짜리 JIRA 티켓을 받는 일이 많았고, 거의 아무것도 명시하지 않아서 사람들에게 전화해야 하는 경우가 잦았음
나는 아직 AI로 일하는 걸 피하고 있음. 실험용으로 로컬 모델 몇 개를 써보려 하지만, 남의 것을 뜯어다 만든 것에 돈을 내기는 거부함. 그리고 지금까지 로컬 모델은 기대 이하였음
원격 모델들은 점점 더 비싸질 것임. 그들의 사업 미래는 추론 비용 개선에 대한 기대에 달려 있음. 이런 감옥에 스스로 묶이고 싶어 해서는 안 됨
Hacker News 의견들
지난 몇 년간 에이전트형 코딩으로 일하면서, 35년간 손으로 직접 프로그래밍할 때보다 내가 쓰는 언어·시스템·도구에 대해 더 많이 배웠음
시스템·기법·접근을 결정하는 능력은 여전히 내가 도구보다 훨씬 낫지만, 이 도구들은 잡다한 세부사항을 많이 아는 아주 박식한 인턴 같음. 경험은 적고 실수도 열정적으로 하지만, 적어도 초반에는 피드백을 받아들이며 행동으로 옮김. 다만 완전히 이해하고 내재화한 것이 아니라 자주 잊어버림
작업하는 모든 것을 전부 알아야 한다는 주장은 매우 순진함. 둘 이상 팀에서 일하면 완전히 이해하지 못하는 부분이 많고, 오래된 코드베이스라면 거의 모든 부분이 낯설 수 있음. 수십 년간 쌓인 거대한 단일 저장소에서는 모두가 당신을 전문가로 보는 부분조차 제대로 이해하고 있으면 운이 좋은 편임
이런 주장을 하는 사람들은 대체로 매우 주니어이거나, 거의 혼자 일하거나, 한 프로젝트를 20년 붙잡고 있었던 것처럼 느껴짐. 팀이나 큰 조직에서 일하는 누구도 코드베이스 전체를 안다고 말할 수 없고, 에이전트형 프로그래밍을 하는 사람도 마찬가지임. 그래도 에이전트에게 질문하면 답을 받을 수 있고, 평생 남의 코드를 읽어온 입장에서 LLM이 쓴 코드도 읽을 수 있음. 나쁜 코드를 기계가 썼든 사람이 썼든 전혀 신경 쓰이지 않고, 적어도 기계는 내 피드백을 받아 행동으로 옮김
사소한 문제라도 저수준 언어, 어셈블리, 덜 흔한 알고리즘, 네트워크 프로토콜 같은 추가 기술이 필요해지는 순간 해결하지 못해 멈춰버린 소프트웨어 팀을 많이 봤음
반대로 본 것을 해석할 능력이 없어서가 아니라, 독점 라이브러리나 독점 운영체제처럼 블랙박스인 것을 써서 내부를 파고들 수 없고 실제 동작을 확인할 방법이 없어 막히기도 함
그래서 아주 드물게만 필요하더라도, 작업하는 모든 것에 대해 전부 알아낼 수 있는 환경은 항상 가능해야 한다고 봄
중요한 건 시스템의 나머지를 배우는 걸 두려워하지 않고, 색인을 유지하는 것임
무엇보다 어떤 것이든 빠르게 파악할 수 있어야 함. 그래야 넓게 다룰 수 있음. 필요할 때는 깊이 파고들고, 필요할 때는 높은 수준에서 훑어보는 식으로 문제에 맞는 적절한 수준을 잡아야 함
오래전 대학에서는 컴퓨터과학 전공자에게 공학 전반을 가르쳤음. “화학공학이나 아날로그 제어 시스템을 언제 알아야 하죠?”라고 묻자, “쓸 일은 없을 것이다. 다만 코딩할 만큼 빠르게 파악하고 나중에 잊으면 된다. 우리는 튼튼한 기반을 주는 것이다”라고 답했음
이건 큰 코드베이스 안에서도 그대로 적용됨
git-ai [0] 같은 도구는 LLM 세션을 캡처하고 각 파일 편집을 특정 에이전트 동작과 연결하며, 에이전트가 특정 코드 조각에 대해 그 주변 대화, 즉 사용자가 무엇을 프롬프트했는지, 그 코드를 만든 LLM의 추론이 무엇이었는지 등을 조회하게 해줌. 균형을 바꿀 수 있지만 아직 널리 쓰이지는 않음
[0] https://usegitai.com/
25년 이상 된 시니어 개발자로서 최근 “5분만 들어와 줄 수 있나요”라는 식으로 회의에 던져졌는데, 중간에 아무 맥락 없이 끌려 들어가는 이런 회의를 정말 싫어함
질문이 소개도 없이 빠르게 쏟아졌고, 수십 개 중 하나인 외부 연동에 관한 내용이었음. 더 나쁘게도 그쪽은 우리와 다른 자체 용어를 씀
이 연동들을 만들 때 모델에 크게 의존했기 때문에 질문을 이해하는 데 매우 힘들었음. 극도로 지루한 작업이었고, 외부의 두꺼운 명세가 제공된 상태였음
모델을 쓰지 않았다면 10배 시간을 들여도 이런 연동은 아마 완성되지 못했을 거라는 생각은 여전히 긍정적임. 하지만 이제는 이런 불편한 순간이 다시 생기지 않도록 “아하” 포인트들을 다시 문서화할지 신중히 생각하고 있음
회의에서 이렇게 무지하고 창피하다고 느낀 적이 없었고, 할 수 있는 말은 “그건 확인해서 답하겠습니다, 이것도요, 저것도요”뿐이었음
인지 부채는 정말 현실이고, 개인적으로는 기술 부채보다 더 아픔. 기술 부채는 팀 전체가 공유하지만 인지 부채는 개인적이며, 그걸 만든 사람이 바로 나였다면 더 잘 알고 있어야 함
앞으로는 “이건 무엇인가”, “저건 무엇인가” 식의 5분짜리 플래시카드형 Markdown 용어 목록을 만들지 않으면 일이 끝난 게 아니라고 볼 것임
시니어 개발자라면 마음에 들지 않는 행동에 제동을 걸어야 하는 사람임. 권한이 있음. “흥미로운 질문이네요. 제 관점을 말하려면 맥락이 더 필요합니다. 시스템 아키텍처를 간단히 설명해 주시거나, 이 접근으로 실제 어떤 문제를 풀려는지 설명해 주실 수 있나요?”라고 하면 됨
그런 대우를 받았을 때 “이 질문에 제대로 답하려면 문서와 코드를 검토해야 합니다”는 완전히 괜찮고, 꽤 외교적인 답변임
전문성이 쌓아 올릴 대상으로 보이는 게 아니라 그저 창의적인 확증 편향을 확인하는 용도로 쓰이는 회의는 즐겁지 않음
생성된 코드에서 문제를 찾으려면 개발자가 신경을 써야 함. 많은 개발자들, 특히 대기업 개발자들은 이미 일에서 상당히 빠져 있고, 가능한 최소 노력으로 티켓을 닫고 책임을 넘길 방법만 찾고 있음
그런 개발자들은 능력이 있더라도 에이전트가 놓친 문제를 찾을 만큼 생성된 코드를 이해하려고 노력하지 않을 것임. 특히 지금 같은 AI 주도 속도 열풍 속에서는 더 그렇다
생성된 코드는 언어적으로는 그럴듯하지만, 흔한 관용구를 자신도 모르게 incoherent하게 흉내 내는 경우가 많아서 실제 버그가 정상적인 인간, 심지어 나쁜 프로그래머도 떠올리기 힘든 방식으로 우연히 숨겨질 수 있음
LLM에는 내부 평가가 없으므로 리뷰어는 이를 감안해 줄 단위로 평가하고, LLM이 애초에 갖고 있지 않았던 숨은 근거와 암묵지를 처음부터 다시 세워야 함. 그러다 비문제에 끌려가 값비싼 시간을 소모하기도 함
이 시점에서는 처음부터 작성하는 것보다 투자가 더 커지는 경우가 많음
어쩌면 지금 회사들은 정크 AI를 사고 있고, 다음 단계에서는 그 “해결책”을 약속받는 중일지도 모름. 자본주의는 정확히 예상대로 작동하고 있음
이 글은 조금 핵심을 비껴간 것 같음
AI를 많이 쓰면 기술 손실은 있음
하지만 방 안의 어색한 코끼리를 인정하고 싶음. AI는 사람들을 너무 빠르게 만들고 있음. 빠른 산출 자체가 나쁘다는 뜻이 아니라, 코드를 만들어낸 전체 이해와 경험보다 빠른 산출물과 코드가 앞서고 있다는 뜻임. 깊은 지식으로 안전한 결정을 하며 만드는 사람보다, 사업 가치를 말하려는 사람에게 보상을 주고 있음
AI는 좋고 좋은 해결책도 만들 수 있지만, 궁극적으로 자신이 뭘 하는지 모르며 최선의 경우에도 강한 조율자가 필요함
우리는 사업 주도 개발의 오물탕에 있고, 나쁜 결정에 대해 충분히 가혹한 평판상 처벌이 돌아가지 않고 있음
다시 말해 기술 손실이 그렇게 큰 문제인지 확신하지 못하겠음. 그냥 우리 일의 성격이 바뀌고 있다는 신호일 수도 있음. C++ 표준을 줄줄 외우고 수백 가지 기능을 올바르게 쓰는 능력보다 좋은 아키텍처를 아는 능력이 더 높게 평가되는 시대가 될지도 모름
일반적인 개발에서는 “정말 이걸 만들고 싶은가”, “이렇게 하면 뭐가 잘못될 수 있는가”를 더 오가며 따지는 편이고, 이상적으로는 PR 승인이나 병합·배포 전에 함. 그 일부가 “나중에 누가 불평하는지 보자”로 옮겨가고 있음. 말하듯이 예방 1온스가 치료 1파운드보다 낫다는 것임
게다가 그 코드는 해당 프로젝트의 관용적인 C++가 아니었고, LLM은 이미 있는 API를 완전히 무시했음. 고칠 수는 있고 메인테이너가 잡았어야 하지만, 생성되는 코드의 양 때문에 모두가 너무 많은 에너지를 써야 함
이런 블로그 글들은 의심할 여지 없이 AI 도움을 받아 쓰였을 텐데, 여기와 인터넷 곳곳에서 수년째 댓글 주제가 되어 왔음. 기술 위축은 심각한 우려이고, 2022년부터 AI에 회의적인 모두가 반복해서 말해왔지만, 어떤 사람들과 어떤 곳은 그냥 신경 쓰지 않는 것 같음
어느 시점부터 코드에 대한 통찰 없이 쓰레기 기계 레버만 당기고 있다면, 상사가 왜 연봉 5만 달러 이상을 받아야 하느냐고 묻는 것도 정당할 수 있음
더 빠르게 가려고 AI를 쓰는 건 잘못된 것을 최적화하는 것임. 내가 일한 모든 곳에서 기능을 구현하는 데 필요한 다른 모든 일에 비해 “코드 작성” 자체가 가장 적은 시간을 차지했음
하루면 코딩할 수 있는 기능을 보자. 먼저 회사가 쓰는 Agile이든 Waterfall이든 계획 의식을 통해 모든 걸 계획하고, 작업을 쪼개고, JIRA 티켓을 만들고, 누가 할지 정해야 함. 이것만 며칠 또는 몇 주가 걸릴 수 있음. 그다음 제안 설계를 담은 설계 문서를 쓰고 동료·팀원 리뷰를 받아야 하며, 실질적인 기능이라면 또 한 주가 걸림. 여러 팀이 관련되면 그 팀들의 동의와 설계 합의를 받아야 하니 한 주를 더하자. 어떤 곳에서는 작업 시작 승인이 필요하고, 승인자의 일정과 가용성에 따라 며칠이 더 걸림
그런 다음 하루 동안 코드를 쓰고 테스트를 통과시킴
그다음 코드 리뷰가 있고, 팀과 많은 왕복을 하며 여러 번 반복하고 추가 리뷰를 받을 수 있음. 또 며칠 또는 몇 주가 감. 더 큰 회사라면 법무, 개인정보, 성능, 접근성, QA 같은 다른 부서의 온갖 리뷰를 통과해야 함. 병렬로 하더라도 보수적으로 2주를 더하자. 마지막으로 스테이징에 올리고 내부 도그푸더 사이에서 어느 정도 숙성 시간을 가져야 작동에 자신이 생김. 1주 추가. 이제 스테이징에서 프로덕션으로 올릴 준비가 됐지만, 진지한 회사라면 아무것도 바로 100% 프로덕션에 보내지 않음. 천천히 비율을 올리고, 롤백이 필요할 경우를 대비해 피드백과 지표를 확인해야 함. 전체 출시까지 또 2주가 걸릴 수 있음
그러면 설계부터 출시까지 두 달쯤 걸린 기능에서, 우리는 하루 걸린 부분을 5분으로 줄이려고 난리 치는 셈임
소프트웨어를 만들 때, 그것이 문제에 대한 이해의 스냅샷임을 기억해야 함. 그것은 모두에게, 미래의 자신에게도, 접근 방식과 명료함, 그리고 당면한 문제에 대한 해법의 적절성을 말해줌. 그러니 무엇을 말할지 현명하게 선택해야 함
설계부터 출시까지 두 달 걸린 기능에서 하루짜리 부분을 5분으로 줄이려 애쓴다는 표현은 잘 짚었음
이런 일은 안정된 회사에서 모든 엔지니어의 일상 중 작지 않은 부분이었음. “플랫폼 엔지니어링”이든 뭐라 부르든 이 영역은 죽었음
또 위험과 노력 대비 보상이 맞지 않아 시도하지 않았을 기술적으로 위험한 아이디어들이 이제 손에 닿음. 단순히 “더 빨리 가기”라기보다, 무언가를 시험해 볼 수 있는 속도가 엔지니어링 과정의 성격 자체를 바꿈
소프트웨어 엔지니어가 충분히 싸지면 이런 프로세스의 많은 필요성이 사라짐. 이미 이런 프로세스를 가진 회사들은 그런 관료제를 깨기가 극도로 어렵기 때문에 곤란하겠지만, 애초에 그런 프로세스가 없거나 제거할 수 있는 회사들은 상당한 경쟁 우위를 갖게 됨
새 소식은 아님. 스타트업은 항상 실행 속도로 기존 기업과 경쟁해 왔음. 새로워진 건 그 속도를 더 오래 유지할 수 있는 능력임
법무, 개인정보, 성능, 접근성, QA 같은 리뷰도 모두 표적 안에 있음. 회사가 이런 리뷰에 따른 법적 책임을 외부 제공자에게 넘길 수 있다면 그렇게 할 것임
[0] 이 프로세스의 상당 부분이 결국 시간을 아끼려던 바로 그 직원들에게 떠넘겨진다는 아이러니는 일단 무시하자
빅테크에는 그런 허세 섞인 절차가 많지만, 작은 회사들은 빠르고 거칠게 움직일 수 있음
코드 품질은 결국 당신에게 달려 있음
에이전트와 반복해서 작업해, 자신이 직접 썼을 때와 똑같은 품질의 코드가 될 때까지 다듬는 걸 막는 건 없음
이런 글들은 꽤 답답함. 다만 작성자가 말한 토큰 비용은 현실이고 위험임
AI 도구는 접근법을 브레인스토밍하고 가끔 코드를 생성하는 데 쓰지만, 실제 타이핑은 내가 직접 함. 그러면 시간이 지나며 메커니즘과 프로그래밍 언어를 잊을 가능성이 줄어듦
솔직히 전체가 LLM에게 코드를 쓰게 프롬프트하고 리뷰하는 일뿐이라면 오픈소스 메인테이너를 굳이 할 것 같지 않음. 전혀 충족감이 없어 보임
실제 유급 직업이라면 LLM 사용 방식이 어떻게 달라질지는 궁금함. 내가 소프트웨어 개발자인 이유는 이 기술 자체를 사랑하기 때문임. 만드는 행위, 뇌를 써서 아이디어를 코드로 바꾸는 행위를 좋아함. 그냥 LLM에 프롬프트하는 일이라면 그 직업을 계속할지 모르겠음. 적어도 전직을 알아보기 시작할 것 같음
유지보수해야 하는 코드에서는 이 방식을 씀. 그래도 모델이 틀린 정보를 많이 섞기 때문에 가끔 당함. 보통 과거에는 맞았지만 지금은 틀린 내용임
버려도 되는 스크립트나 검증이 쉬운 스크립트는 생성하게 하지만, 과도한 설계나 모든 경계 사례를 잡으려는 시도는 피하라고 요청함. 스크립트에서는 실패한 단계가 그대로 드러나도록 오류가 나게 두는 편이 더 이해하기 좋기 때문임
PowerShell처럼 읽기 어렵다고 느끼는 언어는 피하고, 화면 안에 들어올 만큼 짧아서 전부 읽고 이해할 수 있는 것을 생성하는 편을 선호함. Python, Bash, Batch가 내가 주로 쓰는 스크립트 언어임
AI 제안의 50% 이상은 여전히 거절함. 너무 평범하거나, 이유 없이 코드를 옮기거나, 때로는 그냥 틀리기 때문임
웃긴 점은 이 기술이 둘 중 하나라는 것임
전문성 없이 위임은 할 수 있지만 틀렸거나 아예 불가능한지 알 수 없는 관리자용 기술이거나, 전문성은 있지만 그 전문성을 점점 잃게 될 코더용 기술임
그래서 다음 분기까지의 VC와 주주 말고는 누구를 위한 건지 잘 모르겠음
약간 주제에서 벗어나지만, 글에서 Spec Driven Development가 미래라고 말하는 게 웃김
기술적으로는 우리가 Waterfall을 하던 시절 이미 그렇게 했음. 좋은 문서가 있던 시절이 조금 그립기도 함. 지난 10년, 어쩌면 그 이상 동안은 한 줄짜리 JIRA 티켓을 받는 일이 많았고, 거의 아무것도 명시하지 않아서 사람들에게 전화해야 하는 경우가 잦았음
나는 아직 AI로 일하는 걸 피하고 있음. 실험용으로 로컬 모델 몇 개를 써보려 하지만, 남의 것을 뜯어다 만든 것에 돈을 내기는 거부함. 그리고 지금까지 로컬 모델은 기대 이하였음