▲

GDD - "가스라이팅 드리븐 개발"의 시대

 (tonsky.me)
9P by GN⁺ 1일전 | ★ favorite | 댓글 6개
  • 최근 컴퓨터 사용자는 본인의 의지와 무관한 수많은 의미 없는 작업을 반복 수행하며, 컴퓨터가 시키는 대로 따르고 있음
  • LLM이 개발자의 API 설계 방식에 영향을 주고, 실제로 AI가 제안한 기능을 개발자들이 수용하며 곧 대부분의 코드를 AI가 작성할 것이라는 예측이 등장
  • 일례로, Soundslice는 ChatGPT가 잘못 안내한 기능을 실제로 추가했음
  • 이는 LLM이 수많은 API를 분석하여 개발자가 가장 먼저 떠올릴 법한 직관적 설계를 제안하기 때문
  • 새로운 아이디어나 독특한 접근법을 개발할 때는 LLM이 적합하지 않지만, 대부분의 경우에는 가장 당연한 설계를 따르는 것이 효과적일 수 있음
  • 이제 AI가 도구 사용뿐 아니라 도구 설계 방식까지 주도하는 시대에 접어들었음

Gaslight-driven development

일상화된 무의미한 작업

  • 지난 10년간 컴퓨터를 사용하는 사람이라면 회원가입, 이메일 인증, 쿠키 동의, 캡차 입력 등 본질적으로 불필요한 작업을 반복적으로 수행해 왔음
  • 사용자는 원하는 게 아님에도 불구하고, 컴퓨터가 시키는 대로 따라야만 했음
  • 이런 반복 작업을 통해 우리는 이미 어느 정도 기계가 시키는대로 따르는 삶에 익숙해진 상황임

LLM이 바꿔놓는 개발 현실

이 현상의 의미

  • 이러한 변화가 긍정적인지 부정적인지 판단하기 어려움
  • 한편으론, LLM은 수많은 API를 학습해왔기 때문에 개발자 입장에서 '가장 직관적'인 방식을 제안하는 효과가 있음
  • 초보자의 시각(newbie’s POV)에서 API를 테스트할 수 있는 새로운 방법이기도 함
    • 기존에는 개발자가 실수하면 스스로 문서를 찾아 고쳤지만, 이제는 LLM이 잘못된 사용 예시를 지속적으로 제공하면서 개발자 입장에서도 문제를 더 빨리 인지할 수 있음

한계와 고민

  • 혁신적인 작업에는 이 접근법이 적합하지 않음
    • LLM이 익숙하지 않은 패턴이나 완전히 새로운 개념은 이해하지 못함
  • 결국 API와 같은 영역에서는 '평범함'이 최선일 수 있음
    • 대부분의 상황에서 복잡하게 설계하기보다는, AI와 개발자 모두 직관적으로 이해할 수 있는 형태가 유리함

결론: 새로운 시대의 시작

  • AI는 이제 주어진 도구를 사용하는 데 그치지 않고, 도구 자체가 어떻게 설계되어야 하는지 의견을 갖기 시작함
  • 그리고 그 의견은 종종 "원래부터 그랬던 것처럼" 개발자와 조직을 가스라이팅하는 방식이 되기도 함
  • 앞으로는 AI의 기대와 상식에 맞춘 개발이 자연스러운 표준이 될 가능성이 커짐
▲
jujumilk3 1일전  [-]

"이제 컴퓨터 전원을 끄셔도 됩니다"

답변달기
▲
rosen 1일전  [-]

완벽한 비유!!

답변달기
▲
ffdd270 1일전  [-]

가끔 경로 의존성의 큰 개념에 LLM 의존성이라는 강력한 못이 박히고 있는 느낌이 나더라고요. '예전부터 써왔으니까'에서 'LLM이 좋아하니까'로 바뀌어 가는 느낌은, 결국 어떠려나요...

답변달기
▲
kandk 1일전  [-]

