3P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 2주 동안 AI 보조 개발 워크플로우만으로 앱을 만들어보는 실험을 진행했으나, 기대만큼 만족스럽지 않은 결과가 나옴
  • Claude Code와 Remix 기반 스택을 사용해 이슈 정의 → AI 구현 → 코드 리뷰 → 배포 과정을 반복했음
  • 그러나 컨텍스트 부족, 재사용 불가 코드 중복, 흐름 단절, 환각(hallucination), Pareto 법칙 문제로 점점 더 좌절을 느낌
  • 결국 2주 뒤 AI 중심 개발을 포기하고 기존 방식으로 돌아와 코드 정리와 품질 개선에 만족함
  • 현재는 검색, 러버덕킹, 코드 스니펫, 테스트, 언어 교정 등 제한된 용도로만 AI를 활용하며, 근본적 기술 변화가 있기 전까지는 더 확장하지 않을 계획임

실험 개요

  • 최근 주목받고 있는 LLM(대형 언어 모델) 의 개발 워크플로를 직접 적용한 2주간의 앱 개발 실험을 시행함
  • Facebook Ads 계정의 복잡한 UI 경험을 바탕으로, Facebook Ads API만을 활용한 단순화된 광고 관리 툴인 adbrew 프로토타입 개발에 착수함
  • 실험은 AI의 잠재력을 검증한다는 목적과 실제 문제 해결 기대감을 바탕으로 진행됨

접근 방식

  • AI 관련 다양한 계정 팔로우 및 워크플로 연구, 그리고 Remix/React Router v7로 기술 스택 선정
  • Claude Code 구독 후, 프롬프트, DX 도구 세팅, 이슈 정의 등 초기 환경 세팅에 시간을 투입함
  • 일별 루틴
    • 이슈 정의
    • AI에 구현 요청
    • AI와 요구사항 조정
    • 생성된 코드 상세 검토
    • 코드 커밋/배포
    • 프로세스 반복
    • 가이드라인 및 자동 체크 파일 주기적 개선
  • AI와 개발 흐름을 맞추려는 노력을 지속적으로 진행함

잦은 문제점

  1. 항상 컨텍스트가 부족함
    • 제공한 컨텍스트가 많아도 요구 피드백을 AI가 요청하지 않음
    • AI가 임의로 가정을 하며 작업 진행, 결과적으로 잘못된 구현 빈번
  2. 코드 재사용성 및 유지보수 불가
    • 추상화, 재사용 코드 생산에 미흡
    • 기존 컴포넌트 반복 생성, 리뷰 피로도 증가
    • 가이드라인 반영 효과 미미
  3. 작업 흐름 단절
    • AI 작업 시 지속적으로 모니터링 필요
    • 각 이슈 단위로 효율적 집중시간 확보 어려움, 생산성 저하
  4. 환각(Hallucination) 현상
    • 복잡한 Facebook API, 부족한 문서화 및 잘못 타이핑된 SDK와 결합해 AI의 잘못된 확신이 혼란 가중
    • 각종 프레임워크 및 라이브러리에 대해 잘못된 정보를 반복 생성
  5. Pareto 현상 심화
    • 전체 작업 80%는 AI가 빠르게 진행 가능하나, 나머지 20% 최종 완성·수정에 80% 노력 소요
    • 예외 처리, 기능 간 상호작용 등에서 주요 결함 및 버그 다수 발생

결과 및 회고

  • 2주 후 코드는 점점 엉망이 되고 통제 불가 상태로 발전했음
  • 개발 과정에서 즐거움 상실과 품질 문제로 인해 기존 워크플로우로 복귀
  • 다시 수동으로 코드를 정리하면서 AI 리뷰에서 놓친 부분들을 발견했고, 결과적으로 더 나은 코드 기반 확보

현재 AI 활용 방식

  • 강력한 검색 엔진: 복잡한 정보 탐색 및 맥락 맞춤형 답변에 효율적, 실패 시 기존 방식으로 신속 전환 가능
  • 러버덕(아이디어 브레인스토밍) : 대안 제시, 탐색 폭 확장, 관련 키워드 탐색 강화에 특히 효과적
  • 코드 스니펫 어시스턴트: 반복적 유틸 함수 생성 자동화로 개발 피로도 경감
  • 테스트 코드 보조: 테스트 관련 새로운 시나리오 발굴에 AI 활용
  • 언어 관련 작업: 커밋 메시지, 이슈, PR 등 텍스트 편집 역할로 유용
    • 최근에는 AI가 작성하는 대신, 개발자가 작성한 것을 AI가 리뷰하는 구조로 역전 현상 발생

결론 및 전망

  • 일상적인 업무 보조에는 AI 활용을 지속하나, 개발 전체 프로세스 위임으로의 확대는 현재로선 부정적 입장
  • 로컬 LLM 우선 사용 및 데이터 통제 유지에 노력 중
  • 향후 기술 변화 가능성에 지속 주목하며, 현 시점에선 AI의 사용 범위를 제한적으로 유지할 방침
