[5월 COMMIT] <🏃속도가 이해를 추월할 때: AI 시대의 인지 부채> 후기

 

 

 

 

 

🧐 AI 시대, 우리가 놓치고 있는 것들은 무엇일까요?
AI 도구의 도움으로 구현 속도가 빨라지고, 낯선 기술의 진입 장벽도 낮아졌습니다. AI를 통해 만들어지는 코드의 양이 늘어난 만큼, 그것을 리뷰하고 이해하는 데 필요한 시간도 함께 늘어납니다. 코드를 생성하는 속도는 빨라졌지만 사람이 이해하는 속도가 그대로일 때, 그 간극은 생각보다 조용하고 빠르게 벌어집니다.

5월 COMMIT에서는 이 현상을 현장에서 직접 겪고, 깊이 고민해온 세 명의 패널과 함께 이야기를 나눠봅니다. 정답을 찾는 자리가 아니라, 각자가 어떤 상황을 마주했고 어떻게 풀어가려 했는지, 그 고민의 방향을 함께 들어봅니다.

 

 

지난 5월 27일 수요일 저녁, 퇴근 후 신청해두었던 COMMIT 토크에 다녀왔다

최근 계속 가지고 있던 고민과 맞닿아있는 주제라 흥미롭고 재밌게 듣고 왔었다

 

AI 도구 덕분에 구현 속도는 더더욱 빠르게 높아지고 있다

업무에서도 코드를 정말 잘 작성하고 얼마 없었던 실력도 진작에 추월당한지 오래되었다..

100% 이해하진 못하더라도 시간 들여서 질문을 많이 던지면서 나온 결과물에 대해 최대한 이해하려고는 하고 있으나 이렇게 진행하는게 과연 맞나 싶은 생각이 계속 남아있다

 

아래는 기록했던 내용들을 조금 다듬어서 정리해보았다

 

 

 

 

---

 

 

 

1. 코드를 이해한다는 것은 무엇일까

 

Q1. 코드 이해에 대한 정의

AI가 코드를 직접 짜주는 시대에서 우리가 직접 코드를 이해한다를 어떻게 정의하는가

 

AI가 코드를 직접 작성해주는 시대다. 그렇다면 이제 개발자가 코드를 '이해한다'는 것은 무엇을 의미할까.

모든 코드를 한 줄씩 외우듯 파악하는 것만이 이해는 아니다. 오히려 중요한 것은 코드의 구조와 흐름, 그리고 의도대로 동작하는지 설명할 수 있는가에 가깝다.

 

정민 님은 코드의 흐름을 빠르게 파악하기 위해 시각화부터 시작한다고 했다.

시각화는 우리가 가장 받아들이기 좋은 형태이다. 추상적인 개념과 이론들을 직접 눈으로 확인함으로써 요소들간의 연결을 보다 더 잘 이해할 수 있게 도와준다.

엑스칼리드로우나 순서도를 활용해 시각화로 최대한 빠르게 데이터와 로직이 어떤 순서로 흐르는지 확인한다.

AI와 작업을 하다보면 문제가 지속적으로 발생하게 된다. 

그러면서 이런 흐름 속에서 이상하게 보이는 지점이 있으면 AI에게 해당 코드의 역할과 이유를 다시 설명하게 하고, 문제가 생겼을 때는 본질적인 원인을 찾을 때까지 파고든다.

납득이, 이해가 되지 않는다면 본질적인 답을 찾을 때까지 반복하면서 최대한 내가 이해하는 단계까지 도달해야 코드를 통과시킨다.

 

 

호연 님은 사람이 집중해야 할 지점을 앞단과 뒷단으로 나눠 설명하셨다.

• 앞단에서는 내가 원하는 것을 얼마나 명확하게 전달했는가
• 뒷단에서는 결과물이 의도대로 구현되었는가, 이 결과를 어떻게 검증할 것인가

