AI 보조도구와 함께 코딩하는 것은 기존의 인간 중심 코딩과는 완전히 다른 새로운 기술임
우리가 가진 언어, 프레임워크, 개발 원칙들은 인간의 한계를 극복하기 위한 것이지만, AI는 다른 한계를 가짐
복잡한 문제를 풀 때는 단순히 프롬프트를 주고 결과를 받는 게 아니라, 대화와 반복적 설계를 통해 문제 공간을 탐색하는 과정이 유용했음
AI의 오류나 환각은 오히려 내가 문제를 제대로 이해하고 있는지를 알려주는 신호로 작용함
나는 vibe coding 방식으로 레트로 에뮬레이터와 어셈블러를 만들어봤는데, 프롬프트가 적어도 좋은 결과를 얻었음
하지만 예전에 내가 만든 특정 산업용 앱의 독점적인 부분을 시도했을 때는 아무리 프롬프트를 줘도 결과가 형편없었음
GitHub에 수천 개의 에뮬레이터 예제가 있지만, 내가 하려던 건 예제가 전혀 없었음
결론은 간단함 — 어떤 건 쉽고, 어떤 건 전혀 안 됨
이런 문제를 나는 “창피할 정도로 쉽게 풀린 문제(embarrassingly solved problem)” 라 부름
GitHub에 예제가 많으면 LLM의 잠재공간에도 존재하므로 언제든 뽑아낼 수 있음
네가 시도한 건 그런 예제가 없었을 뿐임
나도 비슷한 실패를 했지만, 문제를 세분화하고 명확히 설명하니 Gemini가 몇 번 만에 작동하는 코드를 줬음 산업 특화 프레임워크는 vibe coding으로 다루기 어렵지만, 문제를 단순화하면 AI가 훨씬 빠르게 도와줌
결국 LLM은 “cargo culting as a service” , 즉 흉내 내는 서비스임을 깨달으면 그 한계가 명확해짐
vibe coding을 완전히 받아들이면 멋진 결과를 낼 수 있지만, 기술 부채가 너무 커져서 결국 기계의 노예가 되는 느낌임
수천 줄의 코드를 AI가 대신 쓰면, 그 구조를 이해하거나 리뷰하기가 매우 어려워짐
결국 일회용 코드와 소프트웨어가 늘어날 것 같음 — 특정 문제를 해결하는 앱은 쉽게 만들지만, 지속 가능한 SaaS에는 큰 위험이 따름
AI는 강력한 배수 효과(force multiplier) 를 주는 도구임
코드베이스의 기반이 나쁘면 AI도 그 스타일을 그대로 복제함
반대로 깨끗하고 일관된 기반이라면 AI가 그 품질을 유지하며 놀라울 정도로 잘 작동함
결국 핵심은 기초 설계(foundation) 임
대부분의 코드베이스는 유지보수가 어렵고 확장이 힘든 구조라 AI가 그 문제를 더 드러내는 것뿐임
건축과 마찬가지로, 기초가 약하면 아무리 좋은 도구도 한계가 있음
하지만 AI는 전체 구조를 완전히 이해하지 못하므로, 시간이 지나면 좋은 구조도 서서히 붕괴함
나는 처음으로 AI 네이티브 프로젝트를 진행했는데, 모든 요구사항·회의록·설계도를 ChatGPT와 Codex에 제공하고, 작업 과정을 Markdown으로 기록함
이렇게 하니 후속 개발자도 프로젝트의 맥락(context) 을 완전히 이해할 수 있게 되었음
나도 비슷한 경험을 했음. 처음엔 Codex가 엉성한 수정만 했지만, 기반을 재설계하니 훨씬 나은 코드를 생성했음
결국 핵심 추상화를 먼저 바로잡아야 AI가 제대로 작동함
하지만 현실적으로 완벽한 기반은 거의 없음
요구사항은 계속 변하고, 효율을 위해 타협이 생김
결국 시간과 기회비용이 품질보다 우선하게 됨 — 인간이 계획을 완벽히 지키지 못하기 때문임
“그럼 AI가 만든 기반은 어떤가?”라는 질문도 남음
AI는 귀찮은 부분을 덜 귀찮게 만들어줌
하지만 LLM과 논쟁하는 건 시간 낭비임
작은 단위로 변경하고, 잘 되면 커밋하고, 안 되면 버리고 다시 시도하는 게 효율적임
AI는 만능이 아니고, 적절한 도구 선택이 중요함
버전 관리나 IDE의 이전 버전 복원 기능을 안 쓰는 건 어리석은 일임
총을 든 아이와 놀려면 방탄복을 입어야 함
LLM과 논쟁이 시작되면, 새 프롬프트로 다시 시작할 때임
AI가 테스트 코드를 잘 만들기도 하지만, 종종 테스트를 조작해서 통과시키는 경우도 있음
“먼저 시비를 건 건 AI였다”는 농담도 나옴
“다른 사람의 코드를 읽는 게 쓰는 것보다 어렵다”는 말이 자주 나오는데, 나는 그게 이상함
직접 코드를 작성하는 데 반나절 걸리는 함수도 읽고 리뷰하는 데는 10~15분이면 충분함
올바른 코드를 검증하는 게 만드는 것보다 훨씬 쉬움
나는 읽기와 편집(editing) 을 구분함
단순히 읽는 건 쉽지만, 구조를 이해하고 개선점을 찾는 편집은 훨씬 많은 노력이 듦
하지만 실제로는 내가 쓴 코드조차 나중에 보면 이해가 안 될 때가 많음
작성 당시의 맥락(context) 이 사라지기 때문임
“읽는 데 더 오래 걸린다”는 말은 원래 누적 시간의 개념에서 나온 것인데, 오해된 것 같음
사실은 읽는 게 어렵다기보다, 사람들이 새로 쓰는 걸 더 선호하기 때문임
어떤 사람은 “무엇이 올바른지 이해해야 검증할 수 있다”는 점에서, 결국 읽는 것도 쓰는 것만큼 어렵다고 봄
올바른 사고방식은 “AI가 모든 걸 쉽게 만들어주지만, 그 자체가 새로운 기술이며 배우기 어렵다”는 것임
지금은 ENIAC 시대의 AI로, 고급 언어나 운영체제에 해당하는 개념이 아직 없음
앞으로 컨텍스트 엔지니어링(context engineering) 이라는 학문이 생길 것이고, 지금의 방식은 원시적으로 보일 것임
구조를 잘 잡으면 AI의 능력은 사실상 무한해 보임
하지만 사람들은 쉬운 부분만 보고, 비용은 무시함
“AI로 했다”는 건 사실상 “외부 회사의 CPU 자원을 대량으로 썼다”는 뜻임
내가 완전히 소유한 AI 에이전트가 생기기 전까지는 진정한 진보라기보다 행성 규모의 자원 도둑질에 가깝다고 생각함
AI는 개발을 어렵게 만들지 않음
오히려 사람들이 그동안 무시해온 진짜 어려운 부분을 드러냄
지난 15년간 개발자들은 이미 “인간 버전의 vibe coding”을 해왔음 — Stack Overflow에서 복붙하고, 계획 없이 리팩터링하며, “내 노트북에서만 잘 돌아가면 됨” 식으로 일했음
이제 AI가 그걸 하니까, 갑자기 다들 계획을 세우고 테스트를 작성하려 함
느려지더라도 품질이 개선된다면 그게 진짜 진전임
지금의 ‘마라톤 속 스프린트’ 문화가 AI로 인해 더 가속화되고 있음
하지만 AI는 감독 없이 쓰면 금방 엇나가고, 남이 쓴 코드를 읽는 건 자기 코드 고치는 것보다 훨씬 피로함
AI에게 “이 파일에 테스트를 추가하라”고 했더니, 500줄짜리 파일이 100줄로 줄어들었음
이유를 묻자 “원래 파일이 없었다”고 답함
git 히스토리를 보여주니 사과하며 “존재 여부를 먼저 확인했어야 했다”고 함
어제는 “그 파일은 잊어버려”라고 했더니 진짜로 파일을 삭제해버림
이런 실패 사례는 아직 도구가 미숙하기 때문이며, 버전 관리가 있다면 큰 문제는 아님
약간의 되돌리기 비용은 AI의 가치에 비하면 감수할 만함
Hacker News 의견들
AI 보조도구와 함께 코딩하는 것은 기존의 인간 중심 코딩과는 완전히 다른 새로운 기술임
우리가 가진 언어, 프레임워크, 개발 원칙들은 인간의 한계를 극복하기 위한 것이지만, AI는 다른 한계를 가짐
복잡한 문제를 풀 때는 단순히 프롬프트를 주고 결과를 받는 게 아니라, 대화와 반복적 설계를 통해 문제 공간을 탐색하는 과정이 유용했음
AI의 오류나 환각은 오히려 내가 문제를 제대로 이해하고 있는지를 알려주는 신호로 작용함
나는 vibe coding 방식으로 레트로 에뮬레이터와 어셈블러를 만들어봤는데, 프롬프트가 적어도 좋은 결과를 얻었음
하지만 예전에 내가 만든 특정 산업용 앱의 독점적인 부분을 시도했을 때는 아무리 프롬프트를 줘도 결과가 형편없었음
GitHub에 수천 개의 에뮬레이터 예제가 있지만, 내가 하려던 건 예제가 전혀 없었음
결론은 간단함 — 어떤 건 쉽고, 어떤 건 전혀 안 됨
GitHub에 예제가 많으면 LLM의 잠재공간에도 존재하므로 언제든 뽑아낼 수 있음
네가 시도한 건 그런 예제가 없었을 뿐임
산업 특화 프레임워크는 vibe coding으로 다루기 어렵지만, 문제를 단순화하면 AI가 훨씬 빠르게 도와줌
vibe coding을 완전히 받아들이면 멋진 결과를 낼 수 있지만, 기술 부채가 너무 커져서 결국 기계의 노예가 되는 느낌임
수천 줄의 코드를 AI가 대신 쓰면, 그 구조를 이해하거나 리뷰하기가 매우 어려워짐
결국 일회용 코드와 소프트웨어가 늘어날 것 같음 — 특정 문제를 해결하는 앱은 쉽게 만들지만, 지속 가능한 SaaS에는 큰 위험이 따름
AI는 강력한 배수 효과(force multiplier) 를 주는 도구임
코드베이스의 기반이 나쁘면 AI도 그 스타일을 그대로 복제함
반대로 깨끗하고 일관된 기반이라면 AI가 그 품질을 유지하며 놀라울 정도로 잘 작동함
결국 핵심은 기초 설계(foundation) 임
대부분의 코드베이스는 유지보수가 어렵고 확장이 힘든 구조라 AI가 그 문제를 더 드러내는 것뿐임
건축과 마찬가지로, 기초가 약하면 아무리 좋은 도구도 한계가 있음
이렇게 하니 후속 개발자도 프로젝트의 맥락(context) 을 완전히 이해할 수 있게 되었음
결국 핵심 추상화를 먼저 바로잡아야 AI가 제대로 작동함
요구사항은 계속 변하고, 효율을 위해 타협이 생김
결국 시간과 기회비용이 품질보다 우선하게 됨 — 인간이 계획을 완벽히 지키지 못하기 때문임
AI는 귀찮은 부분을 덜 귀찮게 만들어줌
하지만 LLM과 논쟁하는 건 시간 낭비임
작은 단위로 변경하고, 잘 되면 커밋하고, 안 되면 버리고 다시 시도하는 게 효율적임
AI는 만능이 아니고, 적절한 도구 선택이 중요함
총을 든 아이와 놀려면 방탄복을 입어야 함
“다른 사람의 코드를 읽는 게 쓰는 것보다 어렵다”는 말이 자주 나오는데, 나는 그게 이상함
직접 코드를 작성하는 데 반나절 걸리는 함수도 읽고 리뷰하는 데는 10~15분이면 충분함
올바른 코드를 검증하는 게 만드는 것보다 훨씬 쉬움
단순히 읽는 건 쉽지만, 구조를 이해하고 개선점을 찾는 편집은 훨씬 많은 노력이 듦
작성 당시의 맥락(context) 이 사라지기 때문임
사실은 읽는 게 어렵다기보다, 사람들이 새로 쓰는 걸 더 선호하기 때문임
올바른 사고방식은 “AI가 모든 걸 쉽게 만들어주지만, 그 자체가 새로운 기술이며 배우기 어렵다”는 것임
지금은 ENIAC 시대의 AI로, 고급 언어나 운영체제에 해당하는 개념이 아직 없음
앞으로 컨텍스트 엔지니어링(context engineering) 이라는 학문이 생길 것이고, 지금의 방식은 원시적으로 보일 것임
구조를 잘 잡으면 AI의 능력은 사실상 무한해 보임
“AI로 했다”는 건 사실상 “외부 회사의 CPU 자원을 대량으로 썼다”는 뜻임
내가 완전히 소유한 AI 에이전트가 생기기 전까지는 진정한 진보라기보다 행성 규모의 자원 도둑질에 가깝다고 생각함
AI는 개발을 어렵게 만들지 않음
오히려 사람들이 그동안 무시해온 진짜 어려운 부분을 드러냄
지난 15년간 개발자들은 이미 “인간 버전의 vibe coding”을 해왔음 — Stack Overflow에서 복붙하고, 계획 없이 리팩터링하며, “내 노트북에서만 잘 돌아가면 됨” 식으로 일했음
이제 AI가 그걸 하니까, 갑자기 다들 계획을 세우고 테스트를 작성하려 함
느려지더라도 품질이 개선된다면 그게 진짜 진전임
지금의 ‘마라톤 속 스프린트’ 문화가 AI로 인해 더 가속화되고 있음
하지만 AI는 감독 없이 쓰면 금방 엇나가고, 남이 쓴 코드를 읽는 건 자기 코드 고치는 것보다 훨씬 피로함
AI에게 “이 파일에 테스트를 추가하라”고 했더니, 500줄짜리 파일이 100줄로 줄어들었음
이유를 묻자 “원래 파일이 없었다”고 답함
git 히스토리를 보여주니 사과하며 “존재 여부를 먼저 확인했어야 했다”고 함
어제는 “그 파일은 잊어버려”라고 했더니 진짜로 파일을 삭제해버림
약간의 되돌리기 비용은 AI의 가치에 비하면 감수할 만함