AI를 쓰면서도 엔지니어로 남는 법

AI가 편해질수록 비워지는 느낌

제품을 개발하면서 AI를 더 자주 쓰게 될수록, 어딘가 제 머리가 비워지는 느낌을 받았습니다. 얼마 전에는 AI가 작성한 코드에서 버그가 발생했습니다. 처음에는 직접 디버깅해 보려 했지만, 막상 코드를 따라가며 맥락을 복원하는 일이 생각보다 쉽지 않았습니다. 결국 저는 최근에 출시된 gpt-5.3-codex에게 수정을 맡겼고, 문제는 빠르게 해결되었습니다. 그런데 그 순간부터 묘한 기시감이 남았습니다. “이렇게까지 AI에게 위임해도 괜찮은 걸까?”, “개발은 빨라졌는데 도메인 이해는 얕아진 채로 다음 이슈로 넘어가는 건 아닐까?”, “AI가 계속 발전한다면, 나는 프롬프트를 쓰는 것 말고 무엇을 할 수 있을까?” 같은 질문들이 몇 주 동안 머릿속을 맴돌았습니다.

 

처음 AI를 쓰기 시작했을 때만 해도, 저는 최소한의 절차를 지키려 했습니다. 계획 → 구현 → 디버깅 → 리팩토링의 순서로 과정을 구조화해, 적어도 ‘이해한 상태’에서 다음 단계로 넘어가고 싶었기 때문입니다. 그러나 AI가 제 의도를 점점 더 잘 맞히기 시작하자, 그 과정은 조금씩 생략되기 시작했습니다. 어느새 저는 “~해줘”라는 한 문장으로 결과물을 받아들고, 그 결과를 충분히 이해하지 못한 채 넘어가는 일이 잦아졌습니다.

 

이 불안의 원인을 처음에는 두 가지로 추측했습니다.

• 새로운 방식을 처음 접했을 때 낯선 것에서 느껴지는 불편함
• AI에게 대체당해서 미래에 어떻게 해야 할지 모르겠다는 두려움

그러나 제 경우에는 둘 다 핵심이 아니었습니다.

 

불안의 이름: 인지 부채

Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing T...

Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task – MIT Media Lab

 

해당 논문은 생성형 AI가 즉각적인 편의성을 제공하는 대신, 장기적으로는 사용자의 사고 과정에 ‘인지적 부채(cognitive debt)’가 쌓일 수 있다는 가능성을 제기합니다. 저는 이 개념을 “AI가 일을 대신해 주는 만큼, 내가 직접 문제를 분해하고 가설을 세우고 검증하는 과정이 생략되는 상태”로 받아들였습니다. 단기적으로는 산출물이 좋아지고 속도가 빨라지지만, 장기적으로는 제 머릿속에 재사용 가능한 청크(패턴)가 덜 남을 수 있다는 뜻입니다.

 

물론 이 연구는 에세이 글쓰기를 다루지만, 제게는 개발에서도 비슷한 감각이 있었습니다. 제게 남았던 기시감도 결국 “편해졌는데, 내 안에 무엇이 축적되고 있지?”라는 질문이었습니다. 기능은 더 빨리 완성되는데, 제가 “왜 이렇게 만들었는지”를 설명할 언어가 남지 않는 느낌 말입니다.

 

그때부터 저는 불안을 “AI에게 대체될지도 모른다”가 아니라 “소프트웨어 엔지니어로서의 내가 사라질지도 모른다”로 다시 정의하게 되었습니다. 그리고 이 정의는, 제가 지난 2년 동안 서로 다른 두 종류의 즐거움을 동시에 맛보고 있었기 때문에 더 선명해졌습니다.

 

두 가지 즐거움, 두 가지 자아

저는 지난 2년 동안 개발자로서 두 종류의 즐거움을 경험했습니다. 하나는 “프로덕트 엔지니어”로서의 즐거움입니다. 사용자가 만족할 만한 제품을 만들어 세상에 내보내고, 지표를 확인하며 내일은 무엇을 더 만들어볼지 고민하는 일에서 에너지를 얻었습니다.

 

다른 하나는 “소프트웨어 엔지니어”로서의 즐거움입니다. 지속 가능하고 유지보수하기 쉬운 구조를 만들고, 성능 최적화로 병목을 제거하고, 새로운 기술을 이해해 적용하는 과정에서 만족을 느꼈습니다.

 

두 자아 중 무엇이 진짜 저일까요. 저는 『무의식은 어떻게 뇌를 설계하는가』를 읽으며, ‘유일하고 진정한 나’가 있다기보다 순간순간의 선택과 습관이 모여 지금의 내가 된다는 관점이 인상 깊었습니다. 그렇다면 프로덕트 엔지니어로서의 저도, 소프트웨어 엔지니어로서의 저도 모두 제 일부입니다.

 

그래서 저는 예측할 수도 없는 미래에 맞춰 “소프트웨어 엔지니어”라는 저의 일면을 스스로 없애고 싶지 않았던 것입니다. AI를 잘 쓰는 사람이 되고 싶지만, 동시에 엔지니어로서의 축적도 포기하고 싶지 않았습니다.

 

미래는 예측 불가능하다

링크드인이나 주변의 대화를 듣다 보면 “언젠가는 AI가 개발자를 대체할 것이다”, “소수의 관리자/시니어만 남을 것이다”, “지금도 AI만으로 1인 기업을 만든다” 같은 말이 자주 오갑니다. 저는 이런 예측이 맞느냐 틀리냐를 따지고 싶지는 않습니다. 다만 한 가지는 분명하다고 생각합니다. 미래는, 우리가 바라는 만큼 예측 가능하지 않다는 것입니다.

 