코드를 이해하지 못한 상태에서 단순히 "만들어줘"라고 요청하면 원하는 결과를 얻기 어렵다.

프로젝트가 복잡해질수록 버그 발생이 많아지고 원인 파악도 어려워진다.

PRD로 내가 원하는 바를, 맥락을 보다 더 정확하게 전달하는 것이 중요하므로 코드의 구조와 동작, 흐름을 명확하게 이해하고 있어야한다. 

앞으로 AI가 더 발전하게 될수록 디테일적인 요소 보다는 더 높은 추상화의 레이어를 보면서 구조적인 것을 이해하고 동작의 흐름을 파악하는 것이 중요해질 것이다.

 

테스트 코드도 중요한 도구다. 테스트가 해당 코드의 동작을 명확하게 설명할 수 있다면, 그 자체로 좋은 문서가 된다.

결국 코드를 이해했다는 것은 머릿속 정보를 논리적인 구조로 꺼내 설명할 수 있다는 뜻에 가깝다. 모호하고 추상적인 표현 대신, 의미를 검증할 수 있는 구체적인 용어를 사용하는 습관도 필요하다.

 

 

 

 

 

 

---

 

 

 

 

 

2. 빠른 구현 뒤에 남는 인지 부채

 

Q2. 인지 부채를 겪었던 경험

인지 부채가 실제로 문제가 됐던 순간, 팀이나 프로젝트에서 어떤 일이 벌어졌는지

 

AI를 활용하면 초기 구현 속도는 눈에 띄게 빨라진다.

문제는 충분히 이해하지 못한 코드가 쌓였을 때다.

당장은 잘 동작하는 것처럼 보여도, 시간이 지나면 성능과 보안, 유지보수 비용으로 돌아온다.

실제로도 바이브 코딩으로 내놓았던 서비스에서 보안이나 다양한 기술적 이슈가 발생한 사례들은 꾸준히 나오고 있으며 사용해본 입장에서도 내 인지범위를 넘어가는 결과물은 걷보기에는 괜찮아보여도 언제 어디서 문제가 터져도 이상하지 않을 시한폭탄과도 같았다.

 

 

정민 님은 개발 인력이 부족한 상황에서 쇼츠 생성 자동화 플랫폼을 만들었던 경험을 공유해주셨다.

PM과 디자이너도 개발에 참여할 수 있도록 PRD 작성, 구현, 검증 등의 기본 워크플로우를 마련했다.

처음에는 잘 동작했지만 사람의 직접적인 핸들링과 리뷰가 줄어들자 점차 여러 문제들이 발생했다.

서버에는 무려 수십기가나 하는 매우 무거운 STT 모델이 직접 설치되어 서버 성능이 떨어졌고, 인증과 보안 측면에서도 위험한 지점이 발견됐다.

또한 비개발자 특성상 워크플로우를 만들어줘도 일단 돌아만가면 크게 신경을 안쓰고 "해줘" 사이클을 타면서 초기에 구상했던 엔드 드 이미지에서 재현도가 낮아지게 되었다.

 

이러한 문제들을 결국 사람이 인프라의 주요 변경 사항이나 기술적인 부분을 검토하고 통과시키는 게이트웨이로서 사이클에 다시 참여하였다.

 

 

개인 프로젝트에서도 비슷한 경험이 있었다고 한다.

사용자가 원하는 사이트를 구독하면 아침마다 뉴스 브리핑을 보내주는 서비스를 바이브 코딩으로 시작했는데, 사용자가 1,000명을 넘어서자 특정 시간대에 트래픽이 몰렸다.

오전 7시에 메일을 보내야 했지만 처리 속도가 느려졌고, 결국 주요 코드와 구조를 다시 설계해야 했다.

 

 

호연 님 역시 AI 도입 과정에서 지나치게 하드코딩된 부분을 다시 뒤집느라 많은 시간이 들었던 경험을 이야기했다.

빠르게 만든 코드라도 정확히 설명할 수 없다면 과감하게 제외하고, 이해할 수 있는 코드만 도입하려 했다고 한다.

 

 

