이 블로그가 다루는 것

NeuTeam 의 전제는 한 줄로 줄어듭니다. OSS 도구·패키지와 다양한 AI 모델을 사람이 알고 활용할 줄 알고, SW 개발의 기초만 갖추고 있다면, LLM 기반 자동화 코딩으로 한 명의 개발자가 풀스택 구축뿐 아니라 테스트/기획/서비스 운영까지 끌고 갈 수 있다. 이 가정 위에서 본 사이트의 4 개 카테고리는 각각 다른 위치에서 그 흐름을 받쳐 줍니다.

기획 / Product 리더십 / 방법론 + 업무 사례 풀스택 개발 Engineering 실전 [A] 서비스 운영 Engineering 실전 [B] / 업무 사례 QA / 테스트 Engineering 실전 [A] SW 사전 지식 아키텍처 / 자료구조 / 도메인 AI 모델 LLM / CV / TTS·STT / 시계열 OSS 도구 하니스 / 패키지 / 인프라 개발자 + Agent LLM 기반 자동화 코딩
중앙은 개발자 + Agent 입니다. 안쪽 링의 짙은 세 영역(SW 사전 지식 / AI 모델 / OSS 도구) 은 사람이 반드시 직접 알아야 하는 기초입니다. 바깥 링의 흐린 네 영역(기획 / 풀스택 개발 / QA / 서비스 운영) 은 Agent 와 함께 점차 확장해 가는 영역으로, 전통적 개발자 직무를 넘어섭니다. 화살표는 안쪽 기초 위에서 사람이 외곽까지 영향력을 펼쳐 가는 흐름을 가리킵니다.

각 카테고리는 위 다이어그램의 어느 위치를 받쳐 주는지 분명히 정해져 있습니다. 리더십 / 방법론 은 가장 바깥의 기획/운영 가장자리 — Agentic 시대에 맞춰 사람이 어떻게 일하고 평가하느냐의 축. Agentic Engineering 의 두 갈래는 안쪽 기초(SW 사전 지식) 와 외곽 확장(Engineering 실전 [A]/[B]/[C]) 을 잇는 중심축. Agentic Stack 의 두 갈래(AI 모델 / OSS 도구) 는 안쪽 링 자체 — 사람이 손에 쥐고 있어야 하는 도구함. 업무 사례 는 위 모두를 묶어 외곽까지 작동시킨 결과의 증거입니다. 이어지는 절에서 카테고리별로 어떤 글을 담는지 정리합니다.

People / 조직/운영

리더십 & 방법론

왜 이 카테고리가 필요한가. Agent 가 코드와 업무를 만들기 시작하면 가장 먼저 부정확해지는 것은 도구가 아니라 평가 기준 / 인재 정의 / 1:1 의 질문 세트 입니다. 기업이 Agentic 전환을 시도할 때 도구 도입을 표면이 아닌 근본 변화로 만들기 위해 People 축이 먼저 정렬되어야 합니다.

대표 질문
  • "지금이 도입 시점인가" 를 어떤 신호로 판단하는가
  • Agent 가 만든 코드 비중이 30% 를 넘기면 평가 단위는 어떻게 바뀌는가
  • 가시성을 감시 가 아닌 협업 입력 으로 만들려면 무엇이 필요한가

올라오는 글 시리즈. CTO 인사이트, 평가 체계 갱신, 채용/온보딩 재설계, 1:1 의 질문 세트, 분기별 회고 시리즈.

How to build / Agent 와 함께 / Agent 를 직접 만드는 방법

Agentic Engineering

왜 이 카테고리가 필요한가. 개발자가 Agent 를 활용하는 방식은 두 가지입니다 — (1) Agent 에게 일을 맡기는 사람, (2) 운영/서비스용 별도 Agent 를 직접 개발하는 사람. 두 갈래는 사전 지식이 상당 부분 겹치고, 공통의 기반인 Harness Engineering (Agent 가 동작하는 환경 자체의 설계) 위에 올라갑니다. 본 섹션은 이 세 가지를 한곳에 모아, 데모로 끝나지 않고 프로덕션에 도달하는 절차를 정리합니다.

