▲

아직 아무도 AI로 어떻게 구축해야 할지 모름

 (worksonmymachine.substack.com)
1P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • 최근 4일 만에 Protocollie 개발을 완료했으나, 같은 방식으로 반복할 수 있을지 확신 없음
  • AI 개발 환경에서는 기존의 전문성이나 방법론이 계속 뒤바뀌기 때문에 모두가 영구적인 초보자에 해당함
  • 작업 문서 네 개를 사용해 일련의 실험적 개발 과정을 수행하였고, 이는 공식적인 체계가 아닌 우연적 쌓임 결과임
  • AI와의 협업은 마치 시간 왜곡처럼 짧은 입력에 비해 압도적인 산출이 나오는 새로운 경험을 제공함
  • 이 네 개 문서는 정해진 규칙이나 권장 사례가 아닌 실험의 흔적이며, 앞으로 개발 방식 역시 끊임없이 변화할 전망임

AI 개발의 불확실성과 실험적 접근

최근 4일 만에 Protocollie라는 소프트웨어를 이전에 익숙하지 않은 언어들을 활용하고, 코드 작성조차 직접 하지 않으면서 개발한 경험 발생함
개발 과정에 대해 주변에서 여러 질문을 받았으나 같은 방식으로 다시 구현할 수 있을지는 장담할 수 없음을 인식함
이처럼 한창 변동성이 높은 AI 시대에서는 모든 개발자가 각자 시행착오를 겪고 있으며, 어느 누구도 명확한 전문성을 내세울 수 없는 중간 지대에 머무르고 있음

기술과 전문가라는 개념의 변화

기술 발전 초입에는 모두가 전문성을 가진 척 행동하지만, AI와 같은 빠른 변화에서는 영원히 초보자 상태일 수밖에 없음을 고찰함
Malcolm Gladwell의 1만 시간 법칙처럼 기존 영역은 비교적 변화가 느렸지만, AI 도구의 발전 속도는 너무 빨라 숙련도를 쌓기가 어려움
세계 최고의 AI 페어 프로그래머도 경력이 2년을 넘기 힘든 환경으로, 모두가 시작 단계에서 헤매고 있음

즉흥적 시스템의 등장: 네 개의 문서

개발 과정에서 공식적인 시스템이나 구조를 세웠다기보다 우연적이고 누적적으로 여러 문서를 사용하게 됨

  • 처음에는 아키텍처 관련 문서 한 개로 시작해, 반복되는 문제와 정보전달 문제로 인해 점차 문서가 네 개로 늘어남
  • 네 개의 문서를 최적화된 결과로 정한 것이 아니라, 더는 추가하지 않아도 괜찮다고 느낀 지점임
  • 개발자 역할이 실제로 남들 보기에 진짜인지 가짜인지 의심스러울 때가 있으나, 실제로 소프트웨어가 제대로 동작하고 있으므로, 모든 방법론이나 체계는 결국 결과물을 위한 합의된 허구임을 시사함

각 문서의 역할은 아래와 같음

  • Architecture Overview: README에서 출발, '이 소프트웨어가 무엇을 하는 것 같은지'를 기록
  • Technical Considerations: 반복되는 좌절이나 문제들을 문서화, Claude가 헷갈릴 때마다 세부 내용을 추가
  • Workflow Process: 반복해온 절차를 문서화, 실제로는 공식 규칙이나 신성 불가침의 문서가 아니라, 이번에 우연히 효과있었던 방법의 모음임
  • Story Breakdown: 15-30분 단위의 쪼갠 작업 청크. Claude가 금새 망각하기 때문에 대화 내역을 자주 리프레시하기 위함임

AI 시대의 시간 왜곡

Protocollie 개발 당시, AI와의 협업은 기존 소프트웨어 개발의 시간감각을 완전히 뒤흔드는 경험임

  • Claude에게 특정 기능 작업을 지시한 뒤 그 사이에 개인 생활을 즐기고, 주기적으로 점검 및 간단한 피드백을 주는 방식으로 프로젝트가 진행됨
  • 실제 집중해서 "일"한 시간은 하루 90분 남짓이지만, AI는 그 사이에도 빠르게 코드를 생산함
  • 입력에 비해 결과물이 너무 빠르고 많아 기존의 투입-산출, 노력-성과, 시간-진전 공식이 무너짐
  • 때때로 이렇게 빠른 개발이 죄책감마저 들 정도이며, 전통적 개발 패러다임에 맞지 않는다는 혼란을 느낌

