AI 시대의 개발방법론, HuNova는 무엇을 축적하는가

Part 1. AI 시대, 왜 새로운 개발방법론이 필요한가

1. 치밀한 설계와 살아 있는 글

히가시노 게이고는 대중성과 작품성을 함께 인정받은 일본의 대표 작가다. 안타깝게도 2026년 7월 23일 병환으로 타계했다. 데뷔작 "방과후"부터 유작이 된 "영원의 기억"까지, 공저를 제외하고 106권의 저서를 남긴 다작의 작가이기도 하다. 그가 2023년에 뉴시스와의 서면 인터뷰에서 글쓰기에 대한 생각을 밝혔는데 그중 인상적인 부분이 있어 발췌했다.

오랜 기간 집필을 하면서 소설 쓰는 방식도 변했다. 다양한 추리소설을 쓰는 만큼 플롯과 형식 등에 변주를 주는 것이다. "면밀하게 설계도를 준비"한다고 표현한다. 그는 자신도 젊을 때는 생각이 나는 대로 쓰기 시작해 이야기가 막히면 생각하는 방식으로 썼지만 "나이가 들며 이러한 방식으로는 만족할만한 글이 나오지 않게 됐다"고 했다. 물론 설계도가 있다고 해서 소설이 마음대로 써지는 것은 아니다. 그는 매번 소설을 쓸 때마다 중간에 수정할 부분이 꼭 있다고 한다. "소설은 생물입니다. 로봇을 조립하는 것처럼 되지는 않는 법이죠."

그렇다. 아이디어에서 출발해 조사와 기획을 거치고 치밀한 구상을 했음에도, 막상 써 내려가는 과정에서는 미처 예상하지 못했던 것들이 나타난다. 처음에는 단순한 암시였던 요소가 이야기의 전개 속에서 새로운 의미를 갖기도 하고, 등장인물의 성격이나 관계가 변화하면서 이후의 이야기를 다시 구성해야 하는 경우도 생긴다.

좋은 작품은 설계 없이 만들어지는 것도 아니고, 설계대로만 만들어지는 것도 아니다. 설계는 변화를 제거하기 위한 것이 아니라, 변화 속에서 올바른 판단을 하기 위한 기준이 된다.

소프트웨어 개발도 이와 다르지 않다. 요구사항을 분석하고 설계를 완료했다고 해서 결과물이 처음 계획한 모습 그대로 만들어지는 것은 아니다. 개발 과정에서 새로운 제약과 사실을 발견하고, 이를 근거로 기존 판단과 설계를 수정하는 일은 개발이라는 창작 과정에서도 자연스럽게 발생한다.

2. 코딩은 기술 글쓰기다

팀에 새로 합류한 주니어 개발자들은 소프트웨어 개발을 흔히 코드를 작성하는 일이라고 생각한다. 나는 온보딩 때마다 실제 개발에서 코드는 전체 과정의 일부일 뿐이라는 점을 강조해왔다. 그리고 이 개발 과정을 글쓰기 과정에 비유해서 설명하곤 한다.

개발자는 요구사항을 전달받는 순간부터 코딩을 시작하지 않는다. 먼저 해결해야 할 문제가 무엇인지 이해하고, 사용자의 요구와 비즈니스 목적을 분석한다. 그 과정에서 해결해야 할 범위를 정의하고, 제약사항을 확인하며, 어떤 구조로 문제를 풀 것인지 설계한다. 이후 명세를 통해 구현해야 할 내용을 구체화하고, 코드를 작성한 뒤 테스트를 통해 자신의 판단이 올바른지 검증한다.

작가 역시 글을 쓰기 전에 먼저 이야기를 전달할 대상을 생각한다. 어떤 이야기를 전달할 것인지 결정하고, 등장인물의 목적과 성격, 사건이 발생하는 배경과 관계를 구성한다. 전체 이야기의 흐름을 담은 시놉시스를 만들고, 장면과 문장을 통해 자신의 의도를 표현한다. 그리고 독자가 이야기를 따라갈 수 있는지, 전달하려던 감정과 메시지가 제대로 전달되는지를 끊임없이 고민하고 수정한다.

