standarda 생태계: 개요

standarda · standarda-core · standarda-template · standarda-devtools, 이 네 폴더가 각각 무엇이고, 어떻게 맞물려 프로젝트를 만드는지 이 챕터에서 다룹니다. 이번 강의는 그 출발점으로, 왜 이런 구조인지부터 짚습니다.

이 챕터를 마치면

• 이 구조가 왜 '집단지성'을 가능하게 하는지, 그리고 왜 저절로는 안 되는지 안다
• 네 폴더의 계층(도구·재료 vs 결과물)을 한 문장으로 설명할 수 있다
• template 은 왜 '복사'하고 core 는 왜 '설치'하는지 안다
• core 를 자동 업데이트하지 않는 이유와 그 대가를 안다
• devtools 가 왜 별도 repo 인지, 프로젝트 하나가 어떻게 태어나고 사라지는지 안다

대상은 standarda 구조를 처음 접하는 팀원(비개발자 포함)입니다. 위에서 아래로 순서대로, 개념을 하나씩 쌓아 올리도록 배치했습니다.

1. 왜 이런 구조가 필요한가

우리 팀은 비슷하게 생긴 AI 프로젝트를 여러 개 만듭니다. 겉보기엔 달라도 속을 열어 보면 똑같은 것을 반복합니다.

• 로그인·회원가입 화면 (거의 모든 서비스가 필요)
• PDF·엑셀 문서를 읽어 AI 에 넘기는 코드
• 구글 시트·메일·드라이브 연동
• 서버 설정, 배포 방식, 폴더 구조

이걸 프로젝트마다 처음부터 만들면 두 가지 문제가 생깁니다.

• 낭비: 같은 로그인 화면을 5번 만든다.
• 제각각: 5명이 각자 만들면 5개가 조금씩 다르다. 나중에 "이 프로젝트는 왜 저 프로젝트랑 구조가 다르지?" 하는 혼란.

그래서 팀은 "매번 반복되는 것"을 성격별로 세 묶음으로 분리해 두었습니다. 그리고 그 세 묶음으로 찍어낸 실제 제품들이 따로 있습니다.

2. 더 큰 이유: 집단지성

앞의 두 문제(낭비·제각각)는 '손해를 막는' 이야기입니다. 그런데 이 구조에는 그보다 훨씬 큰 이득이 하나 더 있습니다. 이게 진짜 이유에 가깝습니다.

한 사람의 배움이 팀 전체의 자산이 됩니다.

예를 들어 PDF 읽는 코드를 사흘에 걸쳐 훨씬 정확하게 개선했다고 가정해 보겠습니다.

• 복사·붙여넣기 방식 (배움이 증발한다): 개선은 내 프로젝트 안에서 끝납니다. 옆 프로젝트는 옛 코드를 그대로 쓰고, 그런 개선이 있었다는 사실조차 모릅니다. 반년 뒤 다른 팀원이 같은 문제에 같은 사흘을 다시 씁니다.
• 분리 구조 (배움이 쌓인다): core 에 올리면 이후 설치하는 모든 프로젝트가 그 사흘치 개선을 그대로 받습니다. 내가 사흘 걸려 알아낸 것이 팀원에게는 import 한 줄이 되고, changelog 에 '왜 이렇게 했는지'까지 남아 맥락도 함께 전달됩니다.

3. 배움이 흐르는 통로 4개

배운 것의 성격에 따라 흘려보내는 곳이 다릅니다. 앞으로 배울 네 폴더는 그래서 단순한 코드 보관함이 아니라, 각기 다른 배움이 모이는 통로입니다.

마지막 줄이 특히 중요합니다. 코드만 공유하면 '무엇'만 전해지고, 기록까지 공유해야 '왜'가 전해집니다. 그래서 changelog 에 "이건 어느 프로젝트에서 필요해 만들어졌다"는 한 줄을 남깁니다.

4. 복리 효과: 왜 시간이 지날수록 격차가 벌어지나

팀원 5명이 각자 한 달에 재사용할 부품 1개씩 만든다고 하면:

복사 방식:  한 달 뒤 내가 가진 부품 = 1개  (내가 만든 것뿐)
분리 구조:  한 달 뒤 내가 가진 부품 = 5개  (팀 전체가 만든 것)

1년 뒤 →   복사 방식: 12개  /  분리 구조: 60개

차이는 더하기가 아니라 곱하기로 벌어집니다. 가장 큰 수혜자는 새로 합류한 사람입니다. 첫날부터 팀이 쌓아 온 부품을 전부 갖고 출발하기 때문입니다. 맨바닥이 아니라 팀이 이미 쌓아 온 것 위에서 시작하는 셈입니다.

그래서 이 구조는 '통제'가 아니라 '협업'에 가깝습니다. 내 코드를 core 에 올리는 것은 관리받는 게 아니라, 내 사흘이 동료의 사흘을 아껴 주는 일입니다. 반대로 지금 내가 편하게 쓰는 부품들도 누군가 먼저 만들어 올려둔 것입니다.

5. 두 열쇠: 방어와 성장

단, 저절로 되지는 않습니다. 구조는 통로를 열어 둘 뿐이고, 실제로 배움이 흐르게 하는 것은 사람의 행동입니다. 올리는 쪽은 core 승격 PR 과 changelog 를 남기고, 받는 쪽은 새로 만들기 전에 카탈로그와 changelog 를 먼저 확인해야 합니다. 둘 중 하나만 빠져도 통로는 막힙니다.

이 챕터 전체를 관통하는 열쇠는 두 가지입니다.

• ① 방어: 반복을 줄이고 일관성을 지킨다 (손해를 막는다)
• ② 성장: 한 사람의 배움을 팀 전체로 흘려보낸다 (집단지성)

앞으로 나오는 모든 설계 결정은 이 둘 중 하나에서 나옵니다. 어떤 결정을 만나면 "이건 방어인가, 성장인가?"를 물어보세요.

마무리

• 핵심 정리: 팀은 반복되는 것을 성격별로 세 묶음(core·template·devtools)으로 분리해 두었습니다. 목적은 두 가지, 방어(낭비·제각각 방지)와 성장(한 사람의 배움이 팀 전체로 흐르는 집단지성)입니다. 다만 통로가 열려 있어도, 올리고 찾아보는 사람의 행동이 있어야 흐릅니다.
• 다음 시간: 네 폴더의 아키텍처: 무엇이 '도구·재료'이고 무엇이 '결과물'인지 계층을 봅니다.