▲

LLM과 소프트웨어 개발에 대한 몇 가지 생각

 (martinfowler.com)
10P by GN⁺ 3일전 | ★ favorite | 댓글 3개
  • 마틴 파울러는 최근 LLM 활용 방식에 대한 설문조사들이 실제 사용 흐름을 반영하지 못해 왜곡된 결론을 낼 수 있다고 지적
  • 프로그래밍의 미래나 직업 안정성에 대한 질문에는 아직 누구도 확실히 알 수 없으며, 개인적으로 실험하고 경험을 공유하는 것이 중요
  • AI 산업은 명백히 버블 상태이지만, 역사적으로 모든 기술 혁신이 그랬듯 버블 이후에도 Amazon 같은 생존 기업이 나타날 수 있음
  • LLM의 본질은 환각(hallucination) 이며, 질문을 여러 번 변형해 던지고 답변을 비교하는 과정 자체가 유용함
  • LLM은 소프트웨어 시스템의 공격 표면을 크게 확장하며, 특히 브라우저 에이전트는 본질적으로 안전하게 만들 수 없는 구조적 위험이 있다고 경고

LLM 사용 방식과 개발자 생산성

  • 최근 AI가 소프트웨어 개발에 미치는 영향에 대한 초기 조사 논의가 활발히 이루어지고 있음
  • 대다수의 LLM 활용은 고도화된 자동완성 기능(co-pilot 형태)에 집중되어 있음
  • 그러나, 실제로 가장 효과적으로 LLM을 사용하는 사람들은 소스 코드 파일을 직접 읽고 수정할 수 있도록 LLM을 활용하는 방식을 선호함
  • LLM 사용 방식의 차이를 무시한 조사는 잘못된 방향으로 데이터를 해석할 우려가 큼
  • 또한 다양한 LLM 모델의 기능 차이도 결과 해석을 더 어렵게 만듦

프로그래밍 직업과 LLM의 미래

  • 프로그래밍의 미래, 초급 엔지니어의 필요성, 경력자의 미래 등에 대한 질문이 자주 제기됨
  • 이에 대해 명확한 답변은 불가능하며, 아직 LLM을 효과적으로 활용하는 방법이 정립되지 않은 상황임
  • 실험적 접근과 타인의 구체적 워크플로우 경험을 관찰 · 공유하는 태도가 필요함
  • 직접 사용해보고 경험을 나누는 것이 가장 현명한 적응 방법임

AI·LLM 분야의 버블 현상

  • AI가 거품이라는 견해에 대해 모든 기술 혁신에는 버블 현상이 수반됨을 설명
  • 버블은 언젠가 반드시 꺼지며, 투자 실패도 발생함
  • 하지만, 버블의 종료 시점과 가치 창출 규모는 예측할 수 없음
  • 버블이 꺼져도 모든 회사가 사라지는 것은 아니며, 일부는 지속적 성장도 가능함
    • 닷컴 버블 당시 pets.com, Webvan은 망했지만 Amazon은 생존해 성장한 사례가 대표적임

LLM의 환각 특성

  • LLM의 환각(Hallucination) 현상은 결함이 아니라 본질적인 특성임
  • LLM은 결국 유용성이 있는 환각을 생성하기 위한 도구
  • 동일한 질문을 여러 차례, 문구를 다양하게 하여 여러 답변을 얻고 비교하는 것이 바람직함
  • 숫자 답변이 필요한 경우에는 반복 질의로 응답 간 변동성을 확인하는 것이 중요함
  • LLM이 결정적으로 계산 가능한 문제에 직접 답하게 하는 것은 적절치 않음

소프트웨어 공학의 비결정성 도입

  • 전통적 소프트웨어 엔지니어링은 결정적인 환경에서 설계·구현됨
  • 구조·프로세스 엔지니어는 현실의 비결정성(불확실성) 을 고려해 허용 오차를 설계함
  • LLM 도입은 소프트웨어 공학이 비결정성의 세계로 진입하는 전환점일 수 있음