개발자에게 코드가 있다면 작가에게는 문장이 있다. 하지만 코드와 문장 모두 최종 표현물일 뿐이다. 그 이전에는 문제에 대한 이해, 구조에 대한 설계, 전달하고자 하는 의도, 그리고 결과를 확인하고 수정하는 과정이 존재한다.

결국 개발자가 작성하는 것은 코드와 개발 문서다. 개발 문서에는 문제를 어떻게 이해했는지, 어떤 해결 방법을 선택했는지, 그 과정에서 어떤 판단을 내렸는지가 담긴다. 그런 점에서 코드와 개발 문서는 모두 기술 글쓰기 과정의 결과물이며, 그 과정 자체가 하나의 개발 프로세스가 된다.

3. 좋은 공동 저자는 프로세스에서 만들어진다

누구나 히가시노 게이고처럼 독자를 사로잡는 소설을 쓸 수는 없다. 누구나 폰 노이만이나 다익스트라처럼 시대를 바꾸는 이론과 알고리즘을 만들 수도 없다. 뛰어난 통찰과 창의성은 쉽게 모방할 수 있는 능력이 아니다.

그러므로 우리가 배워야 하는 것은 천재의 결과물이 아니라, 그 결과에 이르기까지 문제와 씨름하고 판단을 거듭하는 과정이다. 문제를 이해하고 정의하며, 구조를 설계하고, 끊임없이 검토하고 수정하는 잘 정립된 프로세스를 따라 우리는 사고하고 판단하는 방식을 배우고 훈련할 수 있다. 천재의 통찰은 복제할 수 없지만, 사고하고 판단하는 체계적인 과정은 반복적인 훈련을 통해 자신의 것으로 만들 수 있다.

이제는 이러한 사고 과정을 AI와 함께 수행할 수 있는 시대가 되었다. 잘 정립된 프로세스를 따르면 AI의 장점을 효과적으로 활용할 수 있다. AI는 사람이 낸 아이디어를 확장하고, 다양한 선택지를 제시하며, 더 나은 판단을 거쳐 하나의 방향으로 수렴할 수 있도록 돕는다. 그렇게 정리된 주제를 바탕으로 사람이 작성한 초안을 다듬고, 논리의 빈틈을 찾아내며, 다양한 관점에서 검토하는 과정에서 AI는 훌륭한 공동 저자가 된다.

지금 여러분이 읽고 있는 글 역시 이러한 과정을 거쳐 만들어졌다. 처음에는 하나의 생각에서 출발했지만, AI와 함께 아이디어를 다양한 관점으로 확장하고 여러 선택지를 비교하며 하나의 주제로 수렴했다. 그 위에 초안을 작성하고, 중복을 제거하고, 구조를 다듬고, 논리의 흐름을 반복해서 검토했다. 그 과정에서 AI는 훌륭한 공동 저자였지만, 무엇을 말할 것인지, 무엇을 버릴 것인지, 어떤 방향으로 글을 이끌어 갈 것인지를 결정한 것은 바로 필자였다.

글쓰기에는 이미 훌륭한 방법론이 많다. 좋은 글을 쓰기 위한 과정은 오래전부터 수많은 작가와 교육자들이 연구하고 발전시켜 왔다. 개발방법론 역시 마찬가지다. 시대마다 새로운 문제를 해결하며 충분히 성숙해 왔고, 지금도 변화에 맞춰 발전하고 있다.

내가 말하고 싶은 것은 기존의 글쓰기 방법론이나 개발방법론을 부정하려는 것이 아니다. AI를 공동 저자로 참여시키면 그 장점을 극대화할 수 있지만, 이를 뒷받침하는 프로세스가 없다면 그만큼 더 큰 혼란과 부작용을 낳을 수도 있다는 점이다.