이 사례들이 보여주는 것은 분명하다.

AI가 만든 코드는 공짜가 아니다.

생성 비용은 낮아졌지만, 이해하지 못한 코드를 미래의 누군가가 다시 읽고 고쳐야 한다.

이때 발생하는 비용이 바로 인지 부채다.

 

 

 

 

---

 

 

 

 

 

3. 모든 코드를 이해해야할까, 스펙과 테스트로도 충분할까

 

Q3. 이해 vs 스펙 및 테스트

AI가 생성하는 코드, 전부 이해해야한다 vs 스펙, 테스트로 충분하다

• •  

 

AI가 생성한 코드를 사람이 전부 이해해야 할까. 아니면 명확한 스펙과 테스트가 있다면 충분할까.

패널들의 이야기를 종합하면, 답은 하나로 고정되지 않는다. 어떤 문제를 해결하는지, 장애가 발생했을 때 영향 범위가 얼마나 큰지에 따라 달라진다.

 

 

개인정보, 결제, 인증, 보안처럼 민감도가 높은 영역은 여전히 사람의 깊이 있는 개입이 필요하다.

미토스의 보안 취약점 탐지 사례처럼 수십년 유지된 오픈소스에서 사람이 발견하지 못한 이슈를 AI가 찾아낸 것처럼 AI의 성능은 앞으로 더 좋아질 것이다.

그러니 이런 스펙, 정의를 잘 하는 것이 정말 중요하며 서비스 운영 관점에서 보안을 핵심적으로 체크하고 어느정도 직접 핸들링을 하는 것이 필요할 것이다.

장애가 터졌을 때 영향을 주는 범위가 클수록 사람이 밀도있게 개입해야한다.

작은 실수가 사용자와 기업에 큰 영향을 미칠 수 있기 때문이다.

 

 

반면 내부 데이터 대시보드처럼 영향 범위가 제한적이고 문제가 생겼을 때 빠르게 복구할 수 있는 영역은 AI에게 더 많이 위임할 수 있다.

이 경우 사람이 매번 모든 구현을 확인하기보다 추상화된 구조, 인터페이스, 프로토콜, 테스트처럼 더 높은 수준의 레이어를 살펴보는 편이 효율적이다.

 

앞으로 AI의 성능이 더 좋아질수록 개발자의 역할은 코드 한 줄 한 줄을 직접 작성하는 데서 의도와 제약 조건을 명확하게 정의하는 방향으로 이동할 가능성이 크다.

중요한 것은 스펙을 잘 작성하고, 변경 이력을 관리하고, 테스트와 검증 기준을 함께 설계하는 능력이다.

내가 원하는 바를 잘 전달하는, 어떻게 명령을 잘 내려서 의도대로 구현된 결과물을 얻어내는지가 앞으로의 요구되는 역량이 될 가능성이 높다.

중요한 질문은 "얼마나 많이 위임할 것인가"가 아니다. "어디까지 위임해도 되는가"를 판단할 수 있는가다.

 

 

 

그렇다면 이 기준을 주니어는 어떻게 해야 잘 녹여야할까

 

호연님

이전에 AI가 없던 시대에서는 시행착오와 디버깅을 반복하면서 개발자의 실력이 성장했었다.

직접 문제를 해결해보는 경험들을 통해 암묵지가 생기고 성장을 하게 되는데 현재에는 AI를 통해 이 경험이 외주화가 되어버렸다.

에이전트가 시행착오를 대신 겪고, 개발자는 완성된 결과만 받아볼 수 있다. 편리하지만 성장의 기회를 놓칠 수도 있다.

과거와 현재를 비교했을 때 이 부분이 가장 큰 전환점이 아닐까 싶다.

그러니 성장을 하려면 이 경험을 최대한 확보해야한다.

 

그렇다고 AI를 쓰지 않는 것이 답은 아니다.

