<div id="readability-page-1" class="page"><div><blockquote>
<p>추상화의 목적은 모호하게 하려는 것이 아니라, 오히려 더 정확하게 말할 수 있는,
새로운 의미적 층위를 만드는 데 있다. — 에츠허르 다익스트라</p>
<p>The purpose of abstraction is not to be vague, but to create a new semantic
level in which one can be absolutely precise. — Edsger Dijkstra</p>
</blockquote>
<p>바이브코딩이란 말도 벌써 낡은 느낌이다. 얼마나 빠르게 새로운 프로덕트, 서비스,
아이디어가 쏟아지는지 따라가기에도 바쁘다. "가끔 똑똑한" 자동 완성에 그치지 않고
적극적으로 코드에 개입할 수 있는 세상이 되었다. 간단한 요구사항을 코드로
바꿔주는 일은 이제 기본이고 긴 맥락을 이해해야 하는 것들도 한번에 척척 쏟아낼
때마다 기분이 이상하다. 때로는 가장 즐거운 부분, 아이디어를 코드로 구체화 하는
과정을 빼앗기는 기분이다. 내 대신 해줬으면 하는 작업을 오히려 내가 부지런히 해서
떠먹여야 하는 상황에 어떤 표정을 지어야 할지 싶어진다. 깊이 고민하며 치열하게
코드를 짜던 시간보다 리뷰 비중이 높아지면서 점점 내 역할과 앞으로 어떤 방향으로
앞으로의 시간을 준비해야 하나 퇴근할 때마다 고민이 커진다.</p>
<p>실제로 코드를 작성하는 시간은 줄어가는데 코드 이해에 필요한 수준은 더 높아진다는
점에 있다. 코드도 학습의 대상이라서 읽고, 작성하고, 수정하고, 실행하면서
멘탈모델을 구축하는 과정이 코드를 이해하는데 필수적인 과정이었다. 물론 LLM을
활용해서 코드를 요약을 한다거나 읽기 쉽도록 시각적인 형태로 전환하는 등의 접근은
이해도를 높이는데 도움이 되지만 그 과정이 결코 내가 이해하는 일 자체를
대신해주지 않는다. 근래 가장 큰 고민인건 내가 코드에 대한 세부적인 이해가 없는
상황에서 코드를 에이전트에 맡길 수 있는가 하는 점이다.</p>
<p>그렇다고 해서 완전히 새로운 상황은 아니다. 코드 단위에서 추상화는 우리에게 이미
익숙한 개념이고 세부적인 구현을 잘 숨기는 것은 오히려 모범 사례다. 코드 뿐만
아니다. 팀과 동료, 구성원에게 일감을 위임하는 것도 추상화에서 달성하려는 목표와
유사하다. 층위가 올라갈 때마다 작업은 아이콘을 오른쪽으로 1픽셀 옮기는 것에서
버튼 스타일 변경, 신규UI 디자인 가이드라인 적용이 되는 것처럼. 이런 수준이
되려면 개인 단계에서의 코드 이해는 필수이며, 팀 차원에서는 언어적/비언어적
상호작용을 통해 지속적으로 이해도를 높여야 한다. 이런 과정을 전부 <code>AGENTS.md</code>에
녹여내 컨텍스트 윈도우를 채울 수 있는 사람이 좋은 결과를 내고 있는 것 아닐까.
코드의 멘탈모델을 이해하고 있으며 팀의 이해도에 기여하고 있었던 중니어-시니어
사람들에겐 더욱 쉽게 유의미한 결과를 만들 수 있을 것 같다.<sup><a href="#user-content-fn-1" id="user-content-fnref-1" data-footnote-ref="" aria-describedby="footnote-label">1</a></sup></p>
<p>자연어가 코드로 변환되는 과정을 볼 때마다 프롬프트도 코드의 동작을 추상화 한다고
생각하게 된다. 코드를 생성한 프롬프트를 모아놓는 것도 비슷한 맥락으로 느껴진다.
업무를 단계적으로 수행할 수 있도록 테스트도 작성하게 하고 예시도 주고 그러면
놀라울 정도로 잘 해낼 때도 많다. 추상화라고 단언하기엔 아직까지 역설적으로
외연의 부분에서 많은 손이 필요하지만 근미래에는 달성할 것이 분명하다. 이렇게
낙관적으로 보면서도 매일 뒤통수 맞는다. 아는 것처럼 척척 얘기하다가도 틀린 부분
지적하면 뻔뻔하게 틀렸네요, 하며 이해 한 척 하면서 또 틀린 얘기 반복 하는 일을
보면 감정 하나 없는 컴퓨터에 화를 내는 사람이 되고 만다. 방금 전에 잘 했다고 또
잘한다는 보장이 잘 없다. 물론 사람도 그렇지만.</p>
<p>나는 오늘도 프롬프트를 수정하고 또 결과를 기다린다. 에이전트는 지치지도
퇴근하지도 않는다. 심지어 그 결과물이 부족할 땐 시간이 답이다. 3달, 6달 후
나오는 새로운 모델이 해결할 것이니까.</p>
<section data-footnotes="">
<ol>
<li id="user-content-fn-1">
<p>사실 최근 연구에서는 생산성이 오히려 떨어졌다는 얘기도 있지만.
<a href="https://arxiv.org/abs/2507.09089">arXiv:2507.09089</a> <a href="#user-content-fnref-1" data-footnote-backref="" aria-label="Back to reference 1">↩</a></p>
</li>
</ol>
</section></div></div>