AI는 좋은 글을 대신 써 주는 존재가 아니다. 좋은 글이 만들어지는 과정을 함께하는 공동 저자다. 잘 정립된 프로세스가 좋은 공동 저자를 만든다.

Part 2. HuNova는 무엇을 축적하는가

4. 변경을 넘어 판단의 맥락을 추적한다

소프트웨어 개발을 하면서 많은 개발자가 한 번쯤 이런 경험을 한다. 오래전에 작성한 코드를 다시 보면서 "내가 왜 이렇게 만들었을까?"라고 생각하는 순간이다. 코드는 남아 있고, Git에는 변경 이력도 남아 있다. 하지만 정작 그 코드를 작성할 당시 어떤 고민을 했고, 어떤 선택지 사이에서 판단했으며, 왜 지금의 구조를 선택했는지는 기억나지 않는다. 코드는 결과를 보여주지만, 결과에 이르기까지의 과정은 보여주지 않는다. 문제는 코드 못지않게 중요한 코드를 만든 판단의 맥락이 사라진다는 것이다.

소프트웨어 개발에서는 오래전부터 문서화의 중요성을 강조해 왔다. 요구사항을 정리하고, 설계를 문서화하고, 인터페이스와 테스트 내용을 기록해야 한다고 했다. 당연하게도 좋은 문서는 개발자가 같은 문제를 반복해서 고민하지 않도록 돕고, 새로운 사람이 기존 시스템을 이해하고, 그 위에서 더 나은 판단을 내릴 수 있게 한다.

하지만 현실에서 문서 기반 개발은 생각처럼 쉽지 않았다. 필자의 경험에 비춰보면 개발 과정에서 문서 작성과 유지는 늘 후순위로 밀리는 경우가 많았다. 게다가 한 번 작성한 문서를 코드 변경에 맞춰 계속 유지하는 것은 더욱 어려운 작업이다.

운영 중인 시스템에 긴급한 문제가 발생하면 대부분 같은 선택을 한다.

"일단 문제를 해결하고 문서는 나중에 정리하자."

하지만 그 나중은 쉽게 오지 않는다. 급한 불을 끄고 나면 또 다시 새로운 요구사항이 들어오고, 또 다른 문제가 발생한다. 그렇게 시간이 지나면 문서는 현재의 코드를 설명하지 못하는 과거의 기록이 된다.

설령 문서를 다시 정리할 기회가 온다고 해도 쉬운 일이 아니다. 변경된 코드에 맞춰 특정 부분만 수정하면 될 것 같지만, 실제로는 그 변경이 어디까지 영향을 미치는지 파악해야 한다. 데이터 구조의 작은 변경이 다른 모듈에 어떤 영향을 주는지, 정책 변경이 어떤 설계 판단을 바꾸는지, 예외 처리가 기존 가정을 깨뜨리는지 확인해야 한다.

결국 문서를 고치는 일은 단순히 문장을 수정하는 일이 아니다. 변경의 영향을 분석하고, 기존 판단이 여전히 유효한지 검토하는 과정이다. 우리가 흔히 이야기하는 리그레션 테스트 역시 현재의 변경이 기존 동작과 가정을 깨뜨리지 않는지 확인하는 과정이다.

HuNova가 다루려는 것은 변경 이력만이 아니다. 변경이 발생한 이유와 그 과정에서 이루어진 판단을 함께 기록하고, 그 흐름을 추적하며 다음 판단을 이끌어 간다.

• 어떤 가정에서 시작했는가.
• 어떤 제약 조건이 있었는가.
• 어떤 근거를 바탕으로 결정했는가.
• 그리고 그 결정이 이후 어떤 영향을 주었는가.

이러한 맥락이 함께 기록될 때 우리는 다시 활용할 수 있는 지식을 축적할 수 있다.