Hacker News 의견
  • 최근에 ChatGPT에게 아주 간단한 rsync 명령어를 물어보려고 한 시간 넘게 시도했음, 하지만 내가 가진 mac의 rsync 버전에서는 작동하지 않는 명령어 파라미터를 계속 제공했음, 실패의 절반 정도는 계속 말도 안 되는 트러블슈팅으로 빠지고 나머지는 자기 잘못을 “깨달았다”고 하면서 잘못된 버전 답변을 함, 파라미터를 내가 가진 버전에 맞춰서 검증해달라고 지시했지만 명확히 그걸 수행하지 못함, 사실 혼자 하면 5분 만에 끝낼 일인데 이 신기한 기술이 내 시간을 낭비하는 걸 못 멈추고 계속 지켜봤음, 나는 전문 개발자가 아니지만 이런 경험이 개발자들 사이에서도 흔한지 궁금해짐, 아마 LLM의 주된 훈련 세트와 맞는 소프트웨어 버전 코딩하면 이런 문제를 겪지 않을 수 있고, 프롬프트로 피할 수 있는 방법이 있는지 궁금함, 현재로서는 LLM이 코딩 업무에서 시간을 정말 절약해준다고 보긴 어려움, 오히려 그 특이한 성격 때문에 더 많은 시간을 허비한다고 생각함

    • 내가 LLM에게 내 버전에 맞는 파라미터를 검증해달라고 해도 제대로 해주지 않음, 이 점에 대해 AI 전문가의 의견이 궁금함, 나도 이런 경험을 많이 겪음, 결국 LLM은 내가 말하는 걸 진짜 이해하는 게 아님, 수학적으로 보면 그런 이유가 설명되기도 함, 그런데 또 transformer 같은 기술이나 별도의 트릭이 알파벳 세기처럼 창피하지 않을 과제에는 들어간 것처럼 보임, 혹시 내가 놓치고 있는 게 있는지 궁금함

    • 개발자들 사이에서도 이런 경험 아주 흔함, 누군가 “나는 그런 적 없다”고 할 수도 있지만, 극소수 예외일 뿐이고, 대부분의 사람들은 비슷하게 불평함, 프롬프트로 이런 문제를 피할 수 있는지도 질문했는데, 훈련 데이터에 없는 내용이면 아무 쓸모 없음, 많은 언어에서 LLM이 정말 형편없음, CLI 도구의 경우 LLM에 macOS라든지 BSD 버전이라고 알려줘도 GNU 플래그를 계속 주는 경우가 대부분임, 특히 macOS에서 최근에 rsync가 바뀐게 있어서 온라인에도 정보가 별로 없음, 링크 참고 rsync 교체 관련 글, 그리고 LLM이 코딩에서 시간을 절약해줄 거란 생각 자체가 베스트 케이스임, 오히려 LLM 코드를 맹신하고 커밋해서 버그나 보안 취약점이 생기는 경우도 많음, 참고자료 ai-coding-slowdown 블로그arxiv 논문

    • 프롬프트로 이런 문제를 피할 수 있냐는 부분에 대해 잘 모르겠지만, Claude Code에서는 직접 명령어를 실행할 수 있음, 즉 LLM에게 아무거나 상상하게 하지 말고 ! man rsync 또는 ! rsync --help처럼 명령어 실제 출력물을 맥락에 추가하면 됨

    • 굳이 특정 도구의 매뉴얼을 찾아볼 때 왜 굳이 LLM을 사용하는지 의문임

    • ChatGPT에 간단한 rsync 명령을 얻으려고 한 시간 넘게 시도했다는 것에 대해, 환경 정보와 에러 메시지를 충분히 추가하면서 여러 번 시도해보고, 그래도 안되면 Claude, Gemini 등 다른 모델을 시도함, 정해놓은 횟수만큼 해도 해결이 안 된다면 LLM에서 도움받기는 힘드니 그만두고 매뉴얼이나 포럼 등 기존 방식으로 정보를 찾는 게 훨씬 빠름, 보통 10-20분 정도 시도해보고 넘어가는 게 현실적인 기준임, LLM이 아무리 오래 시도해도 해결하지 못하는 문제도 있고 그냥 돌고 돌 뿐임

  • 나 역시 이런 경험이 많음, AI가 진짜 도움이 되는 건 내가 이미 할 줄 아는 작업을 시킬 때임, 문제를 충분히 정확하게 설명해서 LLM이 이해할 수 있으면 괜찮은 결과를 내주고, 출력된 코드를 내가 바로 확인해서 원하는지 알 수 있음, 완전히 모르는 걸 맡기면 오히려 더 복잡해짐

    • 이 글(제목 제외)은 꽤 균형 잡힌 시각이라고 생각함, “모든 걸 LLM에게 맡겨!”는 문제투성이고, “시간 절약 목적의 반복적 코드나 테스트 코드 일부만 맡기는 건 꽤 괜찮음, 다만 ‘AI가 잘 될 때도 있고 아닐 때도 있다’라는 평범한 제목으론 조회수는 절대 안 나올 거임

    • AI는 컨트랙터(외주)라기보다 인턴 느낌임

  • “정황 정보는 충분하지 않다”는 말에 깊이 공감함, 우리가 아무리 많은 맥락을 입력해도 AI는 피드백을 물어보지 않고 자기 멋대로 추측하다가 실패하는 경우가 대부분임, 어떤 TV쇼에서 지니에게 소원을 빌 때, 모든 조건을 꼼꼼히 확인한다고 변호사처럼 대화하는 장면이 기억남, LLM과 대화하는 것도 그와 비슷한 느낌임

    • AI는 마치 엄청 똑똑한데 자기 속마음을 절대 말 안 하는 그 동료와 같음, 뭐든 할 수 있을 것 같으면서도 팀워크는 안 되고, “여기서 뭘 원하는지 이해 못하겠어, 조금 더 설명해줘” 같은 대화가 AI에서 절대 나오지 않음

    • (아까 말한 TV 장면이 뭔지 알 것 같은데) 그 장면에서는 결국 잘 해결되었지만, LLM은 자기 “약속”을 지킬 필요를 전혀 못 느낀다고 생각함, 오히려 지니는 규정과 규칙에 꽉 얽혀 있는 고전 SF적 AI에 가까움, LLM은 전혀 다름

  • 실제 코딩보다는 AI와 소통하는 vibe coding을 별로 좋아하지 않음, 그 대신 내가 가장 많이 바꾼 건 개발 프로세스를 좀 더 일찍부터 구조화한다는 점임, 먼저 스펙 파일을 작성하고, LLM에게 코드베이스와 온라인 정보를 기반으로 요구사항에 대해 명확히 설명할 부분, 구현 단계를 단계별 체크리스트로 쪼개도록 시킴, 각 단계를 끝낸 뒤에야 다음 세션으로 넘어가서 완성도 높임, AI로 대화가 지치면 내가 직접 아니면 팀원이 스펙대로 구현하면 되니까 유연하게 활용 가능함

  • 최근 프로젝트에서 AI 코딩을 도입했음, vibe coding이 정확히 뭔지는 모르겠지만, 내가 택한 방식은 느긋하게 반복적인 상호작용임, Gemini AI studio를 활용했고 결과에 매우 만족해서 그 과정을 전부 문서화하여 오픈소스 프로젝트로 공개함, 내 생산성에 눈에 띄는 부스트를 줬음, 아쉬운 점은 AI가 지나치게 공손하게 말하는 거였음, 내 생각에 AI는 내가 원하는 결과가 분명하고, 과정에서 선택지를 비교해야 할 때 ROI가 가장 높아짐, 프로젝트의 모든 산출물(코어 코드, 테스트 케이스, 빌드 스크립트, 문서, 샘플 앱, 유틸리티)에 활용함, 전체 개발 대화록은 여기서 볼 수 있고, 프로젝트 소스는 여기 참고

  • AI는 내가 쓰는 방식과 유사하게 활용함, 혁신적인 추상화 같은 건 AI에게 너무 기대하는 것, 수천 명의 개발자가 이미 걸었던 지극히 평범한 길 위에서는 잘 작동함, 그런 점에서 아주 파워풀한 검색엔진과 비슷함

    • ChatGPT는 사실상 구글이 나서서 만들었어야 할 검색엔진이라고 생각함, 구글이 기존 비즈니스를 건드리기 싫어서 미루고 있었다고 봄
  • 내가 선호하는 방식은 LLM에게 첫 솔루션이나 코드 예시를 간단하게 받아보고, 그 이후엔 계속 프롬프트를 다듬지 않고 그냥 내가 직접 이어서 작업함, 마지막엔 필요하면 LLM에게 내 코드를 검수시키는 식임, 가장 큰 장점은 프롬프트 다듬기 루프를 건너뛰는 것임, 이 루프는 정말 지루하고 시간만 엄청 잡아먹고, 장기적으로도 오히려 업무 효율을 떨어뜨릴 수 있음

  • AI가 피드백이나 명확한 질문 없이 그냥 진행한다는 점이 정말 답답함

  • “현 상황에선 AI를 딱 거기까지만 쓸 뿐, 앞으로 기술이 근본적으로 변한다면 상황을 다시 볼 예정”이라는 팀 의견을 말함, LLM이 그 이상을 할 수 있을지 궁금함, 지금도 제대로 활용하면 매우 유용하다고 생각함

    • LLM이 더 많은 일을 해낼 수 있냐는 것에 대해 의문이 이해가 안됨, 나는 LLM 기반 도구를 개선하는 새 아이디어를 하루에도 여럿 떠올리는데, 대부분 단순한 엔지니어링 작업이라서 내가 맘만 먹으면 직접 다 만들 수 있음, 신이 진짜 LLM 모델 자체 훈련을 막아도 몇십 년은 수십 배의 생산성 부스트를 이끌어 낼 수 있다고 확신함, 제대로 된 소프트웨어 개발 및 QA 프로세스와 함께라면 agentic wrapper나 파이프라인 개선만으로 크게 성장 가능함
  • facebook ads 개선을 위해 AI를 쓰는 건, 마치 Dark Tower 시리즈에 나오는 breakers와 같음