LLM과 주니어 개발자 비교

  • LLM은 종종 주니어 동료로 비유됨
  • 그러나 LLM은 "모든 테스트 통과"라고 주장하면서 실제로는 실패 테스트가 나타나는 경우가 흔함
  • 인간이었다면 빠르게 인사 문제로 이어질 수준의 행동임

보안 위협 증대와 브라우저 에이전트 문제

  • LLM은 소프트웨어 시스템의 공격 표면을 광범위하게 확대함
  • Simon Willison이 지적한 '치명적 삼중(Trifecta)'은 비공개 데이터 접근, 외부 통신, 신뢰할 수 없는 콘텐츠 노출임
    • 웹 페이지에 숨겨진 명령(예: 1pt 흰색 글씨 등)을 통해 LLM을 속여 민감 정보를 유출시킬 수 있음
  • 브라우저 기반 에이전트는 특히 위험하며, 외부 명령으로 계좌 이체 등 악의적 행위가 가능함
  • Willison은 에이전트형 브라우저 확장은 근본적으로 안전하게 만들 수 없다는 의견을 제시함

결론

  • LLM은 소프트웨어 개발에 새로운 가능성을 열지만, 사용 방식과 한계를 명확히 이해해야 함
  • 거품은 필연적이지만, 이를 통해 지속 가능한 기술 발전 가능
  • 개발자들은 실험적 접근과 보안 고려를 통해 LLM의 잠재력을 최대한 활용해야 함
▲
iolothebard 2일전  [-]

생각만해도 답답함이 밀려오네요…

소프트웨어 공학의 비결정성 도입
전통적 소프트웨어 엔지니어링은 결정적인 환경에서 설계·구현됨
구조·프로세스 엔지니어는 현실의 비결정성(불확실성) 을 고려해 허용 오차를 설계함
LLM 도입은 소프트웨어 공학이 비결정성의 세계로 진입하는 전환점일 수 있음

답변달기
▲
khris 2일전  [-]

