소프트웨어 엔지니어링의 기본기가 더 중요하다

요즘 내 가면 증후군은 ‘소프트웨어 엔지니어란 무엇인가’라는 질문으로 나타난다. 인터넷에는 에이전트 기반 엔지니어링으로 무엇을 해낼 수 있는지, 이것이 미래에 어떤 영향을 미칠지를 두고 유용한 정보보다 잡음이 훨씬 많다. 제목에서 이미 드러나듯, 이 글은 소프트웨어와 시스템 개발이라는 퍼즐을 풀 때 필요한 수많은 선택을 신중하게 내리는 일에 관한 이야기다.

‘주요 모델 제공업체’가 쏟아내는 과장과 중독적인 마케팅 열기를 걷어내고 보니, 에이전트 하네스와 모델의 조합은 아주 흥미로운 전동 공구였다. 친구들이 이 도구를 어떻게 쓰는지 지켜보며 정말 많은 것을 배웠다. 늘 그렇듯 가장 놀라운 일을 해내는 사람들은 이를 떠벌리거나, 이 직업이 끝났다는 서사를 소셜 미디어에 올리는 이들이 아니다. 그들은 ‘엄청나게 큰 지렛대’를 손에 넣고 받침점을 찾아 나섰다. 그리고 옛 아르키메데스처럼 지렛대에 힘을 실어 세상을 움직이고 있다.

지난 1년 사이 에이전트 하네스는 ‘이게 가능한가’라는 경계를 넘어섰다. 로마 이야기까지 꺼냈으니 루비콘강을 건넜다고 해두자. 세상의 지식이 허락도 존중도 없이 수집되기를 바라지는 않았다. 제정신이 아닌 사람들이 사익을 챙기는 경제 구조를 파고들어, 가라앉고 있는 미국 경제 위에 땅콩버터를 펴 바르듯 문제를 덮는 것도 원하지 않았다. 내가 본 어떤 자료에서도 대형 모델의 경제성이 지속 가능하다는 근거는 찾지 못했다. 하지만 이 역량 자체가 사라지지는 않을 것이다. 오히려 그 역량을 구현하는 모델은 빠르게 작아지고 있다. 오픈 웨이트 모델 덕분에 성능 좋은 개인용 컴퓨터로도 상당 부분 같은 일을 할 수 있다. 아직 효과가 완전히 같지는 않지만, 걸리는 시간과 역량의 차이는 크지 않다.

‘가능한가’는 출발점에 불과하다. 소프트웨어 또는 시스템 엔지니어라는 직업에서 차지하는 비중은 절반에도 훨씬 못 미친다. 내가 20대에 용접을 배웠을 때와 비슷하다. 얼마 지나지 않아 혼자 들 수도 없고 작업장 문 밖으로 꺼낼 수도 없는 물건들을 만들었다. 아세틸렌 절단기가 있어서 정말 다행이었다. 그때 배운 교훈은 매체만 다를 뿐 지금도 같다고 생각한다. 각 부분을 어떻게 결합하느냐에 따라 모든 것이 달라진다.

조금만 앞을 내다보며 에이전트 하네스로 개발하면 ‘작동한다’를 넘어 ‘테스트할 수 있다’까지는 얻을 수 있다. 나는 develop with red/green TDD라는 프롬프트를 특히 적극적으로 사용한다. 하지만 그보다 높은 수준에서는 결과가 그다지 견고하지 않다. 코드가 작동하는 방식과 API, 다른 소프트웨어와 결합되는 지점인 경계면을 설계하는 일은 과학인 동시에 예술이다. 지금 해결하려는 문제뿐 아니라 그 소프트웨어를 오랫동안 어떻게 운용할지 판단하려면 관점과 경험, 그리고 추측에 의존하는 주관적 기준이 필요하다.

디버깅하기 쉽고 유지보수 가능하며, 계층이 분명하고 조합할 수 있는 소프트웨어를 만드는 일은 여전히 만만치 않다. 그중 상당 부분에는 폭넓고 신중한 추론이 필요하다. 오늘날의 LLM은 프런티어 모델이 보여주는 최첨단 ‘역량’까지 포함해도 바로 이 지점에서 부족하다.

LLM이 ‘추론’하지 않는다는 사실을 알면 도움이 된다. LLM은 예측하며, 모델 자체는 사실상 인간이 기록한 지식을 압축한 것이다. 학습 데이터에 인간의 지식이 담겨 있다면 인간의 추론을 되풀이할 수 있다. 소프트웨어 개발에 초점을 맞춘 에이전트에서는 그런 추론 과정이 모델에 매우 귀중한 데이터다. LLM이 추론을 얼마나 못하는지 쉽게 설명한 연구 논문으로 The Illusion of Thinking이 있다. 내가 지켜보는 연구 중에는 행동의 결과를 예측하는 분야도 있지만, 오늘날 코딩 에이전트가 제공하는 기술은 아니다. 상당히 다른 영역이며 무척 흥미롭다. 더 살펴보고 싶다면 ‘JEPA models’의 작동 방식과 LeWorld Model, Yann LeCun의 최근 강연을 찾아보길 권한다.

그렇다고 LLM을 더 효과적으로 활용할 방법이 부족한 것은 아니다. 아직 제대로 끌어내기 시작하지도 못한 발전 가능성이 많다고 생각한다. 현재 내가 목격하는 성과의 대부분은 적절한 시점에 품질 좋은 간결한 데이터를 제공하고, LLM이 자연어 피드백을 받아 스스로 수정할 수 있도록 결과가 확정적인 검증 도구를 제공하는 데서 나온다. 내가 놀랍다고 느끼는 점은 무엇을 써야 할지 예측하는 능력이 아니라, 도구를 호출하고 지시를 따르는 능력이 뛰어나다는 사실이다.

