Fierabras의 Balsam과 AI의 약속

Source: Dev.to

위에 제공된 텍스트가 없습니다. 번역을 원하시는 본문을 알려주시면 한국어로 번역해 드리겠습니다.

AI “효율성” 내러티브

최근 저는 우리 산업에서 일어나고 있는 어떤 현상을 지켜보고 있습니다. 그 현상은 어딘가 익숙하면서도 쉽게 떨쳐버릴 수 없는 느낌을 줍니다. 기업들은 AI를 통한 **“효율성 향상”**에 대해 이야기하고 있습니다. 20 %, 30 % 등과 같은 수치가 떠돌아다니고, 때로는 그보다 더 큰 수치도 있습니다. 그리고 그 수치와 함께 내려지는 결정들이 있습니다: 팀 규모 축소, 엔지니어 수 감소, 일정 단축.

저는 심지어 기업이 엔지니어링 팀의 대부분을 전부 해고한다는 이야기도 들었습니다(전해 내려오는 이야기든 아니든). 제품 팀이 AI 도구를 점점 더 많이 활용해 직접 코드를 생성합니다. 남아 있는 소수의 엔지니어들은 시스템을 구축하기보다는 검토하고, 배포하고, 시스템을 유지하는 일에 집중하게 됩니다.

피에라브라스의 향유 비유

그 매력은 이해합니다. 정말 이해합니다. 솔직히 말하면, 제 안의 일부는 그것이 사실이길 원합니다. 하지만 저는 돈키호테를 떠올리지 않을 수 없습니다. 소설 속에 피에라브라스의 향유라는 약이 등장합니다. 이 약은 기적적인 치료제—어떤 상처든 치유할 수 있는 치료제라고 알려져 있습니다.

돈키호테는 그것을 전적으로 믿습니다.

그가 결국 향유를 만들고 마셨을 때, 결과는… 기적적이지 않았습니다. 그는 심하게 몸이 아팠고, 치유되지도 않았으며, 회복되지도 않았습니다. 오히려 거의 파멸에 가까운 상태가 되었습니다.

그럼에도 그는 그것이 효과가 있었다고 주장합니다.

그 장면에서 저에게 남은 것은 향유가 실패했다는 점이 아니라 믿음은 실패하지 않았다는 점입니다. 치료에 대한 약속이 너무 강력해서 증거는 무시되었습니다.

지금 AI는 바로 그런 약속처럼 느껴집니다. 도구가 아니라 치료제처럼. 더 빠르게 움직이고, 비용을 줄이며, 노력을 대체하고, 어떤 대가도 치르지 않고 앞서 나갈 수 있는 방법처럼.

AI와의 관계

• 분명히 말하자면, 저는 AI를 사용합니다. 저는 AI가 유용하다고 생각합니다. 경우에 따라서는 믿을 수 없을 정도로 유용합니다.
• AI는 워크플로우를 가속화하고, 아이디어 탐색을 돕고, 이전에 너무 오래 걸리던 개발 과정의 일부에서 마찰을 없앨 수 있습니다.

하지만 저는 우려도 가지고 있습니다.

엔지니어링 vs. 출력

I worry about engineers being replaced. Not completely, not overnight — but enough to matter. Enough to change who gets to stay, who gets to grow, and who never gets a chance to start.

나는 엔지니어가 대체되는 것이 걱정된다. 완전히, 하루아침에가 아니라 — 하지만 충분히 의미가 있다. 충분히 누가 남을 수 있고, 누가 성장할 수 있으며, 누가 시작할 기회조차 얻지 못하는지를 바꾼다.

What worries me more is something harder to see: engineering being redefined as something smaller than it actually is. Software development isn’t just output. It’s judgment. It’s trade‑offs. It’s understanding why something should exist, not just how to build it.

더 걱정되는 것은 보기 어려운 무언가이다: 엔지니어링이 실제보다 더 작은 것으로 재정의되는 것. 소프트웨어 개발은 단순히 출력만이 아니다. 그것은 판단이다. 그것은 트레이드‑오프이다. 그것은 왜 무언가가 존재해야 하는지를 이해하는 것이며, 단지 어떻게 만드는지가 아니다.

When we reduce engineering to output, tools that accelerate output start to look like complete solutions.

우리가 엔지니어링을 출력으로 축소할 때, 출력을 가속화하는 도구들은 완전한 솔루션처럼 보이기 시작한다.

실제 사례

시나리오: 엔지니어가 AI가 같은 문제를 반복해서 해결하려고 루프에 빠진 상황. 다양한 접근 방식과 변형을 시도했지만, 때때로 같은 해결책을 반복하기도 함.
근본 원인: 문제는 코드가 아니라 환경에 있었다.

• 한 시스템은 대소문자 구분 없는 파일 시스템을 사용했음.
• 배포된 환경은 대소문자 구분 있는 시스템이었음.
• 단 한 글자 차이만으로 모든 것이 깨졌음.
• AI는 이를 포착하지 못했음.

이는 AI를 비난하는 것이 아니라, AI가 자연스럽게 이해하는 맥락을 벗어난 경우다.

수년간 나도 비슷한 문제를 겪어봤다. 경험이 중요한 상황, 즉 코드를 읽는 것만이 아니라 코드가 실행되는 복잡하고 일관성 없는 인간적인 시스템을 고려해야 할 때가 있다. 이런 부분은 깔끔하게 번역되지 않는다.

경험 많은 엔지니어를 배제하거나, 그 깊은 경험 없이 AI에만 의존하는 사람들로 대체한다면, 우리는 얼마나 자주 그 루프에 갇히게 될까?

