아는개발자 · 2026-07-28

오늘의 대화

엔터프라이즈급 제품을 LLM으로 개발할 때 명세를 정교하게 만들어도 결과의 멱등성과 화면 일관성을 보장하기 어렵다는 문제에서 대화가 시작됐다. 이를 보완하는 Superpowers 워크플로의 효율을 두고 비용과 품질 평가가 크게 엇갈렸고, 논쟁은 정보 정정의 태도와 커뮤니티 대화 방식 문제로 번졌다. 이후에는 2D 게임 에셋과 애니메이션 제작, 비개발자가 대규모 프로젝트를 유지보수하기 위해 무엇을 배워야 하는지, Codex 사용량 초기화와 원격 제어, 개발용 노트북과 메모리까지 실무적인 경험이 폭넓게 오갔다.

이야기 나온 주제

엔터프라이즈급 AI 개발과 Superpowers 논쟁

한 기획자는 SDD와 정교한 명세를 적용해도 LLM 개발에서 동일 입력에 동일 결과가 나오지 않고, 사람의 코드 리뷰와 세밀한 QA가 없으면 운영 가능한 품질을 유지하기 어렵다고 문제를 제기했다. 문서를 너무 복잡하게 만들면 오히려 화면이 많은 제품에서 일관된 산출물을 얻기 어려워진다는 후속 설명도 나왔다.

대응책으로 금지 조건을 명시한 문서, 충분한 사전 설계와 Superpowers 워크플로가 추천됐다. Superpowers가 브레인스토밍, 작업 계획, worktree, TDD와 단계별 리뷰를 강제해 방향성을 잡아준다는 의견이 있었지만, GPT 5.6 계열에서는 토큰과 시간이 크게 늘고 결과 차이는 작았다는 반대 경험도 제시됐다. 낮은 성능의 모델 자체를 더 똑똑하게 만든다기보다 사람이 챙길 절차를 자동으로 꼼꼼히 수행하게 한다는 쪽이 더 정확한 설명이라는 의견이 나왔다.

이 논쟁은 상대의 사용 경험과 표현 태도를 공격하는 방향으로 격해졌고 운영자가 한 참여자를 내보낸 뒤 관련 대화를 중단시켰다. 기술 정보의 사실 여부를 정정하는 일과 상대를 조롱하는 일은 분리해야 한다는 반응이 다수였다.

• 확인이 필요한 내용: 모델·하네스별 비용 차이, Superpowers 적용 전후의 객관적 품질과 토큰 사용량
• 참고 자료: obra/superpowers
• 원본 시각: 09:19–10:08, 10:31–10:44

게임 에셋과 2D 애니메이션의 한계

바이브코딩으로 게임을 만드는 참여자들은 AI가 한 장의 2D 이미지나 단순 공격 모션은 그럴듯하게 만들지만, 달리기처럼 연속 프레임의 일관성이 필요한 애니메이션은 바로 쓰기 어렵다고 말했다. 사람이 후처리하거나 Adobe 도구를 연결해야 한다는 의견과, 리깅·모션 프리셋이 많은 3D로 전환한 뒤 카툰 렌더링으로 2D 분위기를 내는 방법이 제안됐다.

3D 모델로 구도와 카메라 워킹을 잡고 프레임을 추출하는 접근도 소개됐지만, 원하는 분위기와 세부 스타일을 유지하려면 스토리보드와 디자인 역량이 여전히 필요하다는 쪽으로 모였다. 모델별 역할을 기획·프론트엔드·백엔드·최종 검수로 나누는 개인 워크플로도 제안됐으나 품질 차이는 검증되지 않았다.

• 원본 시각: 10:09–10:30

비개발자의 설계·디버깅 학습

20만~30만 줄 규모 프로젝트를 만드는 비개발자가 개발 지식의 이점을 묻자, 참여자들은 초기에 아키텍처와 작업 단위를 나누고 프로젝트 구조를 사람이 이해하는 것이 유지보수와 토큰 절약에 중요하다고 답했다. 개발자는 코드를 전부 읽기보다 증상에서 원인이 있을 법한 함수나 파일을 좁혀 지시하고, 결과를 더 구체적으로 검수할 수 있다는 설명이었다.

상품 SKU를 외부 플랫폼과 맞추는 기능에서 AI에게 반복 수정을 시키다 방어 로직이 과도하게 쌓인 사례도 공유됐다. 같은 모델을 사용한 개발자 친구는 코드를 보고 원인을 좁혀 몇 시간 만에 해결했다고 한다. 제안된 학습·작업 방법은 다음과 같았다.

• 실패 증상만 말하지 말고 상태 코드, 로그와 관련 파일을 함께 좁힌다.
• 함수 처리 과정에 필요한 로그를 남기고, 증상 덮기보다 근본 원인과 수정 계획을 먼저 설명하게 한다.
• 대화 맥락이 뒤섞였으면 새 세션에서 다시 검토하거나 다른 AI에게 구현안의 맹점을 비평시킨다.
• DB, 스키마, API와 백엔드 아키텍처처럼 데이터 흐름을 이해하는 기초부터 학습한다.
• 핵심 정책과 단일 진실 공급원은 간결하게 유지하고, 히스토리와 과한 세부 문서는 분리해 라우팅한다.