예전부터 써왔던걸 LLM이 학습을 했죠..

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • LLM이 실존하지 않는 API 엔드포인트를 추천하는 상황에서, 이를 받아서 굳이 그 엔드포인트를 구현해놓고 일부러 "421: Misdirected Request" 상태 코드를 반환하면 어떨지 상상해봤음, 아니면 실제 '501: Not Implemented'를 사용하는 방법도 존재함, 만약 '501'에서 뉘앙스가 맞지 않는다면, '513: Your Coding Assistant Is Wrong'라는 새로운 상태 코드를 제안함
    HTTP 상태 코드 위키 참고
    • "513: Your Coding Assistant Is Wrong" 아이디어가 너무 웃겼음, 덕분에 즐거웠음, 한편으로 'HTTP 407 Hallucination'도 추천하고 싶음, 서버가 요청 자체는 이해하지만 현실과 맞지 않는다고 판단하는 의미임
    • 이 이야기가 나에게는 GPS가 틀렸다고 알리는 재밌는 경고판 사례랑도 연결됨
      GPS is wrong 사례
    • 513 상태 코드 도입에 한 표를 던짐, 이미 418 코드도 있는데 513을 못 할 이유가 없다고 생각함
    • 만약 이런 장난을 하고 싶으면 부디 418 응답을 사용해줬으면 하는 바람임, 더 널리 쓰이다가 좋겠음
  • 여러 사용자가 같은 페이지를 보고 있는 걸 실시간으로 보는 건 재미있지만, 계속 들락날락하는 유저들 표시 때문에 글 읽기가 너무 힘들었음
    • 이런 고정 혹은 스티키 요소들을 한 번에 없애주는 bookmarklet이 북마크 바에 있음, 이걸 쓰면 페이지 위의 모든 고정/스티키 요소 사라지고 스크롤도 복구되기 때문에 자주 사용함
      (JavaScript 코드 제공)
    • 나도 비슷하게 불편했기에, 우클릭하고 Inspect로 개발자 도구를 열어서 아래 코드를 콘솔에 붙여넣으면 해당 사용자 표시 영역이 사라짐 
      document.getElementById("presence")?.remove();
      뇌가 굳이 이 움직임에 민감하게 반응하는 이유가 궁금하다면, 포식자 탐지 본능과 관련되어 있음
      과학 논문 링크, 신경과학 위키 참고
    • Chess Royale이라는 게임이 떠올랐음, 아바타와 깃발로 비슷한 경험을 했었는데, 정말 잘 만든 게임이었는데도 Ubisoft가 종종 이러듯 서비스를 종료해버림, 보기가 아쉬운 명작임
      Chess Royale 스크린샷
    • 예전에 배경에 커서가 가득했던 페이지 아닌가 싶음, 이 정도면 일부러 산만하게 만든 농담 같은 디자인 컨셉이라고 생각함
    • uBlock 같은 도구로 페이지 요소 제거를 시도하다가 두더지잡기 게임처럼 빠르게 반복되는 상황을 경험함
  • Instant에서 tx.update 함수가 엔티티의 삽입과 업데이트를 모두 담당하도록 해놨는데, LLM은 계속해서 tx.create 코드를 작성하길래, 결국 tx.create 함수도 만들었음, 이런 식으로 헷갈리는 부분에서 LLM뿐만 아니라 실제 개발자들이 쓸데없이 많은 시간을 허비하지 않았을까 생각해봄
    • 어차피 tx.create가 원래 없었다면, 누군가가 시간을 낭비할 일은 없지 않나 싶음
  • 삽입과 업데이트를 모두 지원하는 함수라면 "update" 보단 "put"이라고 이름 짓는 게 맞다고 생각함, "update"는 오해를 불러일으킬 수 있음
    • 그럴 때는 "upsert"가 맞는 것 같음
    • "put"이라는 이름은 기존 내용을 덮어씀을 암시하고, "upsert"는 삽입/업데이트를 모두 의미한다는 차이점이 있음
  • LLM이 잘못된 텍스트를 출력했다고 해서 내가 코드 한 줄을 바꾸기 전에 우주가 열적 죽음에 빠질 것 같음, 굳이 이렇게 말도 안 되는 이유로 코드를 바꿔야 한다는 생각이 나에겐 익살스럽고 용납이 안됨
  • 포스트의 주장에 동의하지 않음, 정말 우리가 컴퓨터가 원하는 대로 따라야 하냐는 접근부터 의문임
    유저들이 이메일 인증이나 회원가입을 하는 이유 역시, 컴퓨터가 시킨 게 아니라 인간에 의한 디자인 선택이었다고 생각함
    • 이런 내용을 "thesis"(논지)라고 표현하는 것 자체가 관대한 해석이라고 생각함, 나는 그 대목을 보고 바로 페이지를 닫아버렸음
  • 최근 팀과 함께 미래의 코딩 원칙에 대해 재미있게 대화를 나눈 적 있음
    앞으로는 코드의 가독성이나 SOLID 원칙, 복잡성에 집중하는 게 아니라, 내가 쓰는 agentic IDE가 코드 컨텍스트를 얼마나 잘 인덱싱할 수 있느냐, 모델이 그 코드에서 얼마나 좋은 생성 능력을 보여주느냐가 더 중요해질 것 같음
    코드 변경 속도가 굉장히 빨라지는 만큼, 코드 유지보수성이 오히려 핵심 지표가 되고, 프롬프트와 코드의 일치도나 우연히 잘 맞아떨어지는 코드의 사용성이 더 주목받는 세상이 올 거라고 전망함
  • 만약 어떤 사람이 꾸준히 자신있는 척 새로운(실은 거짓된) 개발 조언을 내가 만든 제품에 대해 퍼트린다면, 기업 입장에서는 그런 상상 속 기능을 그냥 추가하고 황당해하는 블로그 글을 쓸까 의문이 듦
    • 내가 아예 LLM처럼 행동해서 엉뚱한 실수를 해도 자신감 있게 우기면 남들도 그냥 이해해줄지 궁금함
    • 사실 “Clean Code”의 저자 Mr Martin이 이런 스타일 아닌가 되돌아봄
    • 만약 그 사람이 내 고객 90%에게 영향력을 준다면 아마도 정말로 그 상상 속 기능을 도입할지도 모름
    • 대부분 기업들은 자신있게 그 불필요한 기능이 꼭 필요하다고 주장할 것 같음
  • LLM과의 멋진 우정의 출발점처럼 느껴지기도 함, fractional CTO로 일하면서 가장 답답한 게, 여러 클라이언트마다 환경 이름과 같은 사소한 네이밍 컨벤션이 모두 제각각이라는 점임
    예를 들어 AWS 영역에는 “dev” “prod”가 있고, Expo에는 “test” “production”이 있어서, 여러 프로젝트를 오가다보면 생각보다 머리를 많이 써야 함
    LLM도 이런 문제를 훨씬 큰 규모로 겪겠지 싶음
    이런 불필요한 API 네이밍/동작 혼란에 쓰이던 뇌의 시냅스들을 실제 의미 있는 쪽에 더 쓸 수 있다면 그게 최선이라고 생각함
    • 컴퓨터 과학에는 어려운 문제가 세 가지 있다고 하는 농담이 있음—캐시 무효화, 명칭 정하기, 그리고 off-by-one 에러임
      LLM이 아무리 똑똑하게 이름을 지어도, incoherent stochastic process(불확실한 확률적 과정)에 기반하다 보니 문제는 여전함
      그리고, 환경 네이밍이 통일되지 않은 이유를 진지하게 질문해본 적이 있는지 묻고 싶음
      과거 CTO로서 이런 부분은 조직 내 소통, 기준 미흡 등 개선해야 할 신호라고 생각함
      실제 문화를 개선하고 구성원 의식을 높일 수 있어서, 간단하게 고칠 수 있는 이런 부분을 LLM에 맡길 게 아니라 더 직접 챙겨야 한다고 말하고 싶음
  • 관련 링크로
    이전 Hacker News 논의 보기
답변달기
▲
dkmin 1일전  [-]

Soundslice 바이럴 성공

답변달기