LLM으로 몇 달간 코딩한 후, 다시 내 두뇌를 쓰기로 했어요

• 고성능 LLM을 활용하여 인프라를 구축했으나, 코드 품질과 유지보수성에서 큰 문제점이 드러남
• AI의 비효율성과 일관성 없는 결과 때문에 직접 코드 이해와 조사, 역량 강화 필요성을 느낌
• 프로젝트를 빠르게 끝내려는 목적이 오히려 코드 구조의 혼란, 중복, 비일관성을 초래함
• 이제는 AI를 단순 반복작업이나 코드 변환 등 보조 용도로만 제한적으로 활용함
• AI 활용이 코딩 감각과 문제해결 능력 저하로 이어질 수 있으므로, 적극적으로 두뇌 사용을 우선시함

---

서론: LLM을 활용한 인프라 구축 시도

• 기존 PHP+MySQL 인프라가 한계에 이르러 새로운 인프라 필요성 인식
• Go와 Clickhouse 선택, AI와 함께 인프라 설계 및 계획 수립 진행
• Claude 등 LLM에게 베스트 프랙티스 및 아키텍처에 대해 문의하며 자세한 계획 도출
• 기능 완성과 빠른 릴리스를 목표로 코드 개발을 속도 중심으로 전개

개발 과정과 문제점 발생

• Cursor 등의 툴을 사용해 AI가 코드를 작성, 본인은 빌드와 테스트 중심으로 작업 진행
• 코드베이스 정돈이 미흡해도 우선적으로 요구되는 데이터 제공에 집중
• 개발을 빠르게 진행했음에도 시간이 지날수록 계속해서 새로운 이슈가 발생함
• Go와 Clickhouse에 대한 경험 부족으로 인한 어려움, AI가 내놓는 수정안이 연속된 문제를 야기함

코드 품질 문제와 한계 체감

• 제작된 코드 전체를 면밀히 검토하는 코드 리뷰 시간 마련
• 같은 기능을 수행하는 파일들이 이름·파라미터·구조 등에서 불일치 및 중복, 혼란 많음
  • 예시: "WebAPIprovider"와 "webApi"가 동일 파라미터를 의미하지만 따로 존재함
  • 동일 메소드가 여러 파일에서 재정의되는 현상
  • 설정 파일 접근 방식 일관성 결여
• 실제로는 여러 주니어 개발자가 소통 없이 동시에 작업한 듯한 결과물 생성

LLM 문맥 피드백의 한계와 전략 변경

• 컨텍스트 정보를 충분히 제공하고, Gemini 등 대형 윈도우 LLM을 활용했음에도 불구하고 일관적인 개선 미흡
• 인프라와 언어에 대한 자기주도적 학습 및 문서, 동영상 자료 등 추가 학습 필요성 인식
• 클린 코드 작성과 조직화를 위해 AI 주도 개발에서 자율적 코드 설계로 방향 전환

AI 보조 활용 방식 변화

• 반복적인 리팩터링과 코드 정비로 직접적인 코드 이해와 관리에 집중
• AI의 역할을 코드 자동 변경, 파라미터 일괄 변경, 코드 변환 등의 단순 반복 작업에 한정
• 새로운 기능 기획, 코드 초안 작성 등은 직접 사고 후 LLM에 검증 or 보조 역할 부여
• AI를 “조수”로 두고, 계획 및 구조 결정권은 개발자 자신이 역임

사고력 저하 우려 및 변화된 태도

• AI가 있으니 두뇌 사용 빈도 감소, 계획이나 사고 과정을 AI에 의존하게 된 현실 인식
• 펜과 종이, 직접적인 설계, 직접 코딩을 통해 개발자 역량과 문제 해결력 회복 추진
• AI로 인해 코딩 감각 저하 위험 있음에 경각심

비개발자 및 ‘Vibe Coding’에 대한 우려

• 비개발자가 LLM만으로 개발을 진행할 때, 복잡·혼란스러운 코드와 오류 반복 현상이 더 심각
• ‘노코드’ 툴보다 AI 기반 개발이 구조 파악에 더 큰 어려움 야기 가능성
• 파악 불가능한 코드 벽, 계속되는 오류-수정-재발 과정에서 근본적 난이도와 위험성 언급

AI 활용 현실에 대한 단상 및 커뮤니티 분위기