지시를 잘 따르는 능력에는 또 다른 단점도 있다. Simon Willison이 ‘치명적인 삼박자’라고 이름 붙인 문제다. 요컨대 LLM 모델은 좋은 조언과 나쁜 조언을 구별하지 못한다. 프롬프트 인젝션 공격을 언제나 일관되게 막는 일은 근본적으로 불가능하다. ‘정렬 작업’, 안전장치, 샌드박스는 최악의 결과를 막는 장벽을 더해주지만 근본적인 빈틈은 남는다. 솔직히 말해 제대로 추론하지 못하면서 지시를 지칠 줄 모르고 따르는 존재는 내게 악몽 그 자체다.

가까운 시일 안에 사후 학습을 위한 추론 과정에 해당하는 데이터를 포함하도록 모델 학습 방식이 발전하기를 바란다. 이를 위한 방법으로 RLHF가 있다. 내가 바라는 미래에는 깔끔한 인터페이스를 갖추고 디버깅과 유지보수가 쉬운 소프트웨어를 만드는 능력이 강화 평가의 핵심 요소로 더 많이 포함된다. 소프트웨어와 시스템의 경계면을 세심하게 검토하고 계획하고 수정하는 일은 에이전트 기반 도우미를 쓰든 쓰지 않든 우리가 소프트웨어를 개발할 때 발휘할 수 있고, 반드시 발휘해야 하는 핵심 역량이다. 사람들이 “아, 그건 구현하기 쉽지…”라고 말하며 깡통 로봇에게 일을 맡기려는 물결을 보고 있자니, 이 역량은 그 어느 때보다 중요해졌다고 생각한다.

지금은 소프트웨어 제작 기술과 더 나은 장인이 되는 방법을 글과 말로 공유하는 사람들을 지켜보기에 아주 좋은 때다. 당연한 말이겠지만 모든 문제를 해결하는 단 하나의 만병통치약은 없다. 언제나 장단점을 따져 당면한 문제에 적합한 선택을 내려야 한다. 현재 활동하는 사람부터 수십 년 전의 선구자까지 수많은 뛰어난 이들이 생각을 공유한 덕분에, 우리에게는 이 일을 위한 훌륭한 도구 상자가 있다. 중요한 것은 올바른 추상화를 선택하거나, 더 나은 선택으로 옮겨갈 수 있도록 기존 추상화를 다시 다듬는 일이다. 그 핵심에는 인지 부하를 관리하고, 어떤 부분을 안정적으로 유지해야 하며 어디를 얼마나 유연하게 바꿀 수 있어야 하는지 알아가는 과정이 있다.

그리고 그렇다. 이 빌어먹을 em dash는 내가 직접 썼다. 나는 글을 쓸 때 괄호 안에 또 괄호를 넣는 표현을 지나치게 좋아하고, 가끔은 쉼표와 괄호 말고 다른 문장 부호도 쓰고 싶다.

^{source https://rhonabwy.com/2026/08/15/software-engineering-fundamentals-matter-more-than-ever/}

HN에서는 AI 코딩의 성패가 모델의 성능만큼이나 요구사항과 검증 체계에 달렸다는 반응이 두드러졌다. 기능 구현과 반복 작업에는 이미 충분히 유용하지만, 디렉터리 구조와 인터페이스, 상태 관리, 오류 처리처럼 명세에 드러나지 않은 판단까지 맡겨도 되는지는 의견이 엇갈렸다. 요구사항이 비어 있으면 AI가 스스로 가정을 채우므로, 코드가 작동한다는 사실만으로 설계까지 적절하다고 보기는 어렵다는 지적이다.

활용 경험도 크게 달랐다. 상당한 규모의 코드베이스를 거의 읽지 않고 수개월간 관리했다는 사례가 있는 반면, 기존 저장소에서는 작은 변경이 잇따른 오류로 번졌다는 경험도 나왔다. 비교적 안정적인 방법으로는 테스트를 먼저 실행할 수 있게 만들고, 명확한 목표와 참조 코드, 아키텍처 규칙을 제공하는 방식이 제시됐다. 사람이 작성한 테스트와 엄격한 타입 검사가 갖춰져야 전수 검토의 부담을 줄일 수 있다는 설명도 뒤따랐다.

유지보수성을 어디까지 중시할지도 핵심 쟁점이었다. 빠른 출시가 우선인 사업에서는 당장 뒤로 밀릴 수 있지만, 기술 부채가 쌓이면 신규 인력이 적응하지 못하고 개발 속도마저 떨어질 수 있다. 한편 AI가 리팩터링과 재작성 비용을 크게 낮춘다면, 초기 시제품을 빠르게 만든 뒤 인터페이스와 모듈 경계를 다듬는 접근도 가능하다는 실험담이 소개됐다.

결국 기본기는 특정 설계 방식이나 유행을 외우는 일이 아니다. 제한된 일정과 비용, 운영 책임 속에서 무엇을 명세하고 어떤 결과를 검증할지 정하는 능력에 가깝다. AI 도입 여부도 생성된 코드의 겉모양보다 테스트 가능성, 오류 처리 기준, 장기 운영 주체, 변경의 파급 범위를 중심으로 판단해야 한다.