시간을 낭비하고, 토큰을 소모하고, 해결책을 하나씩 시도하면서… 적절한 맥락을 가진 사람이면 몇 분 안에 문제를 발견할 수 있는 상황을 말이다.

효율성은 단순히 속도에서 오는 것이 아니다. 어디를 봐야 할지 아는 것에서 온다. 여기서 나는 불안함을 느낀다. 위험은 AI가 작동하지 않는 것이 아니라, 그것이 문제 없이 작동한다고 믿는 것이다.

차세대 엔지니어

이와 관련해 충분히 이야기되지 않는 또 다른 부분이 있습니다: 다음 세대 엔지니어에게 무슨 일이 일어나는지.

• 우리 대부분은 처음부터 완벽한 코드를 작성함으로써 이 기술을 배우지 못했습니다.
• 우리는 문제들을 헤쳐 나가며, 의미가 통하지 않는 디버깅을 하고, 시스템 깊숙이 파고들어 실제로 무슨 일이 일어나고 있는지 이해할 때까지 배웠습니다.

그 과정은 느리고, 때로는 좌절감을 주며, 가끔은 고통스럽습니다. 하지만 진정한 기술이 여기서 비롯됩니다.

엔지니어링의 일상이 프롬프트 작성과 생성된 코드 검토로 이동한다면, 기술 곡선이 변합니다:

시간이 지나면 이것이 중요해집니다. 문제 해결은 표면적인 기술이 아닙니다. 이미 작동하는 코드를 검토함으로써 습득되는 것이 아닙니다. 잃어버린 상태를 여러 번 겪으며, 더 이상 잃어버리지 않을 때까지 얻어지는 것입니다.

시스템을 처음부터 구축하는 엔지니어 수를 줄이면 — 복잡함과 직접 씨름해야 하는 사람이 적어지면 — 깊은 문제 해결 능력이 드물어지는 것에 놀라지 않아야 합니다. 사라지는 것이 아니라 더 작아지고 찾기 어려워져, 소수에게 집중됩니다. 이는 또 다른 형태의 취약성을 만들게 됩니다.

장기적 취약성

우리가 더 적은 인원—작은 팀, 경험이 적은 엔지니어, 생성된 결과물에 더 많이 의존한다는 믿음—으로 더 많은 일을 할 수 있다고 판단하고 결정을 내리면, 비용은 즉시 드러나지 않습니다. 비용은 나중에 다음과 같은 형태로 나타납니다.

• 복잡성
• 취약성
• 이제는 아무도 완전히 이해하지 못하는 시스템

시스템이 빠르게 생성되었다고 해서 건강하게 유지되는 것이 아닙니다. 시스템이 건강하게 유지되는 이유는 누군가가 그것을 충분히 깊이 이해하고 관리하기 때문입니다.

마무리 생각

I don’t think this ends with engineering disappearing. But I do think it’s possible we create a gap. Companies optimize for smaller and smaller teams, more output per person, more reliance on generated code. On paper, it looks efficient. Maybe it even is — for a while.

하지만 시간이 지나면서 우리는 단기 치료제(AI “balsam”)를 구매하고 있다는 느낌을 떨칠 수 없습니다. 동시에 복잡한 시스템을 살아 있게 하는 깊이, 판단력, 인간 경험을 잃는 장기 비용을 무시하고 있습니다.

Source:

엔지니어링에 대한 성찰과 자동화의 부상

모든 생성된 산출물—토큰, 크레딧, 복잡성—의 비용이 처음부터 경험이 풍부한 엔지니어를 두는 것보다 비슷해지는 임계점, 즉 일종의 임계 질량에 다다르고 있다.

그리고 그 깨달음이 찾아올 무렵, 상황은 이미 변했을지도 모른다.

• 그 엔지니어들 중 일부는 떠나게 된다. 두려움 때문이 아니라 좌절감, 번아웃, 혹은 상황이 악화되고 있음을 보고 더 안정적인 길을 선택했기 때문이다.
• 다른 이들은 여전히 남아 있겠지만, 수는 적고, 더 넓게 퍼져서 더 많은 부담을 짊어진다.
• 그 뒤를 잇는 신입들은 깊이 있게 장인을 배울 기회를 충분히 갖지 못했을 수도 있다. 능력이 부족해서가 아니라 주변 환경이 달라졌기 때문이다.

문제를 직접 겪을 기회가 줄어들고, 처음부터 시스템을 구축할 기회도 줄어든다. 가르칠 시간·권한·욕구—혹은 본능—을 가진 멘토도 줄어든다.

이 부분이 내가 계속 되돌아보는 지점이다. 도구가 아니라, 효율성도 아니다. 하지만 직업의 장기적인 형태다.

돈키호테는 Balsam of Fierabras를 단순히 믿은 것이 아니라, 결과가 약속과 맞지 않을 때조차도 그것에 더욱 매달렸다.

아직 그 단계에 이르렀다고 보지는 않지만, 이제는 더 깊은 질문을 던질 가치가 있는 시점이라고 생각한다.

• “우리가 이것을 더 빨리 할 수 있을까?”라는 질문만이 아니라,
• “그 과정에서 우리는 무엇을 잃고 있는가?”라는 질문도 필요하다.

우리가 조심하지 않으면, 조용히 사라져 버린 무언가를 다시 복구하려 애쓰게 되고, 그 방법을 알던 사람들은 이미 떠나버려 물어볼 수 없게 될 수도 있다.

나는 여기서 풍차를 공격하는 것이 아니다. 내가 보는 바를 솔직히 말하고, 모두가 balsam을 마시기 전에 몇 가지 질문을 던져보려는 것이다.

CrossPosted: LinkedIn | Medium