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