edykim.com 블로그 RSS 피드

추상화의 목적은 모호하게 하려는 것이 아니라, 오히려 더 정확하게 말할 수 있는,
새로운 의미적 층위를 만드는 데 있다. — 에츠허르 다익스트라
The purpose of abstraction is not to be vague, but to create a new semantic
level in which one can be absolutely precise. — Edsger Dijkstra
바이브코딩이란 말도 벌써 낡은 느낌이다. 얼마나 빠르게 새로운 프로덕트, 서비스,
아이디어가 쏟아지는지 따라가기에도 바쁘다. "가끔 똑똑한" 자동 완성에 그치지 않고
적극적으로 코드에 개입할 수 있는 세상이 되었다. 간단한 요구사항을 코드로
바꿔주는 일은 이제 기본이고 긴 맥락을 이해해야 하는 것들도 한번에 척척 쏟아낼
때마다 기분이 이상하다. 때로는 가장 즐거운 부분, 아이디어를 코드로 구체화 하는
과정을 빼앗기는 기분이다. 내 대신 해줬으면 하는 작업을 오히려 내가 부지런히 해서
떠먹여야 하는 상황에 어떤 표정을 지어야 할지 싶어진다. 깊이 고민하며 치열하게
코드를 짜던 시간보다 리뷰 비중이 높아지면서 점점 내 역할과 앞으로 어떤 방향으로
앞으로의 시간을 준비해야 하나 퇴근할 때마다 고민이 커진다.
실제로 코드를 작성하는 시간은 줄어가는데 코드 이해에 필요한 수준은 더 높아진다는
점에 있다. 코드도 학습의 대상이라서 읽고, 작성하고, 수정하고, 실행하면서
멘탈모델을 구축하는 과정이 코드를 이해하는데 필수적인 과정이었다. 물론 LLM을
활용해서 코드를 요약을 한다거나 읽기 쉽도록 시각적인 형태로 전환하는 등의 접근은
이해도를 높이는데 도움이 되지만 그 과정이 결코 내가 이해하는 일 자체를
대신해주지 않는다. 근래 가장 큰 고민인건 내가 코드에 대한 세부적인 이해가 없는
상황에서 코드를 에이전트에 맡길 수 있는가 하는 점이다.
그렇다고 해서 완전히 새로운 상황은 아니다. 코드 단위에서 추상화는 우리에게 이미
익숙한 개념이고 세부적인 구현을 잘 숨기는 것은 오히려 모범 사례다. 코드 뿐만
아니다. 팀과 동료, 구성원에게 일감을 위임하는 것도 추상화에서 달성하려는 목표와
유사하다. 층위가 올라갈 때마다 작업은 아이콘을 오른쪽으로 1픽셀 옮기는 것에서
버튼 스타일 변경, 신규UI 디자인 가이드라인 적용이 되는 것처럼. 이런 수준이
되려면 개인 단계에서의 코드 이해는 필수이며, 팀 차원에서는 언어적/비언어적
상호작용을 통해 지속적으로 이해도를 높여야 한다. 이런 과정을 전부 AGENTS.md에
녹여내 컨텍스트 윈도우를 채울 수 있는 사람이 좋은 결과를 내고 있는 것 아닐까.
코드의 멘탈모델을 이해하고 있으며 팀의 이해도에 기여하고 있었던 중니어-시니어
사람들에겐 더욱 쉽게 유의미한 결과를 만들 수 있을 것 같다.1
자연어가 코드로 변환되는 과정을 볼 때마다 프롬프트도 코드의 동작을 추상화 한다고
생각하게 된다. 코드를 생성한 프롬프트를 모아놓는 것도 비슷한 맥락으로 느껴진다.
업무를 단계적으로 수행할 수 있도록 테스트도 작성하게 하고 예시도 주고 그러면
놀라울 정도로 잘 해낼 때도 많다. 추상화라고 단언하기엔 아직까지 역설적으로
외연의 부분에서 많은 손이 필요하지만 근미래에는 달성할 것이 분명하다. 이렇게
낙관적으로 보면서도 매일 뒤통수 맞는다. 아는 것처럼 척척 얘기하다가도 틀린 부분
지적하면 뻔뻔하게 틀렸네요, 하며 이해 한 척 하면서 또 틀린 얘기 반복 하는 일을
보면 감정 하나 없는 컴퓨터에 화를 내는 사람이 되고 만다. 방금 전에 잘 했다고 또
잘한다는 보장이 잘 없다. 물론 사람도 그렇지만.
나는 오늘도 프롬프트를 수정하고 또 결과를 기다린다. 에이전트는 지치지도
퇴근하지도 않는다. 심지어 그 결과물이 부족할 땐 시간이 답이다. 3달, 6달 후
나오는 새로운 모델이 해결할 것이니까.
Footnotes
사실 최근 연구에서는 생산성이 오히려 떨어졌다는 얘기도 있지만.
arXiv:2507.09089 ↩

추상화의 목적

댓글