AI 시대에는 이 과정이 새로운 가능성을 가진다. 기존에는 개발자가 기억하거나 문서로 직접 관리해야 했던 많은 연결 관계를 AI가 함께 추적할 수 있다. AI는 변경된 코드와 기존 문서를 함께 살펴보고, 영향을 받을 수 있는 영역과 다시 검토해야 할 판단을 제안할 수 있다.

• 이 변경은 기존 설계 결정과 어떤 관계가 있는가?
• 이전의 가정 중 다시 검토해야 하는 것은 무엇인가?
• 이번 결정은 어떤 영향을 가져오는가?

이러한 질문을 통해 AI는 단순히 코드를 작성하는 도구가 아니라, 판단 과정을 함께 검토하고 더 나은 방향을 찾도록 돕는 공동 저자가 된다. 그리고 HuNova는 그 사고 과정을 기록하고 추적한다. 변경 이력과 함께 판단의 맥락을 따라간다. 그리고 그렇게 축적된 판단은 Knowledge가 된다. 축적된 Knowledge를 살펴보면 다양한 판단의 맥락 속에서 반복되는 공통된 구조들을 발견할 수 있다.

그것이 다음 단계인 Pattern이다.

5. Knowledge에서 Pattern으로

1994년, 에리히 감마, 리처드 헬름, 랄프 존슨, 존 블리시데스는 Design Patterns: Elements of Reusable Object-Oriented Software를 출간했다. 지금은 GoF(Gang of Four) 디자인 패턴이라는 이름으로 더 잘 알려져 있다. 많은 개발자가 오해하는 것 중 하나가 있는데 GoF가 디자인 패턴을 만들었다고 생각하는 것이다. 그들이 실제로 한 일은 수많은 소프트웨어에서 반복적으로 나타나던 문제와 해결 구조를 분석하고, 그 안에서 공통된 설계 방식을 찾아 정리한 것이다.

Observer, Strategy, Adapter 같은 패턴은 누군가의 독창적인 아이디어에서 갑자기 만들어진 것이 아니다. 서로 다른 시스템을 개발하는 과정에서 비슷한 문제를 해결하기 위해 반복적으로 선택했던 구조였다. GoF는 이러한 사례들을 비교하고 분석하면서 반복되는 구조를 추상화하고, 개발자들이 공유할 수 있는 언어로 정리했다.

Pattern은 개별 사례가 아니라, 여러 사례를 비교하고 분석해 반복되는 구조를 추상화한 결과다. HuNova에서 기록하는 Knowledge도 같은 관점에서 바라볼 수 있다. 4절에서 설명한 것처럼 하나의 판단과 그 맥락은 하나의 Knowledge가 된다. 어떤 가정에서 시작했고, 어떤 제약 조건이 있었으며, 어떤 근거를 바탕으로 결정을 내렸고, 그 결과 어떤 영향을 주었는지를 기록한다. 하지만 하나의 Knowledge만으로는 Pattern을 찾아낼 수 없다. 하나의 경험은 특정 상황에서 이루어진 하나의 판단일 뿐이다. 서로 다른 상황에서 만들어진 Knowledge가 축적되고, 그 안의 판단 과정과 결과를 비교할 때 비로소 반복되는 구조를 이해할 수 있다.

예를 들어 어떤 프로젝트에서는 데이터 조회 성능 문제를 해결하기 위해 캐시를 도입했고, 다른 프로젝트에서는 외부 API 호출 지연을 줄이기 위해 캐시를 도입했다고 하자. 처음에는 서로 다른 문제처럼 보인다. 하지만 각각의 판단 과정과 맥락을 비교해 보면, 반복되는 조회 비용을 줄이기 위해 데이터를 가까운 곳에 저장한다는 공통된 구조를 발견할 수 있다.