앞으로 AI와 하드웨어 등 모든 것들의 성능이 좋아지고 최적화되는 시대에서 손코딩을 하고 있기는 어려울 것이다.

중요한 것은 에이전트가 어떤 문제를 만났고, 왜 그런 해결책을 선택했는지 대화를 통해 간접 경험을 가져오는 것이다.

• 왜 이 구조를 선택했는가
• 다른 방식은 왜 제외했는가
• 문제가 생긴 원인은 무엇인가
• 다음에는 어떤 조건을 먼저 확인해야 하는가

이런 질문을 반복하면 AI를 사용하면서도 시행착오의 맥락을 배울 수 있다.

 

 

 

 

 

정민님

앞으로 코더는 무의미한 용어가 될 것이다. 문법을 아는건 AI가 더 잘하고 앞으로도 더 잘할 것이기 때문.

명령을 잘 내리는 것이 중요하다고 했는데 2가지 포인트에서 수준 차이가 나타난다.

 

용어에 대한 이해도와 커뮤니케이션이다.

 

용어에 대한 이해도.

내가 정확하게 용어를 알고 있는지. 본인이 모르는데 안다고 생각하거나 아는걸 서술하지 못하는 사람들이 많다.

언어별로 장점이 확실한데 그 장점이 왜 있고 엔지니어링 측면에서 이해할 수 있어야 응용할 수 있다.

코어 개념을 잘 알고 이해하고 있어야 요청할 때도 보다 더 상세하고 정확한 요구를 할 수 있다.

 

다른 하나는 커뮤니케이션.

에이전트에게 명령을 내리고 일을 시키지만 채팅이든 PRD나 문서를 전달하든 결국은 소통의 형태를 띄고있다.

사람보다 지식이나 이해도가 좀 더 높을 수 있고 순종적이겠지만 소통이라는 근본적인 형태는 동일하다.

 

 

결국 근본적인 것이 중요하다.

개발자로 성장하기 위해선 결국 엔지니어로써 문제를 해결하는 것. 

딥다이브해서 주어진 상황에서 정말 가장 큰 문제가 뭐고 최선의 솔루션이 무엇인지 찾아내는건, 추상화 레벨이 올라가더라도 이러한 근본적인 구조는 변함없을 것이다.

전공 과목들도 결국은 기초를 다지는 과정 중 일부. 그렇기 때문에 문법 보다는 사고 능력. 컴퓨팅 사고, 논리적 사고. AI를 쓰든 안쓰든 중요하다

 

 

 

 

 

---

 

 

 

4. 성장의 기준도 달라지고 있다

 

Q4. 성장에 대한 재정의

AI 시대에 성장한다는 것, 지금 어떻게 정의하고 있는지

 

AI를 통해 압도적인 생산성, 효율성 등의 여러 면에서 향상되었으나 코드 작성을 AI에게 위임하면서 시키는 나는 바보가 되가는 것 같다는 불안감이 만연하다.

이렇게 혼란스러운 과도기에서 성장이란 어떤 것일지, 어떻게 해야 성장할 수 있을지에 대한 고민이 많아지게 된다.

 

 

AI 시대의 성장은 개인과 조직이라는 두 관점에서 살펴볼 수 있다.

 

개인에게는 이해의 끈을 놓지 않으면서 AI를 활용해 생산성을 높이는 역량이 중요하다.

에이전트에게 일을 맡기는 것 자체보다, 내 의도를 정확하게 전달하고 원하는 방향으로 오랫동안 안정적으로 동작하게 만드는 능력이 필요하다.

 

조직에서는 개인 한 명의 생산성보다 팀 전체의 생산성을 높이는 일이 더 큰 영향을 만든다.

반복되는 워크플로우를 자동화하고, 사람이 개입해야 할 지점을 정하고, 팀이 함께 사용할 수 있는 하네스와 규칙을 만드는 사람이 필요하다.