"스파게티 실험" 단계

현재의 AI 개발 환경을 "스파게티 실험" 단계라고 표현함

  • 즉, 벽에 실험적으로 스파게티를 던지는 과정 자체가 의미 있으며, 무엇이 굳이 붙거나 남는지는 중요하지 않음
  • 각종 삽질, 실험 실패, 우연히 동작한 절차 등은 집단적 실험의 데이터 포인트 역할을 함
  • 본인이 사용한 4문서 시스템도 언제든 무의미해질 수 있으며, 실험정신을 이어가는 것이 중요함

프로그램이란 무엇인가에 대한 재정의

코딩 역사를 돌아보면, 추상화의 발전과 함께 "내가 원하는 것을 설명하면 그것이 구현되는" 시대에 접어들었음을 인식함

  • AI 활용은 단순한 새로운 추상화 계층 이상의, 전혀 다른 실체로 변화하고 있음
  • 지금의 프로그래밍은 구문 지식, 알고리듬 이해, 시스템 설계 능력이 아닌, '정확한 상상력'과 '구조적 바람' 같은 새로운 역량이 요구됨
  • 원하는 바를 명확히 정의할 수 있는 능력이 무엇보다 중요해짐

네 개 문서 시스템의 철학적 의미

되돌아보면, 네 개의 문서들은 코드 자체보다는 기억과 망각, 보존과 재생성에 관한 것임

  • 각 문서는 실제론 특정 역할(아키텍처, 지침, 프로세스, 계획)보다는 "미래의 나를 위해 남긴 메시지" 같은 의미임
  • 모든 개발 문서화는 결국 정보의 유실을 대비한 자신에게 보내는 안내문 성격임

불안정한 고원과 영구적 초보자

지금은 모두가 영구적인 주니어 개발자 상태

  • 전통적인 주니어와 달리 바뀌는 기술 속도 때문에 선임자가 자연스럽게 되는 일은 없음
  • 끊임없이 변화하는 '물리 법칙' 속에서, 안정적 숙련성보다 적응과 실험정신이 중요해짐
  • 이 불확실성은 통제감과의 관계에 따라 불안하거나 해방감 넘치는 경험으로 작용함

앞으로의 변화 방향

다음에 무엇을 만들지, 어떤 프로세스를 쓸지, 이번에 만든 네 개 문서를 계속 쓸지 알 수 없는 상태임

  • 모든 개발자는 동시에 자신의 루틴에서는 전문가, 새로운 상황에서는 완전 초보자임
  • 4일 만의 작업이 과거의 몇 개월 분량이 될 만큼, '원하는 바를 설명하는 역량'이 결정적인 스킬로 부상함
  • 본인의 네 개 문서 역시 권장사항이나 템플릿이 아닌, 잠시의 실험적 결과물일 뿐임

결국 우리는 모두 썰물 때의 모래성(소프트웨어) 을 쌓고 있으며, 진보라는 파도가 곧 그것을 다시 쓸어갈 것을 인지하고 있음
머지않아 누군가는 3문서 시스템, 5문서 시스템, 혹은 완전히 다른 접근방식을 시도할 것이며, 그 방식 또한 효과적일 수 있음

마지막으로, 본인이 사용한 네 개 문서는 현재 GitHub에 공개 중임

  • 이는 절대적인 정답이나 템플릿이 아니고, 특정 시기의 한 실험 사례로 볼 것
  • 다른 사람의 자취를 참고하되 그대로 따라갈 필요는 없음을 강조함
  • 각자의 실험과 방법론을 개발하는 것이 AI 시대의 새로운 개발 생태계임