변하지 않는 데이터를 반복적으로 조회하는 상황에서, 비용을 줄이기 위해 중간 저장 구조를 활용한다. 이것이 서로 다른 문제 속에서 발견할 수 있는 공통된 해결 구조다. 이처럼 개별 판단의 차이를 넘어 공통된 구조를 이해하는 과정이 Pattern을 만드는 과정이다. 그러기 위해서는 Knowledge가 단순히 기록되어 있는 것만으로 충분하지 않다. 축적된 Knowledge를 비교하고 분석할 수 있는 구조가 필요하다.

HuNova의 Knowledge 모델은 이러한 분석이 가능하도록 판단의 맥락을 함께 기록한다.

• 어떤 상황(Context)이었는가.
• 어떤 가정(Assumption)에서 시작했는가.
• 어떤 제약 조건(Constraint)이 있었는가.
• 어떤 근거(Evidence)를 통해 판단했는가.
• 어떤 결정(Decision)을 내렸는가.
• 그 결과 어떤 영향(Impact)이 있었는가.

이러한 정보가 구조적으로 축적되어야 다음과 같은 질문이 가능하다.

• 비슷한 제약 조건에서 우리는 어떤 판단을 반복했는가?
• 특정 문제 상황에서 어떤 결정이 효과적이었는가?
• 예상과 다른 결과가 발생한 이유는 무엇인가?
• 같은 문제가 다시 발생했을 때 어떤 선택을 해야 하는가?

이렇게 축적된 Knowledge를 통해 우리는 특정 상황에서 반복되는 판단의 구조를 이해할 수 있다. 하지만 모든 Pattern이 곧 Principle이 되는 것은 아니다. 여러 상황에서 선택되고, 검증되며, 설명될 수 있을 때 비로소 하나의 원칙으로 발전한다.

6. Pattern에서 Principle로

분산 시스템을 운영하다 보면 예상하지 못한 문제를 자주 만나게 된다. 특히 기존 시스템을 새로운 환경으로 전환하는 과정에서는 하나의 변경이 예상하지 못한 곳에서 문제를 일으키기도 한다. 과거 Hadoop 1세대 환경에서 2세대 환경으로 업그레이드하는 프로젝트에 참여한 경험이 있다. 당시 Hadoop뿐 아니라 HBase, SolrCloud를 기반으로 한 DLP 솔루션을 개발하고 고객사의 운영 환경을 지원하고 있었다. 업그레이드 과정에서는 다양한 장애가 발생했고, 현장 엔지니어들은 문제를 해결하는 데 어려움을 겪고 있었다. 문제는 기술 자체만이 아니었다.

장애가 발생하면 이슈 관리 시스템인 Mantis에 등록했지만, 기록된 내용만으로는 상황을 이해하기 어려운 경우가 많았다. 어떤 환경에서 발생했는지, 어떤 변경 이후 문제가 발생했는지, 어떤 가정을 가지고 원인을 추적했는지, 어떤 검증 과정을 거쳤는지 알기 어려웠다.

결국 같은 문제가 발생해도 이전 경험을 다시 활용하기 어려웠고, 경험이 많은 엔지니어의 기억과 역량에 의존할 수밖에 없었다. 이 문제를 해결하기 위해 현장에 투입된 뒤, 내가 가장 먼저 한 일은 장애의 원인을 찾는 것이 아니라, 장애를 분석하고 기록하는 방식을 바꾸는 일이었다.

발생한 문제와 함께, 문제를 이해하는 과정 자체를 기록하도록 이슈 보고의 틀을 다시 만들었다.

• 어떤 환경(Context)에서 발생했는가.
• 어떤 변경이나 조건(Constraint)이 있었는가.
• 어떤 가정(Assumption)에서 원인을 추적했는가.
• 어떤 근거(Evidence)를 통해 검증했는가.
• 어떤 결정(Decision)을 내렸는가.
• 그 결과 어떤 영향(Impact)이 있었는가.