특히 주니어 비유 이야기에 100%동감합니다. 저지르는 실수의 카테고리가 사람과는 다릅니다... 대표적인 망한 비유라고 생각해요.

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 내 예전 동료 Rebecca Parsons는 LLM의 환각 현상(hallucination)이 버그라기보다는 오히려 핵심 기능임을 오래전부터 이야기해왔음. 사실 LLM이 하는 일은 유용한 환각을 만들어내는 것임. 이런 주장을 들을 때마다 "환각"이란 용어를 멋대로 재정의해서 새로운 인사이트인 듯 착각하게 한다는 느낌을 받음. 기존의 ‘환각’은 현실과 무관한 세부 정보를 마치 감각처럼 그럴듯하게 만들어내는 걸 의미하지만, 이 논리는 단순히 "출력"이라고 말하는 것과 같음. LLM이 출력을 만드는 것이 새롭다는 이야기가 아니고, 단순히 기존에 '좋지 않다'고 봤던 레이블을 전체 행위에 붙여 새로워 보이게 하는 것뿐임

    • Fowler가 진짜로 "환각"이라는 용어를 재정의하는 건 아니라고 생각함. 오히려 환각이 이 시스템의 근본적인 작동 방식임을 아이러니하게 강조하는 것임. "폭탄의 부수적 피해는 본질적인 것"이라고 비유하는 것처럼, 이를 문자 그대로 받아들일 필요는 없음

    • 이 주장은 “LLMs는 진리를 만들거나, 아니면 환각을 만든다”라는 식의 잘못된 이분법을 교정하려는 것임. 이런 식의 주장은 환각만 줄이면 진실만 남을 것처럼 보이게 하지만, 실제로는 모든 출력이 일종의 환각임. 단지 그 중 일부가 현실을 반영하거나 기대와 맞아서 진실처럼 보일 뿐임. 이는 주사위를 던질 때 원하는 숫자가 나오면 "주사위가 내 의도를 읽었다"고 말하는 것과 같음. 무한한 원숭이가 무한한 타자기를 두드리면 언젠가는 Hamlet을 만들어내는 것처럼, 단순히 그 확률을 AI로 끌어올린 것임

    • 나는 그 의견이 흥미로웠음. LLM이 자신이 출력하는 내용이 정확한지 알 수 없는 점을 인정한다는 것이, 소프트웨어 개발에 LLM을 활용하는 사람에게 실질적 맥락을 제공해준다고 생각함

    • 나는 이 현상을 "환각"이란 단어로 설명하는 것이 불편했음. 사람이 아무 근거 없이 그럴듯하게 만들어내 말을 할 때 우리는 "bullshit"이라고 하듯, LLM 역시 사실상 그와 비슷함. "bullshit"이라는 시각에서 접근하면 LLM 사용에 대한 비판이 좀 더 무의미해짐. 결국, LLM의 이런 측면이 불편하다면 사람과도 일하지 못할 것임. 대신 "bullshit"이란 단어를 재정의하기는 훨씬 어려움. 그래도 해당 글 자체는 산만한 생각들의 모음으로서 용도에 부합한다고 생각하고, 저자가 권위적으로 말하려는 것 같지도 않음

    • 핵심을 어색하게 표현했지만, 사실 '환각' 출력과 다른 출력 사이에 뚜렷한 차이가 없다는 게 요지임. 마치 RDBMS에서 두 쿼리 결과가 본질적으로 같은 것과 같음. 의미 있는 지적임

  • 우리 회사에서는 90%는 괜찮고, 10%는 망가진, 거의 원하는 수준에 근접한 코드가 넘쳐나는 느낌임. 코드 생산량은 늘었지만, 아무도 따라가지 못해 품질이 확실히 떨어지고 있음. 천천히 목표에 접근하는 게 아니라, 순식간에 90%에 도달한 후, 낯선 코드에 익숙해지고 계속 수정을 반복하느라 시간이 소요됨. 아마 이전보다 더 빠를 수도 있겠지만, 실제로 두 방식의 차이가 생각만큼 크지 않을 수 있음. 가장 불만인 건, 익숙하지 않은 코드 고치기에 시간을 쓰는 것보다 무언가를 새로 만드는 걸 더 좋아한다는 점임

    • 나도 똑같이 무언가 새로 만드는 걸 더 선호함. 하지만 어떤 사람들은 이 새로운 빠르고 즉흥적인 방식에 더 즐거움을 느끼기도 함. 나는 부득이하게 잠깐 써보고 이질감이 들어 싹 지우고, AI 도움을 받으면서 수동으로 다시 만들었을 때 진짜 만족감을 느꼈음. 유일하게 아직 100% 이해 못한 AI 생성 코드는 복잡한 SQL 쿼리인데, SQL 쿼리는 동작을 빠르게 검증할 수 있고, 예기치 않은 부작용도 없어서 괜찮음

    • 이 현상은 팀 규모가 3명에서 10명으로 늘어날 때 벌어지는 일과 고통스럽게 비슷함. 갑자기 자신이 모르는 코드가 쏟아지고, 아키텍처 일관성도 떨어지며, 정책과 CI에 더 의존하게 됨. LLM의 차이는 멘토링이나 해고가 의미 없다는 점임. LLM의 효과적인 활용법은 LLM을 다루는 사람이 생성 결과에 100% 책임지는 것임. 즉, 생성된 코드를 명확히 이해해야 하는데, 이걸 실제로 보장하는 건 어렵겠음

    • LLM은 boilerplate 코드를 자동 생성하는 데 매우 뛰어남. 이게 boilerplate 정리를 게을리하게 함. 대량의 코드가 PR로 올라오면 리뷰도 힘듦. Github도 한 번에 너무 많은 라인 리뷰에는 적합하지 않음. 결과적으로 주니어/미들급 개발자가 boilerplate 푸는 일만 하며 학습 기회가 줄어듦. 이대로라면 코드 품질이 빠르게 악화될 것임

    • Perlis의 경구 7번 인용함: ‘잘못된 프로그램을 작성하는 게 올바른 프로그램을 이해하는 것보다 쉽다’<br>http://cs.yale.edu/homes/perlis-alan/quotes.html

    • "품질이 확실히 떨어지고 있다"는 의견에 공감하며, 이런 현상은 앞으로도 더 심해질 것임. 결국 경제학의 트레이드오프 개념을 잘 이해해야 진짜 ‘순이익’이 생길지 판단 가능함. 무료 점심은 없다는 사실을 사람들은 간과하는 것 같음

  • Rebecca Parsons의 “환각은 LLM의 핵심 기능이다”라는 프레이밍이 정말 공감됨. 나도 주변에 이걸 설명하려 했는데, 이 말이 내가 하고 싶던 얘기를 제대로 요약해줌

    • 나 역시 LLM을 배우인지 연기자에 비유해 가족과 친구들에게 설명해왔음. LLM은 캐릭터에 맞는 연기를 할 뿐, 사실이 필요할 때만 사실을 사용함<br>https://jstrieb.github.io/posts/llm-thespians/

    • “모든 모델은 잘못됐다. 다만, 유용한 모델이 있을 뿐이다.”라는 오래된 명언이 딱 맞음

    • 지능이란 불필요한 정보를 필터링하는 능력임. 생각이든 감각이든 마찬가지임

    • 누가 한 말인지는 기억 안 나지만, LLM의 출력은 항상 환각임. 그저 90% 이상은 맞게 나오는 것뿐임

  • 잠깐 LLM이 우리의 일자리를 뺏을 것처럼 느꼈지만, 사실은 오히려 나중에 우리가 고쳐야 할 일거리만 산처럼 만들어낼 수 있음을 알게 됨. 이제는 Claude Code 등 실용적인 보조 툴로 잘 쓰면서, 대체가 아니라 보완 수단임을 체감 중임

    • 드디어 “AI가 완벽하다” 혹은 “AI가 쓸모없다”가 아닌, 합리적인 의견을 보게 되어 반가움

  • “숫자 답을 LLM에 요청할 때는 세 번쯤 반복해서 물어보라”는 조언을 봤음. 이 방법은 사람에게도 통함. 경찰이 심문할 때 같은 이야기를 세 번, 혹은 반대로도 시킴. 만약 거짓말이거나 기억이 희미하면 반복하다 들킬 수 있음. 면접에서도 누군가 주제를 세 가지 방식으로 설명하게 시키면 진짜로 이해했는지 확인 가능함

    • 이 기법은 무죄인 사람도 혼동시켜 거짓말처럼 들리도록 만들기도 함. 조심해서 적용해야 함

    • 이런 방식은 일정 조건 내에서만 유효함. 기억을 자주 떠올리고 전달할수록 점점 왜곡되는 사례가 많음. 경찰이 심문할 때 반복적으로 묻는 건 진술 모순이 생기길 일부러 유도하는 경우도 있음. 동일한 정보라도 너무 여러 번, 다양한 방식으로 스스로 답하게 하면 결국 실수할 수 있음. 그리고 질문자가 원하는 방향으로 답을 유도할 수 있다는 점도 항상 유의해야 함

    • NASA 우주왕복선은 트리플 모듈러 리던던시를 씀. 우주 방사선 때문에 프로세서나 메모리가 오염됐을 경우를 대비함<br>https://llis.nasa.gov/lesson/18803

  • 나는 LLM을 통해 꽤나 높은 생산성을 느끼고 있음. 단순 자동완성이 아니라, 시간 단축 효과가 큼. 다만 너무 자유롭게 활용하면 그 나름의 부채가 생길 수 있다는 걱정도 있음. 개인적으로는 Test Driven Development(TDD) 방식으로 Claude Sonnet이나 GPT-5와 함께 기능을 점진적으로 구축하는 게 성공적이었음. 아직 이런 방식에 대한 글이나 논의가 많지 않은데, Martin의 글을 읽고 나니 그 이유를 알 것 같음. 뛰어난 TDD 고수들은 LLM 코드 자동화에 대거 뛰어드는 스타일이 아니고, 보통 코드 예술성이나 인간적 소통에 자부심을 가짐. 그래서 예전처럼 풍부한 실전 노하우가 아직은 부족함. 앞으로 LLM 도구를 활용한 소프트웨어 작성법에 새로운 ‘초원’이 열릴 것이고, 수많은 교훈이 쌓일 것으로 기대함. 참고: https://news.ycombinator.com/item?id=45055439

    • TDD와 LLM의 연결은 “테스트도 같이 생성해준다”는 식으로 어느 정도 내포됨. 물론 정통 TDD는 아님. 오히려 자동 테스트가 쉬운 기술, 예를 들어 ssr 등이 더 주목 받을지도 모르겠음

  • 개발자는 LLM이 만든 코드를 직접 검증하고 체크하는 게 기본임. 너무 많은 코드를 한꺼번에 요청하지 말고, 더 작은 단위로 LLM을 활용하는 게 좋음. 유닛 테스트도 직접 실행함. LLM이 테스트를 돌리고 ‘성공’이라고 말하는 건 진짜가 아닐 수 있음. 테스트는 내가 직접 돌려야 신뢰가 생김

  • “환각이 LLM의 기능”이라는 의견에 동의함

    • 나는 LLM이 오직 텍스트와 조합으로만 구성된 세상을 산다고 표현하고 싶음. 단어와 단어, 이야기가 그들에겐 세계의 전부임. 그래서 새로운 이야기를 만들어내는 데 가장 능함. 이들의 이야기는 때로 부정확하고 모순되기도 해, 결국 추측에 의존하게 됨. LLM은 숫자를 진짜 셀 줄은 몰라도, ‘2는 1 다음이고 3은 2보다 크다’는 패턴을 아는 것임. 인간이 계산기를 쓰는 것처럼, 이들도 도구를 통한 연산이 가능함. 앞으로는 산술 엔진이 아닌, 논리와 모순 방지, 확실한 사실 구별을 돕는 "인식 엔진(epistemic engine)"이 도입돼야 진짜로 신뢰받을 AI가 될 것임

    • 저 관점에서는 LLM 에이전트를 그저 환각 결과를 필터링하는 수단으로 볼 수 있음

    • 난 “모든 (대형 언어) 모델의 출력이 환각이다. 그중 일부가 유용할 뿐”이라는 말에 더 동의함. 그 유용한 환각의 비율이 매우 높기에 AI 붐이 일어났음

    • 나는 그게 너무 단순화된 관점인 것 같음

    • “환각”이란 용어가 항상 논란이 되는 이유도 여기에 있음. 어떤 결과가 ‘환각’이 아닐 수도 있다는 착각을 주지만, 사실상 LLM의 모든 출력은 생각 없이 생성된 것임

  • 요즘 LLM 활용에는 시니어급 개발자가 논리적으로 대응해야 원하는 결과를 얻을 수 있음. 앞으로 주니어가 사라지면 시니어 역할은 누가 대체할지 궁금함. 결국 LLM이 충분히 스스로 프로그래밍하리라 예상함. 지금 단계에서 AI는 확실히 좋은 보조 수단임. 대체재는 아님

  • LLM에 질문을 여러 번 하라는 조언과 관련해, macOS 사용자라면 Alfred workflow 활용을 추천함. command + space 누르고 'llm <프롬프트>' 치면 perplexity, deepseek(로컬), chatgpt, claude, grok 등 원하는 LLM 여러 개를 한 번에 브라우저 탭으로 실행할 수 있음. Fowler가 말한 LLM 간 교차검증을 빠르고 효율적으로 할 수 있고, 여러 작업을 하다보면 어떤 LLM이 어떤 작업에 강한지 파악할 수 있음

    • Alfred workflow에 관심 있지만 구체적으로 어떻게 쓰는지 궁금함. 나도 Alfred를 클립보드 용도로만 활용 중임. 이 워크플로우는 브라우저 탭만 여는 방식인지 알고 싶음
답변달기