https://www.youtube.com/watch?v=bB37cJ-13pI 도움이될만한 영상

바이브코딩을 하면서 가장 크게 느끼는 장벽은 용어와 개념이다. 막연하게 원하는 것은 있다. 이런 기능이 있었으면 좋겠고, 이 과정이 조금 더 편해졌으면 좋겠고, 머릿속에 있는 무언가가 실제로 돌아갔으면 좋겠다. 어떻게 만드는지는 잘 모르겠지만, 그 부분은 에이전트가 알아서 해주기를 기대한다. 그런데 요구사항이 항상 일반적인 것은 아니다. 여러 조건이 복잡하게 얽혀 있기도 하고, 설명하는 사람조차 무엇을 원하는지 정확히 모를 때도 있다. 분명 머릿속에는 어떤 모습이 있는데, 말로 꺼내놓으면 이상하게 중요한 부분이 빠져 있다. 그래도 에이전트는 일을 한다. 전달받은 요구사항을 나름의 방식으로 이해하고, 비어 있는 부분을 채우고, 코드를 작성한다. 그리고 매우 친절하게 설명한다. 어떤 작업을 했고, 어떤 구조를 선택했으며, 무엇을 개선했는지. 테스트를 통과했다는 말도 덧붙인다. 여기서 묘한 안도감이 생긴다. 설명이 정돈되어 있고, 작업 내역이 구체적이며, 내가 미처 생각하지 못한 부분까지 챙긴 것처럼 보인다. 그런데 설명을 끝까지 읽고 나서도 어딘가 찜찜하다. 작업을 많이 했다는 것은 알겠는데, 그 작업이 내가 원했던 방향인지는 여전히 확신하기 어렵다. 나는 개발자다. 코드를 읽을 수 있고, 익숙한 영역에서는 구현이 적절한지 판단할 수 있다. 그런데도 낯선 분야의 작업을 맡기면 비슷한 순간을 만난다. 문장은 읽히는데, 그 문장에 담긴 선택의 무게가 잘 느껴지지 않는다. 각각의 단어는 검색하면 나오지만, 왜 지금 이 선택을 했는지, 다른 선택을 했다면 무엇이 달라지는지까지 이해하려면 시간이 필요하다. 그래서 개발 경험이 없는 사람이 에이전트의 작업 보고를 읽는 상황을 생각하게 된다. 요구사항을 전달할 때 한 번 막히고, 결과를 설명받을 때 다시 막힌다. 처음에는 무엇이라고 요청해야 할지 몰랐고, 나중에는 무엇을 확인해야 할지 모른다. 그 사이에서 에이전트는 열심히 일했다. 가령 “오류가 나면 자동으로 다시 시도하게 해줘”라는 요청을 했다고 해보자. 사용하는 사람 입장에서는 자연스러운 요구다. 잠깐 문제가 생겼다고 매번 버튼을 다시 누르고 싶지는 않으니까. 그런데 여기에는 서로 다른 상황이 들어 있다. 요청이 서버에 도착하지 않았을 수도 있고, 서버가 요청을 거절했을 수도 있다. 서버에서는 이미 처리가 끝났는데, 완료됐다는 응답만 돌아오지 않았을 수도 있다. 화면에는 모두 비슷한 오류로 보이지만, 다음에 해야 할 일은 달라질 수 있다. 예약 신청이 이미 처리된 상태에서 같은 요청을 다시 보내면 어떻게 될까. 사용자는 한 번 신청했다고 생각하는데, 시스템에는 두 번 접수될 수도 있다. 이때 필요한 것은 단순히 재시도 횟수를 늘리는 것보다 구체적인 판단이다. 어떤 실패에 다시 시도할 것인지, 이미 처리된 요청은 어떻게 알아볼 것인지, 결과를 확인할 수 없는 동안 사용자에게 무엇을 보여줄 것인지. 에이전트가 “재시도 로직과 멱등성을 적용했습니다”라고 설명하면 작업은 꽤 잘 마무리된 것처럼 들린다. 하지만 멱등성이라는 단어가 낯선 사람에게는 그 문장도 또 하나의 숙제다. 같은 요청을 여러 번 보내도 한 번 처리했을 때와 같은 효과를 유지한다는 뜻을 알아야, 비로소 다음 질문을 할 수 있다. 어디까지 같은 요청으로 보는지. 시간이 지난 뒤 다시 보낸 요청도 같은 것으로 취급하는지. 그 처리가 실제로 확인됐는지. 이런 순간에 용어를 안다는 것의 의미를 다시 생각한다. 개발하면서 쓰는 단어들에는 반복해서 겪었던 문제가 압축되어 있다. 어떤 일이 잘못될 수 있고, 그것을 어떤 방식으로 다뤄왔는지에 대한 흔적이 들어 있다. 단어 하나를 이해하면 이전에는 보이지 않던 갈림길이 보이기 시작한다. 물론 단어를 외우는 것만으로 판단이 생기지는 않는다. 나도 설명에 등장한 용어를 알아듣는다는 이유로, 설명 전체를 이해했다고 착각할 수 있다. 캐시가 무엇인지 아는 것과 이 서비스에서 얼마나 오래된 정보를 허용해도 되는지 결정하는 일에는 차이가 있다. 인증이 무엇인지 아는 것과 누가 어떤 정보까지 볼 수 있어야 하는지 정하는 일에도 차이가 있다. 결국 그 선택은 내가 만들려는 것의 성격으로 돌아온다. 조금 늦어도 정확해야 하는지, 잠시 오래된 정보가 보여도 빠른 편이 나은지. 사용자가 실수했을 때 되돌릴 수 있어야 하는지, 한 번 확정한 뒤에는 바꿀 수 없어야 하는지. 이런 질문에는 프로젝트마다 다른 답이 있다. 그런데 처음 요구사항을 적을 때는 여기까지 생각하기 어렵다. 보통은 잘되는 장면부터 떠올린다. 버튼을 누르면 저장되고, 로그인하면 내 정보가 나오고, 신청하면 완료 화면이 뜬다. 중간에 연결이 끊기거나, 버튼을 두 번 누르거나, 서로 다른 사람이 같은 정보를 동시에 바꾸는 장면은 나중에 생각난다. 직접 구현할 때는 이런 문제와 부딪히며 생각을 구체화한다. 어떤 값을 저장할지 정하다가 요구사항의 빈틈을 발견하고, 오류를 처리하다가 애초에 결정하지 않은 조건을 만나기도 한다. 귀찮고 더디지만, 코드를 쓰는 과정에서 내가 만들고 있는 것을 이해하게 되는 부분이 있다. 에이전트는 그 구간을 빠르게 통과한다. 덕분에 훨씬 적은 수고로 결과물을 볼 수 있다. 동시에 내가 충분히 생각해보지 않은 선택까지 이미 코드 안에 들어가 있을 수 있다. 에이전트가 선택한 기본값과 관행이 쌓여서 하나의 서비스가 된다. 그 결과를 보면서 “내가 원한 건 이게 아닌데”라고 느낄 때가 있다. 하지만 처음 전달했던 문장을 다시 읽어보면, 지금 불만인 부분을 설명한 적이 없기도 하다. 내 머릿속에서는 너무 당연해서 말하지 않았던 조건이다. 또는 실제 화면을 보고 나서야 중요하다는 사실을 알게 된 조건이다. 이럴 때는 누구의 잘못인지부터 가리기 어렵다. 에이전트가 성급하게 판단한 부분도 있고, 내가 막연하게 넘긴 부분도 있다. 무엇보다 처음부터 완성된 요구사항이 내 안에 있었는지조차 돌아보게 된다. 나는 원하는 것을 전달하고 있다고 생각했지만, 사실은 원하는 것을 함께 찾아가는 중이었을 수 있다. 나는 이 과정 자체에는 큰 가치가 있다고 느낀다. 머릿속으로 생각할 때와 실제로 눌러보며 확인할 때는 다르다. 작동하는 결과물을 보고 나면 없던 질문이 생긴다. 이 버튼은 왜 여기에 있어야 하는지, 이 정보는 정말 필요한지, 이 과정은 왜 두 번 거쳐야 하는지. 막연했던 생각에 구체적인 모양이 생기면서 판단도 조금씩 가능해진다. 다만 결과물이 빨리 나온다고 해서 판단까지 같은 속도로 끝나지는 않는다. 에이전트가 바꾼 내용을 읽고, 실행해보고, 내가 중요하게 생각하는 상황에서도 제대로 동작하는지 확인하는 일은 여전히 남아 있다. 작업을 맡기는 속도에 비해 이해하는 속도가 느려지면, 어느 순간 내가 설명할 수 없는 부분이 계속 늘어난다. 기능은 많아졌는데 전체를 다루기는 오히려 어려워질 수 있다. 나에게도 이 부분은 부담스럽다. 직접 작성한 코드는 적어도 왜 그렇게 썼는지에 대한 기억이 남는다. 에이전트가 작성한 코드는 그 판단의 맥락을 별도로 읽어야 한다. 수정된 파일이 많고 설명이 길수록, 꼼꼼하게 확인했다는 감각과 실제로 이해한 범위가 어긋나기 쉽다. “테스트를 통과했습니다”라는 말도 비슷하게 받아들이게 된다. 반가운 말이지만, 무엇을 확인한 테스트인지는 알아야 한다. 내가 중요하게 생각한 상황이 빠져 있다면 그 부분은 여전히 모르는 상태다. 에이전트가 요구사항을 다르게 이해했다면, 그 이해를 기준으로 작성된 테스트는 통과할 수도 있다. 이런 경험을 생각하다 보면, 에이전트에게 요청하는 방식도 조금 달라져야겠다는 생각이 든다. 구현 방법을 길게 지시하기 전에, 내가 무엇을 중요하게 여기는지부터 분명히 할 필요가 있다. 사용자가 입력한 내용은 사라지면 안 된다. 처리 여부가 확인되지 않았는데 완료됐다고 보여주면 안 된다. 화면은 단순해도 괜찮지만, 잘못된 상태를 정상처럼 보이게 해서는 안 된다. 이런 문장은 어려운 기술 용어 없이도 쓸 수 있다. 그리고 구현하는 쪽에서 어떤 선택을 해야 하는지 판단하는 데 도움이 된다. 모든 세부사항을 알고 시작할 수는 없어도, 어떤 결과를 받아들일 수 없는지는 생각해볼 수 있다. 설명을 요청할 때도 마찬가지다. 사용한 기술의 이름만 나열되면 여전히 멀게 느껴진다. 그 선택 때문에 사용자가 무엇을 경험하게 되는지, 문제가 생겼을 때 어떤 일이 벌어지는지까지 연결되어야 이해가 된다. 전문 용어를 쉬운 말로 바꿔달라는 요청에 더해, 실제 상황을 하나 들어 설명해달라고 할 필요가 있다. 에이전트가 판단한 부분도 드러나면 좋겠다. 내가 명시한 요구사항과, 작업을 진행하기 위해 에이전트가 가정한 조건이 구분되어 있으면 확인하기가 한결 수월하다. 특히 나중에 바꾸기 어렵거나 다른 기능에 영향을 많이 주는 선택은 먼저 질문해주기를 바라게 된다. 그렇다고 사소한 것까지 전부 물어보는 에이전트가 편한 것도 아니다. 맡길 수 있는 일을 맡기려고 사용하는데, 모든 결정을 다시 돌려받으면 금방 지친다. 적당히 알아서 해줬으면 하는 마음과, 중요한 것은 내 의도를 확인해줬으면 하는 마음이 동시에 있다. 어떤 부분을 맡겨도 되는지 서로 맞춰가는 과정이 필요하다고 느낀다. 그래서 바이브코딩을 하려면 어디까지 공부해야 하는지에 대한 질문에도 쉽게 답하기 어렵다. 시작하기 전에 개발자가 배우는 모든 것을 공부할 필요는 없다고 생각한다. 실제로 무언가를 만들어볼 수 있는 기회가 넓어진 것은 반가운 일이다. 작은 불편을 해결하는 도구 하나를 만드는 데 반드시 긴 준비 과정이 필요한 것은 아니다. 다만 만들다 보면 이해가 필요한 순간을 만나게 된다. 그때 용어와 개념이 내 일에 연결된다. 저장한 내용이 사라지고 나서야 데이터가 어디에 남는지 궁금해지고, 여러 사람이 사용하기 시작하면 권한이라는 말이 구체적으로 느껴진다. 같은 동작이 두 번 실행되는 문제를 겪으면 중복 처리라는 단어를 이전과 다르게 읽게 된다. 그렇게 배우는 것은 기억에도 오래 남을 것 같다. 내가 해결하려는 문제가 있고, 그 문제를 설명하는 이름을 뒤늦게 만나는 경험이기 때문이다. 에이전트는 구현을 도와주는 동시에, 지금 눈앞에서 벌어진 일을 설명해줄 수도 있다. 조금씩 이해가 쌓이면 다음 요청은 더 구체적이 되고, 결과를 확인할 때도 더 나은 질문을 할 수 있다. 나 역시 그 과정에서 예외가 아니다. 익숙한 기술을 사용한다는 이유로 요구사항까지 명확하다고 생각하지 않으려 한다. 코드를 읽을 수 있다는 자신감 때문에 사용자가 실제로 겪을 상황을 건너뛰고 있지는 않은지도 돌아보게 된다. 에이전트가 구현을 빠르게 해줄수록, 내가 무엇을 만들고 있는지 설명할 수 있어야 한다는 부담은 오히려 더 또렷해진다. 아직도 에이전트가 알아서 잘해주기를 바란다. 반복되는 작업은 맡기고 싶고, 익숙하지 않은 분야에서도 도움을 받고 싶다. 설명이 친절하고 결과가 빨리 나오는 것도 좋다. 다만 작업이 끝났다는 말을 들었을 때, 잠깐 더 들여다보고 싶다. 내가 요청한 문장이 어떤 의미로 구현되었는지. 설명을 읽고 고개를 끄덕인 부분을 정말 이해했는지. 지금 보이는 결과가 내가 원했던 것에 가까워졌는지. 바이브코딩을 통해 결과물과 함께 내 생각도 조금씩 구체적이 되었으면 한다. 처음에는 막연하게 “이런 게 있었으면 좋겠다”고 말했더라도, 마지막에는 무엇이 필요했고 왜 이렇게 만들었는지 내 말로 설명할 수 있으면 좋겠다. 에이전트와 일하면서 내가 얻고 싶은 감각은 그쪽에 가깝다.

한국 크립토 텔레그램 채널 지도 영토 크기는 채널 구독자 수와 조회수를 기준으로 채널 간 거리는 서로 포워딩을 많이 주고받을수록 가까워지도록 배치했음 최근 한 달간의 데이터를 기반으로 만들었으니 재미로 봐주세여 https://kdp.wtf/kr/metrics/telegram-map