미래가 완벽히 예측 가능했다면, 우리가 지금 투자하는 학습과 시행착오는 얼마나 허무했을까요. 그러나 현실은 늘 그 반대였습니다. 기술은 예상치 못한 방향으로 바뀌고, 직무의 경계도 바뀌고, ‘필요한 역량’의 이름도 자주 바뀝니다. 그래서 저는 예측 게임 대신, 지금의 제 습관과 작업 방식을 설계하는 쪽을 선택하기로 했습니다.

 

공존을 위한 세 가지 프레임

제가 찾고 싶은 길은 단순합니다. AI 트렌드에 올라타되, 프로덕트 엔지니어로서의 속도와 소프트웨어 엔지니어로서의 축적이 같은 방향을 보게 만드는 것입니다. 이를 위해 저는 아래 세 가지 프레임을 잡아보려 합니다.

 

1) 생산과 축적을 분리해서 생각하기
AI는 산출물을 빠르게 만들어 주지만, 제 지식까지 자동으로 만들어 주지는 않습니다. 그래서 저는 개발을 끝내는 것과, 이해를 남기는 것을 서로 다른 작업으로 취급하려 합니다. 같은 PR이라도 “완성”과 “축적”은 체크리스트가 달라야 합니다.

 

2) 구현은 위임해도, 이해는 외주화하지 않기
버그를 고치는 일까지 AI에게 맡길 수 있습니다. 하지만 그 순간에 제가 놓치기 쉬운 것은 “왜 이 수정이 맞는가”입니다. 저는 앞으로 코드가 통과해야 하는 불변식(어떤 상황에서도 지켜야 하는 조건)과 실패 케이스를 먼저 적고, AI의 수정이 그것을 만족하는지 제 언어로 다시 확인하려 합니다.

 

3) AI를 “제가 읽기 쉬운 코드” 쪽으로 정렬하기
좋은 코드, 혹은 읽기 쉬운 코드는 결국 인간의 뇌가 부담 없이 처리할 수 있는 형태를 가집니다. 아래 글은 그 “읽기 쉬움”의 감각을 작업 기억, 청크, 예측 가능성 같은 관점으로 설명합니다.

 

우리는 왜 어떤 코드를 읽기 쉽다고 느낄까

우리는 왜 어떤 코드를 읽기 쉽다고 느낄까

 

“읽기 쉬움”이 줄여주는 비용

• 작업 기억은 제한적입니다. 한 번에 머릿속에 올려둘 수 있는 정보가 제한되어 있기 때문에, 코드가 너무 많은 상태/분기/개념을 동시에 요구하면 이해 비용이 급격히 올라갑니다.
• 뇌는 반복되는 패턴을 “청크”로 묶어 빠르게 처리합니다. 익숙한 구조와 관용적 네이밍은 ‘새로 해석해야 하는 양’을 줄이고, 이미 있는 청크를 재사용하게 만듭니다.
• 우리는 다음 전개를 계속 예측하면서 읽습니다. 예측 가능한 코드(일관된 흐름, 예상 가능한 부작용, 표준적인 에러 처리)는 예측 오차를 줄여 주고, 그만큼 사고를 본질적인 문제에 쓸 여력을 남깁니다.
• 시각적 구조와 논리적 구조가 어긋나면(예: 들여쓰기/중첩이 의미를 숨기거나, 이름이 역할을 가리지 못하거나, 책임이 섞이면) 작업 기억을 더 많이 소모하게 됩니다.

 

이 관점에서 보면 “읽기 쉬움”은 취향의 문제가 아니라, 제 뇌가 지불해야 하는 비용의 문제에 가깝습니다. 읽기 쉬운 코드는 단지 빨리 읽히는 것이 아니라, 더 적은 비용으로 더 많은 맥락을 남기게 해줍니다. 같은 코드를 다시 만나도 빠르게 복원할 수 있고, 비슷한 문제를 다시 풀 때도 내부의 청크를 재사용할 수 있기 때문입니다.

 

저는 이 관점을 AI 사용 방식에 적용해 보고 싶습니다. AI가 작성한 코드가 제 머릿속에 이미 있는 패턴과 잘 맞고, 이름과 구조가 예측 가능하며, 시각적 구조가 논리적 구조와 일치할수록, 저는 더 적은 비용으로 더 많은 맥락을 흡수할 수 있습니다. 결국 목표는 “AI가 소프트웨어 엔지니어로서의 제가 제 철학에 맞게 썼을 법한 코드”를 쓰게 만드는 것입니다.

 

마무리

저는 이제 막 2년차를 넘긴 주니어 개발자이고, “설계 철학”이라고 부를 만한 것이 아직 선명하지 않습니다. 그럼에도 저는 프로덕트 엔지니어로서의 속도와, 소프트웨어 엔지니어로서의 축적을 둘 다 놓치고 싶지 않습니다. 아마 이 글은 그 두 자아를 동시에 지키기 위한 첫 번째 기록일 것입니다.

 

참고 자료

• Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing T...
• 깊이 생각하던 시절이 그리워요 | GeekNews
• 우리는 왜 어떤 코드를 읽기 쉽다고 느낄까
• https://product.kyobobook.co.kr/detail/S000214761920

무의식은 어떻게 나를 설계하는가 | 데이비드 이글먼 - 교보문고