소프트웨어 개발의 「○○ 주도 개발」, 좀 많아요. 근데 프레임워크는 선배들 지혜의 통조림이고, 거기 얹히면 보통 시행착오가 줄어요. 같은 발상을 육아에 옮겨 보는 시리즈 ── TDD・BDD・DDD・XP 를 「육아 프레임워크」로 다시 쓰는 작업, 여기서 시작합니다.
○○ 주도 개발, 좀 많지 않아요?
TDD (테스트 주도 개발), FDD (기능 주도 개발), BDD (행동 주도 개발), MDD (모델 주도 개발), DDD (도메인 주도 설계), TiDD (티켓 주도 개발), CDD (컴포넌트 주도 개발), 요즘은 AIDD (AI 주도 개발) 까지 나왔어요.
하고 싶은 말은 다 알아요.
저도 기본적으로 항상 TDD 로 가고 싶은 사람이에요. 테스트 시나리오부터 먼저 적어 두고 싶어요. 코드 들어가기 전에 「뭐가 됐다 상태인지」 부터 정해 두고 싶어요.
MVP (Minimum Viable Product) 마무리할 때는 FDD 로 가고 싶고. 기능 단위로 잘게 쪼개서 하나씩 Done 으로 떨어뜨리고 싶어요.
… 그건 알아요. 아는데, 그래도 ○○ 주도 개발, 좀 많아요.
소프트웨어 개발에서 프레임워크 (framework / 방법론) 라는 거, 선배들의 지혜랑 경험이 거의 다 담겨 있는 통조림 같은 거예요.
아무 생각 없이 프레임워크에 얹혀서 가는 게 보통 잘 풀려요. 시행착오 줄고, 판단 횟수 줄고, 코드 리뷰도 편해요.
티켓 관리도, ITIL (IT 서비스 관리 모범 사례 모음) 도, PMBOK (프로젝트 관리 지식 체계) 도, 예전에 한 번씩 읽었어요. 자격증도 땄고요. 읽으면서 대부분 「맞지, 맞지」 하고 끄덕이고 있었어요. 당연한 걸 당연하게 하는 게 결국 제일 빠른 길이라는 거, 대충 이거예요.
우리 집 얘기로 바꿔 보면, 레시피랑 똑같아요.
프로가 쓴 레시피대로 하면 일단 적당히 맛있어요. 응용은 「레시피대로 세 번 만들고 나서」, 그런 법칙이 적용돼요.
이걸 개발팀 밖에 도입하려고 하면, 디게 안 먹혀요.
「귀찮아요」「우리 케이스에는 필요 없어요」「이렇게 빡빡하게 안 해도 잘 돌아가는데요」.
속으로는, 야 이거 얼마나 많은 선배들 지혜가 들어 있는 건지 아냐, 그러고 있는데.
근데 솔직히 반은 맞는 말이에요.
ITIL 도 자세히 읽어 보면 「이대로 하라」고 한마디도 안 적혀 있어요. 오히려 케이스별로, 조직별로, 성숙도별로 커스텀해서 쓰라고 적혀 있어요.
○○ 주도 개발도 똑같아요. 프로젝트 규모, 단계, 팀원 숙련도에 맞춰서 골라서 커스텀해서 쓰는 거. 매번 풀세트로 풀파워 가는 게 그 도구의 사용법이 아니에요.
그런 의미에서 비개발자 분들 「우리는 이거 필요 없어요」 도, 절반은 맞아요. 나머지 절반은, 그냥 통조림 라벨을 아직 못 본 거고요.
여기서부터가 본론이에요.
육아도 아마 같은 구조일 거예요.
선배들 지혜 ── 육아 책, 어린이집 선생님 말씀, 아동심리학 연구, 옆 동 할머니가 던지고 가신 한 마디. 형태는 다 다른데, 전부 「방법론의 통조림」이에요.
다만, 아무도 「육아 TDD 같은 사고방식」이나 「육아 DDD 로 4 살 도메인을 존중」 식으로 정리해 주진 않았어요. 개발자 어휘로 보면, 육아의 지혜는 아직 별로 안 정리돼 있다는 게 솔직한 말이에요.
그래서 이 시리즈에요.
개발자이기도 하고 부모이기도 한 사람의 어휘로, 선배들 지혜를 「육아 프레임워크」로 다시 줄세워 보면 뭐가 보일까, 라는 사고 실험이에요.
TDD 라면, 작게 한번 실패시키고 거기서 배우게 하는 「실패 확인 주도」 정도로 옮길 수 있을지도 몰라요.
BDD 라면, Given / When / Then 으로 「이 시간, 이 상황, 아이가 X 하면 → 이렇게 반응한다」고 가설을 세우는 「관찰 주도」 일지도.
DDD 라면, 4 살의 도메인 (공룡은 지금도 어딘가 있다, 엘리베이터는 살아 있다) 을 존중하면서 어른 세계 단어로 설득하지 않는 「아이 세계관 주도」 일지도.
적다 보니 알겠는데, 이거 꽤 튀는 사고 실험이에요.
잘 맞는 회차도 있을 거고, 전혀 안 맞는 회차도 있을 거예요. 안 맞을 땐 「왜 안 맞았는지」도 같이 적을게요. 그것도 선배들 지혜를 쓰는 방법의 하나라고 치고 싶어요.
한 가지만 더, 시리즈의 척추가 될 만한 얘기를 둘게요.
쇼핑할 때 아내가 「이 옷이랑 저 옷 어느 게 더 나아?」 하고 물을 때, 「아무거나 다 좋아」「둘 다 잘 어울려」 하고 답하기보다, 같이 고민해 주는 게 쇼핑 시간이 짧아진다는 얘기가 있어요. (출처는 까먹었어요. 어디 연구 같은 데서 본 거 같기도 하고.)
이거, 소프트웨어 개발의 페어 프로그래밍 (pair programming) 이랑, XP (익스트림 프로그래밍) 정신 그대로네요.
혼자 끌어안고 끙끙대는 것보다 옆에서 같이 끙끙대 주는 사람이 있으면 판단이 빨라요. 결과물도, 살짝 더 나아지고, 만족감이 올라가는 느낌이 있어요.
육아도 아마 똑같을 거예요.
「혼자 생각해」 라고 던지는 것도 물론 하나의 방법이에요. 근데 옆에서 같이 고민해 주는 부모가 있는 쪽이, 아이 판단 속도를 올려 주는 거 아닐까, 요즘 그런 생각을 자주 해요.
부모도 아이랑 같이 고민하면서 업데이트 돼요. 일방통행 교육이 아니라, 페어 프로그래밍이에요.
XP 처럼, 아이랑 부모가 같이 고민하고 같이 자라는 ─ 그런 「육아 프레임워크」를, 소프트웨어 개발 방법론에서 수입해 보는. 그게 이 시리즈 전체 테마예요.