• AI 상용화, 벤치마크, 인플루언서, AI 회사의 과대광고 및 성능 불일치에 혼란감 표출
• 동일 모델·프롬프트에서 완전히 다른 결과 나오는 일관성 결여
• 고성능 최신 LLM조차 클릭하우스 수억 행 쿼리 등 실제 복잡 업무를 완벽하게 소화하지 못함
• 복잡한 세팅 및 비효율적 워크플로우 강요 상황에서, 그 자체가 ‘시간 낭비’일 수 있음
• AI가 굉장한 듯하지만 아직까진 ‘좋지만 뛰어나진 않은 도구’라는 신중한 시각

결론

• 최신 기술과 AI에 여전히 큰 기대와 흥미 보유
• 그러나 현재 시점에서는 올바른 역할과 한계를 이해하고, AI를 보조적이거나 학습용 도구로 제한적으로 활용하는 것이 현명한 전략임
• AI 사용으로 인한 개발자 역량 저하 경고와 함께, 본인의 사고와 계획 중심으로 돌아감
• ‘코드 작동 원리와 구조’를 이해하지 못한 상태에서 AI에 전적으로 의존하는 개발은 실패 가능성 높음

[GN⁺]

Hacker News 의견

• 나는 LLM에 대한 "올인" 마인드를 이해하지 못하는 입장임. 나는 iOS 개발자로 일하고 있는데 평소처럼 일함. 이제는 LLM을 이용해 디자인 기반 임시 뷰 같은 것만 빠르게 만듦. 앱 핵심이 아니라 신규 기능이나 위젯 설치 안내 등 부수적인 화면임. 예전엔 복잡도에 따라 30~60분 걸렸던 걸 이제 5분 만에 끝냄. 웹 개발이 싫은데 LLM은 그런 부분에서 꽤 쓸만함. 큰 변경 작업도 LLM 활용 후 직접 검토하고 git에 커밋함. 근데 LLM만 믿고 흐름을 통제하지 않으면 몇 시간 동안 무너졌다가 처음부터 다시 하는 경우가 생김. 균형 잡힌 접근이 중요하다고 생각함

  • 도구의 유용성은 사람과 문제에 따라 달라짐. 예를 들어 10년 경력의 파이썬 개발자가 거대한 레거시 코드와 완벽히 맞춘 IDE로 안정성 위주의 작업을 한다면 LLM이나 Cursor 같은 도구는 오히려 방해가 될 수 있음. 반면, 1년 차 JS(React, Nextjs 등) 개발자가 새로운 아이디어를 자주 프로토타입화하고 IDE 선호도 없고 실험에 열려 있다면, LLM과 Cursor는 즉각적으로 역량을 크게 향상시켜줌

  • 나도 여러 분야(iOS, 웹 개발 등)를 하는데, LLM의 결과는 두 분야에서 상당히 다름. LLM이 출력한 코드가 제대로 컴파일조차 안 될 때가 많음. 심지어 존재하지 않는 API를 알려준 적도 있음. 반면 Nextjs 앱은 한 번에 잘 만듦. 결국 LLM의 학습 자료 차이에서 오는 결과임

  • LLM 기능을 과신하는 건 자연스러운 일임. 나도 스택오버플로 대체와 짧은 코드 스니펫 얻는 목적으론 꽤 오래 써봤음. 점점 더 많은 책임을 맡기다가 문제를 겪고, 한계를 깨달아 다시 아이디어와 조언 위주로 LLM을 쓰게 됨. 많은 이들이 비슷한 과정을 거친다고 생각함

  • 나도 비슷하게 느끼는 입장임. LLM을 전적으로 신봉하지 말고 반복적이고 지루한 작업(작은 함수, 인터페이스 구현, 문서화 자동화 등)에만 활용함. 이를 통해 많은 시간을 아꼈고 업무 효율도 높아졌음

  • iOS 개발에 있어 LLM의 성능은 들쭉날쭉임. Swift, SwiftUI가 너무 빨리 변하고, 공식 문서도 부실한 것이 한 원인임. 간단한 뷰 생성엔 유용하지만, 비동기 처리나 복잡한 비즈니스 로직에선 쉽게 무너짐. 그래도 방향 제시에 도움은 되지만 잘못된 결과(헛소리)에 빠질 위험도 큼