대표 질문
  • 만 줄 변경을 Agent 와 안전하게 진행하는 절차는 무엇인가
  • 운영 Agent 의 Tool/Function 인터페이스를 어떻게 설계해야 가드레일이 작동하는가
  • 컨텍스트 윈도우/MCP/권한/샌드박스를 어떻게 조합해야 운영 Agent 가 사고를 안 내는가

  • SW 사전 지식

    Agent 를 다루기 전 사람이 먼저 알아야 하는 것 — 모듈 경계와 의존성 그래프, 트랜잭션 모델, 비동기/동시성, 자료구조 선택의 비용, 분산 시스템의 거짓말 8 가지, 인덱스의 직관, 옵저버빌리티의 세 기둥. "이 개념을 모르면 Agent 가 엉뚱한 산출물을 만들고, 만든 시스템도 엉뚱하게 동작한다" 는 실용 관점.

  • Engineering 실전

    세 갈래를 함께 다룹니다. [A] Agent 에게 일을 맡기는 실전 (작업 분할, 검수 루프, 실패 회복, 비용 통제. [B] 운영 Agent 직접 개발) 시스템 프롬프트 설계, Tool/Function calling, RAG, 메모리, 멀티에이전트 오케스트레이션, 가드레일, 평가/관측. [C] Harness Engineering (공통 기반) — MCP 서버 설계, 권한/샌드박스, Agent 추적/로깅 인프라.

What to use / 탐구/평가

Agentic Stack

왜 이 카테고리가 필요한가. 모델/도구의 SOTA 가 분기마다 바뀌는 환경에서 기업이 가장 많이 잃는 것은 의사결정 시간 입니다. "지금 우리 워크로드에 무엇이 적합한가" 를 매번 0 부터 평가하면 도입이 늦어집니다. 본 섹션은 다양한 OSS 모델/도구의 비교 축 과 측정 결과 를 미리 정리해 그 시간을 줄여줍니다.

대표 질문
  • 우리 워크로드에 맞는 OSS 모델/도구의 후보 목록은 무엇인가 (라이선스/자체호스팅 가능성 포함)
  • 같은 OSS 모델의 양자화/추론 엔진을 바꾸면 정확도/속도/비용은 얼마나 달라지는가
  • 사내 데이터로 평가하는 작은 eval set 을 어떻게 만들고 유지하는가

  • AI 모델

    LLM 에 한정되지 않습니다. LLM / Computer Vision / 회귀/시계열 / 이상 탐지 / 이미지 생성 / 음성(TTS/STT) / 멀티모달 / 작은 모델 까지 다양한 OSS AI 모델군의 활용법/성능/자체호스팅/평가 절차. 오픈 웨이트(Llama, Qwen, DeepSeek, YOLO, SAM, Whisper 등) 중심.

  • OSS 도구

    두 갈래를 모두 다룹니다. (1) 사람이 빠르게 설치해 쓰기 좋은 일반 OSS (마케팅 자동화, 모니터링/알림, 보안, 메일/메신저/문서, 리버스 프록시/인증, 백업/복구, FE/BE 패키지/SDK, 작업 큐/스케줄러. (2) Agentic 개발의 기반이 되는 OSS) 코딩 에이전트/하니스, 로컬 추론 엔진, LLM 게이트웨이, 벡터 DB, 평가 OSS, 관측/추적 OSS.

Application / 적용 결과

업무 사례

왜 이 카테고리가 필요한가. 방법/구현/스택을 다 알아도 실제 업무에서 어떤 결과가 나는지 가 가장 결정적입니다. 의사결정자에게 "데모가 아니라 우리 현장에서 작동했다" 는 증거 가 있어야 도입이 진행됩니다. 본 섹션은 그 증거를 모읍니다 — 성공 사례뿐 아니라 실패 모드와 한계 도 함께 기록해 도입 검토자가 위험을 미리 가늠할 수 있게 합니다.

대표 질문
  • Agent 만으로 0→1 시스템을 어디까지 만들 수 있는가
  • 레거시 모놀리스에서 Agent 가 닿을 수 있는 영역과 못 닿는 영역은 어떻게 구분되는가
  • 사내 운영 Agent 의 ROI 를 어떻게 측정하는가 (사람 리뷰 대비 발견율/오탐율/복구 시간 등)

올라오는 글 시리즈. 케이스 스터디(전/후 수치 + 절차 + 트레이드오프), PoC(Proof of Concept) 결과, 영상 데모, 실패 모드 회고.

문의

글의 오류 지적, 다뤄주었으면 하는 도구/모델/방법론, 협업 제안 모두 환영합니다. 개인정보는 운영자에게만 노출되며 공개 게시판에는 드러나지 않습니다.

문의 남기기