장애 해결 과정에서 발생한 판단의 맥락을 축적하기 위한 Knowledge 구조를 만든 것이다. 아마 이 대목에서 여러분은 "장애 보고라면 당연히 이런 내용이 담겨야 하는 것 아닌가"라고 생각할 수도 있다. 하지만 현장에서는 이 당연한 일이 잘 지켜지지 않는다. 형식은 알고 있어도 각 항목에 어떤 내용을 담아야 하는지, 왜 그것이 필요한지 이해하지 못하는 경우가 많다.

그래서 매일 아침 엔지니어들을 모아 엔지니어들이 작성한 이슈를 하나씩 골라 함께 분석하는 시간을 가졌다. 이름은 GMT(Good Morning Training)였다. GMT는 실제 발생한 문제를 함께 분석하며, 장애 해결 과정에서 필요한 사고방식과 판단 기준을 공유하는 과정이었다.

처음에는 우선 시급한 하나의 장애를 해결받는 것이 엔지니어들의 목적이었을 것이다. 하지만 같은 과정을 반복하면서 그들의 질문은 달라졌다.

"이 장애의 원인은 무엇인가?"에서 "비슷한 상황에서 우리는 어떤 판단을 해야 하는가?"로 바뀐 것이다.

이러한 과정을 반복하면서 장애 대응 경험을 개인의 경험과 기억에 남기는 것이 아니라, 팀이 공유할 수 있는 지식으로 축적하는 구조를 체득하게 됐다. 이후 축적된 지식을 서로 비교하고 분석하면서, 어떤 변경이 장애로 이어졌는지, 어떤 조건에서 같은 문제가 반복되는지, 어떤 분석 과정이 효과적인지를 스스로 찾아가기 시작했다. 각자가 기록한 경험 속에 반복되는 구조를 이해하게 된 것이다.

하지만 반복되는 구조가 모두 Principle이 되는 것은 아니다. 특정 상황에서 효과적이었던 방법이 다른 상황에서는 문제가 될 수 있기 때문이다. Pattern이 Principle이 되기 위해서는 다양한 상황에서 적용되고 검증되면서, 언제 유효하고 언제 주의해야 하는지 이해할 수 있어야 한다.

GMT를 통해 엔지니어들이 얻은 것은 장애를 해결하는 경험을 넘어, 장애를 분석하고 판단하는 기준이었다. 여러 장애 사례를 분석하면서 어떤 상황에서 어떤 판단이 효과적인지 이해하고, 이를 팀이 공유할 수 있는 기준으로 발전시킨 것이다. 그 결과 비슷한 유형의 장애는 스스로 해결할 수 있게 되었고, 장기간 방치되던 문제들도 줄어들었다.

하나의 경험과 판단은 Knowledge가 된다. Knowledge를 비교하고 분석하면 Pattern이 된다. 그리고 Pattern이 반복적인 검증을 거쳐 다양한 상황에서 활용 가능한 판단 기준이 될 때 Principle이 된다.

Principle은 누군가가 선언하는 규칙이 아니다. 반복된 경험과 검증을 통해 만들어진 판단 기준이다.

7. Principle에서 Wisdom으로

인간은 오랫동안 스스로를 생각하는 존재로 정의해 왔다. 경험을 해석하고 의미를 부여하며, 끊임없이 새로운 관점을 만들어 왔다. 그래서 인간을 사유하는 동물이라고 부른다. 사유는 하나의 결과로 끝나는 것이 아니라, 경험을 돌아보고 질문을 던지며 기존의 지식을 새롭게 해석하는 과정이다. 그리고 그 과정 속에서 우리는 이전과 다른 관점으로 세상을 바라보게 된다.

사유는 오랫동안 내면의 나와 대화하는 과정으로 설명되어 왔다. 경험을 돌아보고, 질문을 던지고, 스스로 답을 찾는 과정이다.

