THE STEADY COMPANY
로컬 모델과 Opencode를 만져보며 느낀 것 cover image

로컬 모델과 Opencode를 만져보며 느낀 것

Product Engineer 시대로 가는 감각

2026-01-19 21:00

·
  • AI
  • LLM
  • iOS
  • Productivity
  • Tooling

들어가며

2026년 1월 19일 기준으로,
오늘은 Opencode, OhMyOpencode, 그리고 Ollama를 이용해 로컬 모델을 직접 돌려봤어요.

요즘 AI 관련 도구를 "사용한다"는 느낌보다는
개발 환경의 일부로 흡수되는 과정에 있다는 느낌이 강해지고 있어요.

로컬 모델의 현실적인 한계

현재 사용 중인 머신은 RAM 16GB 환경이에요.
이 상태에서 느낀 결론은 꽤 명확했어요.

  • 대형 로컬 모델은 사실상 불가능해요
  • 어중간한 사이즈의 모델은
    → iOS 개발과 병행하기엔 리소스 부담이 커요
  • 경량화된 모델은 실행 자체는 쾌적하지만
    → 정확도와 추론 품질이 눈에 띄게 떨어져요

"로컬에서 다 해결하자"는 이상은 아직 하드웨어 제약을 강하게 받고 있어요.
특히 Xcode, Simulator, 브라우저, AI 툴을 동시에 띄운 상태에서는 더더욱 그래요.

Opencode보다 인상 깊었던 OhMyOpencode

단순히 Opencode 자체보다,
OhMyOpencode의 구조와 철학이 굉장히 인상 깊었어요.

OhMyOpencode에는 하나의 메인 모델과,
그 아래 여러 Teammate(역할 기반 AI) 가 존재해요.

예를 들면 다음과 같아요.

  • Oracle\
    • Design, Debugging 담당\
    • GPT-5.2 Medium
  • Frontend UI/UX Engineer\
    • 프론트엔드 개발 담당\
    • Gemini 3 Pro
  • Librarian\
    • 공식 문서, 오픈소스 구현, 코드베이스 탐색\
    • Claude Sonnet 4.5
  • Explore\
    • 초고속 코드베이스 탐색\
    • Contextual Grep (Grok Code)

명령을 내리면 각 역할이 유기적으로 작업을 분담하고,
일부 작업은 백그라운드에서 병렬로 진행돼요.

특히 ultrawork 옵션을 주면
"해결될 때까지" 계속 작업을 이어간다는 점이 꽤 인상적이었어요.

Product Engineer 시대의 체감

이 구조를 보면서 든 생각은 하나였어요.

이제 iOS / Backend로 나뉘는 시대는 점점 끝나고,
한 명의 Product Engineer가 하나의 제품을 책임지는 시대로 가고 있어요.

이미 도구의 방향성 자체가 그렇게 설계되고 있어요.
역할은 사람이 나누는 것이 아니라,
AI에게 위임되는 방향으로 이동 중이에요.

iOS 개발에 특화해서 써본다면?

다만 당장은 모든 것을 범용적으로 쓰기보다는,
iOS 개발에 특화된 형태로 먼저 실험해보고 싶다는 생각이 들었어요.

예를 들면:

  • 메인 모델은 가장 똑똑한 모델 하나로 두고
  • 그 아래에
    • 클린 아키텍처 검증용 Teammate
    • 유닛 테스트 생성 전용 Teammate
    • 성능 테스트 / 빌드 타임 분석 전용 Teammate
  • 각각이 유기적으로 협업하는 구조

이렇게 되면
"사람이 설계하고, AI가 구현을 보조한다" 수준을 넘어서
설계 또한 AI와 함께 하는 구조가 가능해져요.

파일 시스템 기반 사고와 객체지향적 접근

또 하나 흥미로웠던 포인트는
파일 시스템 기반으로 MD 파일을 생성하고 관리하는 방식이에요.

이걸 객체지향적으로 풀 수도 있을 것 같다는 생각이 들었어요.

예를 들면:

  • Developer 라는 역할 정의
  • 이를 상속받는
    • FrontendDeveloper
    • BackendDeveloper
    • iOSDeveloper
  • 각 역할에 책임과 산출물(MD, 코드, 테스트)을 명시

AI가 단순히 코드를 찍어내는 것이 아니라,
역할을 수행하는 객체처럼 동작하게 만드는 방향이에요.

완전 자동화의 미래

조금 더 나아가면 이런 흐름도 자연스러워요.

  • Zoom 회의 -> 자동 스크립트 생성
  • 스크립트 -> 문서화
  • 문서 -> 유즈케이스 정의
  • 유즈케이스 -> 개발 태스크 생성
  • 태스크 -> 코드, 테스트, 문서 자동 생성

이미 일부는 현실이고,
남은 것은 이 과정을 얼마나 자연스럽게 연결하느냐의 문제처럼 느껴져요.

비용과 로컬 인프라에 대한 생각

현재는 GLM 4.7 모델로 가볍게 실험했지만,
여기에 Claude급 모델을 이식한다면
생산성은 말도 안 되게 올라갈 수밖에 없는 구조예요.

다만 한편으로는:

  • 토큰 사용량 폭증
  • 비용에 대한 부담

이 현실적인 문제가 있어요.

그래서 오히려
대형 로컬 모델을 돌릴 수 있는 공용 PC 하나가 있다면
장기적으로는 비용을 꽤 절감할 수 있지 않을까 하는 생각도 들었어요.

마치며

오늘의 결론은 명확해요.

AI는 더 이상 "보조 도구"가 아니에요.
이미 개발 조직의 구조 자체를 바꾸고 있어요.

이 흐름을 거스를 수는 없고,
결국 중요한 건:

어떤 역할을 사람에게 남기고
어떤 역할을 AI에게 위임할 것인가

2026년은 그 경계를 본격적으로 실험하는 해가 될 것 같아요.