이 논지를 반복해서 읽을수록 표현의 세련됨은 계속 좋아지는데, 아직 경구 단계까지는 못 갔다고 느낌
"the medium is the message", "you ship your org chart", "9 mothers can't make a baby in a month"처럼 몇 마디로 다수에게 꽂히는 문장이 되려면, 의미를 깎아내는 작업에 수년에서 수십 년이 걸림
그리고 우리는 의미 형성을 RL로 다루는 법조차 모르니, AI가 그걸 대신해주진 못함
"can't make 9 babies in a month"
원래는 "9 women can't make a baby in one month"가 맞음
직접 하면서 배움. 이 한마디가 더 경구에 가까워 보임
Intelligence amplification, not artificial intelligence가 괜찮아 보임
줄이면 IA, not AI가 되고, 스페인어로 옮기면 "AI, no IA"라서 더 재밌어짐
취향과 판단력은 AI가 낳아주지 못함
the medium is the message
미국인 100명에게 이 경구의 뜻을 물어보면, McLuhan의 원래 의미를 제대로 짚는 사람은 거의 없을 듯함
AI는 대체로 두 방식으로 쓸 수 있다고 봄
하나는 내가 소유하고 이해하는 코드를 쓰는 데 보조로 쓰는 방식이고, 다른 하나는 AI를 추상화 계층처럼 써서 코드 작성과 유지보수를 맡기는 방식임
후자는 프로토타입, 예제, 레퍼런스처럼 수명이 짧고 코드 품질이나 내 이해도가 크게 중요하지 않은 곳엔 괜찮음
문제는 사실 1이 필요한 일에 2를 갖다 쓰면서 자신과 남을 속일 때 생김
빠르고 쉬워 보여도 결국 코드베이스를 저당 잡히는 셈이고, 그때부터 역량 위축도 시작된다고 봄
많은 엔지니어가 가까운 미래의 어느 시점엔 AI가 1번 방식도 완벽히 해줄 거라고 막연히 믿고 있어서, 2를 활용해 1을 더 쉽게 만드는 인프라에 투자하자는 얘기는 팔기 더 어려움
문제는 그게 저당 잡히는 느낌조차 안 든다는 데 있음
기능은 계속 나가고 겉보기엔 멀쩡한데, 뭔가 터지는 순간 모델에 다시 묻지 않고는 자기 코드도 디버깅 못 한다는 걸 깨닫게 됨
현대적인 IDE, 메모리 관리가 있는 언어, GitHub나 패키지 매니저의 라이브러리 없이는 일 못 하는 엔지니어도 많음
그래서 AI 의존도도 내겐 아주 본질적으로 다르게 느껴지진 않음 Engineer라는 말의 의미도 변할 수 있고, 실제로 Webflow나 WordPress만 쓰는 "web developer"도 이미 존재함
Engineer라는 용어는 이미 크게 변했음
엄격한 정의로 가면 Software Engineering 분야 사람들 중 실제 공인 엔지니어는 거의 없고, 어떤 나라에선 자격과 타이틀까지 붙음
진짜 못 한다는 건지, 아니면 안 한다는 건지 구분해야 함
커리어 초반엔 시간이 충분하면 거의 뭐든 했겠지만, 지금은 할 수 있어도 재미없어서 안 하는 일이 길게 늘어섬
큰 차이는 우리가 최종 비용을 아직 모른다는 점임
AI가 Slack 구독료 수준의 비용일지, 팀원 한 명의 비용일지, 아니면 서비스가 사라져서 AI 접근권 있는 사람을 따로 고용해야 할지 알 수 없음
적어도 지금은 대부분에게 로컬 실행이 현실적이지 않음
그래서 AI에 의존하는 건, 로컬이나 오픈소스 도구일 수 있는 IDE에 의존하는 것과는 꽤 다름
"넌 대체 무슨 엔지니어냐"라는 말이 Jesse Plemons의 새빨간 선글라스 장면처럼 떠오름
경력 10년쯤 된 사람은 코드의 흐름과 논리를 알아서 AI를 써도 코드를 만들고 자기 방식도 개선할 수 있음
반대로 초보자는 흐름이나 논리를 모르고 그냥 복붙하게 되기 쉬워서, AI가 그런 사람들에게 생각할 여지를 더 줄 것 같진 않음
지금의 AI 사용 방식은 지난 20년간의 프로그래밍보다 더 피곤하게 느껴짐
문제를 던지고, 제안을 평가하고, 그중 맞는 방향을 고르고, 이상한 제안을 걷어내고, 다시 다듬어서 거의 맞는 상태로 만드는 과정이 특히 지침
그 뒤 코딩은 1~5시간 돌려서, 내가 직접 했다면 적어도 2~3주는 걸렸을 결과를 내주기도 함
그런데 이렇게 5시간쯤 계획 중심으로 일하면 완전히 녹초가 되고, 이건 순수한 프로그래밍만 할 때의 피로와는 다름
뭔가 배우는 것 같기도 하지만, 솔직히 관리자 일에 더 가까운 느낌도 듦
나도 비슷하게 느낌
LLM과 천천히 문제를 정의하고 그럴듯한 해법을 찾으려면 계속 집중 상태를 유지해야 해서, 예전 같은 몰입 흐름이 잘 생기지 않음
산더미 같은 출력을 계속 처리하면서 핵심을 반복해서 골라내야 하고, 대체로 좋아도 늘 어딘가 미묘하게 어긋나 있어서 꽤 거슬림
LLM 특유의 이상한 오류와 추론 결함 때문에 높은 경계심도 계속 유지해야 하고, 그 비인간적인 커뮤니케이션 스타일을 해석하는 것 자체도 지치게 만듦
AI의 장점 중 하나는 시작을 해주고 계속 밀어준다는 데 있음
다만 pacing이나 procrastination이 오히려 인간에게는 일종의 압력 해소 밸브일 수도 있겠다는 생각도 듦
애초에 생각을 잘 못하는 엔지니어는 많고, AI가 그 사실 자체를 바꾸진 못함
진짜 핵심은 제대로 생각하지 못하는 것임
그게 Software Engineering 영역이 많이 망가진 이유 중 하나고, AI는 해결은 못 하고 더 큰 혼란을 잠시 미룰 뿐일 수 있음
일부는 동의하지만, AI는 리더십이 사람들의 허풍과 헛소리를 간파하기 더 어렵게 만드는 효과는 분명히 있다고 봄
공학 학위를 받고도 생각을 못 한다는 게 어떻게 가능한지 궁금함
대학에서 컨닝으로 버틴 사람도 안 들키고 빠져나가려면 결국 비판적 사고는 필요했음
듣기 싫어할 수 있지만, 컨닝을 잘하는 것조차 꽤 많은 사고력을 요구함
AI에게 어느 수준에서든 생각을 맡기는 사람은 원래 그것을 가치 있게 여기지 않았다고 봄
"use it or lose it"라는 말처럼, 이를 뒷받침하는 연구는 점점 늘어나는데도 소프트웨어 개발에서 LLM 사용은 괜찮고 우리의 가치는 사고력에 있다는 식의 글도 계속 나옴
이게 ADHD나 불안 성향과 관련 있을 수도 있고, 컴퓨터로 일하는 사람들에게 꽤 흔한 특성일 수도 있지만, 나는 거의 항상 생각하고 있음
다른 일에 완전히 몰입했다가도 불쑥 해결책이 떠오르는 순간이 이 일의 아름다움 중 하나임
이제 AI는 그런 생각을 행동으로 빠르게 바꾸는 도구가 되어줌
예전엔 실마리를 잡기도 전에 흐름을 놓칠 때가 있었는데, 지금은 휴대폰으로 몇 분 안에 생각을 부분적으로라도 현실로 만들고 다시 하던 일로 돌아갈 수 있음
시선을 잠깐 돌리면 아이디어를 잃어버릴까 걱정하지 않아도 되는 점이 특히 큼
지금 numba를 다시 만들고 있는데, 이걸 손으로만 하는 건 상상하기 어려움
몇 년 전에 시도했을 땐 몹시 고통스럽고, 느리고, 지저분했음
수년간 쌓인 추상화 위에 작은 것들이 끝없이 얹혀 있어서 더 그랬음
이번엔 LLM을 써서 다시 하고 있는데, 원래 몇 주 걸릴 일이 하룻밤 사이 끝나기도 함
그래도 코드는 직접 보고, 생성된 C 출력도 보고, 앞으로 나와 LLM이 함께 다루기 쉽도록 아키텍처 통제도 계속 쥐고 있음
이게 내 사고를 대체하는지는 잘 모르겠음
수개월 동안 수작업으로 쓰고 고치며 버텼다면 컴파일러나 트랜스파일러를 더 많이 배웠겠지만, 그러면 이것만 붙잡고 있었을 것임
대신 지금은 Golang으로 커스텀 파일시스템용 NFS 서버 지원까지 따로 작성할 시간도 남음
나도 AI가 내 사고 과정의 어떤 부분을 대체하고 있는지 걱정함
이제는 에이전트들이 기능 전체에 필요한 변경사항을 찾아내고, 계획 단계에서 아주 세밀하게 풀어둔 뒤, 구현은 거의 처음부터 맞게 해내는 수준의 시스템을 만들어 둠
지난 1년 동안 내가 직접 코드를 읽는 일은 점점 줄어들었고, 지금 시스템에 대해 내가 느끼는 편안함이 과한 건 아닌지 자주 자문하게 됨
워낙 높은 정확도와 성공률을 반복해서 봐서 이제는 본능적으로 의심하지 않게 됨
언젠가 크게 데일 거라 계속 기다리는데도, 이상하게 그 순간이 잘 오지 않음
물론 작은 누락과 되돌림은 있었지만 그건 예전에도 있었음
차이는 예전엔 내가 고생해서 쓴 코드라 훨씬 개인적인 관계가 있었다는 점임
이제 문제가 생기면 코드를 탓하기보다, 왜 시스템이 스스로 정답을 못 냈는지, 혹은 왜 구현 전에 계획에서 그 전체를 드러내지 못했는지를 다시 파고들게 됨
소프트웨어에서 AI의 가장 큰 장점은 코드를 더 빨리 만들 수 있다는 데 있음
가장 큰 단점은 엄청나게 더 빨리 만들고 싶게 유혹한다는 데 있음
그래서 개인 프로젝트에는 AI를 쓰지 않음 머리를 날카롭게 유지하고 싶기 때문임
AI를 포함하는 프로젝트라면 예외가 있을 수 있어도, 그 코드를 짜는 데 AI를 쓰진 않음
반면 회사 일은 신경 안 씀
매니저가 Claude로 완전히 vibe coding하길 원하면 그렇게 할 뿐이고, 그로 인해 생기는 기술 부채 비용을 내가 내는 건 아니기 때문임
Hacker News 의견들
이 논지를 반복해서 읽을수록 표현의 세련됨은 계속 좋아지는데, 아직 경구 단계까지는 못 갔다고 느낌
"the medium is the message", "you ship your org chart", "9 mothers can't make a baby in a month"처럼 몇 마디로 다수에게 꽂히는 문장이 되려면, 의미를 깎아내는 작업에 수년에서 수십 년이 걸림
그리고 우리는 의미 형성을 RL로 다루는 법조차 모르니, AI가 그걸 대신해주진 못함
원래는 "9 women can't make a baby in one month"가 맞음
직접 하면서 배움. 이 한마디가 더 경구에 가까워 보임
Intelligence amplification, not artificial intelligence가 괜찮아 보임
줄이면 IA, not AI가 되고, 스페인어로 옮기면 "AI, no IA"라서 더 재밌어짐
취향과 판단력은 AI가 낳아주지 못함
미국인 100명에게 이 경구의 뜻을 물어보면, McLuhan의 원래 의미를 제대로 짚는 사람은 거의 없을 듯함
AI는 대체로 두 방식으로 쓸 수 있다고 봄
하나는 내가 소유하고 이해하는 코드를 쓰는 데 보조로 쓰는 방식이고, 다른 하나는 AI를 추상화 계층처럼 써서 코드 작성과 유지보수를 맡기는 방식임
후자는 프로토타입, 예제, 레퍼런스처럼 수명이 짧고 코드 품질이나 내 이해도가 크게 중요하지 않은 곳엔 괜찮음
문제는 사실 1이 필요한 일에 2를 갖다 쓰면서 자신과 남을 속일 때 생김
빠르고 쉬워 보여도 결국 코드베이스를 저당 잡히는 셈이고, 그때부터 역량 위축도 시작된다고 봄
기능은 계속 나가고 겉보기엔 멀쩡한데, 뭔가 터지는 순간 모델에 다시 묻지 않고는 자기 코드도 디버깅 못 한다는 걸 깨닫게 됨
현대적인 IDE, 메모리 관리가 있는 언어, GitHub나 패키지 매니저의 라이브러리 없이는 일 못 하는 엔지니어도 많음
그래서 AI 의존도도 내겐 아주 본질적으로 다르게 느껴지진 않음
Engineer라는 말의 의미도 변할 수 있고, 실제로 Webflow나 WordPress만 쓰는 "web developer"도 이미 존재함
엄격한 정의로 가면 Software Engineering 분야 사람들 중 실제 공인 엔지니어는 거의 없고, 어떤 나라에선 자격과 타이틀까지 붙음
커리어 초반엔 시간이 충분하면 거의 뭐든 했겠지만, 지금은 할 수 있어도 재미없어서 안 하는 일이 길게 늘어섬
AI가 Slack 구독료 수준의 비용일지, 팀원 한 명의 비용일지, 아니면 서비스가 사라져서 AI 접근권 있는 사람을 따로 고용해야 할지 알 수 없음
그래서 AI에 의존하는 건, 로컬이나 오픈소스 도구일 수 있는 IDE에 의존하는 것과는 꽤 다름
경력 10년쯤 된 사람은 코드의 흐름과 논리를 알아서 AI를 써도 코드를 만들고 자기 방식도 개선할 수 있음
반대로 초보자는 흐름이나 논리를 모르고 그냥 복붙하게 되기 쉬워서, AI가 그런 사람들에게 생각할 여지를 더 줄 것 같진 않음
지금의 AI 사용 방식은 지난 20년간의 프로그래밍보다 더 피곤하게 느껴짐
문제를 던지고, 제안을 평가하고, 그중 맞는 방향을 고르고, 이상한 제안을 걷어내고, 다시 다듬어서 거의 맞는 상태로 만드는 과정이 특히 지침
그 뒤 코딩은 1~5시간 돌려서, 내가 직접 했다면 적어도 2~3주는 걸렸을 결과를 내주기도 함
그런데 이렇게 5시간쯤 계획 중심으로 일하면 완전히 녹초가 되고, 이건 순수한 프로그래밍만 할 때의 피로와는 다름
뭔가 배우는 것 같기도 하지만, 솔직히 관리자 일에 더 가까운 느낌도 듦
LLM과 천천히 문제를 정의하고 그럴듯한 해법을 찾으려면 계속 집중 상태를 유지해야 해서, 예전 같은 몰입 흐름이 잘 생기지 않음
산더미 같은 출력을 계속 처리하면서 핵심을 반복해서 골라내야 하고, 대체로 좋아도 늘 어딘가 미묘하게 어긋나 있어서 꽤 거슬림
LLM 특유의 이상한 오류와 추론 결함 때문에 높은 경계심도 계속 유지해야 하고, 그 비인간적인 커뮤니케이션 스타일을 해석하는 것 자체도 지치게 만듦
다만 pacing이나 procrastination이 오히려 인간에게는 일종의 압력 해소 밸브일 수도 있겠다는 생각도 듦
애초에 생각을 잘 못하는 엔지니어는 많고, AI가 그 사실 자체를 바꾸진 못함
그게 Software Engineering 영역이 많이 망가진 이유 중 하나고, AI는 해결은 못 하고 더 큰 혼란을 잠시 미룰 뿐일 수 있음
대학에서 컨닝으로 버틴 사람도 안 들키고 빠져나가려면 결국 비판적 사고는 필요했음
듣기 싫어할 수 있지만, 컨닝을 잘하는 것조차 꽤 많은 사고력을 요구함
AI에게 어느 수준에서든 생각을 맡기는 사람은 원래 그것을 가치 있게 여기지 않았다고 봄
"use it or lose it"라는 말처럼, 이를 뒷받침하는 연구는 점점 늘어나는데도 소프트웨어 개발에서 LLM 사용은 괜찮고 우리의 가치는 사고력에 있다는 식의 글도 계속 나옴
다른 일에 완전히 몰입했다가도 불쑥 해결책이 떠오르는 순간이 이 일의 아름다움 중 하나임
이제 AI는 그런 생각을 행동으로 빠르게 바꾸는 도구가 되어줌
예전엔 실마리를 잡기도 전에 흐름을 놓칠 때가 있었는데, 지금은 휴대폰으로 몇 분 안에 생각을 부분적으로라도 현실로 만들고 다시 하던 일로 돌아갈 수 있음
시선을 잠깐 돌리면 아이디어를 잃어버릴까 걱정하지 않아도 되는 점이 특히 큼
지금 numba를 다시 만들고 있는데, 이걸 손으로만 하는 건 상상하기 어려움
몇 년 전에 시도했을 땐 몹시 고통스럽고, 느리고, 지저분했음
수년간 쌓인 추상화 위에 작은 것들이 끝없이 얹혀 있어서 더 그랬음
이번엔 LLM을 써서 다시 하고 있는데, 원래 몇 주 걸릴 일이 하룻밤 사이 끝나기도 함
그래도 코드는 직접 보고, 생성된 C 출력도 보고, 앞으로 나와 LLM이 함께 다루기 쉽도록 아키텍처 통제도 계속 쥐고 있음
이게 내 사고를 대체하는지는 잘 모르겠음
수개월 동안 수작업으로 쓰고 고치며 버텼다면 컴파일러나 트랜스파일러를 더 많이 배웠겠지만, 그러면 이것만 붙잡고 있었을 것임
대신 지금은 Golang으로 커스텀 파일시스템용 NFS 서버 지원까지 따로 작성할 시간도 남음
이제는 에이전트들이 기능 전체에 필요한 변경사항을 찾아내고, 계획 단계에서 아주 세밀하게 풀어둔 뒤, 구현은 거의 처음부터 맞게 해내는 수준의 시스템을 만들어 둠
지난 1년 동안 내가 직접 코드를 읽는 일은 점점 줄어들었고, 지금 시스템에 대해 내가 느끼는 편안함이 과한 건 아닌지 자주 자문하게 됨
워낙 높은 정확도와 성공률을 반복해서 봐서 이제는 본능적으로 의심하지 않게 됨
언젠가 크게 데일 거라 계속 기다리는데도, 이상하게 그 순간이 잘 오지 않음
물론 작은 누락과 되돌림은 있었지만 그건 예전에도 있었음
차이는 예전엔 내가 고생해서 쓴 코드라 훨씬 개인적인 관계가 있었다는 점임
이제 문제가 생기면 코드를 탓하기보다, 왜 시스템이 스스로 정답을 못 냈는지, 혹은 왜 구현 전에 계획에서 그 전체를 드러내지 못했는지를 다시 파고들게 됨
소프트웨어에서 AI의 가장 큰 장점은 코드를 더 빨리 만들 수 있다는 데 있음
가장 큰 단점은 엄청나게 더 빨리 만들고 싶게 유혹한다는 데 있음
그래서 개인 프로젝트에는 AI를 쓰지 않음
머리를 날카롭게 유지하고 싶기 때문임
AI를 포함하는 프로젝트라면 예외가 있을 수 있어도, 그 코드를 짜는 데 AI를 쓰진 않음
반면 회사 일은 신경 안 씀
매니저가 Claude로 완전히 vibe coding하길 원하면 그렇게 할 뿐이고, 그로 인해 생기는 기술 부채 비용을 내가 내는 건 아니기 때문임