Human Nova는 이 사유의 과정에 새로운 대화 상대를 더한다. 혼자 내면과 대화하던 인간은 이제 AI와 함께 질문하고, 검토하고, 새로운 관점을 탐색한다. AI는 인간의 사고를 대신하는 존재가 아니다. 인간이 더 깊게 사고할 수 있도록 질문을 던지고, 다른 관점을 제시하며, 판단 과정을 함께 검토하는 공동 저자다.

이것이 가능한 이유는 AI가 인간이 가진 사고의 한계를 보완할 수 있기 때문이다. 인간은 경험과 기억을 바탕으로 사고하지만, 한 사람이 경험할 수 있는 범위와 기억할 수 있는 정보에는 한계가 있다. AI는 방대한 자료를 빠르게 연결하고, 서로 다른 분야의 지식을 비교하며, 인간이 놓친 관점과 질문을 제시할 수 있다. 인간은 AI를 통해 자신의 사고 범위를 확장하고, 혼자였다면 발견하기 어려웠던 가능성을 탐색할 수 있다.

하지만 AI를 공동 저자로 초청하는 것만으로는 충분하지 않다. AI가 사유의 과정에 제대로 참여하기 위해서는 함께 검토할 수 있는 기반이 필요하다. 인간의 경험과 판단이 Knowledge로 기록되어 있어야 하고, 왜 그렇게 판단했는지, 어떤 가정과 제약 조건이 있었는지, 어떤 결과가 발생했는지를 함께 남겨야 한다.

그래야 AI는 과거의 경험을 단순히 검색하는 수준을 넘어, 현재의 문제와 연결하고 새로운 질문을 던질 수 있다. AI는 축적된 Knowledge 속에서 유사한 사례를 찾고, 서로 다른 경험 사이의 관계를 비교하며, 반복되는 구조를 찾아 Pattern을 이해한다. 하지만 축적된 Knowledge만으로 새로운 모든 상황을 판단할 수 있는 것은 아니다. 경험은 중요한 판단의 기반이지만, 경험하지 못한 문제는 항상 존재한다. AI는 HuNova에 축적된 Knowledge에서 Pattern을 찾는다. 그리고 이를 AI가 학습한 방대한 외부 지식과 연결해, 기존 경험의 범위를 넘어 새로운 관점과 가능성을 제시한다.

Wisdom은 어느 순간 갑자기 얻어지는 능력이 아니다. 경험을 돌아보고, 그 안에서 의미를 찾고, 새로운 상황에 적용하며, 결과를 다시 검토하는 과정 속에서 점차 응축된다. Knowledge는 축적되고, Pattern은 발견되며, Principle은 정리된다. 그리고 Wisdom은 그 모든 과정이 반복되면서 특정한 상황에서 발현되는 판단의 힘이다.

HuNova가 추구하는 것은 인간과 AI가 함께 이 과정을 수행하는 것이다. 인간은 경험의 맥락을 기록하고 판단의 책임을 가진다. AI는 인간의 사고를 확장하는 대화 상대가 된다. 이 과정에서 축적된 경험은 새로운 Knowledge가 되고, 다시 다음 판단의 기반이 된다.

결국 HuNova는 지식을 관리하는 방법론이 아니다. 인간과 AI가 함께 사고하며, 경험을 이해하고 판단을 발전시키는 기술 글쓰기 방법론이다.

---

이 글은 HuNova 개발방법론 연작의 두 번째 글이다.
이전 글에서는 AI 시대에 왜 새로운 개발방법론이 필요한지 살펴보았다.

- [이전 글: AI 시대, 우리는 왜 새로운 개발방법론이 필요한가]

이번 글에서는 HuNova가 축적하는 대상이 단순한 코드나 문서가 아니라, 판단의 맥락이라는 점을 살펴보았다. 이어지는 글에서는 이렇게 축적된 Knowledge가 실제 개발 과정에서 어떻게 활용될 수 있는지 다룰 예정이다.