또한 조직 내 나의 위치가 어디인지 인지하고 혼자서만 하는 것이 아닌 같이, 그리고 얼만큼 팀웍이 강하고 시너지를 낼 수 있는지, 커뮤니케이션을 얼마나 명확하게 할 수 있는지 등이 더더욱 중요해지는 것 같다.

결과를 보여주는 것도 중요하다.

AI 활용 자체가 목적이 되어서는 안 된다.

실제로 사용자 경험을 개선했는지, 운영 비용을 줄였는지, KPI에 기여했는지가 더 중요하다.

 

 

그렇다면 AI가 존재하기 전후 성장하는 방식에서 바뀐게 있을까?

 

결국은 많은 시간을 효과적으로 쓰는 사람이 성장하는 방식은 동일하다.

AI를 많이 쓰면 그만큼 의존하고 역량이 떨어지지 않을까, 개인의 성장 측면에서는 비효율적이지 않을까 싶기도 하지만 AI를 많이 사용해본 사람은 어디에서 문제가 생기는지도 더 빨리 알게 된다.

많이 쓰면 쓸수록 각 모델이나 워크플로우, 유스케이스 등 여러 상황에서 반복적으로 발생하는 문제들을 더 많이 접하게 되고 일을 시키는 과정에서 마주하는 문제들을 더 많이 접하게 되는, 해결해야하는 경험을 더 많이 쌓게 되는 것이다.

 

처음에는 다소 비효율적으로 느껴지더라도 시행착오를 통해 자신만의 활용 방식을 만들고, 그 경험을 복리처럼 쌓아가는 과정이 필요하다.

AI를 통해 생산성을 실제로 극대화하는 사람들이 많으며 AI를 어떻게 활용하는지에 따라 그러한 생산성과 성장은 점차 갭이 커질 것이다.

 

 

 

 

 

---

 

 

 

 

 

5. 팀이 AI를 잘 쓰려면 무엇이 필요할까

Q5. 팀과 조직의 AX 변화

팀이 AI를 쓸수록 조직 구조나 협업 방식이 달라지고 있는지, 있다면 직접 겪은 변화는 어떤 것이 있는지

 

 

호연 님은 AI를 활용하면서 개인의 책임 범위가 넓어지고 있다고 설명하셨다.

사람 간의 커뮤니케이션도 일종의 병목이다. 

서로간의 이해를 맞추고 업무를 진행하는 비용도 제품 개발의 비용으로 포함된다.

이전에는 여러 사람이 나눠서 처리해야 했던 일을 한 사람이 맡을 수 있게 되면서, 이러한 커뮤니케이션 비용을 줄일 수 있게 되었다.

 

또한 정말 AX팀으로, 네이티브 AI 조직으로 변화하기 위해선 AI가 일을 잘 할 수 있게 만드는 환경이 필요하다.

AI를 잘 활용하는 팀에는 공통점이 있다.

정보가 투명하고, 기록이 잘 정리되어 있으며, 맥락이 구조화되어 있다.

회의록, 커밋, 문서, 의사결정 기록이 깔끔하게 남아 있으면 다음 작업으로 넘어가기가 쉬워진다.

사람뿐 아니라 AI도 팀의 맥락을 더 정확하게 이해할 수 있다.

 

동시에 팀 수준의 생산성을 높이기 위한 역할도 중요해지고 있다.

에이전트 인프라와 운영 환경을 만들고, 워크플로우와 하네스를 개선하고, 구성원들의 피드백을 반영하고 전담할 사람이 필요하다.

잘하는 팀을 보면 개발 보단 팀 수준의 생산성을 높이기 위해 전담마크하는 사람이 있었다.

 

결국 AI 네이티브 조직은 단순히 모든 구성원이 AI 도구를 사용하는 조직이 아니다.

단순히 회사에서 클로드 코드 맥스, 챗지피티 프로 등 구독비를 지원해준다고 해서 AX 조직이 되진 않는다.

