최근 팀의 정책과 기획 정보를 하나의 SSOT로 모으는 작업을 하고 있다. 기능별로 흩어져 있던 정책, 상태값, 라이프사이클, 예외 규칙 같은 것들을 도메인 단위로 정리하고, AI가 해당 문서를 컨텍스트로 활용할 수 있도록 만드는 작업이다.
예전에는 화면 하나를 만들기 위해서도 꽤 많은 단계를 거쳤다. 피그마에서 화면을 기획하고, 각 화면의 액션과 상태를 정의하고, 별도의 문서에 정책을 작성했다. 데이터 구조나 API 명세는 또 다른 곳에 있었다. 하나의 기능을 설명하기 위해 여러 곳에 정보가 나뉘어 있었고, 개발자는 그 정보들을 오가며 전체 맥락을 이해해야 했다.
문제는 정보가 흩어져 있다는 사실만이 아니었다. 각각의 문서는 나름대로 완결돼 있었지만 서로 연결되어 있지는 않았다. 화면에서는 A라고 설명하고 정책서에서는 B라고 정의하는 일이 생겼다. 문서가 업데이트되지 않으면 구현은 자연스럽게 이전의 맥락을 따라갔다.
결국 개발자는 문서를 읽는 것만으로는 충분하지 않았다. 여러 문서 사이의 관계를 직접 추론하고, 빠진 부분을 질문하고, 서로 다른 정보를 조합해야 했다.
그런데 AI를 개발 과정에 적극적으로 사용하기 시작하면서 이 문제를 바라보는 관점이 조금 달라졌다.
이제 컨텍스트가 설계 대상이 됐다
AI에게 코드를 작성해 달라고 하는 건 생각보다 어렵지 않다. 어려운 건 AI가 무엇을 알고 있어야 하는지 정의하는 일이다.
같은 요청을 하더라도 어떤 정책을 알고 있는지, 어떤 상태값을 기준으로 하는지, 기존 시스템이 어떤 구조인지에 따라 결과는 달라진다. 코드 자체를 잘 작성하는 것보다 그 코드가 어떤 맥락에서 작성되어야 하는지를 전달하는 일이 중요해졌다.
예전에는 개발자가 코드를 작성하기 전에 필요한 정보를 찾아서 이해했다. 이제는 AI가 구현하기 전에 필요한 정보를 어떻게 제공할 것인지 고민하게 된다.
그래서 최근에는 문서의 양보다 문서 간의 관계를 더 많이 생각한다.
하나의 도메인에 필요한 정책과 규칙은 어디까지인가. 다른 도메인과 공유하는 정보는 어떻게 참조해야 하는가. 동일한 규칙이 여러 문서에 중복되어 있다면 무엇을 기준으로 삼아야 하는가. 정책이 바뀌었을 때 어떤 컨텍스트까지 영향을 받는가.
예전에는 코드에서 모듈을 나누고 의존성을 관리했다면, 지금은 컨텍스트에서 비슷한 고민을 하고 있다.
코드의 응집도와 결합도를 고민하던 일이 컨텍스트의 응집도와 의존성을 고민하는 일로 확장된 셈이다.
추상화의 대상이 달라졌다
백엔드 개발을 하던 시절에는 코드 레벨의 추상화에 관심이 많았다.
어떤 책임을 객체에 둘 것인지, 모듈을 어디까지 분리할 것인지, 공통 로직을 어떻게 추출할 것인지. 잘못된 추상화는 코드를 복잡하게 만들고, 잘못된 경계는 변경을 어렵게 만들었다.
그래서 도메인을 나누고, 책임을 분리하고, 의존성을 줄이는 일이 중요했다.
지금은 그 고민이 조금 다른 형태로 나타난다.
AI에게 제공하는 컨텍스트도 마찬가지다. 모든 정보를 하나의 거대한 문서에 넣으면 필요한 정보를 찾기 어렵고, 반대로 지나치게 잘게 나누면 문서 사이의 관계를 이해하기 어려워진다. 각각의 문서는 정확하더라도 서로 연결되지 않으면 전체 시스템의 맥락을 설명하지 못한다.
결국 어디까지를 하나의 컨텍스트로 볼 것인지, 어떤 정보는 독립적으로 관리하고 어떤 정보는 참조하도록 할 것인지 결정해야 한다.
이건 단순히 문서를 잘 쓰는 문제가 아니다. 시스템을 어떤 단위로 이해하고 설명할 것인지에 대한 설계 문제에 가깝다.
코드 아키텍처를 고민하던 방식이 컨텍스트 아키텍처를 고민하는 방식으로 옮겨가고 있다는 생각이 든다.
문서가 코드에 가까워지고 있다
여기서 한 가지 더 달라진 점이 있다.
예전의 문서는 사람에게 설명하기 위한 것이었다. 개발자가 읽고 이해하고, 그 내용을 바탕으로 코드를 작성했다. 문서와 코드는 서로 다른 결과물이었다.
하지만 AI가 개발 과정에 들어오면서 문서는 조금 다른 역할을 갖게 됐다.
정책서에 정의된 상태값과 규칙이 실제 구현과 일치하는지 확인하고, 새로운 기능을 만들 때 기존 정책을 참고하고, 변경 사항이 다른 기능에 미치는 영향을 검토하는 데 문서가 사용된다.
이렇게 되면 문서는 단순한 설명 자료가 아니다. 구현의 입력이자, 구현 결과를 검증하는 기준이 된다.
물론 문서가 코드 자체가 된다는 의미는 아니다. 실제 동작을 결정하는 것은 여전히 코드이고, 문서만으로 구현의 정확성이 보장되는 것도 아니다.
다만 개발 과정에서 문서가 차지하는 위치는 분명히 달라지고 있다. 코드가 구현의 결과물이라면, 컨텍스트는 그 구현이 어떤 방향으로 이루어져야 하는지 정의하는 기반이 된다.
AI나 LLM은 흔히 사람이 생각하는 ’당연한것이나 통상적인것’을 쉽게 놓치기 때문에..
그래서 문서의 정확성이나 최신성을 관리하는 일이 이전보다 훨씬 중요해졌다고 느낀다.
지금
AI 시대의 개발이 무엇인지 아직 명확하게 정의하기는 어렵다.
다만 개인적으로 체감하는 변화는 있다.
예전에는 코드를 어떻게 잘 구조화할 것인지 고민했다. 이제는 AI가 제대로 이해하고 구현할 수 있도록 정보를 어떻게 구조화할 것인지 고민한다.
코드의 복잡성을 줄이는 것만큼 컨텍스트의 복잡성을 줄이는 일이 중요해졌다. 그리고 컨텍스트를 잘못 나누거나 연결하면, 그 결과가 코드에 그대로 반영될 수 있다.
어쩌면 개발자의 역할이 사라진다기보다는 설계해야 하는 대상이 넓어지고 있는 것일지도 모르겠다.
코드를 작성하는 방법을 아는 것에서, 무엇을 만들어야 하는지 이해하고 그에 필요한 맥락을 구성하는 일까지.
최근 SSOT를 정리하면서 느끼는 건, 결국 AI를 잘 활용하는 일도 기존에 개발하면서 중요하게 생각했던 원칙들과 크게 다르지 않다는 것이다.
좋은 추상화, 명확한 책임, 적절한 경계, 낮은 결합도.
다만 이제 그 고민의 대상이 코드에만 머물지 않는다는 점이 조금 달라졌을 뿐이다.