• LLM 옹호자들은 대부분의 병목이 코드 생성에 있지 않다는 사실을 간과함. 코드를 빠르게 만드는 것만큼 코드 리뷰, 테스트, 코드베이스 이해에 두 배 이상의 시간 투입이 필요함. 장기적으로 유지·보수(버그 수정, 리팩토링 등)를 하려면 반드시 이런 과정을 거쳐야 함

  • 코드 읽기는 쓰기보다 훨씬 어려워서, 실제로 더 많은 시간을 코드 이해에 씀. 그런데 만난 한 CEO는 맥락 정보를 도구로 제공해 개발자는 코드를 읽지 않아도 된다는 식으로 주장함. AI가 엔지니어링의 본질을 바꾼다는 논리임. 솔직히 좀 혼란스러움

  • LLM이 내 코드를 다시 설명해줄 땐 꽤 쓸만하단 느낌을 받음

  • 누군가들 자동화된 코드 에디터를 극찬할 때마다 같은 생각을 하곤 함

  • 현실적으로 대부분의 개발자는 의존성 라이브러리의 내부 구현엔 크게 신경 쓰지 않음. 인터페이스 작동 여부만이 중요함. LLM이 만든 코드나 npm 패키지, rust crate를 들여오는 것의 차이는 큼. 문제점도 알지만 이 관행이 널리 쓰이는 이유가 있음

• 나도 비슷하게 생각함. 요즘은 새로운 기술을 배우거나 표준 API(특히 boto3)용 클라이언트 코드 생성에 LLM을 주로 사용함. docker compose 파일 변경을 도와주는 Windsurf도 써봤는데 제대로 동작하지 않아 실망했음. 프로토타입은 만들 수 있겠지만 그게 전부는 아님. LLM은 devops 영역에서 판도를 바꿨다고 생각함(이제 API 세부 정보는 덜 중요해짐). 그렇지만 중요한 결정은 여전히 내가 해야 한다고 봄. 인터페이스 정의는 직접 하고, LLM에 구현만 맡기는 식으로 활용. 이게 "분위기 타는 코딩"은 아니라고 생각함

  • 나도 비슷한 경험을 했음. Cursor, Copilot은 스마트 자동완성, 짧은 함수 생성, 빠른 프로토타입 등에는 환상적임. 하지만 일주일 동안 LLM 주도 코드베이스로 작업하다 보니 구조가 엉망진창이 되었음. 진짜 발전은 언젠가 올지도 모르지만 현재(2025년 5월)는 이 수준임

• 코드 리뷰 시 엄청난 버그가 터지면서, Cursor 사용으로 얻은 효율성이 순식간에 사라지는 경험을 했음. 다시 VSCode로 돌아오고, Copilot도 구체적으로 요청할 때만 제한적으로 씀. Cursor의 탭 완성 기능은 처음엔 마법처럼 느껴지지만, 곧 그 효과가 사라짐

  • 동료가 최근에 삭제한 코드를 Cursor가 탭 완성으로 다시 입력하려는 걸 반사적으로 보는 게 제일 재밌음

  • 코드 생성 에이전트에 어떤 제한(예: SOLID 원칙, 린트, 100% 커버리지, 명확한 설계 문서 등)을 줬는지 궁금함

• 나에게도 공감 가는 의견임. 나도 LLM을 아주 많이 사용하지만 두 가지 규칙을 둠. 깊게 사고할 문제는 절대 LLM에 맡기지 않음(복잡한 설계는 반드시 직접 해결). 두 번째로, LLM이 내놓은 코드는 반드시 줄 단위로 꼼꼼히 리뷰하고 수정함. 보통 LLM이 만든 코드는 장황하거나 방어적임. 프롬프트로 고친다해도 결국 미래 유지보수의 책임은 나에게 있음. 코드 생성 결과에 무심하면 불안함이 남음. 내 방식대로 쓰면, 여전히 LLM을 많이 쓰고 더 빠르게 개발할 수 있음

  • 나는 심층 분석 자체를 AI에 맡기는데, 그 목적은 구체적 실행 계획(세부 구현 단계, 검증 기준 등)과 재현 가능한 리포트 작성을 위함임. 계획 수립과 검증엔 반복이 필요하긴 하지만, AI의 도움으로 훨씬 빨리 끝낼 수 있음. 가끔은 계획에 따라 한 번에 끝낼 때도 있음. 상세한 계획과 문서로 일관성을 확보하면 만족감이 큼

  • LLM이 만든 코드를 줄 단위로 꼼꼼히 검토해야 한다면, 과연 시간 절약이 되냐는 의문이 생김