AI가 잘 일할 수 있도록 맥락과 권한, 기록, 검증 절차를 설계한 조직에 가깝다.

 

 

 

---

 

 

 

 

6. 더 많이 하는 것보다 중요한 것

Q6. 현 시점에서 가장 중요하게 여기는 것

AI와 함께 일하는 개발자로서 지금 가장 중요하게 여기는 것은 무엇인지

 

 

AI를 활용하면 한 사람이 처리할 수 있는 일의 범위가 넓어진다.

하지만 인간의 인지 능력과 체력은 그대로다.

생산성을 높이려다가 오히려 과부하와 번아웃을 겪을 수도 있다.

실제로도 AI를 사용하여 생산성이 높아진 만큼 더 많은 일을 맡게되는 케이스들이 많아지고 있다.

과한 POMO로 조직, 개인도 AI를 해야만 살아남는 것 같은 과도기로, 물론 AI를 사용해야 경쟁력을 갖출 수 있겠으나 이런 추세는 단기간이 아닌 앞으로 이어질 방향성이다.

그러니 당장의 AI 사용에 너무 맹목적으로 매달리기보단 꾸준히 사용하며 AI 활용도를 높이되 그 과정 속에서 개인의 행복감을 느낄 수 있는 AI 바깥의 다른 것을 찾는 것, 균형감을 유지해서 롱런할 수 있는 부분도 요구된다.

 

 

AI를 많이 쓰다보면 ADHD가 온 것 같고 여러 시도들을 하다가 잘 안풀리면서 자괴감을 느끼기도 한다.

여러 개의 터미널과 탭을 동시에 띄우고 수많은 작업을 병렬로 처리하면 당장은 많은 일을 하는 것처럼 느껴진다.

하지만 맥락 전환이 잦아질수록 이해하지 못한 코드와 미완성 작업이 쌓일 가능성도 커진다.

 

토크에서 인상 깊었던 제안은 오히려 단순했다.

• 동시에 열어두는 작업을 줄인다.
• 하나의 문제에 집중한다.
• 처음부터 PRD와 의도를 명확하게 작성한다.
• 에이전트가 나에게 질문하도록 만든다.
• 결과물을 받을 때 구조와 이유를 다시 확인한다.

처음 요청을 잘 작성하는 데 시간을 들이면 잘못된 구조와 사이드 이펙트를 줄일 수 있다.

무엇보다 정신적으로도 훨씬 건강한 방식이다.

남들이 더 많은 도구를 사용하고 더 많은 작업을 동시에 처리하는 것처럼 보여도, 본질은 달라지지 않는다.

중요한 문제를 찾고, 의도를 명확하게 정의하고, 해결 과정과 결과를 책임지는 능력이 필요하다.

 

 

 

 

---

 

 

 

 

마치며

 

 

이번 토크를 들으며 가장 크게 남은 문장은 이것이었다.

AI 시대에는 코드를 많이 만드는 사람보다, 중요한 문제를 정확히 정의하고 결과를 책임질 수 있는 사람이 더 중요해진다.

 

또한 최근에 읽었던 책, "일을 위한 디자인" 에서도 비슷한 메세지를 전달하는 것을 보면서 경험이 많은 시니어분들이 주장하시는 공통된 메세지가 있음을 느끼고 있다.

 

구조와 맥락, 무엇에 집중하고 어떤 태도를 갖춰야할지.

 

AI가 구현을 더 많이 대신할수록 개발자는 의도, 구조, 검증, 보안, 운영이라는 더 본질적인 문제에 집중해야 한다.

생산성을 높이는 것도 중요하지만 이해의 끈을 놓지 않는 것이 먼저다. 모든 것을 한 번에 따라가려 하기보다, 하나의 문제를 분명하게 정의하고 제대로 해결하는 경험을 쌓아야 한다.

결국 본질적인 문제 해결 능력은 사라지지 않는다. 오히려 AI 시대가 되면서 그 가치가 더 또렷하게 드러나고 있다.