▲
GN⁺ 11시간전  [-]
Hacker News 의견

  • 이 글에 정말 공감함. Kidlin’s Law, 즉 “문제를 명확하게 글로 쓸 수 있으면, 이미 절반은 해결한 것이다”라는 이론을 우연히 발견했음. 요즘 AI 시대에 매우 강력한 원칙임. 자연어가 기술과 소통하는 주된 수단이 되면서, 명확하게 문제를 정의할 수 있으면 AI의 잠재력도 극대화할 수 있음. 비동기형 코딩 접근법도 정말 흥미로움. 개인적으로 Repl.it을 매우 자주 사용하고 있는데, 문제 해결에 집중할 수 있어서 놀라운 변화임. 코딩 도구를 사용할 때 마리오 카트에서 스타나 버섯 먹은 느낌을 받음. 너무 신나기도 하지만, 때로는 AI가 완전히 이상한 방향으로 갈 때도 있어 실시간으로 결정 개입이 필요한 경우도 있음. 스택 하나 관리만 해도 힘들었는데, 이제는 무한한 스택을 상대하는 기분임

    • 나도 스스로 소프트웨어 엔지니어로 성장하는 과정에서, 하고 싶은 것을 설명할 수 있도록 소프트웨어 세계의 용어 자체를 익히는데 많은 시간을 들였다는 점을 종종 떠올리게 됨

    • Repl.it은 정말 잘될 때는 몇 분 안에 해결되는 일이 오후 내내 걸릴 때도 있음. 하지만, 가끔은 프롬프트 박스 아래에 있는 추천사항을 시도해도 제대로 작동하지 않아서 매우 실망스러움

    • 사실 문제를 명확하게 진술하는 게 옛날부터 항상 어렵고, 지금도 마찬가지임. 명확한 자연어를 코드로 바꿔주는 도구가 생긴 건 정말 멋진 일이지만, AGI가 나와도 명확한 스펙을 만들어내야 하는 작업 자체는 변하지 않을 것임. 도구 덕분에 코딩 자체에 싸우는 시간은 줄일 수 있겠지만, 결국 정말로 명확한 명세 작성이 가장 어려운 부분임

  • 새로운 프로그래밍 방식이 너무 마음에 듦. 이 방식이 어디로 갈지 모르겠지만 당장은 만족스러움. 지금도 평소엔 휴식할 시간에 코드를 만들고 있고, 이게 오히려 휴식처럼 느껴짐. 오래 일한 시니어 개발자에게 특히 좋음. 요즘엔 에디팅 일이 대부분 지루함. 코드를 보고 잘못된 패턴을 발견하면 새로운 아이디어를 실험하기 위해 많은 부분을 바꿔야 하는데, 옛날엔 Stack Overflow 검색하고 고민해야 했던 일들이 이제는 Copilot 힌트 한 번, 혹은 Claude가 그냥 다 해결해줌. 예를 들면, 모의 주식 거래소를 만들었는데, 원래는 실제 거래소에 연결하는 것 때문에 종종 미뤄지는 작업이었음. 이제는 Claude가 HN 읽는 동안 다 만들어놓음. 여기에 전략 구현까지 하려면 사실상 지루하기만 했던 반복작업도 바로 처리됨. 오타, 의존성 추가 같은 일들 때문에 시간이 오래 걸렸는데, 이젠 그럴 필요도 없음. 이렇게 하면 코드가 엉망이 될까 걱정할 수도 있는데, 나는 항상 Claude와 대화하면서 변경사항을 비판적으로 검토함. 경험이 도움이 되긴 하지만, AI가 오답으로 가는 것도 금방 감지할 수 있음. 그래서 내 커리어에 딱 맞는 순간에 이런 도구를 만나게 된 셈임. 문제는 주니어 개발자들에게 남아있음. 계단이 사라진 산꼭대기로 한 번에 올라가는 셈이라서, 어떻게 성장할 수 있을지 궁금함

    • 주니어 개발자들 전망에 동의함. 거의 50살에 30년 넘게 여러 분야에서 프로그래밍했지만, 내 경험에 기반해 에이전트를 잘 다루고 아키텍처를 튼튼하게 만드는 법을 알고 있음. 경험 없이 모든 게 AI가 조리해서 나온다면, 후배들이 어떻게 성장할지 정말 궁금함. 시간이 알려줄 문제임

    • 나도 대형 언어 모델 즐겁게 사용하지만, 계속 프롬프트만 입력하는 건 지루하고 불안하기도 함. 프로그램이 돌아가는 원리를 정확히 모르는 기분임. 직접 무언가를 만드는 건 정말 재미있고, 이미 해본 반복 작업이나 신경 안 쓰는 업무는 LLM에게 시킴. Claude로 터미널 기반 snake 게임도 만들어봤는데, 정말 신기했음

    • 예전의 자질구레한 작업들로 돌아갈 수 없다는 걸 스스로 깨달았는지 궁금함. LLM 등장 덕분에, 작업하는 동안 밖에 나가고 싶은 마음이 커짐. 예전처럼 12시간씩 모니터만 보며 두 개의 블랙박스를 연결하지 못해 허송세월하는 경험을 신입 개발자들은 더 이상 겪지 않아도 되니 부럽기도 함

    • 실제로 구현할 때 모두 처음부터 끝까지 한 번에 처리하는지 궁금함. 나는 항상 반복적이고 점진적으로 작성하고 다듬으면서 구현함. 드로잉에 비유하면, 전체를 대략 잡고, 점점 세밀하게 보완해나가는 구조임. 각 단계마다 내가 뭘 하고 싶은지 조금씩 명확해지고, 최소한의 노력으로 최대 효과를 내는 방식임. 코딩은 리팩토링 중심으로, 최소한으로 동작하는 코드를 만든 다음, TODO 주석을 남기고 반복적으로 개선하는 스타일임

    • 이런 도구들이 예전부터 수천 번 해왔던 지루한 작업을 대신해주어서 정말 설레임

  • 내가 생각하는 AI란 인터넷에 존재하는 모든 정보 위에서 대화를 할 수 있는 차세대 구글 검색임. 검색 엔진이 대중화되면서 여러 산업(신문, 전화번호부, 백과사전, 여행사 등)에서 일자리가 사라졌던 것처럼, AI도 그런 변화를 불러옴. 하지만 이것이 사람들이 생각하는 것만큼 존재론적 위기는 아니라고 봄. AI는 그냥 하나의 도구임. 영리하고 창의적인 사람들이 이 도구를 활용해 멋진 일을 많이 할 것임. 결국 사용은 사용자에게 달렸음. 검색은 채팅이 되었음. 예전엔 직접 찾아봤지만, 이제는 채팅을 하면 AI가 대신 찾아주고, 그 이상도 해줌

    • 채팅형 LLM 인터페이스가 최적의 방식인지는 잘 모르겠음. 좀 더 스마트한 접근법이 필요해 보임

    • 구글 전성기와는 다르게, 이제는 신호 대비 노이즈가 더 많아지고, 데이터 출처도 흐려짐

    • 이미 구글 검색 결과는 쓸 만한 정보보다 AI가 많이 만든 쓰레기가 먼저 노출되는 느낌임

    • 최신 검색 엔진은 답만 주고, 답으로 가는 과정은 제공하지 않아서, 올바르게 정보를 찾고 기록하는 사람의 역할이 사라지고 있음. 이 부분이 사라지면 결국 모두 방향을 잃게 될 것임. AI가 기존 정보를 다시 활용하므로, 창작자(특히 좋은 저널리즘 기자)에게 수익을 돌려주는 방법이 필요함. 그렇지 않으면 민주사회 기반이 무너질 위험이 큼. 뉴스 산업은 이미 수년간 위기에 처해 있었고, 그 결과로 불신과 분열, 잘못된 정보, 외부 조작 등을 경험하고 있음. AI가 마지막으로 업계에 치명타를 줄 수도 있음. 단순한 일자리 대체 문제가 아니라, 지금 우리가 가는 길이 매우 어두운 방향임

    • 검색 이외의 다양한 분야에서도 명확히 유용함

  • Claude Code를 폰에서 클라우드 VM으로 돌려, 산책길이나 자전거 라이딩 중에도 피드백을 주며 작업을 계속하고 싶음

  • 입력과 출력 비율이 흥미로움. 우리는 대개 아웃풋 양을 극대화하려고 하지만, 이제는 반대임. 나는 최대량보다는 일의 과정이 구체적이고 검증 가능한 단계로 나눠지길 바람. Cursor와 요구사항을 같이 작성할 때 처음에는 잘 되지만, 실수로 계획과 어긋나는 대량의 코드를 생성하는 문제가 있음. 마크다운 제목 뒤에 빈 줄을 추가 못하거나, 반복적으로 알려줘야 하는 사소한 점도 있음. 반복 과정과 품질, 일관성을 내가 좀 더 통제할 수 있으면 좋겠다고 느낌. 테스트가 가능한 닫힌 문제로 바꿀 수 있을 때 AI가 진가를 발휘함. 내가 열린 문제를 닫힌 문제로 변환하는 걸 도와주는 도구가 필요함

  • “사무실로 들어가 Claude가 만든 걸 테스트하고, 잘 되면 커밋하고 푸시함” 이런 경험이 자꾸 반복되니까, 사이버 보안 컨설턴트로서 앞으로 돈을 정말 많이 벌 수 있을 것 같음

    • 가능성은 있음. 하지만 자율주행차 얘기에서처럼, 인간보다 실수가 줄긴 하겠지만 완전히 사라지지는 않을 거라는 점도 기억해야 함

  • 이건 vibe 코딩이 아니고, 완전히 새로운 거라고 생각함. 나는 이걸 “flex coding”이라고 부름. 한 오후에 전체 앱을 만들고, 좋은 아빠 역할까지 했음. “이제 서버 연결 UI 만들어줘”라고 하면, Claude가 코딩하고 나는 다시 일상으로 돌아감. 아침도 만들고, 아들과 놀고, TV도 보고, 그 사이 사이 Claude가 계속 코딩함. 한두 시간마다 잠깐 들러서 테스트 후 피드백 주는 식임

    • 감정적으로 정말 매력적이고, 많은 사람들이 꿈꾸는 라이프스타일이겠지만 Claude의 코드가 정말 신뢰할 수 있는 수준임? 고객에게 비용을 청구하거나 내 명예를 걸 제품에 사용할 수 있는가? 내 답은 “아니오”임. 직접 써 보니 참조 오류, 기존 타입 복붙 후 이름만 바꾸고, 타입 오류가 아예 없는 상황을 자주 봄. 테스트 코드를 짜게 했더니, 실패하면 실패하는 게 아니라 결국 자가검증만 통과하는 이상한 테스트를 만들기도 함. 소중한 시간 가족과 보내는 건 좋지만, 내가 만든 앱을 중요한 곳에 쓰라고 권하진 않겠음

    • 이런 식으로 일하는 사람에게 왜 급여를 줘야 하냐는 의문과, 내가 직접 할 수 있는데 왜 소프트웨어에 비용을 내느냐는 생각이 듦

    • 조심하라는 의미로, 이제 곧 Claude가 너도 일 좀 하라고 불평하기 시작할지도 모름

  • LLM 활용 소프트웨어 도구들에 한계를 느낌. 하나의 글로벌 시스템 프롬프트를 모든 OpenRouter Key 기반 앱에 공통으로 적용하는 방법도 없고, 한 앱에서 다른 앱으로 대화를 옮기는 것도 곤란함. 모든 앱에 동일한 MCP 툴 접근 권한조차 제대로 제공되지 않음. Claude Code UX가 현재는 최고인 것 같지만, Claude 구독에 묶이고 싶지는 않고 내 키를 통해 원하는 공급자와 연결하고 싶음

  • 보안, 국제화, 현지화, 접근성, 사용성 등등을 성공적으로 프롬프트했던 부분을 놓친 것 같음. 이런 품질 요소가 없는 채로 “소프트웨어 제작자”를 자처하는 아마추어가 너무 많은 게 문제임. 이런 측면들이 빠지면 상용 소프트웨어로는 절대 성공할 수 없음. 이런 부분을 쉽게 프롬프트로 해결할 수 있다고 생각한다면, 그 분야에서 진지한 경험이 없는 것임

    • 공정하게 보면, 실제로 상업용 소프트웨어 중에도 이 부분을 제대로 고려하지 않은 경우가 많음

    • 나 역시 회의적이지만, 링크된 문서 네 개 중에서 최소한 접근성과 사용성 문서는 포함되어 있음. 국제화와 현지화는 안 보여도 본질적으로 크게 다를 건 없다고 생각함. 반면, 보안 문제는 정말 별개의 영역이라고 느낌

    • “내 네 개의 문서 시스템? 결국은 패턴이 된 스파게티일 뿐이고, 내일이면 모두 무너질 수도 있음. 다시 스파게티를 던지는 거임” 이런 식으로 개발이 스케일 될 거라고 믿는 사람들이 아직 많다는 게 놀라움

  • 최근 모델 기반 개발에 실험적으로 접근 중이고, 글의 "프로그래밍은 뭔가?"라는 부분에 깊이 공감함. 25년의 경험과 컴퓨터공학을 모두 활용하지만, 손으로 코드를 직접 쓰는 전통적 프로그래밍은 아닌 것 같음. 지금은 무언가를 수작업으로 만드는 게 아니라 도구를 조종하는 파일럿 같은 기분임. 수작업을 즐기는 사람은 앞으로 5년 안에 업계를 떠날 가능성이 높다고 보임. 물론 여전히 수작업이 필요한 부분이 있겠지만, 새로운 방법론이 열리고 있음. 현재는 모두가 이 방법론에 능숙하지 않지만, 이 역시 업계의 일부가 될 것임

    • 한때는 생산성을 높이기 위해서는 반드시 지식을 습득해야 했는데, LLM 덕분에 이제 생산성 단계로 바로 건너뛸 수 있음. 단순한 지식 민주화라기보다는, 아예 지식 자체가 불필요해지는 현상임
답변달기