• 일부 회사들은 소프트웨어 엔지니어에게 LLM 사용을 강제함(Copilot/Cursor 사용 실적을 집계). 이 통계가 해고 지표로 사용될 가능성이 큼. LLM 사용을 강제로 한 달 동안 해보니 오히려 실력이 빠르게 퇴화함을 느낌. 간단한 일엔 도움이 되지만 사고 자체를 LLM에 너무 의존하다 보면 루프에 빠지기 쉬움. 생산성은 오르지 않았고, 오히려 스프린트 업무량만 늘었음. LLM에 대한 종교적인 맹신이 회사 내에 팽배함. 보안 이슈도 심각함. 현 시점이 하이프 싸이클의 정점이라는 신호가 곳곳에서 보임. AI회사들이 원자력 발전소라도 만들지 않는 이상 지금의 대형 AI모델 유지에는 막대한 비용이 들어 사라질 거라 생각함. 앞으로는 터보 자동완성 기능 정도만 살아남을 것 같음. 트랜스포머 모델도 한계가 명확해서 80년대 신경망처럼 특정 용도로만 남고 다시 사라질 것임. 결국 부침을 겪으면서 30년 후 다시 대두될 것임. 진짜 이렇게 될 때 누가 맨몸으로 수영하고 있었는지 드러날 것임

  • 이런 현상을 방지하려고 주 1회라도 Copilot을 아예 끄고 일하는 'no Copilot Fridays' 자체 규칙을 시행중임

  • 나도 Cursor를 자동완성 및 짧은 코드 스니펫 정도로만 쓰고 있는데, 그래도 실력 약화가 느껴짐. 결국 "안 쓰면 잊는다"는 뇌의 특성을 실감함

• 나도 비슷한 문제점을 목격함. 장난감 프로젝트에 90% LLM을 사용함. 손수 코딩보다 10배 빠르지만, 설계 품질이 떨어지고 뭔가 이질적임. LLM 주도 코드가 미래라고 믿지만, 관리를 잘못하면 혼란에 빠짐. 아키텍처 개선을 반복적으로 유도하며 프롬프트를 바꿔보기도 하는데, 결과는 들쭉날쭉임. 아마 더 나은 프롬프트 엔지니어링, 혹은 설계와 지침을 명확하게 문서화하는 게 해답일지도 모름. 도구 성능이 10배 빨라지고 지연이 줄어들면 체감이 완전히 달라질 것임

  • 이렇게 "10배 더 좋은" 시기가 빨리 왔으면 함. 그런데 지금 문제는 이미 그 수준에 도달했다고 광고/홍보하는 분위기임. 많은 이들이 "내가 잘 못 쓰는 걸까"라는 생각에 빠짐. 하지만 아직 도구 자체가 그 정도는 아니라고 봄

  • 클래스, 메서드를 직접 정의해 두고 LLM에 구현만 맡기면 좋음. 복잡한 부분엔 메서드 몸체에 구현 방향을 메모해 놓음. 이렇게 하면 큰 그림을 내가 그리고 LLM엔 특정 코드 생성만 맡길 수 있음. LLM은 지나치게 열심히 도와주려는 빠른 주니어 개발자 느낌임. 코드 생성이 워낙 저렴해져서 맘껏 버리고 다시 만들 수 있음. 실제 내 경우 데이터셋 처리 코드를 LLM 도움으로 여러 번 완전히 버리고 다시 썼더니 결국 원하던 결과와 퍼포먼스를 얻음. 남이 써줬으면 포기했을 작업임

  • 이런 도구들은 그린필드 프로젝트 시제품 단계에서 빛남. 하지만 실제 배포에 다다를수록 그 10배 효과는 점점 사라짐. 아키텍처를 신중하게 관리하지 않으면 결국 수고만 늘어남

  • 복잡한 코드베이스에선 현재로선 고급 음성-텍스트 입력처럼만 쓸 만함(근데 음성이 아니라면 오히려 그냥 손코딩이 더 빠름)

  • 아키텍처와 가이드라인을 명시적으로 기록해야 한다는 데 동의함. 명시적으로 조건과 동작을 정의할수록 효과적임

• 다익스트라가 쓴 오래된 명저 "자연어 프로그래밍의 어리석음" 글의 요지가 현재 논의에 적합함. 공식 언어만이 프로그래밍의 엄청난 발전을 가능하게 했다는 주장임. LLM과 vibe-coding이 코딩을 잘 프롬프트하는 소수만의 마법이 될 위험이 있다는 관점임

• 나는 Copilot이 500자 미만 코드 제안을 할 때만 좋음. Go, Python에서 새로운 패턴도 배우고 타이핑 양도 줄임. 내게 있어선 그냥 더 나은 자동완성임. 그 이상 길거나 복잡하면, 수정하고 지적하는 데 드는 비용이 얻는 이익을 초과함(특히 반복적인 코드가 아닌 경우엔 그렇지 않음)

• 지금은 LLM이 생성하는 결과를 반드시 이해하고 밀착 감독해야 함. 반면, 2~3주마다 새로운 모델이 나오고 기존보다 훨씬 좋아지기 때문에 강한 결론을 내기엔 이르다고 봄.