개발자는 제약과 구현 가능성을 빨리 판단하는 반면, 비개발자는 기존 제약에 덜 묶여 B2C 사용성에 집중할 수 있다는 장점도 언급됐다. 개발 용어를 비개발자식 설명과 함께 작성하게 하고, 일반 대화 세션에서 Codex에 보낼 지시를 다듬는 두 세션 방식도 소개됐다.

• 원본 시각: 10:45–12:56

사용량 초기화와 병렬 작업 도구

Codex 사용량이 예고 후 초기화된 듯한 상황에서 남은 사용량을 더 쓸지 고민하는 반응이 이어졌다. GPT 5.6 sol을 몇 시간 돌려 주간 한도를 빠르게 소진했다는 경험과, 첫 메시지 이후 5시간 단위 초기화 시각을 아침 루틴으로 맞춘다는 개인 팁도 나왔다. 공식 정책이 아닌 당시 화면과 체감에 근거한 이야기다.

Orca는 여러 프로젝트뿐 아니라 한 프로젝트 안의 여러 작업을 병렬로 진행할 때도 편하다는 후기가 나왔다. AI를 기다리는 동안 다른 프로젝트를 실행하거나 문서·테스트·배포 자동화를 보강하는 식으로 일하는 사람이 있는 반면, 병렬 작업 자체가 아직 피곤하다는 반응도 있었다.

• 확인이 필요한 내용: 당시 사용량 초기화 범위와 주기, 모델별 실제 사용량 계산
• 원본 시각: 10:09–10:13, 11:27–11:39, 13:16–14:16

원격 제어와 업무 자동화

회사에서 새 개발 아이디어가 없다는 질문에는 반복 업무 자동화, 개인 비서 봇, 테스트·빌드·배포 자동화와 문서 정리가 제안됐다. 지역 기사를 주기적으로 수집하고 AI로 분류하는 개인용 스크랩 도구 사례가 나왔고, n8n은 코드 리뷰 도구 자체가 아니라 LLM을 묶어 코드 리뷰 워크플로를 구성할 수 있는 자동화 도구라고 정정됐다.

모바일에서 Claude Code 세션을 확인하고 조작하려는 질문에는 /remote-control과 기본 설정에서 원격 제어를 항상 켜는 방법이 소개됐다. Tailscale로 개발 환경에 접속해 태블릿에서 확인한다는 사례도 있었지만, 인증과 네트워크 보안 조건은 논의되지 않았다.

• 원본 시각: 13:26–14:51

개발 노트북과 메모리 선택

폐쇄망에서 Java·Spring Boot 웹 개발을 할 노트북을 고르는 질문에서는 GPU보다 실제 기술 스택, 이동성, 보안 규정과 운영 환경을 먼저 확정해야 한다는 답이 나왔다. 원격 데스크톱을 쓸 수 없는 환경이고 Mac도 허용되지 않아 Windows 노트북을 골라야 했으며, MSI·ASUS의 가격 경쟁력과 사후지원 부담, ThinkPad 제안이 함께 언급됐다.

Mac은 서버와 비슷한 Unix 계열 환경과 AI 도구 사용 경험이 장점으로 평가됐지만 가격과 적응 비용이 단점으로 꼽혔다. Codex 세션을 병렬로 돌릴 때 18GB에서 응답 없음이 발생했다는 경험, 24GB에서 세 세션과 소수의 서브에이전트가 가능했다는 경험이 엇갈려 32GB 이상을 선호하는 의견이 많았다. 이는 프로젝트와 실행 도구에 따라 달라지는 개인 사례다.

Kimi K3 공개 소식과 Ollama Cloud·Cursor 지원도 언급됐다. 모델 크기가 매우 커 로컬 구동은 대부분에게 어렵고, Ollama Cloud의 기본 요금에는 포함되지 않아 공식 가격과 비슷하다는 확인이 뒤따랐다.

• 확인이 필요한 내용: 노트북별 최신 가격·지원 정책, 실제 메모리 요구량, Kimi K3의 정확한 모델 크기와 서비스별 가격
• 원본 시각: 15:53–19:16

대화의 분위기

오전에는 실무 경험의 차이를 검증하는 과정이 인신공격에 가까워지며 방 분위기가 크게 거칠어졌다. 운영자의 정리 뒤에는 비개발자의 구체적인 사례를 중심으로 조언이 차분하게 이어졌고, 도움을 받은 참여자가 감사 인사를 전하면서 대화가 회복됐다. 오후에는 AI가 일하는 동안 간식을 먹거나 게임을 한다는 농담과 비싼 메모리 가격에 대한 탄식이 섞였다.

연결

• 아는개발자 전체 보기
• 전날 아는개발자 대화
• 같은 날 에이전트코리아의 모델 역할 분담·오케스트레이션 대화