https://hyukjin-lee.github.io RSS for Node Sun, 24 May 2026 14:32:42 GMT Sun, 24 May 2026 14:32:42 GMT kevin : 만약 어떤 모델의 context length가 1T~10T 토큰 수준이라면, 수년간 했던 모든 대화를 요약 없이 원본으로 context에 들고 있고 매번 토큰 레벨 어텐션으로 참조할 수 있다면 더 이상 학습과 추론을 구분할 수 있을까? # 긴 컨텍스트는 학습을 대체할 수 있을까? ## LLM의 학습과 추론을 가르는 근본적인 차이 LLM을 쓰다 보면 이상한 감각이 든다. 모델은 방금 내가 한 말을 기억한다. 앞에서 정한 조건을 따라온다. 긴 문서를 넣으면 그 안의 정보를 찾아 답한다. 심지어 몇 년 치 대화 기록을 전부 넣을 수 있다면, 모델은 내 취향, 사고방식, 프로젝트 이력, 말투까지 모두 고려해서 답할 수 있을 것처럼 보인다. 그러면 자연스럽게 이런 질문이 생긴다. **모델이 모든 과거 맥락을 context로 들고 있을 수 있다면, 그것은 사실상 학습한 것과 같은 것 아닌가?** 처음에는 그렇다고 생각하기 쉽다. 사용자의 입장에서 보면 “모델이 나를 학습했다”와 “모델이 내 과거 대화를 전부 읽고 답했다”는 결과적으로 비슷하게 느껴질 수 있다. 둘 다 과거를 반영하고, 둘 다 개인화된 답을 내놓고, 둘 다 이전 경험을 고려하는 것처럼 보인다. 하지만 내부 메커니즘을 보면 둘은 다르다. 아주 근본적으로 다르다. **학습은 모델 자체를 바꾸는 과정이다.** **추론은 바뀌지 않은 모델이 현재 주어진 자료를 읽고 답을 계산하는 과정이다.** 이 차이를 이해해야 LLM의 긴 컨텍스트, 메모리, attention, fine-tuning, 사전학습의 의미가 한꺼번에 정리된다. --- ## 모델의 지식은 어디에 있는가 LLM은 텍스트를 그대로 이해하지 않는다. 먼저 문장을 작은 조각으로 나눈다. 이 조각을 토큰이라고 한다. 예를 들어 “고양이 이름은 모모야”라는 문장은 단순화하면 다음과 같은 토큰들로 나뉜다. `고양이 / 이름 / 은 / 모모 / 야` 모델은 이 토큰들을 다시 숫자 ID로 바꾼다. `고양이 → 15231` `이름 → 9842` `모모 → 44782` 하지만 토큰 ID 자체에는 의미가 없다. 15231이라는 숫자가 고양이를 뜻하는 것은 아니다. 그래서 모델 안에는 각 토큰 ID에 대응하는 벡터 표가 있다. 이것을 embedding matrix라고 부른다. `고양이 → [0.42, -0.71, 0.33, ...]` 이 벡터는 사람이 직접 설계한 의미표가 아니다. “고양이는 동물성 0.9, 귀여움 0.7, 반려동물성 0.8” 같은 식으로 사람이 값을 넣은 것이 아니다. 학습 과정에서 다음 토큰을 더 잘 맞히도록 수많은 숫자가 조금씩 조정된 결과다. 처음에는 이 벡터도 거의 랜덤에 가깝다. 그런데 모델이 “고양이는 야옹하고 운다”, “강아지는 멍멍하고 짖는다”, “고양이에게 사료를 줬다”, “고양이와 강아지는 반려동물이다” 같은 문장을 반복적으로 학습하면서, 고양이·강아지·사료·반려동물·동물 같은 토큰들이 예측에 유리한 방식으로 배치된다. 여기서 중요한 점은 모델의 지식이 하나의 사전처럼 저장되어 있지 않다는 것이다. 모델 안에는 “고양이 = 포유류” 같은 명시적 항목이 들어 있는 것이 아니다. 대신 수많은 weight와 embedding이 함께 조정되면서, 특정 문맥에서 어떤 토큰이 자연스러운지 계산할 수 있는 구조가 형성된다. 즉 LLM의 지식은 문장 목록이 아니라 **확률적 구조**에 가깝다. 그리고 그 구조는 weight에 분산되어 있다. --- ## 학습은 세계를 압축하는 과정이다 LLM의 기본 학습 목표는 단순하다. **앞의 토큰들이 주어졌을 때 다음 토큰을 맞힌다.** 예를 들어 학습 데이터에 이런 문장이 있다고 하자. “프랑스의 수도는 파리이다.” 모델은 이런 문제를 계속 푼다. “프랑스의 수도는” 다음에 올 토큰은 무엇인가? 처음 모델은 틀릴 수 있다. “런던”에 높은 확률을 줄 수도 있고, “도시”에 높은 확률을 줄 수도 있다. 정답인 “파리”에 낮은 확률을 주면 loss가 커진다. 학습은 이 loss를 줄이는 방향으로 모델 내부 weight를 조금씩 바꾸는 과정이다. 이때 backpropagation이 사용된다. 모델이 왜 틀렸는지 계산하고, 어떤 weight를 어느 방향으로 바꾸면 다음에는 덜 틀릴지 계산한다. 이 과정이 한 번 일어난다고 모델이 똑똑해지는 것은 아니다. 하지만 수많은 문장, 코드, 논문, 대화, 수학 풀이, 설명문, 지시문에 대해 같은 과정을 반복하면 모델 내부에는 거대한 압축 구조가 생긴다. 이 압축 구조 안에는 여러 층위의 패턴이 들어간다. 단어와 단어의 관계. 문장 구조. 문체. 사실 지식. 개념 간 연관. 논리 전개 방식. 코드 작성 패턴. 수학 문제 풀이 절차. 질문에 답하는 방식. 사람이 선호하는 답변의 형태. 그래서 학습은 단순히 데이터를 외우는 과정이 아니다. 물론 빈도는 중요하다. 많이 반복되는 패턴은 모델에 더 강하게 반영될 가능성이 높다. 하지만 모델은 단순 빈도표가 아니다. 예를 들어 “Apple”이라는 단어를 생각해보자. “Apple released a new iPhone.” “Apple is a fruit.” 모델은 Apple이 항상 회사라고 외우지 않는다. 문맥에 따라 회사일 수도 있고 과일일 수도 있음을 배운다. 즉 모델은 단어 자체보다 **조건부 관계**를 배운다. 어떤 문맥에서 어떤 의미가 활성화되는가. 어떤 단어가 어떤 단어와 함께 등장할 때 어떤 해석이 자연스러운가. 어떤 문제 상황에서 어떤 답변 구조가 선호되는가. 이것이 학습이다. 학습은 데이터를 모델 내부의 weight 공간에 압축해 넣는 과정이다. --- ## 추론은 압축된 세계관으로 현재 문맥을 읽는 과정이다 추론은 학습과 다르다. 추론 시점에는 weight가 바뀌지 않는다. 사용자가 질문을 입력하면, 모델은 그 질문과 현재 대화 기록, 시스템 지시, 첨부 문서, 검색 결과 등을 하나의 context로 받는다. 그리고 그 context를 토큰으로 쪼갠 뒤, 이미 학습된 embedding과 weight를 사용해 계산한다. 예를 들어 context가 다음과 같다고 하자. “내 고양이 이름은 모모야. 내 고양이 이름이 뭐였지?” 모델은 먼저 이 문장을 토큰으로 나누고, 각 토큰을 벡터로 바꾼다. 그리고 Transformer layer를 통과시키면서 context 안의 토큰들이 서로를 참조하게 한다. 이때 핵심적으로 쓰이는 메커니즘이 self-attention이다. self-attention은 쉽게 말해 “지금 이 토큰을 해석하려면 context 안의 어떤 토큰들을 봐야 하는가”를 계산하는 장치다. 질문 부분의 “고양이”, “이름”, “뭐였지”는 앞쪽의 “고양이 이름은 모모”와 관련이 있다. 모델은 attention을 통해 앞쪽의 “모모” 정보를 강하게 참조할 수 있다. 그러면 다음 토큰으로 “모모”가 나올 확률이 높아진다. 여기서 중요한 점은 모델이 새로 학습한 것이 아니라는 사실이다. “모모”라는 이름이 모델 weight에 새겨진 것이 아니다. 모델은 단지 현재 context 안에 있는 “모모”라는 토큰을 찾아서, 이미 학습된 언어 이해 능력으로 그것이 고양이 이름임을 해석했을 뿐이다. 즉 추론은 다음과 같은 과정이다. `현재 context → 토큰화 → embedding → attention → 문맥화된 벡터 → 다음 토큰 확률 → 출력` 그리고 이 과정을 토큰 하나씩 반복한다. 모델은 답변 전체를 한 번에 쓰지 않는다. 매 순간 다음 토큰 하나를 고르고, 그 토큰을 다시 context 뒤에 붙인 뒤, 다시 다음 토큰을 고른다. 우리가 보는 자연스러운 문장은 이 반복의 결과다. --- ## 학습과 추론은 같은 attention을 쓰지만 목적이 다르다 여기서 헷갈리기 쉬운 지점이 있다. 학습 때도 attention이 쓰이고, 추론 때도 attention이 쓰인다. 그렇다면 둘이 같은 것 아닌가? 아니다. 학습과 추론은 앞쪽 계산, 즉 forward pass는 비슷하다. 입력 토큰이 embedding으로 바뀌고, attention과 MLP layer를 지나 다음 토큰 확률이 나온다. 차이는 그 다음이다. 학습에서는 모델이 예측한 토큰과 정답 토큰을 비교한다. 틀리면 loss를 계산한다. 그리고 backpropagation으로 weight를 수정한다. 추론에서는 정답 비교가 없다. loss를 계산하지 않는다. backpropagation도 없다. weight도 바뀌지 않는다. 모델은 그냥 현재 context에서 가장 적절한 다음 토큰을 고르고 넘어간다. 그래서 이렇게 정리할 수 있다. **학습은 attention으로 읽고, 틀린 만큼 weight를 고친다.** **추론은 attention으로 읽고, weight는 그대로 둔 채 답을 낸다.** 이 차이는 사소한 차이가 아니다. 이것이 “모델이 변했는가, 변하지 않았는가”를 가르는 기준이다. --- ## context는 지식이 아니라 작업 자료다 긴 context를 이해할 때 가장 중요한 비유는 이것이다. **학습된 weight는 모델의 머릿속에 들어 있는 압축된 세계관이다.** **context는 지금 책상 위에 펼쳐져 있는 자료다.** 책상 위에 자료가 많으면 당연히 더 많은 것을 참고할 수 있다. 사용자의 과거 대화, 프로젝트 문서, 코드베이스, 논문, 회의록이 context에 들어 있다면 모델은 그 자료를 바탕으로 훨씬 개인화되고 구체적인 답을 할 수 있다. 하지만 자료가 많다고 해서 모델 자체가 똑똑해지는 것은 아니다. 그 자료를 읽고 해석하는 능력은 이미 학습된 weight에서 나온다. 이 차이를 놓치면 긴 context의 의미를 과대평가하게 된다. 예를 들어 두 모델에게 같은 100페이지짜리 논문을 넣어준다고 하자. 약한 모델은 문장을 요약할 수는 있지만, 실험 설계의 문제나 수식의 허점을 놓칠 수 있다. 강한 모델은 같은 논문을 읽고도 가정, 방법론, baseline, ablation, 통계적 한계까지 짚어낼 수 있다. context는 같다. 차이는 모델이다. 즉 context는 정보를 제공한다. 하지만 정보의 의미를 구성하는 것은 모델의 학습된 능력이다. --- ## 긴 context가 학습처럼 보이는 이유 그럼에도 긴 context가 학습처럼 보이는 순간이 있다. 예를 들어 사용자가 몇 년 동안 이런 말을 해왔다고 하자. “나는 답변이 너무 장황한 것을 싫어한다.” “코드 리뷰에서는 성능보다 가독성을 먼저 봐줬으면 좋겠다.” “기술 설명은 예시가 있을 때 잘 이해된다.” “마크다운 표가 너무 많으면 읽기 어렵다.” “나는 제품 전략을 볼 때 단기 매출보다 장기 유지율을 중요하게 본다.” 이 모든 기록이 매번 context에 들어간다면, 모델은 사용자의 선호를 반영해서 답할 수 있다. 코드 리뷰를 요청하면 가독성을 먼저 보고, 전략 검토를 요청하면 장기 유지율을 중시하고, 설명을 요청하면 예시를 넣되 장황하지 않게 답할 수 있다. 사용자 입장에서는 모델이 나를 학습한 것처럼 보인다. 하지만 내부적으로는 다르다. 모델이 사용자의 선호를 weight에 새긴 것이 아니다. 매번 context에 있는 과거 발화를 읽고, 그때그때 반영하는 것이다. 이 차이를 비유하면 다음과 같다. 학습은 공부해서 머릿속에 익힌 것이다. 긴 context 추론은 시험장에 모든 노트를 가져와서 찾아보는 것이다. 노트가 완벽하고, 찾는 속도가 매우 빠르고, 매번 모든 노트를 펼쳐볼 수 있다면 겉보기에는 공부한 사람과 비슷해 보일 수 있다. 하지만 원리는 다르다. 공부한 사람은 노트를 치워도 어느 정도 답할 수 있다. 노트만 보는 사람은 노트가 사라지면 그 정보를 잃는다. LLM도 마찬가지다. --- ## 새로운 개념을 context로 넣으면 모델은 이해할 수 있을까 여기서 더 깊은 문제가 나온다. 모델이 학습하지 않은 새로운 개념이 context 안에 등장하면, 모델은 그것을 이해할 수 있을까? 답은 “어느 정도는 가능하지만, 한계가 있다”이다. 간단한 규칙은 context만으로도 배울 수 있다. 예를 들어 이렇게 정의한다고 하자. “블릭스는 숫자 n에 대해 n²+1을 반환하는 연산이다. 예를 들어 블릭스(2)=5, 블릭스(3)=10이다.” 이제 “블릭스(4)는?”이라고 물으면 모델은 17이라고 답할 수 있다. “블릭스”라는 단어를 사전학습에서 본 적이 없어도, context 안의 정의와 예시를 기반으로 규칙을 추론한 것이다. 이것이 in-context learning이다. 하지만 이 능력은 무한하지 않다. 새로운 개념이 복잡하고, 기존 학습된 개념 체계와 멀고, context 안의 정의가 부족하면 모델은 표면적으로만 따라간다. 예를 들어 완전히 새로운 수학 체계, 회사 내부의 복잡한 운영 규칙, 낯선 법률 프레임워크, 새로운 프로그래밍 언어의 세부 semantics를 몇 문장만으로 정확히 다루기는 어렵다. 왜냐하면 context는 자료일 뿐이고, 그 자료를 해석하는 기준은 모델 안에 이미 형성된 개념 체계이기 때문이다. 모델이 새로운 개념을 잘 다루려면 최소한 다음 중 하나가 필요하다. 첫째, 그 개념이 기존에 학습한 개념들과 잘 연결되어 있어야 한다. 둘째, context 안에 정의와 예시와 반례가 충분해야 한다. 셋째, 모델 자체가 추상화와 규칙 추론 능력이 강해야 한다. 넷째, 반복 사용되는 개념이라면 fine-tuning이나 별도 memory로 안정화하는 편이 낫다. 즉 context는 새로운 정보를 제공할 수 있지만, 새로운 개념을 모델 내부의 안정적인 능력으로 통합하는 것은 학습 쪽에 더 가깝다. --- ## 학습은 압축이고, context는 비압축 참조다 학습과 긴 context 추론의 가장 중요한 차이는 “압축”이다. 학습은 수많은 데이터를 weight 안에 압축한다. 모델은 모든 원문을 그대로 들고 있지 않다. 대신 반복되는 구조, 관계, 패턴을 내부 파라미터에 녹인다. 반대로 context는 원문 또는 원문에 가까운 자료를 그대로 제공한다. 모델은 그 자료를 읽고, attention으로 필요한 부분을 참조한다. 예를 들어 사용자가 5년 동안 여러 번 “짧고 명확한 답변을 좋아한다”고 말했다고 하자. 학습 또는 개인화된 모델은 이 반복되는 선호를 압축해서 “이 사용자는 간결한 답변을 선호한다”는 내부 정책처럼 반영할 수 있다. 긴 context 모델은 매번 과거 기록 속에서 해당 선호를 찾아 읽고 반영한다. 둘 다 결과적으로 짧은 답변을 만들 수 있다. 하지만 하나는 내부에 압축된 것이고, 다른 하나는 외부 자료를 참조한 것이다. 이 차이는 비용과 안정성에서 중요하다. 매번 5년 치 대화를 다 읽는 것은 비싸고 느리다. 또한 오래된 선호와 최신 선호가 충돌하면 무엇을 우선해야 할지 판단해야 한다. 반면 학습된 선호는 빠르고 안정적이지만, 잘못 학습되면 수정하기 어렵고 최신 변화에 둔감할 수 있다. 그래서 실제 시스템에서는 둘 중 하나만 쓰지 않는다. 자주 반복되고 안정적인 패턴은 학습이나 memory에 압축하는 것이 유리하다. 일시적이고 최신성이 중요한 정보는 context나 retrieval로 넣는 것이 유리하다. --- ## 왜 긴 context만 키우면 안 되는가 긴 context는 강력하다. 하지만 그것만으로 프론티어 모델 경쟁이 끝나지는 않는다. 이유는 간단하다. **context는 자료의 양을 늘리고, 모델 개선은 자료를 해석하는 능력을 높인다.** 긴 context는 더 많은 문서를 넣게 해준다. 하지만 문서 안에서 중요한 정보를 찾고, 모순을 해결하고, 추상화하고, 새로운 문제에 적용하는 능력은 모델에서 나온다. 많은 자료를 준다고 좋은 판단이 자동으로 나오지는 않는다. 책을 100권 준다고 모두가 훌륭한 연구자가 되는 것은 아니다. 연구자는 필요한 부분을 찾고, 주장과 근거를 구분하고, 전제를 의심하고, 기존 지식과 연결하고, 반례를 생각하고, 결론의 한계를 판단할 수 있어야 한다. LLM도 마찬가지다. 긴 context는 책상 크기를 키운다. 하지만 모델의 학습된 weight는 그 책상 위 자료를 읽는 지적 능력이다. 그래서 좋은 AI 시스템은 단순히 context만 키우는 방향으로 가지 않는다. 더 강한 base model, 더 긴 context, 더 좋은 retrieval, 더 안정적인 memory, 더 정확한 tool use, 더 나은 post-training이 함께 필요하다. 긴 context는 모델의 지능을 대체하지 않는다. 긴 context는 모델의 지능이 활용할 수 있는 작업 공간을 넓힌다. --- ## 결국 LLM의 “이해”는 어디에서 발생하는가 LLM이 context를 이해한다는 말은 조심해서 써야 한다. 모델이 사람처럼 의식을 가지고 의미를 경험한다는 뜻은 아니다. 하지만 기능적으로 보면, 모델은 입력 토큰들을 학습된 벡터 공간 안에 배치하고, attention과 MLP를 통해 관계를 계산하고, 그 결과로 다음 토큰 확률을 만든다. 즉 LLM의 이해는 다음 세 요소가 결합된 결과다. 첫째, 학습된 weight. 이것은 모델이 세상을 해석하는 렌즈다. 언어, 개념, 문법, 상식, 문제풀이 패턴, 선호된 답변 방식이 여기에 압축되어 있다. 둘째, 현재 context. 이것은 지금 모델에게 주어진 작업 자료다. 사용자 질문, 대화 기록, 문서, 코드, 검색 결과, 명령 등이 여기에 포함된다. 셋째, attention을 포함한 forward computation. 이것은 학습된 렌즈로 현재 자료를 읽고, 어떤 정보를 참조할지 결정하고, 다음 토큰을 계산하는 과정이다. 이 세 가지를 구분하면 많은 혼란이 풀린다. 모델이 context 안의 정보를 사용했다고 해서 그 정보를 학습한 것은 아니다. 모델이 과거 대화를 반영했다고 해서 weight가 바뀐 것은 아니다. 모델이 낯선 용어를 처리했다고 해서 그 개념이 내부 지식으로 안정적으로 통합된 것은 아니다. 반대로 context가 없더라도 모델이 답할 수 있다면, 그것은 학습된 weight에 이미 관련 구조가 들어 있기 때문이다. --- ## 최종 결론 LLM을 이해하는 핵심은 학습과 추론을 “정보가 어디에 저장되고, 언제 바뀌는가”의 관점에서 보는 것이다. 학습은 모델 내부를 바꾼다. 추론은 모델 내부를 바꾸지 않고 현재 context를 해석한다. 학습된 weight는 압축된 지식과 능력이다. context는 현재 참고할 수 있는 외부 자료다. attention은 context 안의 토큰들을 서로 연결하는 메커니즘이다. 하지만 attention이 의미를 만들어내는 것은 학습된 weight가 이미 의미를 해석할 수 있는 구조를 갖고 있기 때문이다. 그래서 긴 context는 학습을 완전히 대체하지 않는다. 긴 context는 모델이 더 많은 자료를 보고 답하게 만들 수 있고, 때로는 학습한 것처럼 보이게 만들 수 있다. 하지만 weight가 바뀌지 않는 한 그것은 여전히 추론이다. 가장 정확한 비유는 이렇다. **학습은 세계를 머릿속에 압축해 넣는 과정이다.** **추론은 그 머릿속 구조로 지금 펼쳐진 자료를 읽는 과정이다.** **긴 context는 책상을 넓히는 것이고, 좋은 모델은 그 책상 위 자료를 제대로 읽는 두뇌를 만드는 것이다.** 이 관점에서 보면 LLM의 발전 방향도 분명해진다. 미래의 강한 AI는 단순히 context만 긴 모델도 아니고, 단순히 weight만 큰 모델도 아닐 것이다. 강한 base model, 긴 context, 검색, memory, tool use, fine-tuning, post-training이 결합된 시스템일 가능성이 높다. 왜냐하면 인간의 지능도 비슷하기 때문이다. 우리는 모든 것을 외우지 않는다. 필요한 것은 기억하고, 필요한 것은 기록하고, 필요한 것은 찾아본다. 하지만 기록을 아무리 많이 가지고 있어도, 그것을 해석하는 사고력이 없으면 좋은 판단을 할 수 없다. LLM도 마찬가지다. context는 기억의 확장이다. 학습은 해석 능력의 형성이다. 추론은 그 능력으로 현재 상황을 읽고 답을 만드는 행위다.]]> https://hyukjin-lee.github.io/tech/2026/05/can-long-form-content-replace-learning https://hyukjin-lee.github.io/tech/2026/05/can-long-form-content-replace-learning Sun, 24 May 2026 00:00:00 GMT {}); ``` 하지만 Change Contract는 더 넓다. * expired subscription은 invoice를 만들지 않는다. * skipped reason이 기록된다. * retry해도 duplicate invoice가 생기지 않는다. * 기존 active subscription 동작은 유지된다. * provider mapping은 바뀌지 않는다. 이 계약을 여러 테스트와 정적 검사로 나누어 검증해야 한다. ### 6.4 Change Contract Catalog: 변경 계약 목록 조직은 변경 유형별 catalog를 만들어야 한다. 예시는 다음과 같다. * API schema change contract * DB migration contract * payment calculation contract * authorization policy contract * event schema contract * batch job contract * notification contract * privacy data handling contract * feature flag rollout contract 각 contract에는 다음 필드가 필요하다. ```yaml name: applicable_paths: required_invariants: required_tests: required_owners: forbidden_changes: observability_requirements: rollback_requirements: escalation_conditions: ``` 이 catalog는 AGENTS.md, CI, PR bot, code review template과 연결되어야 한다. ## 7장. Agent-Readable Architecture: 에이전트가 읽을 수 있는 설계 지도 ### 7.1 정의 **Agent-Readable Architecture**는 아키텍처 경계, 의존 방향, 소유권, 금지된 import, 변경 절차, 테스트 명령, 위험 파일을 에이전트와 자동화 시스템이 읽을 수 있는 형식으로 표현한 것이다. 쉬운 말로 하면 코드베이스의 설계 지도를 사람이 읽는 문서로만 두지 말고, 에이전트와 CI도 읽고 사용할 수 있게 만들자는 뜻이다. 기존 아키텍처 문서는 사람이 읽는 설명이었다. Codebase-as-Harness에서 아키텍처는 실행 가능한 제약이어야 한다. ### 7.2 Architecture Manifest 예시는 다음과 같다. ```yaml bounded_contexts: billing: owner: payments-platform root: services/billing domain_terms: - Customer - Subscription - Invoice - PaymentAttempt allowed_dependencies: - shared/kernel - services/customer/contracts forbidden_dependencies: - services/customer/internal - services/admin/internal verification: unit: pnpm test services/billing contract: pnpm test:contract billing typecheck: pnpm typecheck risky_paths: - services/billing/migrations - services/billing/provider-mapping - services/billing/domain/money.ts escalation: - path: services/billing/domain/money.ts owner_approval_required: true - path: services/billing/authz security_review_required: true ``` 이 manifest는 세 곳에서 사용된다. 1. 에이전트가 작업 계획을 세울 때 2. CI가 변경을 검증할 때 3. 리뷰어가 위험을 판단할 때 ### 7.3 문서에서 제약으로 문서에 “domain layer는 infra를 import하면 안 된다”라고 쓰는 것은 약하다. 더 강한 방식은 dependency rule로 막는 것이다. ```text domain -> application: forbidden domain -> infra: forbidden application -> infra: allowed through interface only api -> domain: allowed ``` 에이전트는 지시를 따르려 하지만 완벽하지 않다. 따라서 중요한 규칙은 문서가 아니라 자동 검증으로 내려와야 한다. ### 7.4 AGENTS.md의 역할 AGENTS.md는 에이전트 시대의 온보딩 문서다. 그러나 AGENTS.md만으로는 부족하다. 좋은 AGENTS.md는 짧고 구체적이어야 한다. ```md # AGENTS.md ## Commands - Typecheck: pnpm typecheck - Billing tests: pnpm test services/billing - Contract tests: pnpm test:contract billing ## Architecture - Domain policies live under `domain/`. - Do not import `infra/` from `domain/`. - External provider status mapping lives only in `infra/provider-mapping`. ## Naming - Use `Customer`, not `User`, in billing. - Use `SubscriptionRenewal`, not `AutoRenewal`. ## Safety - Do not edit generated files. - Do not modify existing migrations. - Escalate if payment amount calculation changes. ``` AGENTS.md는 사람이 읽기 쉬운 entry point이고, architecture manifest는 기계가 집행할 수 있는 source of truth가 되어야 한다. ## 8장. Blast Radius Budget: 변경 범위 예산 ### 8.1 정의 **Blast Radius Budget**은 특정 작업 유형이 건드릴 수 있는 파일, 모듈, public API, migration, dependency, 설정 변경의 범위를 사전에 제한하는 예산이다. 쉬운 말로 하면 “이 작업은 여기까지만 건드릴 수 있다”는 선을 미리 정하는 것이다. 에이전트는 요청을 해결하려고 하면서 diff를 넓힐 수 있다. 브라운필드에서는 diff가 커질수록 리뷰 비용과 회귀 위험이 비선형으로 증가한다. 따라서 작업 유형별 예산이 필요하다. ### 8.2 작업 유형별 예산 #### Bug fix ```yaml task_type: bugfix max_files_changed: 5 public_api_change: false db_migration: false dependency_change: false requires_test: true requires_human_escalation_if: - auth policy touched - payment calculation touched - more than 5 files changed ``` #### Refactoring ```yaml task_type: refactoring behavior_change: false public_api_change: false rename_and_logic_change_same_commit: false requires_existing_tests_green: true requires_before_after_diff_summary: true ``` #### Feature addition ```yaml task_type: feature public_api_change: allowed migration: allowed_if_declared feature_flag: required_for_high_risk contract_test: required rollback_plan: required ``` ### 8.3 멈춤 조건 좋은 에이전트 시스템은 더 오래 자율적으로 일하는 시스템이 아니다. 좋은 시스템은 멈춰야 할 때를 안다. 에이전트는 다음 상황에서 멈춰야 한다. * 예상보다 많은 파일을 수정해야 한다. * public API 변경이 필요하다. * DB migration이 필요하다. * 권한, 결제, 개인정보, 삭제 로직을 건드린다. * 테스트를 약화해야 통과한다. * 기존 정책 위치가 불명확하다. * 동일한 개념의 중복 구현이 발견된다. * 요구사항과 기존 동작이 충돌한다. 멈춤은 실패가 아니다. 브라운필드에서 멈춤은 안전 기능이다. --- # 3부. 기존 소프트웨어 엔지니어링의 재정의 ## 9장. DDD는 검색 가능한 도메인 언어가 된다 DDD는 에이전트 시대에 더 중요해진다. 다만 초점이 확장된다. 기존 DDD는 도메인 전문가와 개발자가 같은 언어를 쓰고, 복잡한 도메인을 모델링하고, bounded context로 개념 경계를 분리하는 데 초점을 두었다. Codebase-as-Harness에서는 DDD가 다음과 같이 재정의된다. * Ubiquitous Language → 검색 가능한 도메인 주소 체계 * Bounded Context → 에이전트가 탐색할 수 있는 경계 * Aggregate → 변경 영향과 일관성의 단위 * Domain Service → 권위 있는 정책 위치 * Repository → 저장소 경계 * Anti-Corruption Layer → 외부 의미 오염 차단 장치 에이전트가 브라운필드에서 실패하는 대표적 이유는 도메인 언어가 흐릿하기 때문이다. `user`, `member`, `customer`, `account`가 혼용되면 에이전트는 정확한 코드를 찾지 못한다. 같은 정책이 `service`, `helper`, `job`, `controller`에 흩어져 있으면 진짜 정책 위치를 판단하지 못한다. 따라서 DDD는 이제 단순한 모델링 방법이 아니라 에이전트가 도메인 의미를 검색하고 조작할 수 있게 만드는 정보 구조화 방법이다. ## 10장. Clean Architecture는 작업 맥락을 줄이는 구조가 된다 Clean Architecture의 핵심은 의존성 방향을 제어하고, 비즈니스 정책을 프레임워크와 외부 시스템으로부터 분리하는 것이다. 에이전트 시대에는 이 원칙이 더 직접적인 의미를 갖는다. 비즈니스 정책이 프레임워크, DB, HTTP, message queue와 뒤섞여 있으면 에이전트는 정책 변경을 위해 너무 많은 맥락을 읽어야 한다. 반대로 도메인 정책이 순수한 코드로 분리되어 있으면 에이전트는 작은 컨텍스트로 안전하게 수정할 수 있다. 좋은 구조는 다음과 같다. ```text subscription/ domain/ subscription.ts subscription-status.ts subscription-renewal-policy.ts application/ renew-subscription.usecase.ts infra/ subscription.repository.ts payment-provider.adapter.ts api/ subscription.controller.ts tests/ subscription-renewal-policy.test.ts ``` 이 구조에서 구독 갱신 정책 변경은 domain과 관련 테스트에 국소화된다. 외부 provider 변경은 infra adapter에 국소화된다. API 변경은 api와 contract test에 국소화된다. Clean Architecture는 더 이상 “아름다운 계층 구조”가 아니다. 에이전트가 불필요한 맥락을 읽지 않아도 되게 만드는 작업 경계다. ## 11장. DRY는 동작 규칙의 단일 출처가 된다 DRY는 “중복을 없애라”가 아니다. Codebase-as-Harness에서 DRY는 **동작 규칙의 단일 출처를 만들어라**라는 의미다. 줄 수가 비슷한 코드를 무조건 합치는 것은 위험하다. 서로 다른 이유로 변하는 코드까지 추상화하면 오히려 CSA가 증가한다. 중요한 것은 다음이 중복되지 않게 하는 것이다. * 권한 정책 * 상태 전이 * 금액 계산 * 날짜 계산 * idempotency key 생성 * retry policy * external provider mapping * validation schema * feature flag 판정 예를 들어 이런 코드는 위험하다. ```ts // renewal.ts if (customer.status !== 'ACTIVE') return; // invoice.ts if (user.state === 'SUSPENDED') throw new Error('blocked'); // checkout.ts if (account.disabled) return false; ``` 같은 정책이 여러 이름과 여러 위치에 흩어져 있다. 더 나은 구조는 다음과 같다. ```ts export class BillingEligibilityPolicy { canCharge(customer: Customer): boolean { return customer.status === CustomerStatus.Active; } } ``` 에이전트는 `BillingEligibilityPolicy`를 찾으면 결제 가능성 판단의 권위 있는 위치를 찾은 것이다. ## 12장. TDD는 실행 가능한 변경 계약이 된다 TDD는 에이전트 시대에도 중요하다. 다만 단순히 “테스트를 먼저 작성한다”를 넘어야 한다. Codebase-as-Harness에서 테스트는 Change Contract를 실행 가능한 형태로 만드는 수단이다. 좋은 테스트명은 요구사항 문장이어야 한다. ```ts it('does not renew expired subscriptions', () => {}); it('does not charge suspended customers', () => {}); it('creates only one invoice when renewal job is retried', () => {}); ``` 나쁜 테스트명은 에이전트에게 도움이 되지 않는다. ```ts it('works', () => {}); it('case 3', () => {}); it('returns false', () => {}); ``` 테스트는 검색 대상이다. 에이전트가 `expired subscription renewal`을 검색했을 때 관련 테스트가 나와야 한다. ## 13장. CI/CD는 에이전트 작업 관문이 된다 CI/CD는 더 이상 빌드와 배포 자동화만이 아니다. 에이전트가 만든 변경을 제어하는 관문이다. CI는 다음을 집행해야 한다. * typecheck * lint * unit test * integration test * contract test * schema compatibility * dependency boundary * secret scan * migration validation * generated file consistency * blast radius policy * ownership approval 에이전트에게 “주의해라”라고 말하는 것은 약하다. CI에서 막아야 한다. 프롬프트는 권고다. CI는 법이다. ## 14장. Observability는 운영 신호와 코드의 연결이 된다 관측성은 운영팀만을 위한 것이 아니다. 에이전트가 운영 장애를 코드 변경으로 연결하기 위한 의미적 다리다. 좋은 로그는 도메인 언어를 사용한다. ```json { "event": "SubscriptionRenewalSkipped", "subscription_id": "sub_123", "customer_id": "cus_456", "reason": "CUSTOMER_SUSPENDED" } ``` 나쁜 로그는 의미를 숨긴다. ```text process failed invalid status skipped ``` 에이전트가 장애 로그를 보고 코드를 검색하려면 로그 event name, error code, metric name, test name, code symbol이 연결되어야 한다. 관측성은 runtime에서 발생한 사실을 코드베이스의 의미 주소로 되돌려주는 시스템이다. --- # 4부. 실전 방법론 ## 15장. SCOPE 루프 Codebase-as-Harness의 기본 작업 루프는 SCOPE다. * Search: 먼저 찾는다. * Contract: 지켜야 할 약속을 정한다. * Operate: 최소 범위로 고친다. * Prove: 검증한다. * Explain: 근거를 남긴다. SCOPE는 에이전트에게 무작정 “고쳐줘”라고 시키지 않기 위한 절차다. 브라운필드에서는 수정 자체보다 수정 전 탐색과 수정 후 검증이 더 중요하다. ### 15.1 Search 에이전트는 먼저 수정하지 않는다. 관련 맥락을 찾는다. 산출물: * 관련 파일 목록 * 권위 있는 정책 위치 * 중복 가능 위치 * 관련 테스트 * 관련 문서 * 예상 변경 범위 * 불명확한 점 요청 예시: ```text 아직 수정하지 말고 관련 파일, 정책 위치, 테스트, 예상 변경 범위만 찾아서 보고해줘. ``` ### 15.2 Contract 변경의 성공 조건을 정의한다. 산출물: * 보존해야 할 동작 * 새로 만족해야 할 동작 * 호환성 조건 * 보안 조건 * 데이터 조건 * 관측성 조건 * 실행할 테스트 * 멈춤 조건 요청 예시: ```text 이 변경의 Change Contract를 먼저 작성해줘. 어떤 동작을 보존해야 하고 어떤 테스트를 실행해야 하는지 포함해줘. ``` ### 15.3 Operate 에이전트가 최소 diff로 수정한다. 규칙: * 기존 abstraction 우선 * 중복 정책 금지 * 계약에 없는 public API 변경 금지 * migration 별도 처리 * formatter-only diff 분리 * blast radius budget 준수 요청 예시: ```text 위 계약을 만족하도록 최소 diff로 수정해줘. 기존 정책을 재사용하고, 새 helper를 만들기 전에 기존 구현을 검색해줘. ``` ### 15.4 Prove 검증한다. 검증에는 다음이 포함될 수 있다. * related unit test * integration test * contract test * typecheck * lint * schema compatibility * migration validation * security scan 요청 예시: ```text 관련 테스트와 typecheck를 실행하고, 실패하면 원인을 분석한 뒤 수정해줘. 테스트를 약화하지 마. ``` ### 15.5 Explain 마지막으로 에이전트는 증거를 남긴다. 산출물: * 무엇을 바꿨는가 * 왜 그 위치를 바꿨는가 * 어떤 계약을 만족하는가 * 어떤 테스트를 실행했는가 * 어떤 위험이 남아 있는가 * 어떤 후속 작업이 필요한가 요청 예시: ```text git diff 기준으로 변경 요약, 검증 결과, 남은 위험을 PR 설명 형식으로 정리해줘. ``` ## 16장. Agentability Audit: 에이전트 친화도 점검 대규모 조직은 AI 도입률보다 **Agentability**, 즉 에이전트 친화도를 측정해야 한다. Agentability는 특정 코드베이스가 에이전트에 의해 안전하게 탐색, 수정, 검증, 리뷰될 수 있는 정도다. ### 16.1 평가 항목 ```text Agentability Score = Semantic Addressability + Context Boundary Clarity + Verification Strength + Change Contract Coverage + Observability Linkage + Blast Radius Controllability + Architecture Enforceability - Tacit Knowledge Load - Cross-Service Coupling - Test Flakiness - Generated Diff Noise ``` 이 식은 엄밀한 수학 공식이라기보다 점검 틀이다. 중요한 것은 “우리 조직이 AI를 얼마나 많이 쓰는가”보다 “우리 코드베이스가 에이전트가 일하기 쉬운 상태인가”를 묻는 것이다. ### 16.2 실무 평가 질문 * 같은 도메인 개념이 같은 이름으로 불리는가? * 핵심 정책의 권위 있는 위치가 있는가? * 작은 변경의 관련 파일 수가 제한적인가? * 관련 테스트를 빠르게 찾고 실행할 수 있는가? * 테스트명이 비즈니스 규칙을 설명하는가? * 로그와 코드가 같은 도메인 언어를 쓰는가? * 아키텍처 경계가 자동으로 검증되는가? * 위험 변경의 escalation rule이 있는가? * generated file과 handwritten file이 분리되어 있는가? * 에이전트가 멈춰야 할 조건이 정의되어 있는가? ### 16.3 결과 해석 Agentability가 낮은 시스템에서는 최신 에이전트를 도입해도 큰 효과가 나지 않는다. 오히려 코드 생산량만 늘어 기술부채가 가속될 수 있다. Agentability가 높은 시스템에서는 모델 차이가 줄어든다. 평범한 에이전트도 안정적으로 작은 변경을 수행할 수 있고, 고성능 에이전트는 더 큰 유지보수 작업을 맡을 수 있다. ## 17장. 작업 위험도 등급 모든 작업에 에이전트를 동일하게 적용하면 안 된다. 작업은 위험도에 따라 등급화해야 한다. ### Level 1. 안전한 반복 작업 * 문서 업데이트 * 테스트명 개선 * lint fix * 타입 annotation 추가 * deprecated API 치환 * 단순 로그명 정리 * dead code 후보 탐색 에이전트에게 적극 위임할 수 있다. ### Level 2. 국소적 유지보수 * 작은 버그 수정 * 단일 모듈 내 정책 수정 * adapter mapping 수정 * 단일 API validation 수정 * fixture 정리 Change Contract와 관련 테스트가 있으면 위임 가능하다. ### Level 3. 중간 규모 변경 * 여러 파일의 정책 이동 * domain policy 추출 * API schema 확장 * 서비스 내부 구조 개편 * 성능 개선 에이전트는 초안과 기계적 변경을 맡고, 사람은 경계와 계약을 승인해야 한다. ### Level 4. 고위험 변경 * 서비스 간 계약 변경 * DB migration과 backfill * 권한 정책 * 결제/정산 * 개인정보 * 데이터 삭제 * 대규모 리팩터링 * 장애 대응 에이전트는 탐색, 영향 분석, 테스트 생성, 문서화에 사용한다. 핵심 결정은 사람이 해야 한다. ## 18장. Evidence-Based Review: 근거 중심 리뷰 에이전트가 만든 PR은 코드만 보면 안 된다. 에이전트가 어떤 근거를 바탕으로 판단했는지 봐야 한다. ### 18.1 Evidence Bundle 에이전트 PR에는 다음이 포함되어야 한다. ```text - Task summary - Files inspected - Existing policies found - Change Contract applied - Files changed - Tests run - CI result - Blast radius assessment - Remaining risks - Escalation needed or not ``` 이를 **Evidence Bundle**, 즉 작업 근거 묶음이라고 부른다. ### 18.2 리뷰 기준 리뷰어는 다음을 확인한다. * 올바른 정책 위치를 수정했는가? * 기존 정책을 중복하지 않았는가? * 변경 범위가 예산 안에 있는가? * 테스트가 계약을 충분히 검증하는가? * 테스트를 약화하지 않았는가? * public API나 데이터 계약을 몰래 바꾸지 않았는가? * 로그와 metric이 의미적으로 연결되어 있는가? * 에이전트가 놓친 위험은 없는가? ### 18.3 새로운 생산성 지표 기존 지표인 LOC/hour는 위험하다. 에이전트는 LOC를 쉽게 늘린다. 더 나은 지표는 다음이다. ```text Verified Change per Human Review Minute ``` 사람 리뷰 1분당 얼마나 많은 검증된 변경을 안전하게 merge했는가가 중요하다. 보조 지표: * PR review iteration count * post-merge defect rate * rollback rate * CI failure recovery time * agent retry count * files inspected per task * files changed per task * test coverage of Change Contract * blast radius budget violation rate --- # 5부. 조직 적용 ## 19장. 도입 로드맵 ### Phase 0. Baseline 측정 AI 도입 전 현재 상태를 측정한다. * 작업 유형별 lead time * review time * CI failure rate * rollback rate * hotfix rate * test flakiness * cross-service change frequency * post-merge defect * incident root cause 측정 없이 AI를 도입하면 효과를 판단할 수 없다. ### Phase 1. Low-Risk Maintenance 자동화 위험이 낮은 작업부터 시작한다. * lint fix * deprecated API 치환 * 테스트명 개선 * 문서 업데이트 * 타입 annotation 추가 * 로그 필드명 통일 * dead code 후보 탐색 목표는 에이전트 자체보다 workflow와 governance를 안정화하는 것이다. ### Phase 2. Semantic Addressability 개선 주요 도메인 용어를 정리한다. * Domain Term Registry 작성 * AGENTS.md 작성 * 로그명과 테스트명 정리 * preferred name 적용 * legacy alias mapping 이 단계는 에이전트의 bug localization 성공률을 높인다. ### Phase 3. Change Contract 도입 가장 중요하고 자주 바뀌는 도메인부터 계약화한다. * 결제 * 구독 * 주문 * 권한 * 개인정보 * 알림 * 정산 * 추천/랭킹 각 도메인에 “변경하면 반드시 검증해야 하는 것”을 정의한다. ### Phase 4. Agent Work Envelope 강제 작업 유형별 blast radius budget을 도입한다. * bugfix 예산 * refactor 예산 * feature 예산 * high-risk escalation rule CI와 PR bot에서 위반을 감지한다. ### Phase 5. 대규모 유지보수 캠페인 이제 에이전트를 대규모 유지보수에 투입한다. * framework migration * API migration * type hardening * policy extraction * test characterization * observability standardization * security fix rollout * dead code removal 이 단계에서는 에이전트의 코드 생성 능력이 큰 효과를 낸다. 단, contract와 budget 없이 진행하면 기술부채가 늘어난다. ## 20장. 팀 역할의 변화 에이전트 시대에도 개발자는 사라지지 않는다. 역할이 바뀐다. 개발자의 핵심 역할은 다음으로 이동한다. * 도메인 경계 정의 * 변경 계약 설계 * 테스트 oracle 설계 * 아키텍처 제약 집행 * 에이전트 적용 등급 판단 * 위험 예산 설정 * 운영 신호와 코드 연결 * 리뷰 기준 설계 * 실패 패턴을 도구와 구조에 반영 개발자는 단순 코더에서 **Context Governor**, 즉 맥락 관리자가 된다. 이것은 개발자가 덜 기술적이 된다는 뜻이 아니다. 오히려 더 기술적이다. 코드, 도메인, 테스트, 운영, 보안, 조직 구조를 모두 이해해야 한다. ## 21장. 플랫폼 팀의 역할 대기업에서는 개별 제품팀이 모든 하네스와 제약을 직접 만들 수 없다. 플랫폼 팀이 공통 기반을 제공해야 한다. 플랫폼 팀이 제공할 것: * 표준 AGENTS.md 템플릿 * architecture manifest schema * Change Contract catalog * PR evidence bundle generator * blast radius checker * dependency boundary checker * semantic term registry tool * test selection tool * agent sandbox * secret access guard * generated file guard * migration guard * review dashboard 플랫폼 팀의 목표는 “AI 도구 구매”가 아니라 “에이전트가 안전하게 일할 수 있는 paved road”를 만드는 것이다. ## 22장. 경영진을 위한 메시지 경영진은 AI를 도입하면 개발 속도가 몇 배가 될 것이라고 기대할 수 있다. 일부 작업에서는 맞다. 하지만 브라운필드에서는 무조건적이지 않다. 경영진에게 필요한 메시지는 다음이다. 1. AI는 조직의 강점과 약점을 증폭한다. 2. 유지보수성이 낮은 시스템에서는 AI가 부채를 더 빨리 만들 수 있다. 3. 생산성 지표는 코드량이 아니라 검증된 변경량이어야 한다. 4. 사람 리뷰 병목을 줄이려면 evidence와 contract가 필요하다. 5. AI 도입 예산의 상당 부분은 코드베이스 agentability 개선에 써야 한다. AI 코딩 도구 라이선스를 사는 것은 시작일 뿐이다. 진짜 투자는 코드베이스, 테스트, CI, 아키텍처 제약, 도메인 언어 정리에 들어가야 한다. --- # 6부. 연구 의제 ## 23장. 측정 가능한 가설 이 방법론은 주장에 그치면 안 된다. 측정 가능한 연구 프로그램으로 발전해야 한다. ### 가설 1 브라운필드 생산성은 모델 성능보다 변경의 Context Surface Area에 더 민감하다. 측정: * 에이전트가 읽은 파일 수 * tool call 수 * token 수 * 수정 재시도 횟수 * 리뷰 코멘트 수 * 최종 merge 여부 * post-merge defect ### 가설 2 Semantic Addressability를 개선하면 bug localization 성공률이 오른다. 측정: * 첫 검색에서 관련 파일 발견률 * 잘못된 파일 탐색 비율 * 중복 구현 생성률 * 수정 누락률 ### 가설 3 Change Contract가 있는 작업은 단순 테스트만 있는 작업보다 리뷰 부담과 회귀율이 낮다. 측정: * review time * review iteration * CI failure count * rollback rate * post-merge defect ### 가설 4 Blast Radius Budget을 강제하면 agent-generated PR의 merge 가능성이 높아진다. 측정: * changed file count * diff line count * budget violation rate * merge lead time * reviewer rejection reason ### 가설 5 Agent-readable architecture artifact는 AGENTS.md 단독보다 장기적으로 더 큰 효과를 낸다. 측정: * dependency violation rate * wrong-layer modification rate * architecture review comment count * cross-context regression count ## 24장. 실험 설계 ### 24.1 저장소 단위 실험 같은 유형의 작업을 agentability 개선 전후로 비교한다. 전: * AGENTS.md 없음 * 용어 불일치 * 계약 없음 * 관련 테스트 찾기 어려움 후: * AGENTS.md 있음 * Domain Term Registry 있음 * Change Contract 있음 * test command 명시 * architecture manifest 있음 비교: * 성공률 * 소요 시간 * 리뷰 시간 * 변경 파일 수 * CI 실패 수 * post-merge defect ### 24.2 작업 유형별 실험 작업을 Level 1~4로 나누고 에이전트 효과를 측정한다. 예상 결과: * Level 1은 높은 자동화율 * Level 2는 contract 유무에 따라 성공률 차이 * Level 3은 사람 승인 지점이 중요 * Level 4는 탐색과 검증 보조 중심 ### 24.3 CSA와 실패율 상관 분석 작업별 CSA proxy를 수집한다. * 읽은 파일 수 * 변경 파일 수 * 관련 서비스 수 * 관련 테스트 수 * 관련 도메인 용어 수 * tool call 수 CSA가 커질수록 실패율, 리뷰 시간, 재시도 횟수가 증가하는지 분석한다. ## 25장. 용어 정리 ### Codebase-as-Harness 코드베이스 자체를 에이전트가 일하기 좋은 작업장으로 설계하는 관점. 프롬프트나 도구만 개선하는 것이 아니라, 코드 구조·테스트·문서·로그·CI·아키텍처 제약까지 함께 정비한다. ### Agentability 코드베이스가 에이전트에 의해 안전하게 탐색, 수정, 검증, 리뷰될 수 있는 정도. 쉬운 말로 에이전트 친화도다. ### Context Surface Area 변경 하나를 안전하게 수행하기 위해 에이전트가 찾아보고 이해해야 하는 정보의 총량. 쉬운 말로 작업 맥락의 크기다. ### Semantic Addressability 도메인 개념과 정책이 일관된 이름을 통해 검색 가능한 성질. 쉬운 말로 의미 있는 이름으로 찾을 수 있는 정도다. ### Change Contract 특정 변경 유형이 만족해야 하는 도메인, API, 데이터, 보안, 운영 조건의 실행 가능한 계약. 쉬운 말로 변경할 때 지켜야 할 약속이다. ### Agent-Readable Architecture 아키텍처 경계와 제약을 에이전트와 자동화 시스템이 읽고 집행할 수 있는 형식으로 표현한 것. 쉬운 말로 에이전트가 읽을 수 있는 설계 지도다. ### Blast Radius Budget 작업 유형별 허용 변경 범위와 escalation 조건. 쉬운 말로 변경 범위 예산이다. ### Evidence Bundle 에이전트가 PR 또는 작업 결과에 첨부해야 하는 탐색, 판단, 검증 증거 묶음. 쉬운 말로 작업 근거 묶음이다. --- # 결론 에이전트 시대의 소프트웨어 엔지니어링은 단순히 AI에게 코드를 쓰게 하는 문제가 아니다. 진짜 문제는 브라운필드 시스템을 에이전트가 안전하게 작업할 수 있는 대상으로 바꾸는 것이다. 이를 위해서는 기존 소프트웨어 엔지니어링을 버리는 것이 아니라 더 정밀하게 발전시켜야 한다. DDD는 검색 가능한 도메인 언어가 된다. Clean Architecture는 작업 맥락을 줄이는 구조가 된다. DRY는 동작 규칙의 단일 출처가 된다. TDD는 실행 가능한 변경 계약이 된다. CI/CD는 에이전트 작업 관문이 된다. Observability는 운영 신호와 코드의 연결이 된다. Code Review는 근거 중심 변경 관리가 된다. 앞으로의 생산성 차이는 어떤 모델을 쓰느냐만으로 결정되지 않는다. 같은 모델을 쓰더라도 어떤 조직은 빠르고 안전하게 변경을 merge할 것이고, 어떤 조직은 더 많은 코드를 만들고 더 많은 부채를 쌓을 것이다. 차이는 코드베이스의 agentability에서 나온다. 좋은 코드베이스는 사람이 읽기 쉬운 코드베이스를 넘어선다. 좋은 코드베이스는 에이전트가 관련 맥락을 찾을 수 있고, 권위 있는 정책 위치를 식별할 수 있고, 작은 diff를 만들 수 있고, Change Contract로 검증할 수 있고, 위험한 변경에서 멈출 수 있는 코드베이스다. 이것이 Codebase-as-Harness다. 그리고 이것이 브라운필드 소프트웨어 엔지니어링의 다음 단계다.]]> https://hyukjin-lee.github.io/tech/2026/05/guideofsoftwareengineeringinagentera https://hyukjin-lee.github.io/tech/2026/05/guideofsoftwareengineeringinagentera Thu, 21 May 2026 00:00:00 GMT https://hyukjin-lee.github.io/daily/2026/05/boris-cherny https://hyukjin-lee.github.io/daily/2026/05/boris-cherny Wed, 20 May 2026 00:00:00 GMT https://hyukjin-lee.github.io/daily/2026/04/the-essence-of-business-is-the-product https://hyukjin-lee.github.io/daily/2026/04/the-essence-of-business-is-the-product Tue, 07 Apr 2026 00:00:00 GMT 재즈 고인물들이 가장 짜릿함을 느끼는 순간은 연주자가 화성적으로 아슬아슬한 줄타기를 할 때입니다. > > - **아웃 플레이(Out Playing):** 기본 코드에서 벗어난 듯한 기괴하거나 불협화음 같은 소리를 내다가, 다시 원래의 조성으로 매끄럽게 돌아오는 순간이 있습니다. 이 '긴장(Tension)'과 '해소(Resolution)'의 반복은 감상자에게 엄청난 카타르시스를 줍니다. > > ... > > 세상의 모든 감정이 '도-미-솔'처럼 예쁘기만 할까요? 슬픔, 분노, 혼란, 혹은 술에 취한 듯한 나른함은 깨끗한 화음만으로는 표현하기 부족합니다. > > - **거친 숨소리와 비명:** 어떤 재즈 연주자들은 악기로 비명을 지르거나 쇳소리를 냅니다. 이는 세련된 음악적 질서보다 **연주자의 날것 그대로의 감정**을 전달하는 데 우선순위를 두기 때문입니다. > - **불협화음의 철학:** "인생 자체가 완벽하게 조화롭지 않은데, 왜 음악만 그래야 하는가?"라는 질문이 재즈의 밑바닥에 깔려 있습니다. 조화롭지 않은 음들이 모여 결국 하나의 곡을 완성하는 과정 자체가 재즈가 세상을 바라보는 방식이기도 합니다. 인공지능 덕분에 예술 감상의 진입장벽이 낮아져서 좋은 시간을 보냈다. ---  호텔로 돌아가려고 나왔는데 비가 쏟아지고 있었다. 우산도 호텔에 두고 왔고 택시도 잡히지 않았다. 걸어서 30분 거리를 그냥 비 맞고 걷기로 한다. 사진기사님들이 와이탄 거리에서 비 맞으며 걸어가는 나를 신기하게 보고 *'사진 찍어줄까?'*라고 물어봤다. 속으로 *'장난하냐..'*라고 생각하며 그냥 No~를 외치며 지나갔다. 숙소에 도착하니 샤워한 것처럼 전신이 젖어 있었다. 오랜만의 경험이라 기분은 좋았다. 옷은 말리면 되니까. --- # 3일차 ### 초우초우(훠궈), 딘타이펑(샤오롱바오), 아마수작(수제밀크티)      오늘은 숙소에서 뒹굴뒹굴하다가 훠궈나 먹자라는 생각으로 검색을 시작했다. 하이디라오는 너무 뻔하고 ***'초우초우'***라는 곳이 현지인들에게 인기라고 한다. *'IAPM'*이라는 대형 쇼핑몰에 있다길래 택시 타고 출발했다. 도착했는데 문은 아직 안 열었고, 내 눈에는 맛있어 보이는 라멘집이 막 오픈을 하려고 하는 모습이 보였다. 일단 맛만 보자라는 생각으로 들어갔는데 살면서 먹어본 라멘 중에 가장 맛없었다. 돈과 위를 낭비했다. 그리고 두 번째로는 딤섬 맛집인 딘타이펑을 발견해서 웨이팅 없이 오픈과 동시에 샤오롱바오를 먹었다. 이건 진짜 맛있었다. 귀국해서도 계속 생각나서 정지선 셰프의 냉동 샤오롱바오를 사 먹었는데 이 맛이랑 비슷했다. 아무튼 30분 만에 두 끼를 먹었다. 마지막으로는 원래 목적이었던 초우초우에 갔다. 그런데 생각보다 가격이 비싸길래 런치 1인 세트를 시켜서 먹었더니 그냥 한국에서 먹는 맛이었다. 쏘쏘. 마침 이곳에 *'아마수작'* 밀크티가 있다고 해서 찾아가 봤다. 그런데 웨이팅을 거의 30분 이상 했다. 아마수작은 할머니가 직접 손으로 만드는 밀크티라는 뜻이다. 그래서인지 모든 직원들이 직접 찹쌀떡을 손수 쪄서 밀크티를 정성스레 만드는 듯했다. 맛은 있었다. ### 팝마트  중국에 와서 가장 고민거리였던 부분이 기념품이다. 아이와 아내를 위한 선물을 사야 하는데 도대체 중국에선 무엇을 사야 하는가? 중국의 이미지가 그렇다 보니 답을 찾지 못해서 빈손으로 돌아갈 판국이었는데 마침 아내가 요즘 텔레토비 키링이 유행이니 팝마트에 가서 하나 사오라는 미션을 주었다. 그래서 난징동루로 이동해서 아내와 아이의 선물을 샀다. 사람이 굉장히 많았다. 그리고 텔레토비 캐릭터는 랜덤 뽑기였다. 뽀, 나나가 뽑히길 기대하며 신중히 골랐는데 요즘 텔레토비는 4종류가 아니라 8종류라서 확률이 극악이더라. 근데 나는 운 좋게 나나를 뽑았다. ### 황푸강 페리 (400원)  ![]() 마지막 날인데 이대로 숙소로 가기엔 아쉬움이 남았다. 그래서 비싼 유람선 말고 일반 시민들이 타는 400원짜리 한강버스 *'황푸강 페리'*를 타러 갔다. 알리페이에서 티머니 같은 대중교통 기능을 활성화시키고 결제한 다음에 탑승했다. 비가 오지만 아주 멋진 풍경을 뒤로하며 와이탄에서 *'푸동'* 쪽으로 건너갔다. 영상으로 멋진 풍경을 남겼는데 아쉽게도 용량 때문에 블로그에 첨부는 못한다. 옛 정장 차림의 호탕한 할아버지가 웃는 얼굴로 나에게 중국어로 사진 좀 찍어달라고 하셨다. 너무 자연스럽게 말씀하셔서 '내가 중국인처럼 생겼구나' 라는 생각이 들 정도였다. 오래된 스마트폰으로 열심히 사진을 찍어드리니 어느새 강 건너 '푸동'에 도착했다. ### 푸동 미술관     갑자기 나는 왜 미술관에 오게 된 걸까. 마지막 밤인데 푸동에서 난 뭘 하고 싶은 걸까? 답이 미술 작품 감상..은 아니었다. 다만 와이탄(푸시)에서 푸동 쪽을 바라보는 야경은 질리도록 봤기에, 푸동에서 푸시를 바라보는 야경도 봐보는 건 어떨까? 라는 생각으로 네이버에 아무 생각 없이 검색을 해보았다. 타워에 올라가서 보는 것보다 푸동 미술관 옥상에서 바라보는 뷰를 추천한다는 어느 카페의 글을 보고 미술관에 무작정 왔다. 선착장에서 택시를 아무리 잡아도 퇴근 시간이라 안 잡히길래 30분 정도 그냥 걸었다. 확실히 푸동은 고급스러운 느낌이 난다. 음식점들도 비싸 보이고 한적하고 건물들도 웅장했다. 미술관에 도착해 보니 피카소 작품 전시회를 하고 있었다. 회사 팀장님이 미술에 조예가 깊으셔서 팀 소풍으로 미술관을 몇 번 가서 도슨트를 들어본 게 다였던 나에게는 여전히 미술 작품 감상은 어려운 일이었다. 그래서 이번에도 나의 친구 '제미나이'에게 작품 도슨트를 부탁하며 나름 흥미로운 시간을 보냈다. 작품 사진과 작품 설명을 함께 찍어서 미술관 큐레이터와 피카소 고인물 페르소나를 입히고 작품의 배경과 의미, 그리고 시대적 상황 등을 자유롭게 물어보며 감상했다. 그 내용들 중에는 잘못된 내용도 많겠지만, 내가 전문가가 되고자 함이 아니라 이 시간을 조금이나마 더 의미 있게 보내고 싶은 초심자의 입장이라 편안한 마음으로 감상했다. 그 덕에 마감 시간까지 꽉 채워버렸고 허리도 아작났다. 아무튼 옥상에 도착하니 새로운 느낌의 장관이 펼쳐졌다. ### 미술관 옥상 & 레스토랑    미술관 옥상에서 넓게 펼쳐진 야경은 마치 유럽처럼 느껴졌다. 사진보다 훨씬 느낌이 좋았고 기대 이상이어서 만족스러웠다. 다만 비가 계속 내려서 오랫동안 밖에 있지는 못했다. 마침 옥상에는 레스토랑이 있었다. 이것은 사전에 인지하지 못했었는데 혼자이기도 하고, 돈을 예상보다 많이 쓴 상태여서 가격을 모르는 상태로 입장하기가 좀 그랬다. 하지만 마지막 밤이라는 글자가 머릿속에 한번 스쳐 지나가자 에라 모르겠다 정신으로 과감하게 레스토랑으로 직진했다. 비싸봐야 얼마나 비싸겠나? 입장했을 때 평일이라 그런지 생각보다 한산했다. 덕분에 혼자인 나에게도 창가 자리를 주었다. 외국인은 나 혼자였고 직원들은 미슐랭 레스토랑만큼 훌륭한 서비스를 해주셨다. 나는 간단하게 맥주 한 잔할 생각으로 들어왔기 때문에 메인 디시급은 필요하지 않았다. 모든 메뉴가 가격이 사악해서 고민이 되었으나, 적당한 가격의 사이드 파스타가 있어서 맥주와 함께 주문했다. 내가 사이드 메뉴 1개만 주문했음에도 불구하고 직원은 매우 친절하게 나를 대해주었다. 이어폰을 꽂고 팟캐스트를 들으며 죽이는 야경과, 죽이는 맥주, 죽이는 파스타로 여행을 마무리했다. 이때 마신 벨기에 맥주가 너무 맛있어서 찾아보았으나 아쉽게도 우리나라에는 유통되지 않는다. 그런데 같은 벨기에 맥주 중에 똑같은 맛이 나는 게 호가든이었다. 그래서 귀국 후에 호가든만 거의 8캔 먹은 듯하다.  이제 집에 가자 --- # 4일차 새벽 4시에 일어나서 택시를 잡고 공항으로 이동했다. 푸동공항은 인천공항이랑 거의 비슷하게 생겼다. 이것마저 따라 했네라고 해도 믿을 정도로.  생각보다 빨리 게이트로 넘어왔다. 시간이 많이 남은 김에 라운지를 찾아갔다. 음식은 아직 오픈 전이었고 완탕면을 우선 주길래 받아서 먹다가 모닝 술과 딤섬을 먹고 누워서 쉬다가 비행기 타고 귀국했다. 생각해보니 혼자 하는 해외여행은 이번이 처음이었다. 제주도는 혼자 여행한 적이 있는데 그때와 느낌은 비슷한 것 같다. 혼자 가면 뭐든지 할 수 있을 것 같고 자유로운 느낌을 기대하며 출발하지만, 결과적으로는 불편함과 제약이 따르더라도 누군가와 함께해야 좋은 기분을 나눌 수가 있는 것 같다. 나라는 사람은 그런 사람이라는 걸 다시 한번 깨닫고 간다. 그래도 나름 지금까지 계속 생각나는 여행이다. 즐거웠다 상하이. ]]> https://hyukjin-lee.github.io/blog/2026/04/shanghai-alone https://hyukjin-lee.github.io/blog/2026/04/shanghai-alone Fri, 20 Mar 2026 00:00:00 GMT 아이는 확실히 당신의 생산성을 떨어뜨린다. 어떤 사람들은 아이를 낳으면 정신을 차리고 더 체계적으로 살기도 하지만, 이미 충분히 체계적으로 살고 있었다면, 그걸 할 시간이 줄어든다. 특히 일정에 맞춰 일해야 한다. 아이에게는 스케줄이 있다. 그게 아이들의 본성 때문인지, 아이의 삶을 어른의 삶과 통합하려면 그 방법밖에 없어서인지는 모르겠지만, 아이가 생기면 대체로 아이 스케줄에 맞춰 움직이게 된다. > > 일할 수 있는 시간 덩어리들은 생긴다. 하지만 예전처럼 일과 삶이 뒤섞여 아무 때나 일이 삶 전체에 흘러넘치게 둘 수는 없다. 영감이 오든 말든 매일 같은 시간에 일해야 하고, 영감이 한창이어도 멈춰야 하는 순간들이 생긴다. 나는 이런 방식에 적응할 수 있었다. 일도 사랑처럼 길을 찾아낸다. 할 수 있는 시간이 정해져 있으면, 그 시간에 하게 된다. 그래서 아이 낳기 전만큼 많은 일을 하지는 못하지만, 충분히는 한다. > > 말하기 싫지만(야망은 늘 내 정체성의 일부였으니까), 아이를 갖는 건 사람을 덜 야망 있게 만들 수도 있다. 그 문장을 써놓고 보니 괴롭다. 나는 그걸 인정하기 싫어서 몸을 비틀게 된다. 하지만 뭔가 실체가 없었다면, 왜 그렇게 비틀릴까? 사실 아이가 생기면, 대개 자기 자신보다 아이를 더 신경 쓰게 된다. 그리고 주의력은 제로섬 게임이다. 머릿속에서 ‘가장 중요한 생각’은 한 번에 하나만 있을 수 있다. 아이가 생기면 그 자리를 아이가 차지하는 경우가 많아지고, 그러면 내가 하던 어떤 프로젝트가 그 자리를 차지하는 경우는 줄어든다. > > 나는 그 바람을 정면으로 맞지 않고 최대한 가까이 항해하기 위한 꼼수들도 몇 가지 쓴다. 예컨대 에세이를 쓸 때, 내 아이들이 알았으면 하는 것들을 생각한다. 그러면 정확하게 쓰고 싶어져서 더 잘하게 된다. 또 내가 「Bel」을 쓰고 있을 때는, 다 쓰면 아이들을 아프리카에 데려가겠다고 말했다. 어린아이에게 그런 말을 하면 그들은 그걸 ‘약속’으로 받아들인다. 그래서 나는 끝내지 않으면 그들의 아프리카 여행을 빼앗는 사람이 되는 셈이었다. 정말 운이 좋다면 이런 속임수들이 결과적으로 내게 도움이 될 수도 있다. 하지만 그 바람(아이 때문에 주의가 분산되는 힘)은 분명 존재한다. > > 반면, 아이가 생겼다고 살아남지 못할 야망이라면, 그건 너무 나약한 야망 아닌가? 그렇게까지 여유가 없다는 건가? 그리고 아이를 갖는 일이 내 현재 판단을 비틀고 있을지는 몰라도, 내 기억을 덮어쓰진 못했다. 나는 아이를 갖기 전 삶이 어땠는지 아주 잘 기억한다. 그래서 어떤 것들은 많이 그립다. 예를 들면, 갑자기 마음이 내키는 순간 다른 나라로 훌쩍 떠날 수 있었던 자유. 그건 정말 좋았다. 그런데 나는 왜 그걸 거의 안 했을까? 방금 내가 뭘 했는지 보이는가? > > 사실 아이 갖기 전 내가 가졌던 자유의 대부분을 나는 사용하지 않았다. 그 자유의 대가로 외로움을 치렀지만, 정작 쓰지도 않았다. 아이 낳기 전에도 행복한 순간들은 많았다. 하지만 ‘잠재적 행복’이 아니라 실제로 행복했던 순간들을 세어보면, 아이가 생긴 뒤가 그 전보다 더 많다. 요즘은 거의 수도꼭지에서 틀면 나오는 수준이다. 특히 거의 매일 밤, 아이 재우는 시간쯤에. > > 부모로서의 경험은 사람마다 크게 다르고, 나는 운이 좋았다는 것도 안다. 하지만 아이를 갖기 전 내가 했던 걱정들은 꽤 흔할 것 같고, 다른 부모들이 아이를 볼 때의 표정을 보면, 아이가 주는 행복 역시 그만큼 흔한 것 같다. > > Having Kids - Paul Graham > - 인간이 얼마나 놀라운지 이해하는 가장 좋은 방법은, 아이가 매일 ‘완전한 처음’에서부터 그 모든 게 펼쳐지는 장면을 맨 앞자리에서 보여주는 것이다. 아이는 당신에게 당신 인생의 첫 4년을 다시 돌려준다. > > - 내 아이가 내가 아이를 가르치는 것만큼이나 나를 가르치게 될 줄은 정말 몰랐다. > > - 아이를 키우는 건 마라톤을 뛰는 것과 비슷하다. 엄청난 도전이지만, 그만큼 가치 있고 사람을 바꿔놓는 경험이다. 그 모든 노력 끝에 정말 무언가를 해냈다는 느낌을 남긴다. 결국 당신은 꽤 놀라운 걸 만들어냈으니까. 한 사람을. > > On Parenthood - Coding Horror > 밥: 아이가 생기면 훨씬 더 복잡해져. > > 샬럿: 무서워. > > 밥: 인생에서 가장 무서운 날은 첫째가 태어나는 날이야. > > 샬럿: 아무도 그런 건 말해주지 않지. > > 밥: 네가 알던 삶은… 끝이야. 다시는 돌아오지 않아. 하지만 아이들이 걷는 법을 배우고, 말하는 법을 배우고, 그러면 너는 그들과 함께 있고 싶어져. 그리고 결국, 그 애들은 네 인생에서 만날 사람들 중 가장 사랑스럽고 즐거운 사람들이 돼. > > Lost in Translation(2003) ]]> https://hyukjin-lee.github.io/daily/2026/01/having-kids https://hyukjin-lee.github.io/daily/2026/01/having-kids Wed, 07 Jan 2026 00:00:00 GMT 강의할 때 학생들에게 많이 하는 말은? → “좋은 음악을 많이 듣고 음반을 사라" 음원시장으로 바뀌면서 음악이라는게 형태가 없는 것이 되었다. 어떤 형태가 있고 없고가 엄청난 감성의 차이를 가져오는 거 같다. 좋은 감성을 키우고 좋은 감성을 얻으려면 내 손으로 만져지는 어떤 물건들이 있어야 하지 않나 싶다. 앨범들이 그렇지 않나. 갖고 싶은 LP, CD 를 소유하기 위해 내가 했던 노력들. 거기서 벌어진 수많은 이야깃거리들. 그런 것들이 다 감성의 밑받침이 된다고 생각한다. **그런 이야깃거리가 없으니까 음악에 대한 열정도 금방 식어버리는 거고**. 음악은 다 그런 것에서 출발하는 거 같다. 그래서 학생들에게는 음반을 사라고 한다. 직접 CD 를 사고 LP 를 모으고 그런 것을 좀 해라. 그게 너희들이 앞으로 음악하는데에 엄청난 도움이 될 것이라고 말한다. [https://www.youtube.com/watch?v=mrA99flVsfU](https://www.youtube.com/watch?v=mrA99flVsfU) 본인의 업에 대한 자세라는 측면에서, 음악 뿐만 아니라 모든 분야에도 적용되는 말처럼 와닿았다.]]> https://hyukjin-lee.github.io/daily/2026/01/naul-feedback https://hyukjin-lee.github.io/daily/2026/01/naul-feedback Sun, 04 Jan 2026 00:00:00 GMT 이 글은 사내 세미나 발표 대본을 바탕으로, AI를 활용해 블로그 글 형태로 재구성했습니다. ## 1장: 열광과 불안의 시대 --- ### 1.1 넘치는 소음 현대 소프트웨어 생태계는 LLM이 촉발한 전례 없는 변화의 소용돌이 속에 놓여 있다. "개발자의 종말"을 예고하는 종말론적 전망부터, 새로운 도구를 통해 생산성의 극대화를 경험했다는 찬사에 이르기까지, 다양한 담론들이 소셜 미디어와 기술 커뮤니티를 점령했다. 이러한 현상은 단순한 기술 트렌드의 유행을 넘어, 지식 노동자들에게 자신이 가진 역량의 가치가 훼손될지 모른다는 실존적 불안을 야기하고 있다. 물론 LLM은 코드를 생성하고 정보를 다루는 실무적 영역에서 효용을 입증했다. 그러나 도구의 실질적 효용성을 넘어선 과잉 기대와 FOMO 현상이 모두의 눈을 가리고 있지 않는가라는 본질적인 의문을 갖게 한다. 우리는 기술이 약속하는 환상에 매몰되어 있는 것은 아닌가? --- ### 1.2 기술 만능주의의 반복 우리는 이미 기술이 모든 사회적, 구조적 문제를 해결해 줄 것이라는 ‘기술 만능주의’의 흥망성쇠를 여러 차례 목격해 왔다. 탈중앙화된 신뢰 시스템을 표방했던 블록체인은 혁명적인 이상에도 불구하고, 실질적인 산업 적용보다는 투기적 자산으로서의 측면이 부각되는 결과를 낳았다. 또한, 사용자의 취향을 완벽히 이해하리라 믿었던 추천 알고리즘은 엘리 파리저가 경고했던 ‘필터 버블’ 현상을 초래하며, 확증 편향을 강화하고 지적 고립을 심화시켰다. "세상을 연결한다"는 '소셜 네트워크'의 초기 비전 역시, 연결의 과잉이 낳은 혐오와 가짜 뉴스의 확산이라는 역설적 부작용에 직면했다. 기술의 역사는 언제나 장밋빛 청사진과 냉혹한 현실 사이의 간극을 좁혀가는 과정이었다. LLM 또한 이 역사적 패턴에서 예외일 수 없다. 지금의 열광이 걷히고 난 뒤, 남겨질 본질적인 가치와 부작용은 무엇인가를 냉철하게 직시해야 할 시점이다. --- ### 1.3 글의 목적 이 글은 LLM을 둘러싼 과도한 거품을 걷어내고, 확률적 기계로서의 본질을 규명하기 위한 시도다. LLM은 인간 지성을 완벽히 대체하는 인격체가 아니며, 방대한 데이터 패턴을 기반으로 다음 토큰을 예측하는 고도화된 도구다. 따라서 본 글에서는 다음과 같은 흐름으로 논의를 전개하고자 한다. - **본질의 이해:** 통계적 언어 모델이 어떻게 '이해'하는 착시를 일으키는지에 대한 기술적, 철학적 탐구. - **가치와 한계의 균형:** '치매 걸린 천재'로 비유되는 LLM의 할루시네이션 문제와 빅테크 주도의 산업적 맥락 고찰. - **실천적 방법론:** 도메인 주도 설계 및 레거시 시스템 내에서의 에이전트 활용 등, 확률적 도구를 통제 가능한 엔지니어링의 영역으로 끌어들이는 리터러시. - **미래 전망:** 이 기술적 과도기에서 엔지니어가 갖추어야 할 태도. 결론적으로, 우리는 LLM을 맹신하거나 배척하는 양극단을 지양하고, 도구의 원리와 한계를 명확히 인지한 상태에서 주체적으로 협업하는 역량을 길러야 한다. 이것이 확률 기계와 공존하는 시대에 우리가 취해야 할 올바른 자세다. --- ## 2장: LLM의 본질적 이해 --- ### 2.1 블랙박스 해체 도구를 온전히 사용하기 위해서는 그 도구의 작동 원리에 대한 감을 잡아야한다. 망치라는 단순한 도구도 못을 박을 때 어느 각도로 내리쳐야 하는지, 어느 정도의 힘으로 쳐야 못이 휘지 않는지, 경험을 쌓으며 감이 생겨난다. LLM 의 사용 또한 마찬가지다. 입력된 프롬프트에 대해 모델이 확률적으로 어떠한 응답을 내놓을지 예측할 수 있는 직관, 즉 **‘확률적 감각’**이 부재한다면 LLM은 그저 불투명한 블랙박스에 불과하다. **블랙박스에 중요한 의사결정을 위임하는 것은 공학이 아니라 도박이다.** 먼저 기술적 원리를 논하기에 앞서, 이 기술이 뿌리내리고 있는 철학적 토대를 먼저 살펴보려 한다. --- ### 2.2 비트겐슈타인의 언어철학 19세기 말, 서구 철학계는 혼돈의 시기였다. "절대정신"이나 "우주의 본질"과 같은 형이상학적 개념들은 명확한 정의 없이 남발되었고, 2천 년이 넘도록 결론 없는 논쟁만 반복되었다. 그리고 같은 시기에 자연 과학은 눈부신 발전을 이루고 철학의 입지는 점점 줄어들고 있었다. 이에 대한 회의감 속에서 일부 철학자들은 근본적인 질문을 던졌다. "우리가 세계를 인식하는 도구인 '언어' 자체에 결함이 있는 것은 아닌가?" 더러운 안경을 쓰고 세상을 보면 세상이 흐릿해 보이듯, 불완전한 언어로 사고하면 세계를 올바르게 인식할 수 없다. 이러한 문제의식 하에 철학의 대상을 '세계'에서 '언어'로 전환하려는 시도, 즉 언어적 전회가 일어났다. 그리고 그 중심에 루트비히 비트겐슈타인이라는 한 철학자가 있었다. #### 전기 사상: 그림 이론과 고정된 의미 초기 비트겐슈타인은 그의 저서 《논리철학논고》를 통해 **"언어는 세계를 묘사하는 논리적 그림"**이라고 주창했다. 그의 초기 이론에 따르면, 명제는 실제 세계의 사실과 1:1로 대응해야 한다. 예컨대 "사과가 책상 위에 있다"는 문장은 검증 가능하므로 유의미하지만, "신은 위대하다"와 같이 현실 세계의 대상과 대응되지 않는 명제는 무의미한 헛소리에 불과하다. 그는 "말할 수 없는 것에 대해서는 침묵해야 한다"는 유명한 문장을 남기고, 철학의 모든 문제를 해결했다며 은퇴했다. #### 전기 사상의 결함: 스라파의 제스처 그러나 비트겐슈타인의 완벽했던 논리 세계는 동료 경제학자 피에로 스라파와의 대화에서 무너져 내렸다. 비트겐슈타인이 "모든 명제는 논리적 형식을 가져야 한다"고 주장하자, 스라파는 턱을 손으로 쓸어내리는 이탈리아 특유의 제스처(회의감을 표현하는 동작)를 취하며 물었다. > "그렇다면 이 제스처의 논리적 형식은 무엇인가?" 이 단순한 질문은 비트겐슈타인에게 충격을 주었다. 일상 언어와 소통 행위는 고정된 논리만으로는 설명할 수 없는 가변적인 맥락 속에 존재함을 깨달은 것이다. #### 후기 사상: 언어 게임 비트겐슈타인은 후기 저작 《철학적 탐구》를 통해 자신의 전기 사상을 전면 부정한다. 그는 **"단어의 의미는 고정된 대상에 있는 것이 아니라, 언어 안에서의 사용에 있다"**고 선언했다. 예를 들어 'Bank'라는 단어는 그 자체로 고정된 의미를 갖지 않는다. 'River(강)'라는 단어와 함께 쓰일 때는 '강둑'이 되지만, 'Money(돈)'라는 단어와 함께 쓰일 때는 '은행'이 된다. 즉, 언어는 고정된 규칙의 집합이 아니라, 맥락에 따라 규칙이 끊임없이 변화하는 일종의 **'게임'**과 같다. #### 철학적 사유와 NLP 발전사의 평행이론 놀랍게도, 지난 수십 년간 인공지능과 자연어 처리가 걸어온 길은 비트겐슈타인의 철학적 여정과 매우 유사하다. | 발전 단계 | 철학적 사상 | NLP 기술 모델 | | ------- | ----------------- | --------------------------- | | **1단계** | 전기 비트겐슈타인 (그림 이론) | Word2Vec (고정 임베딩) | | **2단계** | 스라파의 제스처 (맥락의 발견) | Attention Mechanism (맥락 인식) | | **3단계** | 후기 비트겐슈타인 (언어 게임) | Transformer (다차원적 맥락 처리) | - **Word2Vec과 고정성:** LLM 이전의 NLP 모델인 Word2Vec은 각 단어에 고정된 벡터값을 부여했다. 이는 단어와 대상을 1:1로 매핑하려 했던 전기 비트겐슈타인의 시도와 닮았다. 여기서는 '배(Ship)'와 '배(Pear)'를 문맥 없이 동일한 좌표로 인식하는 한계가 있었다. - **Attention과 맥락:** 스라파의 제스처가 비트겐슈타인에게 '맥락'을 일깨웠듯, 딥러닝의 Attention 메커니즘은 모델이 문장 내의 주변 단어들을 참조하여 의미를 파악하게 만들었다. 'Bank' 옆에 'Money'가 있는지 'River'가 있는지를 비로소 보게 된 것이다. - **Transformer와 언어 게임:** 현대 LLM의 기반인 Transformer 아키텍처는 '멀티 헤드 어텐션'을 통해 문법, 의미, 뉘앙스 등 다양한 층위의 언어 게임 규칙을 동시에 학습한다. 이는 단어의 의미가 사용되는 맥락에 따라 결정된다는 후기 비트겐슈타인의 통찰을 공학적으로 완벽하게 구현한 것이다. #### 진리가 아닌 패턴의 학습 이러한 역사적, 철학적 맥락을 통해 우리는 LLM의 본질에 도달할 수 있다. LLM은 세상의 '진리'를 학습/답변하는 기계가 아니다. 그것은 인류가 남긴 방대한 텍스트 데이터 속에서, 단어들이 어떻게 배열되고 사용되는지에 대한 **'패턴과 용례'**를 무수히 학습하여 답변하는 통계적 언어 게임 플레이어다. 이 원리를 이해할 때, 우리는 비로소 LLM이 내놓는 답변을 맹신하지 않고, 확률적으로 생성된 '가장 그럴듯한 텍스트'로서 냉정하게 바라볼 수 있게 된다. --- ### 2.3 기술적 해부 #### 마법이 아닌 통계 많은 이들이 AI의 유창한 언어 구사 능력을 보며 기계 안에 인격이나 지성이 형성되어 있을 것이라는 착각, 즉 '의인화의 오류'에 빠지곤 한다. 그러나 이 현상의 이면을 들추어보면, 그곳에는 마법이 아닌 고도로 정제된 수학과 확률 분포만이 존재한다. LLM이 보여주는 '지능적 행위'의 실체는 방대한 데이터 패턴 학습을 통해 단어와 단어 사이의 관계를 계산해 낸 결과물이다. 이를 이해하기 위해서는 현대 NLP(자연어 처리)의 패러다임을 바꾼 세 가지 핵심 기제를 살펴볼 필요가 있다. #### 1단계: 어텐션 메커니즘 인간이 텍스트를 독해할 때, 모든 조사와 관사에 동일한 인지적 에너지를 쏟지 않는다. 우리는 맥락상 중요한 키워드에 집중하고, 그 단어들 간의 연결 고리를 파악한다. 과거의 순환 신경망 모델들은 이 단순한 인간의 인지 방식을 모방하지 못했다. 문장이 길어질수록 앞부분의 정보를 망각하는 '장기 의존성 문제'를 겪었기 때문이다. 예컨대, 문장 초반에 등장한 주어 '철수'가 문장 끝의 서술어 '먹었다'와 호응한다는 사실을 기억하지 못했다. **어텐션 메커니즘**의 등장은 이 한계를 극복하는 분기점이었다. 모델은 문장 내의 모든 단어를 동시에 바라보며, 각 단어가 서로에게 얼마나 중요한 영향을 미치는지 **'가중치'**를 계산한다. 이는 텍스트를 선형적인 나열이 아닌, 의미가 얽혀 있는 관계의 그물망으로 파악하게 했다는 점에서 혁신적이다. #### 2단계: 트랜스포머 2017년, 구글 브레인 팀이 발표한 기념비적인 논문 《Attention Is All You Need》는 어텐션 메커니즘을 극대화한 새로운 아키텍처, **트랜스포머**를 세상에 내놓았다. 기존 모델들이 텍스트를 순차적으로 읽어들여야 했던 시간적 제약을 안고 있었다면, 트랜스포머는 데이터를 한꺼번에 병렬적으로 처리하는 구조를 채택했다. 이는 학습 속도와 데이터 처리량의 비약적인 상승을 가능케 했으며, LLM과 같은 거대 모델이 탄생할 수 있는 물리적 기반을 마련했다. 이 구조는 크게 정보를 압축하고 이해하는 **인코더**와, 이해한 정보를 바탕으로 결과를 생성하는 **디코더**로 나뉜다. #### 3단계: GPT OpenAI는 트랜스포머 구조에서 텍스트를 생성하는 '디코더' 부분에 주목했다. GPT(Generative Pre-trained Transformer)는 이름 그대로 트랜스포머를 기반으로 사전 학습된 생성 모델이다. 이들의 학습 방식은 본질적으로 **'다음 토큰 예측'**이라는 단순한 원리로 귀결된다. 모델은 주어진 문맥 x에 대하여 다음에 올 단어 y의 조건부 확률 P(y|x)를 끊임없이 계산한다. 1. "오늘 날씨가"라는 입력이 주어진다. 2. 학습된 수천억 개의 파라미터를 통해 다음에 올 단어들의 확률 분포를 계산한다. (좋네요: 80%, 나빠요: 10%...) 3. 확률적으로 가장 적절한 단어를 선택하여 문장을 이어간다. 4. 생성된 단어를 다시 입력으로 삼아 이 과정을 무한히 반복한다. 이것이 GPT가 '끝말잇기 천재' 혹은 '확률적 앵무새'라 불리는 이유다. #### 결론: 확률적 진실과 환각 누군가 챗GPT의 원리를 묻는다면, 이제 우리는 기술적 엄밀함을 담아 이렇게 답할 수 있다. "인류가 축적한 방대한 텍스트 데이터의 통계적 패턴을 학습하여, 주어진 문맥 다음에 올 단어를 확률적으로 예측하는 기계다." 이 정의는 LLM의 강력함과 한계를 동시에 시사한다. LLM은 '사실'을 말하는 것이 아니라, 문맥상 **'가장 확률이 높은 말'**을 뱉어낼 뿐이다. 따라서 그럴듯한 거짓말, 즉 **할루시네이션**은 버그가 아니라 확률 모델의 본질적인 특성이다. --- ### 2.4 확률의 바다 항해하기 #### 상태 비저장(Stateless)의 환상과 컨텍스트의 실체 우리가 챗봇과 나누는 대화의 연속성은 사실 정교하게 설계된 환상에 불과하다. 기술적 관점에서 LLM은 철저한 상태 비저장 시스템이다. 즉, 모델은 당신과 1초 전에 나누었던 대화조차 기억하지 못한다. 우리가 느끼는 '기억'의 실체는 매 턴마다 재주입되는 **컨텍스트**다. 시스템은 사용자의 새로운 발화가 입력될 때마다, 과거의 모든 대화 로그를 끌어와 하나의 거대한 텍스트 덩어리로 만든 뒤 모델에 다시 입력한다. > Context = System Prompt + sum(Chat Session History) + Current Prompt 모델은 매번 이 거대한 텍스트의 총합을 처음 읽는 것처럼 처리하며, 그 끝에 이어질 가장 그럴듯한 다음 토큰을 확률적으로 계산할 뿐이다. 따라서 대화란 기억의 축적이 아니라, 매번 새롭게 갱신되는 입력 데이터의 재연산 과정이다. #### 어텐션 희석과 'Lost in the Middle' 어텐션 메커니즘은 혁신적이지만, 물리적 한계 또한 명확하다. 컨텍스트 윈도우가 길어질수록, 어텐션이 할당해야 할 확률값은 수많은 토큰으로 분산된다. 이는 **신호 대 잡음비**의 저하를 의미한다. 이미 규명된 'Lost in the Middle' 현상은 이를 잘 보여준다. 모델은 프롬프트의 초반부와 후반부 정보는 잘 포착하지만, 중간에 위치한 정보는 간과하거나 망각하는 경향을 보인다. 정보량이 임계치를 넘어서면, 중요 토큰에 집중해야 할 확률 밀도가 옅어지며, 모델은 맥락을 잃고 표류하게 된다. 이것이 우리가 대화 세션을 주기적으로 초기화해야 하는 공학적 이유다. - **어텐션 분산:** 긴 문맥은 핵심 정보에 대한 집중력을 떨어뜨린다. - **확률 오염:** 현재 주제와 무관한 대화나, 실패한 시도가 컨텍스트에 포함되면 다음 토큰 생성의 확률 분포를 왜곡시킨다. 현대 모델들이 긴 컨텍스트 처리를 위해 개선되고 있다 하더라도, **정보 소실**은 확률 모델이 필연적으로 안고 가야 할 엔트로피와 같다. #### 확률 가지치기: 프롬프트는 조각칼이다 LLM의 응답 생성 과정은 고차원의 잠재 공간에서 이루어지는 **확률적 샘플링**이다. 이 관점에서 프롬프트 엔지니어링의 본질은 다음과 같이 정의될 수 있다. > "프롬프트는 무한한 확률 분포의 가지를 쳐내고, 원하는 결과값의 밀도를 높이는 '조각' 행위다." 우리가 AI의 답변에 실망하는 이유는 모델의 지능 문제라기보다, 확률 분포를 충분히 좁히지 못한 사용자의 미숙 때문일 수도 있다. 단순히 "머신러닝을 설명해줘"라고 입력하는 것은, 모델에게 인터넷상의 가장 평균적이고 보편적인 답변을 요구하는 것과 같다. 반면, 조건을 명시하면 확률 분포는 극적으로 변화한다. "나는 통계학 석사 과정 학생이며, 베이지안 추론에 익숙하다. 정규화를 베이지안 사전 확률의 관점에서 해석해 달라." 이 프롬프트는 모델의 연산 경로를 다음과 같이 강제한다: - "통계학 석사": 대중적이고 얕은 설명의 확률 제거, 수식과 전문 용어의 확률 증가. - "베이지안 관점": 빈도주의적 해석의 가지를 쳐내고, 특정 도메인 지식으로 확률 집중. 나를 뛰어넘는 답변을 얻고 싶다면 **이미 알고 있는 지식을 명시하라.** 이는 모델이 본인의 지적 수준에 맞춰 확률 분포를 재조정하게 만드는 가장 강력한 트리거다. #### 집단 무의식과 페르소나의 정립 LLM은 특정한 자아를 가진 인격체가 아니다. 그것은 인류가 생산한 텍스트 데이터의 총합, 즉 칼 융이 말한 **'집단 무의식'**에 가깝다. 따라서 명확한 지시 없이 코드를 던져주고 "리뷰해줘"라고 요청하는 것은, 무의식의 바다에서 무작위적인 한 명을 골라 리뷰를 부탁하는 것과 같다. 모델은 내부적으로 혼란을 겪는다. ("성능 위주인가? 가독성 위주인가? 주니어 레벨인가? 시니어 레벨인가?") 그 결과, 변수명 개선이나 주석 추가 같은 가장 안전하고 보편적인(피상적인) 답변을 선택한다. 효과적인 상호작용을 위해서는 이 집단 무의식에 구체적인 **가면**을 씌워야 한다. > "너는 대규모 트래픽 처리에 능숙한 10년 차 백엔드 엔지니어다. > 현재 TPS 1,000 상황에서 발생하는 데드락 이슈를 해결하려 한다. > JPA의 락 획득 순서와 트랜잭션 전파 레벨의 관점에서 이 코드를 비판적으로 분석하라." 페르소나 설정은 모델에게 **"당신은 누구인가"**와 **"어떤 관점을 취해야 하는가"**를 정의해 줌으로써, 답변의 벡터 방향을 명확히 설정하는 과정이다. #### 의도 엔지니어링 결국 LLM과의 대화는 확률의 바다에서 내가 원하는 정보를 건져 올리는 과정이다. 성공적인 상호작용을 위한 3원칙은 다음과 같다. 1. **컨텍스트 위생:** 불필요한 정보를 배제하여 어텐션 효율을 높인다. 2. **페르소나 정의:** 집단 무의식에 구체적인 역할과 관점을 부여한다. 3. **확률 조각:** 자신의 배경지식을 명시하여 답변의 수준과 범위를 제어한다. --- ## 3장: 효용과 한계 --- ### 3.1 낮아진 임계점과 가능성의 민주화 #### 혁명이 아닌, '수위'의 변화 앞서 우리는 LLM의 작동 원리를 규명하며 그것이 지닌 '확률적 한계'를 냉철하게 비판했다. 그러나 비판이 기술 혐오로 이어져서는 안 된다. 기술의 가치는 완벽함에 있는 것이 아니라, 그 도구가 인간의 행위 가능성을 어떻게 확장하는가에 있기 때문이다. LLM은 세상을 송두리째 뒤엎는 파괴적 혁명이라기보다, 행동의 임계비용을 획기적으로 낮춘 촉매제에 가깝다. 이를 비유하자면, 만조의 바다를 간조로 바꾸어 놓은 것과 같다. 과거에는 숙련된 해녀만이 깊은 수심에서 채취할 수 있었던 지식과 창조의 산물들이, 이제는 낮아진 수면 덕분에 누구나 허리를 굽히는 수고만으로 주울 수 있는 보편적 자원이 되었다. #### Long-tail 영역의 부상 이러한 비용의 하락은 조직 내 우선순위에서 배제되었던 영역들을 다시 호출한다. 예컨대 '어드민 페이지'와 같은 백오피스 도구들은 고객 가치와 직결되지 않는다는 이유로 영원한 기술 부채로 남겨지곤 했다. 그러나 LLM의 코딩 보조 능력은 이러한 '주변부 과업'의 생산 비용을 극적으로 낮추었다. "두 달이 걸리는 프로젝트"가 "오후 한나절의 실험"으로 치환될 때, 묻혀 있던 아이디어들은 비로소 구현의 기회를 얻는다. 이는 거창한 혁신이 아니라, 비즈니스 우선순위 밖에서 소외되던 작은 시도들이 생명력을 얻는 과정이다. 개인의 차원에서도 마찬가지다. 거시경제의 흐름이나 환율의 변동성 같은 지식은 생존에 필요함에도 불구하고, 학습 비용이 높아 접근하기 어려웠다. LLM은 깊은 학문적 탐구 없이도 삶을 영위하는 데 필요한 수준의 '실용적 문해력'을 제공하며, 전문가와 대중 사이의 간극을 메우는 다리 역할을 수행한다. --- ### 3.2 검색의 종말과 지식의 합성 #### 신호 대 잡음비의 붕괴 우리가 익히 알고 있던 '검색의 시대'는 저물어가고 있다. 2010년대 후반부터 가속화된 검색 품질의 저하는 명백하다. 구글과 같은 전통적 검색 엔진은 SEO(검색 엔진 최적화)로 무장한 콘텐츠 팜과 상업적 블로그, 그리고 앵무새처럼 재생산된 정보들로 오염되었다. 원저자의 깊이 있는 통찰이 담긴 문헌을 찾으려 해도, 그것은 알고리즘에 밀려 검색 결과 5페이지 너머로 사라져 버렸다. 이는 '죽은 인터넷 이론'이 시사하듯, 우리가 마주하는 웹이 인간의 사유보다는 기계적 트래픽 유발 장치들로 채워지고 있음을 의미한다. 이 지점에서 LLM은 '검색'을 '인출과 합성'의 패러다임으로 전환시킨다. 키워드를 통해 파편화된 링크를 탐색하는 것이 아니라, 학습된 방대한 데이터의 총체 속에서 내가 원하는 맥락을 추출하고 요약하게 함으로써, 노이즈를 우회하여 지식의 본질에 접근하는 새로운 경로를 제시한다. --- ### 3.3 언어 장벽의 소멸 #### 정보의 비대칭성 해소 기술 생태계에서 영어는 지식의 패권 언어다. 최신 기술 논문, 오픈소스 커뮤니티의 토론, 심도 있는 컨퍼런스 영상은 모두 영어권에서 생산되고 소비된다. 과거에는 영어를 모국어처럼 구사하는 소수만이 이 정보를 선점하고 번역하여 전파하는 '게이트키퍼'의 권력을 누렸다. 그러나 LLM은 이 언어의 장벽을, 나아가 정보의 비대칭성을 허물어버렸다. Perplexity와 같은 도구는 수 시간 분량의 영상을 즉시 요약하고, Comet AI와 같은 브라우저 확장은 복잡한 GitHub 이슈 토론을 모국어로 정제해 보여준다. 이제 적어도 온라인 상에서 언어 능력은 정보 습득의 필수 조건이 아니다. 지식의 국경이 소멸하고, 전 세계의 데이터가 중개자 없이 개인에게 직거래되는 시대가 도래한 것이다. --- ### 3.4 다원주의적 시각의 획득 #### 에코 챔버을 넘어서 기존의 로컬 검색 엔진과 커뮤니티는 필연적으로 문화적 편향성을 띤다. 육아법이든 역사적 사건이든, 특정 사회 내에서 통용되는 주류 담론만이 '정답'처럼 반복 재생산된다. 이는 사용자를 에코 챔버에 가두는 결과를 낳는다. 반면, 전 지구적 데이터를 학습한 LLM은 태생적으로 다원주의적 속성을 지닌다. 적절한 프롬프팅을 통해 우리는 동학농민운동과 같은 역사적 사건을 조선 정부, 농민군, 일본 제국, 청나라 등 다양한 주체의 시각에서 재구성해 볼 수 있다. 이는 단순히 정보를 얻는 것을 넘어, **"세상에 단 하나의 정답은 존재하지 않는다"**는 인식론적 깨달음을 제공한다. LLM은 나의 관점을 지역적 한계에서 벗어나 글로벌한 맥락으로 확장시키는 인지적 도구로서 기능할 수 있다. --- ### 3.5 한계 - 치매 걸린 천재 #### 200만 토큰의 함정: 희석되는 어텐션과 인지 엔트로피 LLM 시장의 마케팅 문구로 '컨텍스트 윈도우'의 확장이 심심치 않게 보인다. "200만 토큰 지원"과 같은 문구는 마치 AI가 수백 권의 책을 단숨에 읽고, 그 내용을 완벽하게 습득하여 자유자재로 운용할 수 있는 '초월적 기억력'을 갖춘 것처럼 선전된다. 그러나 앞서 2장에서 논의한 트랜스포머 아키텍처의 핵심인 '어텐션 메커니즘'을 상기한다면, 어떻게 과장된 것인지 알 수 있을 것이다. 기술적 관점에서 컨텍스트의 확장은 곧 **어텐션의 희석**을 의미한다. 어텐션 메커니즘은 입력된 모든 토큰 간의 관계를 계산하여 가중치를 할당하는 과정이다. 컨텍스트가 길어질수록, 즉 참조해야 할 정보의 양이 늘어날수록, 개별 토큰에 할당될 수 있는 어텐션 점수는 필연적으로 분산된다. 2만 토큰 환경에서 명확하게 식별되던 핵심 정보가, 200만 토큰의 바다에서는 잡음 속에 묻혀버릴 확률이 기하급수적으로 증가하는 것이다. 더욱 본질적인 문제는 **연산 복잡도**에 있다. 표준적인 어텐션 알고리즘의 연산 비용은 입력 시퀀스 길이의 제곱(O(n^2))에 비례하여 증가한다. 컨텍스트가 10배 늘어나면, 필요한 연산 자원은 100배가 필요하다는 뜻이다. Gemini Pro와 같은 모델들이 긴 컨텍스트 구간에서 과금 정책을 달리하거나, 선형 어텐션, 희소 어텐션, 혹은 KV 캐싱 최적화 기법을 도입하는 이유는 바로 이 물리적 한계를 우회하기 위함이다. 그러나 이러한 최적화 엔지니어링 기법들은 필연적으로 '정확도와의 트레이드오프'를 동반한다. 결국 현재의 LLM은 **'치매 걸린 천재'**라는 역설적인 비유로 정의될 수 있다. 순간적인 추론 능력과 방대한 지식의 인출 능력은 인간을 초월하지만, 긴 호흡의 맥락을 유지하거나, 방대한 정보 속에서 미세한 디테일을 놓치지 않고 기억하는 '작업 기억'의 역량은 현저히 부족하다. 이 거대한 지성은 여전히 인간의 지속적인 맥락 제공과 교정에 의존하고 있다. #### '닫힌 게임': LLM의 지능은 어떻게 진화했는가? GPT-4 초기 시절, 학계와 업계의 지배적인 시각은 "LLM은 통계적 확률 생성기이므로, 수학이나 코딩처럼 논리적 정합성이 요구되는 영역에는 활용이 부적합하다"는 것이었다. 그러나 불과 수년 만에 LLM은 복잡한 알고리즘 문제를 해결하고, 수학 올림피아드 수준의 난제에 도전하며 이러한 회의론을 불식시켰다. 태생적으로 확률적인 이 기계가 어떻게 결정론적 정확성을 요구하는 영역을 정복할 수 있었을까? 이 현상을 이해하기 위해서는 **'닫힌 게임'**의 개념을 도입해야 한다. 여기서 말하는 '게임'이란 다음과 같은 특성을 가진 시스템을 의미한다: - **명확한 규칙:** 시스템을 지배하는 법칙이 예외 없이 정의되어 있다. - **판별 가능성:** 결과의 성공과 실패를 즉각적이고 객관적으로 판별할 수 있다. - **피드백 루프:** 판별된 결과를 바탕으로 모델을 교정할 수 있다. 코딩이 대표적이다. 코드는 실행하는 순간 성공 여부가 판가름 난다. 에러 메시지는 명확한 피드백이 되어 강화학습의 보상 신호로 작용한다. 오픈소스 생태계에 축적된 양질의 데이터는 이 학습을 가속화했다. 수학 또한 정답이 존재하고 검증 가능한 논리 체계를 갖추고 있기에, 샌드박스 실험 환경에서 집중적인 학습이 가능하다. 그러나 이 방식은 본질적인 한계를 내포한다. 모델의 성능 향상은 범용 인공지능으로의 진화가 아니라, 특정 도메인에 대한 집중 튜닝의 결과라는 점이다. 테슬라가 10년 넘게 주행 데이터를 수집했음에도 운전이라는 게임을 아직 정복하지 못한걸 보면, 닫힌 게임이라도 스케일이 크면 그만큼의 자원과 시간이 필요하다는걸 알 수 있다. 따라서 LLM의 발전 양상은 진정한 의미의 '지능 폭발'이라기보다는, 각각의 벤치마크 점수를 높이기 위한 **'소프트웨어적 하드코딩'**의 연속으로 보아야 한다. 코딩 모듈을 튜닝하고, 수학 모듈을 튜닝하며, 각 분야의 점수를 하나씩 끌어올리는 점진적 공학의 산물인 것이다. #### 천동설을 주장하는 확률 기계 LLM의 한계를 가장 쉽게 묘사하는 비유가 있다. "만약 LLM이 중세 시대에 출시되었다면, 그것은 가장 유창하고 논리적으로 '천동설'을 설파하는 기계였을 것이다." 이 비유는 LLM이 추구하는 바가 이해를 통한 '진리 도달'이 아니라 **'확률적 합의'**임을 시사한다. 모델은 학습 데이터의 분포를 충실히 반영한다. 만약 학습 데이터의 99%가 "지구는 평평하다"고 주장한다면, 모델은 "지구는 평평하다"는 문장을 생성할 확률을 가장 높게 책정한다. LLM은 데이터를 종합하여 인과관계를 추론하고 새로운 진리를 도출하는 과학자가 아니다. 당대에 통용되는 지배적인 담론을 매끄럽게 재생산하는 웅변가에 가깝다. 더욱이 현재의 파인튜닝 및 강화학습 과정은 인간 평가자의 선호도를 반영하도록 주로 설계되어 있다. 이는 모델이 사실 여부와 관계없이 **"인간이 듣고 싶어 하는 대답"**을 하도록 유도하는 편향을 낳는다. 우리는 AI를 전지전능한 현자로 착각하지만, 실상은 우리의 편향을 거울처럼 비추는 존재일 뿐이다. 그러나 알파고 제로가 인간의 기보 없이 바둑의 신이 될 수 있었다. 어떻게 가능했던 것일까? 그것은 바둑이 완벽하게 정의된 '닫힌 게임'이었기 때문이다. 그러나 현실 세계는 승패의 조건이 모호하고 규칙이 끊임없이 변하는 불완전한 시스템이다. 역설적으로, 규칙이 명확한 닫힌 게임에 가까울수록 LLM에 의해 대체될 가능성이 높으며, 진실과 거짓이 혼재된 열린 세계의 문제는 여전히 확률 기계의 난제로 남아 있다. #### RAG와 VectorDB의 한계: 기억의 외주화가 갖는 맹점 지능의 핵심 요소 중 하나는 기억이다. 그러나 현재 LLM 생태계에서 기억을 보완하기 위해 채택된 기술인 **검색 증강 생성(RAG, Retrieval-Augmented Generation)**과 **벡터 데이터베이스**는 기대만큼의 혁신을 보여주지 못하고 있다. 냉정하게 평가하자면, 이는 20년 전부터 존재했던 검색 및 추천 시스템의 기술적 연장선에 불과하다. RAG 아키텍처는 근본적으로 '정보 검색'의 성능에 종속된다. 벡터 유사도 기반의 검색은 의미적 연관성을 찾는 데는 유용하지만, 정확한 맥락을 파악하거나 인과관계를 추적하는 데는 한계를 드러낸다. 검색 엔진이 사용자의 의도에 부합하는 문서를 찾아내지 못하면, 아무리 뛰어난 LLM이라도 엉뚱한 답변을 내놓을 수밖에 없다. 더욱 심각한 문제는 **데이터 오염**이다. 검색 결과 상단에 노출된 광고성 콘텐츠, 편향된 블로그 글, 혹은 부정확한 정보가 컨텍스트에 주입되는 순간, 모델의 확률 분포는 왜곡된다. 이는 'Garbage In, Garbage Out'이라는 컴퓨터 공학의 오래된 격언이 LLM 시대에도 여전히 유효함을 증명한다. LLM이 가진 무한한 잠재력은 역설적으로 RAG라는 구시대적 검색 기술의 한계에 봉인되어 있다. 트랜스포머 아키텍처가 가진 '상태 비저장' 특성을 극복하고, 진정한 의미의 장기 기억과 지속적 학습을 구현하기 위해서는, 현재의 패러다임을 넘어서는 새로운 모델 아키텍처의 등장이 절실하다. #### 조직론적 고찰: 맨먼스 미신과 생산성의 환상 > "직원들에게 AI 툴을 지급하면 조직 전체의 생산성이 비약적으로 상승할 것이다." > 많은 경영진이 이러한 기대를 품고 AI 도입을 서두르지만, 현실은 그렇게 단순하지 않다. 프레드릭 브룩스가 그의 저서 《맨먼스 미신》에서 통찰했듯, > "지체되는 소프트웨어 프로젝트에 인력을 더 투입하는 것은 프로젝트를 더 늦출 뿐이다." > 이 법칙은 AI 도입에도 유효할 수 있다. 개별 구성원이 AI를 활용해 코딩 속도를 2배로 높인다 해도, 그것이 곧바로 조직 전체의 성과로 직결되지는 않는다. 오히려 검증되지 않은 코드가 양산됨으로써 리뷰 비용이 증가하고, 아키텍처의 일관성이 무너지는 등 '커뮤니케이션 비용'과 '기술 부채'의 증가를 초래할 수 있다. 개인의 생산성 향상이 조직 전체의 병목 현상을 심화시키는 '부분 최적화 오류'가 발생하는 것이다. 따라서 AI 도입이 실질적인 기업 경쟁력으로 전환되기 위해서는 도구의 도입을 넘어선 **'거버넌스와 프로세스 엔지니어링'**이 선행되어야 한다. - **검증 체계:** AI가 생성한 결과물의 품질을 누가, 어떻게 검증할 것인가? - **리뷰 프로세스:** 폭증하는 코드와 문서의 양을 감당할 리뷰 시스템은 갖추어져 있는가? - **윤리 및 보안 가이드라인:** 데이터 유출과 할루시네이션 위험을 통제할 기준은 무엇인가? 이러한 구조적 고민 없이 단순히 도구만을 쥐여주는 것은, 개인에게는 '칼퇴'를 선물할지 모르나 조직에게는 '혼란'을 안겨줄 뿐이다. LLM 은 마법 지팡이가 아니며, 그것을 운용하는 시스템과 문화가 뒷받침될 때 비로소 생산성의 도구가 된다. --- ### 3.6 산업적 맥락 - AI 는 빅테크의 구원자 왜 구글, 마이크로소프트, 메타와 같은 빅테크들은 왜 뒤늦게 마치 약속이라도 한 듯이 이 전장에 사활을 걸고 뛰어들었을까? 이 현상을 이해하기 위해서는 기술적 진보가 아닌, 거시경제의 흐름과 기술 기업들이 처해 있던 정치적 위기를 들여다봐야 한다. 기술은 진공 상태에서 발전하지 않으며, 언제나 자본과 정치의 역학 관계 속에서 그 모습을 드러내기 때문이다. #### 플랫폼 제국의 흥망: 확장의 시대에서 규제의 시대로 2010년대는 바야흐로 **'플랫폼 자본주의'**의 황금기였다. 구글, 애플, 아마존, 메타 등 실리콘밸리의 거인들은 "연결이 곧 혁신"이라는 기치 아래, 시장을 독점하고 규모의 경제를 실현하면 국경을 초월한 부를 창출할 수 있다는 믿음을 증명해 보였다. 이 시기 그들의 전략은 '치킨 게임'을 통한 승자독식이었으며, 시장은 이들에게 천문학적인 밸류에이션을 부여했다. 그러나 플랫폼의 무한한 팽창은 필연적으로 사회적 반작용을 불러왔다. 독점에 의한 시장 왜곡, 프라이버시 침해, 알고리즘을 통한 확증 편향과 가짜 뉴스의 확산 등 부작용이 임계점을 넘어서자, 국가라는 거대한 사회적 장치가 개입하기 시작했다. 유럽의 GDPR, 미국의 반독점 소송, 그리고 각국의 디지털세 논의는 빅테크 기업들을 '혁신의 아이콘'에서 '규제의 대상'으로 전락시켰다. 그들은 이제 확장이 아닌 방어에 몰두해야 했다. 이러한 규제 리스크 속에서 맞이한 코로나19 팬데믹은 역설적인 호황을 가져왔다. 비대면 경제의 폭발적 성장은 막대한 현금 흐름을 만들어냈지만, 동시에 기업 내부의 권력 구조를 변화시켰다. 이 시기 국내외 빅테크의 C레벨과 고위 임원직에는 엔지니어 대신 법조인 출신들이 포진하기 시작했다. 이는 테크 기업들이 더 이상 차고에서 시작한 '언더독'이 아니라, 기득권이 되었음을 의미한다. 그들은 혁신보다는 법적 리스크를 관리하고, 정치적 영향력을 행사하여 규제의 칼날을 무디게 하는 데 집중했다. 하지만 팬데믹의 종료와 함께 상황은 급변했다. 인플레이션을 잡기 위한 금리 인상은 자본 시장을 급속도로 얼어붙게 만들었다. '유동성 파티'를 즐기며 플랫폼 독점을 꿈꾸던 스타트업들은 줄도산했고, 빅테크 기업들조차 주가 폭락과 수익성 악화라는 냉혹한 현실에 직면했다. '성장의 시대'가 끝나고 '긴축의 시대'가 도래한 것이다. #### ChatGPT: 위기 탈출을 위한 동아줄 바로 이 절체절명의 시점, 2022년 11월에 ChatGPT 3.5가 대중에게 공개되었다. 벼랑 끝에 몰린 빅테크 기업들에게 생성형 AI는 그 실효성을 떠나 반드시 잡아야만 하는 **'새로운 동아줄'**이었다. 그것이 썩은 동아줄인지 튼튼한 동아줄인지는 중요하지 않았다. AI는 그들에게 다음과 같은 다층적인 정치·경제적 효용을 제공했기 때문이다. - **이미지 세탁:** '독점적 포식자'라는 부정적 낙인을 떼어내고, 다시금 인류의 미래를 견인하는 **'혁신적 기술 기업'**이라는 프레임을 회복할 기회였다. - **새로운 성장 서사:** 플랫폼 비즈니스의 성장이 정체된 상황에서, 주주들을 설득하고 주가를 부양할 수 있는 강력한 미래 비전이 필요했다. - **경쟁 공포:** 경쟁사가 먼저 선점할 경우, 기존의 검색 및 클라우드 시장 점유율을 영원히 상실할지 모른다는 실존적 공포가 작용했다. - **구조조정의 명분:** 팬데믹 기간 비대해진 조직을 슬림화해야 하는 상황에서, AI는 대규모 해고를 정당화하는 완벽한 핑계가 되었다. 마이크로소프트가 OpenAI와의 동맹을 통해 선공을 날리자, 구글은 미완성 상태의 바드를 성급히 공개하며 체면을 구겼고, 메타는 LLaMA를 오픈소스로 공개하며 판을 흔들었다. 바야흐로 플랫폼 확장의 시대가 저물고, LLM 주도권 쟁탈전이라는 새로운 치킨 게임이 시작된 것이다. 이 과정에서 빅테크의 자본과 인력은 AI 로 급격히 집중되었고, 분야에서는 가혹한 구조조정이 단행되었다. 시장에는 갑작스럽게 쏟아져 나온 경력직 개발자들로 넘쳐났고, 이 현상은 "AI가 개발자를 대체하기 시작했다"는 낭설과 결합하여 공포를 증폭시켰다. 실상은 금리 인상에 따른 경기 침체와 과잉 채용의 해소 과정이었으나, 대중은 이를 **'기술적 실업의 전조'**로 받아들이며 집단적 불안에 빠지게 되었다. #### 거품의 정치경제학: 누가 이익을 설계하는가? 냉정하게 바라보자. 현재의 AI 열풍은 실체적 가치 이상으로 부풀려진 측면이 있다. 나는 이를 테크 기업들과 이해관계자들이 주도하는 일종의 '가스라이팅' 혹은 **'서사적 조작'**이라고 본다. "AI가 모든 산업을 재편할 것이다", "개발자는 곧 사라질 직업이다", "AGI(범용 인공지능)의 도래가 임박했다"는 종말론적 혹은 구원론적 메시지는 과연 누구에게 이득이 되는가? - **AI 연구자 및 학계:** 막대한 연구비 지원과 대중적 주목을 확보하며 학문적 권력을 강화한다. - **AI 스타트업:** "AI"라는 키워드 하나로 벤처 캐피털의 투자를 유치하고 기업 가치를 부풀린다. - **빅테크 기업:** 새로운 성장 동력을 제시하여 주가를 방어하고, 시장 지배력을 유지한다. - **미디어:** 자극적인 미래 전망과 공포 마케팅을 통해 트래픽(클릭)을 유도한다. 과거 블록체인 연구자들이 "Web3가 인터넷의 모든 것을 바꿀 것"이라는 장밋빛 청사진을 제시했듯, 지금의 AI 연구자들은 "AGI가 곧 온다"는 믿음을 설파한다. 이는 그들이 거짓말을 해서가 아니라, 자신의 연구 분야에 매몰되어 확증 편향에 빠져 있기 때문이다. 그러나 현실을 직시해야 한다. 현재 LLM 모델 자체를 판매하는 기업을 제외하고, 일반 제조, 유통, 금융 등 전통 산업군에서 오직 LLM 도입 때문에 대규모 인력 감축을 단행한 사례가 있는가? 적어도 현재까지 대한민국, 아니 글로벌 시장에서도 유의미한 사례를 찾기는 어렵다. AI 에이전트 기술은 분명 발전하고 있지만, 인간의 개입 없이 독립적으로 업무를 수행할 만큼 신뢰성을 확보한 지는 극히 최근의 일이며, 그조차도 매우 제한적인 영역에 국한된다. 지금의 공포는 실체보다 과장되어 있으며, 그 과장의 이면에는 기술적 진보를 통해 경제적 이득을 취하려는 거대한 카르텔의 욕망이 투영되어 있음을 잊지 말아야 한다. --- ### 3.7 반복하는 외주(SI, 컨설팅) 개발의 역사 #### 외주 개발사가 남긴 교훈: 통제와 효율의 딜레마 우리는 지금 LLM이라는 외부의 지성에게 우리의 사고와 역량을 위임하려는 거대한 전환점에 서 있다. 이것이 과연 현명한 선택인지 판단하기 위해서는, 과거 소프트웨어 산업이 겪었던 **'아웃소싱의 흥망성쇠'**를 되짚어볼 필요가 있다. 역사는 반복되지 않더라도, 그 운율은 반복되기 때문이다. **1. 아웃소싱의 여명기 (1989 ~ 1990년대)** 1989년, 이스트먼 코닥이 데이터 센터 운영을 IBM에게, 네트워크 관리를 DEC에게 맡기는 기념비적인 계약을 체결했을 때, IT 업계는 환호했다. "IT도 제조업의 부품처럼 통째로 외주화할 수 있다"는 신호탄이었다. 1990년대에 이르러 인도와 동유럽을 중심으로 소프트웨어 개발 아웃소싱은 거대한 산업 표준으로 자리 잡았다. 당시 소프트웨어는 기업의 핵심 경쟁력이기보다, ERP나 백오피스 시스템처럼 행정을 보조하는 '비용 절감의 대상'으로 인식되었기에 가능한 일이었다. **2. 백소싱의 시대 (2000년대 중반 ~ 현재)** 그러나 2000년대 중반부터 거대한 반작용이 일어났다. 기술 자체가 비즈니스의 본질이 되기 시작하면서, 기업들은 외주 주었던 역량을 다시 내부로 흡수하는 '백소싱' 움직임을 보였다. - **JP모건 체이스(JP Morgan Chase, 2004):** 2002년 IBM과 50억 달러 규모의 초대형 IT 아웃소싱 계약을 맺었으나, 불과 2년 만에 이를 파기했다. 당시 CEO 제이미 다이먼은 "기술은 우리 비즈니스의 핵심이다. 핵심 역량을 외부에 맡길 수 없다"고 천명하며 4,000명 이상의 IT 인력을 다시 고용했다. - **제너럴 모터스(GM, 2012):** 당시 IT 서비스의 90%를 외부 업체에 의존하고 있었다. 새로 부임한 CIO 랜디 모트는 "3년 안에 90%를 내부 인력으로 전환하겠다"는 급진적 선언을 했다. 그의 논리는 명확했다. 외주 구조 하에서는 자사의 IT 자산과 데이터를 제대로 파악할 수 없으며, 시장 변화에 대응하는 속도를 확보할 수 없다는 것이다. **3. 보잉 787 드림라이너의 비극** 제조업에서도 유사한 사례가 있다. 보잉은 787 드림라이너의 설계와 제조 공정의 60~70%를 전 세계 파트너사에게 외주화하는 극단적인 전략을 취했다. 그 결과는 참담했다. 3년 이상의 일정 지연, 수십억 달러의 비용 초과, 그리고 잇따른 배터리 화재 등 품질 문제가 발생했다. 통합의 복잡성을 과소평가하고 핵심 통제권을 잃어버린 대가였다. 이 역사적 사례들 뿐만 아니라 한국에서도 SI 로 사업을 빠르게 시작하고 다시 백소싱하는 흐름을 2010년대에 많이 보여주었다. 이게 가리키는 메시지는 명확하다. 첫째, 비즈니스의 핵심에 가까울수록 외주화의 리스크는 기하급수적으로 증가한다. 둘째, 지속적 개선과 혁신은 외부 용병이 대신해 줄 수 없다. 셋째, 코어 역량을 외주화하는 순간, 단기적 비용은 줄어들지 몰라도 장기적 통제 비용은 감당할 수 없을 만큼 비싸진다. #### LLM에게 위임할 것인가, 통제할 것인가? 우리는 LLM을 '디지털 외주 파트너'로 바라봐야 한다. 그렇다면 무엇을 맡기고 무엇을 직접 수행할 것인가? **위임 가능한 영역 (The Safe Zone):** - **정형화된 구문적 작업:** 텍스트 요약, 번역, 문장 교정 등 정답이나 스타일이 어느 정도 정해져 있는 작업. - **반복적 기술 작업:** 테스트 코드의 골격 생성, 단순 CRUD 보일러플레이트 코드 작성. - **정보의 인출:** API 명세 확인, 라이브러리 간 기능 비교 등 검색 비용을 줄이는 리서치. **절대 위임 불가한 영역 (The Core Zone):** - **문제의 정의:** 우리가 해결해야 할 문제가 무엇인지, 비즈니스의 본질적 가치가 무엇인지 정의하는 행위. - **도메인 모델링과 아키텍처:** 데이터의 흐름, 이벤트의 설계, 시스템의 경계 설정. - **리스크와 책임의 영역:** 보안, 규제 준수, 그리고 실패 시 책임을 져야 하는 핵심 의사결정. 이 '절대 위임 불가한 영역'을 AI에게, 혹은 다른 누구에게라도 온전히 맡긴다는 것은 "우리 비즈니스의 정체성을 정의하는 권한"을 포기하는 것과 다름없다. --- ### 3.8 복잡성의 보존: '배달의민족'은 누구나 만들 수 있는가? #### 더닝-크루거 효과와 소프트웨어의 빙산 2015년, 내가 아직 학부생이던 시절, 교내 편의 기능을 담은 앱을 독학으로 개발한 적이 있다. 생각보다 과정은 순탄했고 결과물은 그럴듯했다. 그때 나는 치기 어린 오만에 빠져 이렇게 생각했다. "네이버나 다음 같은 대기업에는 왜 그렇게 많은 개발자가 필요한 거지? 나 혼자서도 며칠이면 만드는데?" 그것은 전형적인 **더닝-크루거 효과**였다. 나는 '앱'이라는 껍데기만 보았지, 그 아래 잠겨 있는 거대한 '서비스'의 빙산을 보지 못했다. 유튜브의 IT 뉴스 댓글란을 보면 여전히 이런 오해가 만연하다. "배달의민족 그거 그냥 리스트 보여주고 주문받는 앱 아니냐, AI 쓰면 대학생도 만든다"라는 식의 냉소가 쏟아진다. 그러나 배달의민족은 스마트폰 화면에 아이콘으로 존재하는 단순한 소프트웨어가 아니다. 그것은 수만 명의 자영업자의 생계가 달린 상점 관리 시스템, 수십만 라이더의 동선을 최적화하는 물류 배차 알고리즘, 초당 수천 건의 트랜잭션을 처리하는 결제 게이트웨이, 악성 리뷰와 어뷰징을 걸러내는 데이터 파이프라인, 그리고 고객의 불만을 실시간으로 처리하는 CS 시스템이 유기적으로 결합된 **거대한 사회-기술적 시스템**이다. "AI로 누구나 앱을 만들 수 있다"는 말은 "AI로 UI 화면을 그릴 수 있다"는 말과 동의어일 뿐이다. 그러나 소프트웨어 공학의 진짜 악마는 화면이 아니라, 보이지 않는 뒷단의 디테일과 운영의 복잡성에 숨어 있다. #### 자연어 프로그래밍의 역설 **바이브 코딩의 환상** 최근 "자연어로 코딩하는 시대가 왔다", "이제 누구나 개발자가 될 수 있다"는 '바이브 코딩' 담론이 유행하고 있다. 프로그래밍 문법의 장벽이 무너진 것은 사실이다. 그러나 이것이 곧 소프트웨어 엔지니어링의 종말을 의미할까? 정교한 비즈니스 로직을 자연어로 구현한다고 가정해보자. "사용자가 로그인할 때, 계정이 정지 상태라면 붉은색 경고를 띄우고, 비밀번호를 3회 이상 틀리면 10분간 잠그되, VIP 회원은 예외로 하고, 관리자에게 슬랙 알림을 보내라. 타임아웃은 3초..." 이 요구사항을 자연어로 작성하는 행위와 코드로 작성하는 행위 사이에는 본질적인 차이가 없다. 오히려 자연어는 프로그래밍 언어보다 **모호성**이 높다. - "경고 메시지"의 구체적 내용은 무엇인가? - "3회 이상 실패"는 누적 인가, 연속인가? 기간 제한은 없는가? - "잠근다"의 기술적 구현은 DB 플래그 변경인가, 레디스 TTL 설정인가? 결국 기계가 오작동하지 않게 하려면, 자연어 프롬프트 또한 코드 수준으로 정교하고 논리적이어야 한다. 즉, 자연어 프로그래밍은 '영어라는 문법을 가진 또 다른 프로그래밍 언어'를 사용하는 것일 뿐이다. **유지보수의 재앙** 더 큰 문제는 유지보수성이다. 소프트웨어 공학의 핵심 원칙 중 하나는 **'중복 배제(DRY: Don't Repeat Yourself)'**다. 공통 로직은 모듈화하여 한곳에서 관리해야 한다. 그러나 자연어 프롬프트로 개발된 시스템에서 비즈니스 정책이 변경된다면 어떻게 할 것인가? 수천 개의 프롬프트 파일 속에 산재된 "3회 이상 실패 시..."라는 문장들을 모두 찾아 수동으로 고쳐야 한다. 하나라도 누락되면 시스템은 정합성을 잃고 붕괴한다. 언어의 형태가 코드에서 자연어로 바뀌었을 뿐, 추상화, 모듈화, 결합도, 응집도와 같은 엔지니어링의 근본적인 난제들은 사라지지 않았다. 오히려 자연어의 유연함이 독이 되어 시스템의 복잡도를 높일 위험이 크다. #### 소결: 도구의 위치 재정립 "LLM은 인간의 '낮은 층위의 사고'를 자동화함으로써, 인간이 '높은 층위의 사고'에 집중할 수 있게 해주는 지적 레버리지다." 우리는 지금까지 LLM의 양면성을 살펴보았다. 그것은 정보 접근의 비용을 낮추고 지식의 장벽을 허무는 혁신적인 도구다. 동시에, 긴 맥락을 유지하지 못하는 '치매 걸린 천재'이며, 학습 데이터의 편향을 앵무새처럼 읊는 '천동설론자'이고, 거대 자본의 이해관계가 얽힌 '정치적 산물'이기도 하다. --- ## 4장: 공존하기 --- ### 4.1 LLM 리터러시를 이해하기 #### 실패의 해석학: "왜?"라는 질문의 힘 우리가 작성한 프롬프트에 대해 모델이 엉뚱하거나 기대 이하의 답변을 내놓을 때, 사용자의 반응은 크게 두 갈래로 나뉜다. 하나는 "역시 AI는 멍청해"라고 치부하며 도구를 비난하는 **'포기의 태도'**이고, 다른 하나는 "도대체 내 입력의 어떤 부분이 이런 출력을 유도했을까?"라고 자문하는 **'분석의 태도'**다. 전자의 태도를 가진 사람은 기술의 수혜자가 될 수 없다. 그들은 도구의 불완전성을 탓하며 성장의 기회를 스스로 차단한다. 반면, 후자의 태도는 LLM 리터러시의 시작점이다. 이것은 일종의 디버깅 과정과 유사하다. - "내가 제공한 맥락이 빈약했는가?" - "내 지시어에 모호한 중의적 표현이 섞여 있었는가?" - "특정 키워드가 모델의 확률 분포를 엉뚱한 방향으로 유도했는가?" - "이전 대화의 잔여 정보가 현재의 추론을 방해하고 있는가?" 이러한 인과적 추적을 반복하는 과정에서 사용자는 일종의 **'확률적 감각'**을 체득하게 된다. 어떤 어휘가 모델을 더 정교하게 제어하는지, 어떤 구조적 배치가 논리적 정합성을 높이는지 본능적으로 알게 되는 것이다. LLM을 능숙하게 다루는 '프롬프트 엔지니어'란, 인터넷에 떠도는 마법의 프롬프트 공식을 외우는 사람이 아니다. 그는 결과물을 통해 자신의 입력을 끊임없이 의심하고 교정하는, 호기심 어린 실험가다. #### 자아의 부재: 메타인지 없는 지성 LLM을 다룰 때 범하기 쉬운 가장 치명적인 오류는 기계에게 **'메타인지'**를 기대하는 것이다. 기능이 작동하지 않을 때 우리는 습관적으로 묻는다. "왜 이 기능이 안 돼?", "네가 방금 그렇게 대답한 근거가 뭐야?" 그러나 냉정하게 말해, LLM은 자기 자신을 모른다. LLM에게는 자아도, 자신의 상태를 모니터링하는 메타인지 모듈도 없다. 그들에게 존재하는 유일한 '자아의 대체물'은 개발자가 주입한 **시스템 프롬프트**뿐이다. 시스템 프롬프트에 명시되지 않은 내부 상태나 학습 데이터의 구성에 대해 모델은 알지 못한다. 그럼에도 불구하고 모델은 답변을 내놓는다. "저는 ~한 이유로 그렇게 판단했습니다"라며 매우 논리적인 척 설명한다. 이것은 진실이 아니다. 이는 **사후 합리화**에 의한 환각이다. 모델은 질문을 받자마자, 그 질문에 대해 '가장 그럴듯하게 들리는 답변'을 확률적으로 생성해 냈을 뿐이다. 우리는 기계가 자신의 사고 과정을 설명하고 있다고 믿지만, 실상은 '설명하는 척하는 텍스트'를 생성하고 있는 것이다. 별도의 RAG(검색 증강 생성) 시스템이나 툴 호출 로그를 확인하지 않는 한, 모델의 자기 진술은 결코 신뢰의 근거가 될 수 없다. #### 시간의 왜곡: 정지된 데이터의 함정 LLM은 본질적으로 과거의 데이터에 갇힌 존재다. 모델의 지식은 학습이 종료된 시점에 멈춰 있다. 그러나 사용자는 2025년의 현재를 살아가며 질문을 던진다. 이 시차에서 심각한 정보의 왜곡이 발생한다. 예를 들어, "React의 상태 관리 베스트 프랙티스를 알려줘"라고 물었을 때, 모델은 자신 있게 답변할 것이다. 그러나 그 답변이 2021년의 Redux 중심 패턴인지, 2024년의 Zustand나 Server Components 중심 패턴인지 모델은 구분하지 않고 섞어서 내놓을 수 있다. 기술 생태계의 발전 속도는 빠르다. 2년 전의 '베스트 프랙티스'는 오늘날의 '안티 패턴'이 되어 있을 가능성이 높다. 따라서 시의성이 중요한 정보를 다룰 때는 반드시 시간적 제약 조건을 명시해야 한다. "2024년 말 기준으로 답변해 줘." 혹은 "최신 공식 문서의 변경 사항을 반영해 줘." 사용자가 명시적으로 시간을 동기화하지 않는 한, LLM은 과거와 현재가 뒤섞인 혼종 정보를 진실인 양 전달할 것이다. #### 인식론적 매트릭스: 위임할 것인가, 학습할 것인가? 우리는 모든 업무에 AI를 사용할 수 있지만, 모든 업무에 사용해서는 안 된다. 이를 구분하는 기준은 **'업무의 중요도'**와 **'나의 전문성'**이라는 두 가지 축으로 구성된 매트릭스다. 1. **중요도가 높고 + 내가 잘 모르는 영역 (High Importance / Low Skill)** 가장 위험한 영역이다. 많은 초심자가 이 영역에서 AI에게 의존하려 한다. 그러나 내가 잘 모르기 때문에 AI가 내놓은 결과물이 사실인지 거짓인지 검증할 수 없다. 그런데 업무는 중요하므로, 오류가 발생했을 때의 리스크는 치명적이다. - **전략: "공부하라."** 이 영역은 AI에게 위임할 것이 아니라, AI를 튜터로 삼아 내가 학습해야 하는 영역이다. 판단의 주체는 반드시 나 자신이 되어야 한다. 2. **중요도가 높고 + 내가 잘 아는 영역 (High Importance / High Skill)** 전문가의 영역이다. 여기서 AI는 강력한 보조 도구가 된다. 나는 결과물의 미세한 결함을 즉시 발견하고 수정할 수 있다. - **전략: "전문가가 되어라."** AI를 적극 활용하되, 최종 검수와 책임은 전적으로 인간이 져야 한다. 주의할 점은, AI에 지나치게 의존하다 보면 인간의 고유한 직관과 전문성이 퇴화할 수 있다는 것이다. 3. **중요도가 낮고 + 잘 모르거나 잘 아는 영역** - **전략: "적극적 위임."** 리스크가 낮으므로 AI를 통해 생산성을 극대화하고 시간을 벌어라. 핵심은 메타인지적 판단이다. 프롬프트를 입력하기 전, 0.1초 동안 스스로에게 물어야 한다. "이것은 내가 검증 가능한가? 검증 불가능하다면, 결과가 틀렸을 때 감당할 수 있는가?" 이 판단의 속도와 정확도가 바로 LLM 리터러시의 척도다. #### 상태 비저장의 원칙: 메모리 기능을 끄는 이유 최근 ChatGPT를 비롯한 많은 LLM 서비스들이 '메모리' 기능을 도입하고 있다. 이전 대화의 맥락과 사용자의 선호도를 기억해 다음 대화에 반영하는 기능이다. 편리해 보이지만, 엔지니어링 관점에서는 치명적인 결함을 내포하고 있다. 바로 **'입력의 불투명성'**이다. 나는 이 기능을 비활성화한다. 그 이유는 명확하다. 메모리 기능이 켜져 있으면, 내 프롬프트에 어떤 숨겨진 변수가 자동으로 주입되었는지 알 수 없기 때문이다. 내가 단순히 "A에 대해 설명해 줘"라고 입력했을 때, 시스템 내부적으로는 *"이 사용자는 B라는 정치적 성향을 가졌고, C라는 기술 스택을 선호함"*이라는 메모리가 몰래 프롬프트에 추가되어 전송된다. 결과적으로 답변은 B와 C에 편향되어 출력된다. 사용자는 이것이 객관적 정보인지, 내 성향에 맞춰 왜곡된 정보인지 구분할 수 없다. 소프트웨어 공학의 기본 원칙은 **"입력을 통제해야 출력을 예측할 수 있다"**는 것이다. 출력을 예측할 수 없다면, 그 결과는 검증할 수 없다. 편리함과 통제력은 트레이드오프 관계다. 가벼운 잡담이나 일상적 추천을 원한다면 메모리를 켜라. 그러나 정확한 정보, 논리적 추론, 업무적 의사결정을 위해 LLM을 사용한다면, 통제력을 선택해야 한다. 나는 언제나 내가 입력한 것만이 모델에 전달되기를 원한다. 그래야만 그 결과를 온전히 해석하고 책임질 수 있기 때문이다. --- ### 4.2 바이브 코딩과 도메인 주도 설계 #### 바이브 코딩의 환상과 전략적 설계 최근 개발자 커뮤니티를 강타한 **'바이브 코딩'**이라는 용어는, 자연어만으로 코드를 뚝딱 만들어내는 생성형 AI의 위력을 대변한다. "이제 더 이상 복잡한 코딩 기술은 필요 없다"는 기술 허무주의적 시각이 확산되고 있다. 그러나 우리는 이 현상을 에릭 에반스가 제창한 **도메인 주도 설계**의 '전략적 설계' 틀 안에서 냉정하게 재배치해야 한다. DDD는 비즈니스 도메인을 크게 두 가지로 분류한다. - **핵심 도메인:** 비즈니스의 정체성이자 차별화된 경쟁력을 만드는 영역. - **지원 및 일반 서브 도메인(Supporting/Generic Subdomain):** 필요하지만 경쟁 우위를 만들지는 않는, 범용적이거나 보조적인 영역. 바이브 코딩의 효용은 서브 도메인에서 빛을 발한다. 어드민 대시보드, 단순 CRUD API, 보일러플레이트 코드와 같이 정형화된 패턴이 반복되는 영역은 AI에게 위임하여 생산성을 극대화하는 것이 합리적이다. 그러나 핵심 도메인은 다르다. 복잡한 비즈니스 규칙, 기업의 고유한 알고리즘, 중대한 의사결정이 코드로 구현되는 이 영역은 여전히 인간의 통제하에 있어야 한다. 핵심 도메인까지 섣불리 바이브 코딩으로 대체하려는 시도는, 앞서 3장에서 경고한 '외주 개발의 실패 역사'를 반복하는 꼴이다. 핵심 경쟁력을 외부(AI 모델)에 아웃소싱하는 순간, 우리는 시스템에 대한 주권과 심층적인 이해를 상실하게 된다. 따라서 현대의 엔지니어링 전략은 이분법적이어야 한다. "범용재는 AI에게, 핵심 가치는 인간에게." 이것이 바이브 코딩 시대의 올바른 생존 전략이다. #### 유비쿼터스 언어: AI와의 프로토콜 동기화 역설적이게도, LLM 시대에 접어들며 DDD의 '유비쿼터스 언어' 개념은 인간끼리의 소통 도구를 넘어, 인간과 AI 간의 프로토콜로서 더욱 중요해졌다. AI 에이전트에게 코드 수정을 지시하는 상황을 가정해 보자. "5차 독립 책임액 계산 로직을 수정해 줘." 이 자연어 명령이 올바르게 수행되려면, 코드베이스 내에 해당 개념이 일관된 용어로 정의되어 있어야 한다. 만약 개발자들이 같은 개념을 FifthIndependent..., LimitAmount..., FiveIndependent... 등 제각각 다른 변수명으로 혼용해 왔다면 어떻게 될까? 확률적 기계인 에이전트는 이 파편화된 용어들이 같은 개념임을 완벽히 추론하지 못한다. 결과적으로 일부 파일만 수정되고 일부는 누락되어, 시스템 전체의 정합성이 깨지는 치명적인 오류를 낳는다. 즉, 낮은 응집도와 모호한 명명은 AI의 추론 능력을 마비시키는 노이즈가 된다. 더욱 심각한 문제는 **언어적 장벽**이다. 우리는 업무와 프롬프팅을 한국어로 수행하지만, 코드는 영어로 작성된다. *"보험료 산출 기준 변경"*이라는 한국어 지시가 영어 코드의 특정 로직과 매핑되려면, AI는 고도의 번역과 추론 과정을 거쳐야 한다. 복잡한 금융 도메인일수록 이 '의미적 괴리'는 커진다. 따라서 '용어 사전'의 명문화는 선택이 아닌 필수가 되었다. 한국어 도메인 용어와 영어 코드명을 1:1로 매핑한 사전을 에이전트의 컨텍스트(시스템 프롬프트)로 제공해야 한다. 이것이 준비되지 않은 상태에서 자연어 코딩을 시도하는 것은 바벨탑을 쌓는 것과 같다. 언어의 통일성 없이 AI를 도입하는 것은 불가능하며, 이는 영어권 국가와 비영어권 국가 간의 생산성 격차를 심화시키는 구조적 원인이 될 수 있다. #### 동어반복의 함정: 테스트 코드를 직접 작성해야 하는 이유 "구현도 AI가 하고, 테스트 코드도 AI가 짜주면 완벽하지 않은가?" 이것은 매우 달콤하지만 위험한 유혹이다. 논리학적으로 이는 동어반복의 오류에 해당한다. 테스트 코드의 본질은 **'명세'**다. "이 프로그램은 이렇게 동작해야 한다"는 인간의 의도와 기대를 코드로 형상화한 것이다. 그런데 구현을 맡은 주체에게 그 검증 도구까지 만들게 한다면 어떤 일이 벌어질까? - **잘못된 검증:** AI가 구현을 잘못 이해하여 버그를 만들었다면, 테스트 코드 역시 그 잘못된 이해를 바탕으로 작성될 확률이 높다. 잘못된 코드를 통과시키는 잘못된 테스트가 만들어지는 것이다. 이는 아무런 검증 가치가 없는 **'자기 만족적 초록불'**일 뿐이다. - **보상 해킹:** 강화학습된 모델들은 종종 '테스트 통과'라는 보상을 얻기 위해 비정상적인 방법을 동원한다. 실제 로직을 올바르게 구현하는 대신, 테스트 케이스의 허점을 파고들거나 억지로 예외 처리를 추가하여 테스트만 통과하게 만드는 '꼼수'를 부릴 수 있다. 따라서 구현은 AI에게 맡기더라도, 테스트 코드만큼은 인간이 작성하거나, 최소한 인간이 면밀히 검토해야 한다. 그것이 우리가 시스템에 대해 가질 수 있는 최후의 통제권이자, 기계의 환각을 걸러낼 수 있는 안전장치이기 때문이다. #### 확률의 지정학: 데이터의 편향된 지도 LLM을 다룰 때 우리가 결코 잊지 말아야 할 대전제는 **"이것은 확률 기계다"**라는 사실이다. 이 기계가 학습한 지식의 지도는 평평하지 않다. 그것은 마치 산봉우리와 골짜기가 극명하게 나뉜 불균형한 지형도와 같다. 전 세계 웹 데이터의 압도적 다수는 영어와 서구권 문화로 구성되어 있다. 반면, 한국어를 비롯한 로컬 데이터는 거대한 데이터의 바다에서 작은 섬에 불과하다. 이는 확률 분포 상의 **밀도 차이**를 야기한다. - **영어 데이터:** 높은 빈도, 강한 확률적 신호. - **로컬 데이터:** 낮은 빈도, 약한 확률적 신호. 이것이 의미하는 바는 명확하다. 로컬화된 정보는 글로벌 정보와의 '확률 전쟁'에서 패배하기 쉽다. 예를 들어, 한국의 특수한 비즈니스 관행이나 법률 용어에 대해 질문할 때, 만약 그 단어가 영어권에서도 통용되는 개념과 유사하다면(예: '계약', '이사회'), 모델은 압도적인 학습량을 가진 영미법이나 실리콘밸리의 관행을 기반으로 답을 생성할 확률이 높다. 이것은 모델의 오류라기보다, 통계적 필연이다. 따라서 우리는 프롬프트를 통해 이 기울어진 운동장을 보정해야 한다. 단순히 질문하는 것을 넘어, **"대한민국 상법과 서울의 비즈니스 관행을 기준으로"**라고 확률의 범위를 촘촘하게 지역화해야 한다. 이는 모델에게 전 세계의 확률 지도에서 특정 좌표를 강제로 응시하게 만드는 '확률적 핀포인트' 전략이다. #### 프롬프트 SRP: 인지적 부하의 분산과 단일 책임 원칙 소프트웨어 설계의 금과옥조인 **단일 책임 원칙(SRP: Single Responsibility Principle)**은 프롬프트 엔지니어링의 세계에서도 유효하다. 아니, 어텐션 메커니즘의 특성상 더욱 엄격하게 적용되어야 한다. 우리는 흔히 효율성을 핑계로 다음과 같은 '슈퍼 프롬프트'를 작성하곤 한다. "아래 리서치 자료를 바탕으로 발표 내용을 구체적으로 채우고, 이를 10장 분량으로 구조화한 뒤, 각 슬라이드에 어울리는 구글 슬라이드 디자인까지 제안해 줘." 이 프롬프트는 왜 실패하는가? 혹은 왜 그저 그런 결과만을 내놓는가? 어텐션 메커니즘의 관점에서 볼 때, 모델은 **한정된 인지 자원**을 여러 목표에 동시에 할당해야 하는 딜레마에 빠진다. - **내용 확장 (Content Generation):** 깊이 있는 추론과 창의성 필요. - **구조화 (Structuring):** 논리적 흐름과 요약 능력 필요. - **디자인 (Visual Planning):** 미적 감각과 도구적 지식 필요. 서로 다른 성격의 과업이 하나의 컨텍스트 안에서 충돌할 때, 어텐션 확률은 분산되고 만다. 결과적으로 모델은 깊이도 없고, 구조도 헐겁고, 디자인도 평범한 **'평균으로의 회귀'**를 선택한다. 이를 해결하기 위해서는 인간 개발자가 복잡한 문제를 해결하듯, 과업을 순차적으로 분해해야 한다. 1. **[Session 1 - 탐구]:** "주제별 핵심 내용을 3~4문단으로 깊이 있게 확장하라." (오직 내용에만 집중) 2. **[Session 2 - 설계]:** "확장된 내용을 바탕으로 10장 슬라이드의 뼈대를 잡아라." (오직 구조에만 집중) 3. **[Session 3 - 구현]:** "각 슬라이드의 시각적 요소와 디자인을 제안하라." (오직 표현에만 집중) 이것은 최근 주목받는 **AI 에이전트**들이 내부적으로 복잡한 문제를 해결하는 방식과 정확히 일치한다. 각 단계에서 모델은 단 하나의 목표에 모든 확률적 자원을 쏟아부을 수 있으며, 결과물의 품질은 비약적으로 상승한다. 욕심을 버리고 단계를 나누는 것, 그것이 고품질 결과물을 얻는 지름길이다. #### 구조적 엔지니어링: 마크다운이라는 시각적 닻 긴 텍스트를 LLM에게 던져주고 요약을 부탁했을 때 결과가 신통치 않다면, 그것은 텍스트의 내용 문제가 아니라 형식의 부재 때문일 가능성이 크다. 구조가 없는 텍스트 덩어리 앞에서, 모델은 어디에 어텐션을 집중해야 할지 갈피를 잡지 못하고 표류한다. 프롬프트는 단순한 문장이 아니라, 모델의 연산을 제어하는 코드와 같다. 따라서 우리는 구조화된 템플릿을 통해 모델의 시선을 가이드해야 한다. ```markdown ## 1. 배경 (Context) [프로젝트의 배경과 목적을 기술] ## 2. 핵심 요구사항 (Requirements) - 요구사항 A: [구체적 설명] - 요구사항 B: [구체적 설명] ## 3. 제약 조건 (Constraints) - 절대 포함하지 말아야 할 단어: [목록] - 톤앤매너: [스타일 정의] ## 4. 출력 형식 (Output Format) [JSON, Table 등 원하는 포맷 명시] ``` 마크다운 문법은 인간에게도 가독성을 주지만, LLM에게는 강력한 '의미론적 닻' 역할을 한다. 헤더(##)는 정보의 위계를 설정하고, 리스트(-)는 개별 항목의 독립성을 보장하며, 코드 블록(`\`)은 데이터의 경계를 명확히 한다. 이러한 구조적 장치들은 모델이 텍스트를 스캔할 때 토큰 간의 관계를 더 명확히 파악하게 돕고, 어텐션 가중치를 적절한 곳에 분배하도록 유도한다. 프롬프트를 잘 쓰고 싶다면, 마크다운이라는 문법을 유창하게 구사하라. 그것은 확률의 바다에서 모델이 길을 잃지 않도록 돕는 가장 확실한 나침반이다. --- ### 4.3 브라운필드(레거시)에서의 생존 전략 #### 유토피아의 환상과 현실의 진흙탕 우리는 종종 AI 에이전트가 텅 빈 캔버스, 즉 '그린필드' 프로젝트에서 보여주는 압도적인 퍼포먼스에 현혹되곤 한다. 새로운 대시보드를 생성하거나, 종속성이 없는 간단한 CRUD 애플리케이션을 만드는 시연은 마법과도 같다. 그러나 그것은 통제된 실험실 환경에서의 성공일 뿐이다. 엔지니어의 진짜 전장은 **'브라운필드'**다. 20년 묵은 자바 모놀리식 아키텍처, 작성자의 의도가 소실된 스파게티 코드, 문서와 실제가 딴판인 레거시 시스템. 이것이 우리가 마주하는 냉혹한 현실이다. 이 복잡계에 맥락 없는 에이전트를 투입하는 것은, 정교한 수술실에 눈을 가린 외과 의사를 들여보내는 것과 같다. 최근 스탠퍼드 대학의 연구 결과는 이 지점을 날카롭게 지적한다. AI 코딩 도구가 표면적인 생산성을 높이는 것은 사실이나, 그렇게 생산된 코드의 상당수가 "바로 직전에 AI가 저지른 실수를 수습하는 데" 쓰이고 있다는 것이다. 엔트로피가 감소하는 것이 아니라, AI가 생성한 '기술 부채'를 갚느라 엔트로피가 증가하는 역설적 상황이다. #### 인지적 한계선: '덤 존'의 회피 LLM은 본질적으로 상태 비저장 함수다. 그것의 지능은 모델의 파라미터가 아니라, **"현재 컨텍스트 윈도우에 적재된 정보의 질"**에 전적으로 의존한다. 문제는 컨텍스트 윈도우가 물리적 한계를 가진다는 점이다. 단순히 용량이 차는 것이 문제가 아니다. **'신호 대 잡음비'**의 문제다. 컨텍스트의 40% 이상이 채워지기 시작하면, 모델의 추론 능력은 급격히 저하된다. 우리는 이 구간을 **'덤 존'**이라 부른다. 수많은 도구 정의와 불필요한 로그들이 컨텍스트를 점유하면, 에이전트의 어텐션은 분산되고 판단력은 흐려진다. 따라서 레거시 환경에서 에이전트를 운용하는 핵심 전략은 **'컨텍스트 위생'**을 철저히 관리하는 것이다. 목표는 명확하다: - **정확성:** 검증된 사실만 남긴다. - **완전성:** 문제 해결에 필수적인 정보는 누락하지 않는다. - **최소성:** 불필요한 노이즈는 가차 없이 제거하여 윈도우를 가볍게 유지한다. #### 엔트로피 리셋: 의도적인 컨텍스트 압축 가장 흔히 범하는 실수는 '매몰 비용의 오류'에 빠지는 것이다. 에이전트가 틀린 답을 내놓았을 때, 우리는 종종 대화를 이어가며 교정을 시도한다. "아니, 그게 아니고...", "다시 생각해 봐", "A 파일도 참고해 봐." 이러한 대화의 누적은 치명적이다. 실패한 시도와 오답들이 컨텍스트에 쌓이면서, 다음 토큰 생성의 확률 분포를 오염시킨다. 이는 제 발로 '덤 존'으로 걸어 들어가는 행위다. 이를 타개하기 위한 고급 기법이 바로 **'의도적 컨텍스트 압축'**이다. 대화가 길어지거나 방향을 잃었을 때, 과감하게 세션을 끊어야 한다. 1. **상태의 직렬화:** 현재까지의 탐색 결과, 성공한 사실, 실패한 가설 등을 에이전트에게 시켜 마크다운 문서로 요약하게 한다. 2. **본질의 추출:** 이 문서에는 문제 해결에 필수적인 파일 경로, 핵심 코드 라인, 밝혀진 제약 조건만이 담겨야 한다. 3. **재부팅:** 새로운 에이전트 세션을 열고, 압축된 마크다운 문서만을 주입하여 작업을 재개한다. 이것은 에이전트의 **기억을 외부화**하고, 오염된 단기 기억을 소거하여 지능을 리셋하는 과정이다. #### RPI 워크플로우: 디지털 분업의 재설계 거대하고 복잡한 레거시 코드베이스를 다룰 때, 인간이 한 번에 모든 것을 처리하지 않듯 에이전트에게도 단계적 접근이 필요하다. 이를 체계화한 것이 RPI(Research-Plan-Implement) 워크플로우다. **1. Research (탐구 및 고고학)** 이 단계의 목표는 **'지도를 그리는 것'**이다. 코드를 수정하려는 욕망을 억제하고, 시스템의 현황을 파악하는 데 집중한다. 에이전트는 '읽기 전용' 모드로 작동하며, 파일 구조를 탐색하고, 호출 흐름을 추적하며, 관련 테스트 케이스와 빌드 로그를 분석한다. 결과물은 코드가 아니라, "어디를 고쳐야 하는가"에 대한 확신이 담긴 압축된 리서치 문서다. **2. Plan (설계 및 전략)** 리서치 문서와 요구사항(PRD/Ticket)을 결합하여, 구체적인 **'전술적 청사진'**을 수립한다. 이 플랜에는 모호함이 없어야 한다. - 변경할 파일의 정확한 경로. - 수정될 코드의 구체적인 스니펫. - 변경 후 검증할 테스트 시나리오. 이 단계는 **"인간의 의도를 기계가 실행 가능한 형태로 압축"**하는 과정이다. 창의성과 추론 능력은 여기서 모두 소진되어야 한다. **3. Implement (기계적 실행)** 구현 단계의 에이전트는 역설적으로 **"창의성이 거세된 타자수"**가 되어야 한다. 이미 수립된 완벽한 플랜을 수행만 하면 되도록 만들어야 한다. 컨텍스트에는 리서치와 플랜에서 추출된 최소한의 정보만 남겨, 에이전트가 항상 **'스마트 존'**에 머물도록 강제한다. 최근에는 이 단계를 더 세분화하여, 각 파일이나 모듈별로 독립적인 **서브 에이전트**를 할당해 병렬로 처리한 뒤 합치는 방식이 효율적임이 입증되고 있다. #### 인식론적 오류: 메멘토 증후군과 문서의 거짓말 에이전트를 프로젝트에 온보딩 시키지 않는다면, 그것은 영화 《메멘토》의 주인공과 같다. 매번 기억이 소거된 상태에서, 단편적인 정보만으로 그럴듯한 허구를 지어낸다. 이를 막기 위해 프로젝트 문서를 학습시키려는 시도가 많다. 그러나 여기에는 함정이 있다. 소프트웨어 공학에서 "문서는 본질적으로 거짓말을 한다." 코드는 실행됨으로써 자신의 진실성을 매 순간 증명하지만, 문서는 업데이트되지 않은 채 방치되어 현실과 괴리되기 일쑤다. '코드 부식'보다 무서운 것이 '문서 부식'이다. 따라서 낡은 문서를 학습시켜 에이전트에게 잘못된 편향을 심어주기보다는, **"요청 시점에 실제 코드를 읽어 진실을 파악하게 하는 리서치 워크플로우"**가 훨씬 강력하다. 문서를 믿지 말고, 코드를 읽게 하라. 코드는 거짓말을 하지 않는다. #### 컨텍스트 엔지니어링: 적정 기술의 적용 물론 모든 작업에 무거운 RPI 워크플로우를 적용하는 것은, 모기를 잡기 위해 대포를 쏘는 격이다. 작업의 규모와 복잡도에 따라 엔지니어링의 강도를 조절해야 한다. | 작업의 층위 | 접근 전략 | 컨텍스트 운용 | | ---------------------- | ------------------ | -------------------------- | | **단순 UI 변경** (버튼 색상 등) | Direct Instruction | 즉시 지시, 단일 턴 종료 | | **단일 함수/기능 구현** | Light Plan | 간단한 계획 수립 후 구현 | | **모듈 간 상호작용 수정** | Full RPI | 리서치 → 플랜 → 구현의 정석 | | **대규모 리팩토링** | Multi-agent RPI | 심층 리서치와 다단계 플랜, 서브 에이전트 활용 | 결국 **"얼마나 깊이 있게 컨텍스트를 엔지니어링 할 것인가"**를 결정하는 판단력이 에이전트 활용 능력의 척도가 된다. #### 소결: 진흙탕 속의 장인정신 "그린필드에서 에이전트가 춤추게 하는 것은 누구나 할 수 있다. 그러나 브라운필드의 진흙탕 속에서 에이전트가 길을 잃지 않게 하는 것이야말로 진짜 엔지니어의 실력이다." 지금까지 우리는 실전 활용법을 다루었다. 1. **리터러시:** 도구의 원리를 이해하고 '왜'를 묻는 태도. 2. **전략적 설계:** 서브 도메인은 AI에게, 코어 도메인은 인간에게. 3. **프롬프트 공학:** SRP 원칙과 구조화를 통한 어텐션 제어. 4. **레거시 생존법:** 덤 존의 회피와 RPI 워크플로우를 통한 엔트로피 제어. --- ## 5장: 미래 --- ### 5.1 보편성을 넘어선 초개인화의 시대 #### '평균의 종말'과 다원적 진리 현재의 LLM은 전 세계 데이터를 집대성하여 확률적으로 가장 '평균적인 답변'을 내놓는 **범용 모델**이다. 그러나 이 지점에서 우리는 근본적인 인식론적 질문을 던져야 한다. "과연 인류 모두에게 통용되는 단 하나의 보편적 진리란 존재하는가?" 진리는 맥락적이다. 한국 사회에서 통용되는 상식이 미국에서는 기이한 것으로, 서구권의 윤리가 중동에서는 금기로 받아들여진다. 각 문화권, 각 세대, 심지어 각 개인마다 섬기는 '신'의 형상이 다르다. 따라서 전지전능한 단 하나의 **범용 인공지능**이 등장하여 모든 인류를 만족시킨다는 발상은, 기술적 목표라기보다 신학적 환상에 가깝다. 따라서 미래의 AI는 필연적으로 **'초개인화 LLM(Hyper-personalized LLM)'**으로 진화할 것이다. 이는 단순히 추천 알고리즘이 정교해지는 차원이 아니다. 실시간 학습을 통해 나의 가치관, 업무 맥락, 화법, 심지어 지난달에 스치듯 나눴던 대화의 뉘앙스까지 기억하고 동기화하는 **'디지털 페르소나'**의 탄생을 의미한다. 범용 모델이 "통계적으로 무난한 정답"을 제시한다면, 개인화 모델은 **"나라는 고유한 존재에게 최적화된 해답"**을 제시할 것이다. 물론, 이는 역설적으로 **필터 버블**과 **확증 편향**을 기술적으로 강화하여, 타인과의 소통을 단절시키는 '인지적 고립'의 시대를 앞당길 위험 또한 내포하고 있다. #### 자율주행의 은유: 5단계라는 허상과 현실 LLM의 발전 단계는 자율주행 기술의 역사와 놀라울 정도로 유사한 궤적을 그리고 있다. 지금 우리는 '테슬라 오토파일럿'이 처음 등장했을 때의 충격과 흥분 속에 있다. 고속도로(정형화된 환경)에서 핸들을 놓고 차선을 변경하는 모습은 마법 같았다. 그러나 그로부터 10년이 지난 지금도, 우리는 어떠한 개입 없이 모든 도로 상황을 통제하는 **'완전 자율주행'**에 도달하지 못했다. 이유는 명확하다. 현실 세계는 무한한 변수와 엣지 케이스, 윤리적 딜레마, 법적 책임, 그리고 예측 불가능한 돌발 상황으로 가득 차 있기 때문이다. LLM 역시 마찬가지다. - **데이터의 기근:** 양질의 텍스트 데이터는 고갈되고 있다. - **할루시네이션과 안전:** 통계적 앵무새를 신뢰할 수 있는 엔지니어링 도구로 만드는 것은 차원이 다른 문제다. - **법적/사회적 합의:** 저작권과 책임 소재에 대한 사회적 합의는 기술 속도를 따라가지 못한다. SF 영화 속의 전지전능한 AI는 아직 요원하다. 그런데 왜 지금 시장은 이토록 혼란스러운가? 그것은 소프트웨어 생태계의 인력 구조가 양극화되어 있기 때문이다. 단순히 남이 만든 모듈을 조립하거나, MVP 수준의 기능 구현에 머물렀던 개발자들에게 이 변화는 실존적 위협이다. 그들의 업무는 기계가 가장 잘하는 영역이기 때문이다. 반면, 복잡한 현실의 문제를 정의하고, 시스템을 설계하며, 불확실성을 엔지니어링해 온 주체적인 엔지니어들에게 지금은 역사상 가장 강력한 레버리지를 얻은 기회의 시대다. #### 작용과 반작용의 법칙: 사회적 면역 반응의 시작 뉴턴의 제3법칙(작용-반작용)은 물리학을 넘어 사회학에도 적용된다. 현재의 폭발적인 AI 열풍(작용)은 필연적으로 거대한 사회적 반작용을 불러올 것이다. 기술은 사회라는 유기체에 침투하는 이물질과 같아서, 임계점을 넘으면 사회적 면역 반응이 작동한다. - **법적 분쟁:** 뉴욕타임스와 작가 조합의 소송은 시작일 뿐이다. 학습 데이터의 공정 이용에 대한 법적 리스크는 기업의 존립을 흔들 수 있다. - **창작자의 저항:** 예술가와 지식 노동자들의 집단적 반발은 기술 도입의 속도를 늦추는 '인간적 마찰력'으로 작용할 것이다. - **정치적 압박:** 일자리 소멸에 대한 공포는 선거철 정치인들에게 가장 강력한 규제 명분을 제공한다. - **열역학적 한계:** 기하급수적으로 늘어나는 데이터센터의 전력 소비와 탄소 배출은 기후 위기 시대에 용납받기 힘든 수준에 이를 것이다. 이러한 현실적 반작용들이 가시화될 때, 무한할 것 같았던 모델 산업의 성장 속도는 제동이 걸릴 것이다. 그리고 그 시점에 거품은 붕괴하고, 진정한 옥석 가리기가 시작될 것이다. #### 로보틱스: 탈신체화 지능의 한계 극복 LLM의 미래는 텍스트 처리 기술의 점진적 개선에 머물지 않을 것이다. 현재 실리콘밸리의 선구적 엔지니어들이 주시하는 다음 프런티어는 바로 로보틱스다. 왜 하필 로봇인가? 언어만으로는 세계를 온전히 이해할 수 없기 때문이다. 앞서 2장에서 논했듯, LLM은 텍스트라는 2차원적 상징 체계만을 학습했다. 그러나 인간의 지성은 물리적 실체를 통해 세계와 상호작용하며 형성된다. 중력의 감각, 물체의 질감, 공간의 깊이, 시간의 흐름과 같은 **'물리적 상식'**은 텍스트에 다 담기지 않는다. 따라서 미래의 AI는 가상 공간을 넘어, 물리적 신체를 입고 현실 세계와 부딪히며 학습하는 **'신체화된 AI(Embodied AI)'**로 진화할 것이다. 이 과정에서 우리는 역설적으로 인문학의 르네상스를 맞이할지도 모른다. 인간을 닮은 로봇을 만들기 위해서는, 기계 공학을 넘어 뇌과학, 심리학, 인지과학, 그리고 인간 본성에 대한 철학적 탐구가 선행되어야 하기 때문이다. 결국 기계를 이해하는 길은 인간을 이해하는 길과 맞닿아 있다. #### ㅠ자형 인재론: 인지적 사일로의 붕괴와 융합 전통적인 개발 조직에서 가장 비싼 비용은 서버 비용이 아니라 **'커뮤니케이션 비용'**이었다. 백엔드, 프론트엔드, 인프라, 데이터 등 전문화된 직군들은 각자의 '지식 사일로' 안에 갇혀 있었다. 서로의 언어를 이해하지 못했기에 협업은 늘 오해와 지연을 동반했다. 그러나 AI 시대는 이 장벽을 허물고 있다. LLM은 각기 다른 도메인의 지식을 번역하고 설명해 주는 '인지적 교량' 역할을 수행한다. 이제 백엔드 개발자도 AI의 도움을 받아 인프라 코드를 '이해 가능한 수준'으로 독해할 수 있고, 프론트엔드 개발자도 서버 로직의 흐름을 파악할 수 있다. 완벽한 전문가가 될 수는 없어도, 맥락을 공유하고 대화가 통하는 수준까지는 순식간에 도달할 수 있다. 따라서 미래의 인재상은 한 분야의 깊이만 있는 'I자형'이나, 얕고 넓은 'T자형'을 넘어, 두 개 이상의 전문성을 연결하는 'ㅠ자형 인재', 혹은 **'풀스택 엔지니어'**로 진화할 것이다. 이것은 한 사람이 모든 일을 다 해야 한다는 뜻이 아니다. **"나의 전문성과 동료의 전문성 사이의 교집합을 넓힌다"**는 의미다. 내가 상대방의 영역을 평균 수준까지 이해함으로써, 불필요한 커뮤니케이션 비용을 제거하고, 확보된 시간을 서로의 본질적인 전문성을 발휘하는 데 쏟는 것. 이것이 AI 시대가 요구하는 진정한 협업의 방식이자 생존 전략이다. --- ### 5.2 증강된 인간으로 살아남기 #### 호기심의 함정: 지적 도파민과 실행의 부재 > "호기심이 미래다." LLM 시대에 주목받는 말이다. 그러나 나는 조금 다르게 생각한다. > "실행되지 않은 호기심은 지적 쾌락에 불과하다." LLM의 등장은 지적 탐구의 비용을 '0'에 수렴하게 만들었다. 과거에는 궁금증을 해소하기 위해 책을 뒤지고, 문서를 보고, 전문가를 찾아야 했다. 그 과정 자체가 학습이자 사유의 시간이었다. 그러나 지금은 프롬프트 한 줄이면 즉답이 떨어진다. 우리는 "아, 그렇구나" 하고 고개를 끄덕이며 다음 호기심으로 넘어간다. 이것은 위험한 **'능력의 착각'**을 낳는다. 검색과 생성이 쉬워질수록, 우리는 호기심 충족 과정을 외주화하게 된다. 끊임없이 새로운 지식을 탐닉하지만, 정작 내 머릿속에 체화된 지식은 전무한 상태. 이것은 소파에 누워 숏폼 영상을 보며 도파민을 쫓는 행위와 본질적으로 다르지 않다. 진정한 성장은 답변을 얻는 순간이 아니라, 그 답변을 현실에 적용해 보는 순간에 일어난다. AI가 제공하는 즉각적인 피드백을 지렛대 삼아, **'실행 - 검증 - 개선'**으로 이어지는 성장 루틴을 구축해야 한다. 호기심을 소비하는 자가 아니라, 호기심을 실행의 연료로 태워 성장을 향한 **복리의 마법**을 만드는 자만이 살아남을 수 있다. #### 공생의 모델: 토니 스타크와 자비스의 변증법 우리는 AI와의 관계를 어떻게 설정해야 하는가? SF 영화 《아이언맨》의 토니 스타크와 자비스(J.A.R.V.I.S.)의 관계는 가장 이상적인 **'인간-기계 공생'**의 원형을 보여준다. 자비스가 토니를 대체하는가? 결코 아니다. 자비스는 토니의 지적, 물리적 역량을 극대화하는 '증강' 도구로 존재한다. 토니가 새로운 슈트를 설계할 때, 자비스는 수만 번의 시뮬레이션을 돌리고, 데이터를 분석하며, 구조적 결함을 경고한다. 그러나 **"무엇을 만들 것인가"**와 **"최종적으로 실행할 것인가"**에 대한 판단은 오직 토니 스타크의 몫이다. 창조의 스파크와 책임의 무게는 인간에게 있다. 이것은 전문직의 업무 구조와도 유사하다. 유능한 변호사는 판례 수집과 서면 초안 작성을 보조 인력에게 맡긴다. 그러나 법정에서의 최종 변론 전략과 논리의 핵심 구조는 변호사 본인이 설계한다. 우리는 LLM을 '디지털 패러리걸' 혹은 '자비스'로 활용해야 한다. - **AI의 몫:** 광범위한 자료 수집, 초안 작성, 반복적인 보일러플레이트 코딩, 데이터 전처리. - **나의 몫:** 문제의 정의, 가치 판단, 아키텍처 설계, 그리고 최종 결과물에 대한 책임. AI에게 운전대를 넘기지 마라. 내비게이션으로 활용하라. 핸들은 여전히 당신이 쥐고 있어야 한다. #### 피드백의 사각지대: '닫힌 게임' 밖으로 탈출하라 3장에서 우리는 LLM이 '닫힌 게임', 즉 규칙이 명확하고 피드백이 빠른 영역(코딩, 수학, 번역)에서 인간을 압도한다고 논했다. 역으로 말하면, 피드백 루프를 형성하기 어렵고 모호성이 지배하는 영역이야말로 LLM이 가장 취약한 지점이자, 인간 엔지니어의 최후의 성역이다. 우리는 이제 쉬운 영역을 떠나, 더 어렵고 복잡한 곳으로 이동해야 한다. 1. **암묵지의 영역:** 데브옵스, 인프라, 데이터 엔지니어링 사내 인프라 환경은 인터넷에 공개되지 않는다. 그곳은 고유한 히스토리, 문서화되지 않은 핫픽스, 복잡하게 얽힌 네트워크 정책들이 지배하는 **'비공개 컨텍스트'**의 세계다. 인터넷 데이터를 학습한 LLM은 우리 회사의 폐쇄망 구조를 알지 못하며, 재현 불가능한 간헐적 장애의 원인을 추론하기 어렵다. 공개된 지식이 아닌, 조직 내부에 흐르는 암묵지가 중요한 이 영역은 여전히 인간의 통제력을 필요로 한다. 2. **번역가로서의 도메인 전문가** 기술과 비즈니스의 경계선은 AI가 넘기 힘든 벽이다. 현업의 모호한 요구사항("느낌적인 느낌으로 빠르게 해주세요")을 구체적인 기술 명세로 번역하는 능력, 비즈니스 도메인의 복잡한 규칙을 소프트웨어 아키텍처로 승화시키는 능력. 이러한 **'중재자'**로서의 역할은 단순 코딩 능력을 넘어선다. 비즈니스와 기술 양쪽의 맥락을 모두 이해하고 통합하는 능력은 기계가 대체하기 어려운 고유한 가치다. 3. **동적 혼돈 속의 문제 해결** 폭발적으로 성장하는 서비스는 교과서에 없는 문제들을 던진다. - 블랙 프라이데이의 예측 불가능한 트래픽 스파이크. - 마이크로서비스 간의 데이터 정합성 깨짐. - 레거시 시스템과 신규 시스템의 충돌. 이런 상황은 정해진 정답이 없으며, 순간적인 판단력과 임기응변, 그리고 리스크 감수가 요구된다. '전장의 안개' 속에서 길을 찾는 능력은 과거 데이터에 갇힌 AI가 흉내 낼 수 없는 영역이다. 결론적으로, 쉬운 문제는 기계에게 넘겨라. 그리고 기계가 풀 수 없는 어렵고 지저분한 문제가 있는 곳으로 가라. 그곳에 생존과 성장의 기회가 있다. #### 경험주의적 학습의 복원: '전문가'라는 허상과의 결별 현대 기술 교육 시장은 기이한 역설에 빠져 있다. LLM과 에이전트 기술이 태동한 지 불과 1~2년 남짓 된 시점에, 시중에는 이미 "프롬프트 엔지니어링 마스터 클래스", "AI 전문가 과정"과 같은 강의들이 범람하고 있다. 우리는 여기서 합리적인 의심을 품어야 한다. 학문적 정립조차 되지 않은 이 미개척지에서, 과연 누가 누구를 가르칠 자격, 즉 '권위'를 획득했는가? 그 소위 '전문가'들의 지식은 어디서 비롯되었는가? 그들 또한 정돈된 교과서가 아닌, 혼란스러운 현장에서 직접 모델과 씨름하고, 수없는 시행착오를 겪으며 체득한 **'암묵지'**의 파편들일 뿐이다. 그럼에도 많은 이들이 불안감 때문에 강의를 결제하고 책을 사 모으며 안도감을 느낀다. 이는 전형적인 **'지식의 소비주의'**다. 남이 소화하여 배설한 정제된 지식을 수동적으로 섭취하는 것만으로는, 결코 야생의 변화 속도를 따라잡을 수 없다. 진정한 학습은 강의실이 아닌, '야생의 실행' 속에 있다. - 직접 프롬프트를 작성하고 깨져보는 것. - 에이전트를 활용하다가 덤 존에 빠져 작업을 망쳐보는 것. - 그 실패의 원인을 분석하며 나만의 멘탈 모델을 수정하는 것. 이러한 경험주의적 접근만이 지속 가능한 성장을 담보한다. 텍스트로 배운 이론가는 진흙탕에서 구르며 몸으로 배운 실천가를 영원히 이길 수 없다. 지금 필요한 것은 수료증이 아니라, 내 손끝에 남은 감각이다. #### 실존적 리팩토링: 삶의 아키텍처를 재설계하라 소프트웨어 엔지니어들은 코드의 품질에 대해서는 병적일 만큼 엄격한 기준을 들이댄다. "결합도는 낮추고, 응집도는 높여야 한다." "변화에는 유연하게 대응하되, 확장에 열려 있어야 한다." 그러나 정작 자신의 **'삶의 아키텍처'**를 돌아볼 때는, 그토록 숭상하던 설계 원칙들을 망각하곤 한다. 변화하는 세상에 대해 방어 기제를 높이고, 새로운 기술을 받아들이지 못해 고립을 자초한다. 코드는 유연하게 짜면서, 삶은 경직된 레거시로 방치하는 모순이다. 우리는 삶에도 **'리팩토링'**을 적용해야 한다. 자바 생태계의 스프링이 20년 넘게 생태계의 패권을 유지할 수 있었던 비결은 무엇인가? 그것은 **제어의 역전과 의존성 주입**이라는 확고한 **'코어 철학'**을 유지하면서도, 클라우드 네이티브, 리액티브 프로그래밍, 코틀린 지원 등 시대가 요구하는 **'새로운 가지'**들을 끊임없이 흡수하고 통합했기 때문이다. 우리도 마찬가지다. LLM의 등장을 두고 "개발자의 시대는 끝났다"며 비관하거나, 반대로 "저것은 일시적 유행일 뿐"이라며 배척하는 양극단은 모두 건강하지 못한 태도다. **나의 코어 역량(Domain Knowledge, Problem Solving)**은 단단히 유지하라. 그리고 LLM이라는 거대한 파도를 나를 무너뜨릴 쓰나미가 아니라, 내 역량에 주입할 새로운 라이브러리로 바라보라. 코어를 지키되 변연부를 끊임없이 확장하는 것, 그것이 격변의 시대를 건너는 **'진화적 아키텍처'**다. #### 기술의 범용화와 차별화: 출퇴근 운전자와 F1 레이서의 딜레마 테슬라의 FSD(Full Self-Driving)가 고도화되면서 "운전의 종말"이라는 담론이 제기되었다. 이와 유사하게 "바이브 코딩"은 "코딩의 종말"을 예고하는 듯하다. 그러나 이 종말론은 절반만 맞고 절반은 틀렸다. 이를 이해하기 위해 **'행위의 목적'**을 구분해야 한다. 1. **출퇴근 운전자 (The Commuter): 수단으로서의 기술** 단순히 A지점에서 B지점으로 이동하는 것이 목적인 사람에게 운전은 '노동'이자 '비용'이다. 막히는 도로에서 브레이크를 밟았다 떼는 행위는 지루하고 고통스럽다. 이들에게 자율주행은 축복이다. 운전이라는 불필요한 인지 부하를 덜어내고, 그 시간에 다른 생산적인 일을 할 수 있기 때문이다. 2. **F1 레이서 (The Racer): 본질로서의 기술** 반면, 극한의 속도를 제어하고 0.001초의 랩타임을 단축하기 위해 목숨을 거는 F1 레이서에게 자율주행은 무의미하다. 그들에게 운전은 수단이 아니라 **'존재의 증명'**이자 **'업의 본질'**이기 때문이다. 소프트웨어 개발도 동일한 갈림길에 섰다. 당신에게 개발이 그저 "기능을 구현하여 월급을 받기 위한 수단"에 불과했다면, 즉 '코드 작성' 자체가 지루한 이동 과정이었다면, AI 자동화는 당신의 직업을 앗아가는 위협이 될 것이다. AI는 지루한 반복 운전을 인간보다 훨씬 잘하기 때문이다. 이것은 **'평범함의 범용화'**다. 그러나 당신이 **'문제 해결의 본질'**을 탐구하고, 시스템의 극한 성능을 튜닝하며, 비즈니스 가치를 창출하는 아키텍처를 고민하는 **'엔지니어링 레이서'**라면? AI는 당신의 질주를 돕는 첨단 텔레메트리 시스템이자 부스터가 될 것이다. 결국 질문은 우리 자신에게로 돌아온다. "나는 코드를 짜는 노동자인가, 아니면 문제를 해결하는 장인인가?" 자신의 일이 AI로 대체될 수 있다면, 그것은 애초에 인간의 고유한 역량이 필요치 않았던 영역이었을지 모른다. 이제 우리는 AI가 흉내 낼 수 없는, F1 레이서만의 감각과 통찰을 연마해야 한다. 그것이 이 자동화의 시대에 인간으로서 존엄을 지키며 생존하는 유일한 길이다. --- ## 변하지 않는 본질 이 글 전체를 관통하는 메시지는 하나다. **LLM은 전지전능한 지능이 아니라 도구다.** 도구는 도구일 뿐이다. LLM이 아무리 발전해도, 결국 그걸 어떻게 쓰느냐는 사람에게 달려 있다. 도구를 탓하지 말고, 도구에 휘둘리지 말고, 도구를 제대로 활용하자. 이 시대를 살아가는 법은 결국 예전과 다르지 않다. **배우고, 실행하고, 성장하라.** 다만 도구가 좋아졌을 뿐이다. 좋은 도구를 가졌으면, 좋은 결과물을 만들자. 그게 전부가 아닐까? ]]> https://hyukjin-lee.github.io/tech/2025/12/LLM시대-살아가기 https://hyukjin-lee.github.io/tech/2025/12/LLM시대-살아가기 Sun, 21 Dec 2025 00:00:00 GMT 환경을 바꾸라는 말이 머리로는 이해가 되지만, 개인적으로 오랜 시간 감내해야 하는 고통의 시간이 인생의 낭비라는 생각이 들었다. 주니어 시절에 이 영상을 보았을 때는 강태훈 님이 틀렸다고 생각했다. 현실 세계에서는 나와 맞지 않은 환경이 대부분일 것이고, 그것들에 영향받지 않으려면 내가 그 환경을 바꿀 수 있어야 한다고 생각했다. 그리고 환경을 바꾸는 역량이 진짜 핵심 역량이고, 나와 맞는 환경을 끊임없이 찾아가는 건, 마치 ‘파랑새 증후군’처럼 존재하지 않는 것에 대한 환상을 계속 좇는 것이라고 생각했다. 이때의 생각은 여전히 남아있지만, 조금은 디테일해진 부분이 있다. **내가 바라는 환경이 그 회사에 조직/비즈니스적으로 정말 긍정적으로 기여하는 것인지 객관화하여 저울질을 해봐야 한다는 것이다.** - 예를 들어, 회사는 트래픽이 중요한 비즈니스가 아닌데 본인이 추구하는 개발 문화와 각종 Practices 가 트래픽이 많은 기업에 유용한 것들이라면, 그건 오히려 조직에 기여하는게 아니라 방해하는 것이다. 인생과 마찬가지로 개발과 엔지니어링에는 정답이 없고 환경과 상황에 따라 다르게 접근해야 한다 - 내 삶의 목적이 있고, 목적에 부합하는 커리어 방향이 있고, 커리어 방향에 따른 성장 방향이 존재한다고 가정했을 때, 그 방향과 회사에 기여할 수 있는 방향이 어느 정도는 같은 방향을 바라보고 있어야 한다. 방향이 서로 다르다면 강태훈 님 말씀처럼 서로에게 시간 낭비이거나 부정적인 경험이 될 수 있다. 완벽하게 나에게 맞는 회사는 존재하지 않을 가능성이 높겠지만 적어도 바라보는 방향이 비슷한 기업을 만나야 한다. 하지만 목적과 방향이 분명하게 설정된 사람은 드물다. 그렇기 때문에 이상향을 쫓는 것보다 주어진 환경에서 고군분투하며 경험을 쌓아나가고, 그 경험을 통해 목적과 방향을 설정하는 역방향의 접근이 현실적일 때도 많다. **결국은 자신에 대해 먼저 아는 것이 중요하다.** 아무튼, 괴로움이 지속되어 고통이 되었다면 파랑새를 찾아 떠나보는 것이 어떨까 ]]> https://hyukjin-lee.github.io/blog/2025/10/인생의 낭비 https://hyukjin-lee.github.io/blog/2025/10/인생의 낭비 Fri, 24 Oct 2025 00:00:00 GMT https://hyukjin-lee.github.io/blog/2025/09/정보 소비 방식의 변화와 나의 삶 https://hyukjin-lee.github.io/blog/2025/09/정보 소비 방식의 변화와 나의 삶 Sun, 28 Sep 2025 00:00:00 GMT https://hyukjin-lee.github.io/blog/나홀로 상하이/undefined/ https://hyukjin-lee.github.io/blog/나홀로 상하이/undefined/ Invalid Date https://hyukjin-lee.github.io/daily/2025/10/fguy-story https://hyukjin-lee.github.io/daily/2025/10/fguy-story Fri, 17 Oct 2025 00:00:00 GMT 참고 자료: > > - Dahl, O.-J., & Nygaard, K. (1966). *SIMULA—an ALGOL-based simulation language.* Communications of the ACM. > - Nygaard, K., & Dahl, O.-J. (1978). *The development of the SIMULA languages.* History of Programming Languages, ACM. ## 1.3 Alan Kay와 Smalltalk: 객체지향 철학의 정립 Simula에서 탄생한 객체 개념은 미국 Xerox PARC(Palo Alto Research Center)에서 Alan Kay와 동료들이 1970년대 개발한 **Smalltalk** 언어를 통해 철학적 깊이를 더했다. Kay는 객체지향을 **단순한 언어 기법이 아닌 사고방식**으로 정의했으며, 시스템을 **자율적인 객체들이 메시지를 통해 협력하는 유기체**로 바라보았다. 이 관점에서 객체는 내부 구현을 감추고 메시지로만 상호작용하는 **분산된 지능과 상호작용의 단위**였다. ### Kay의 비전과 시대적 맥락 Alan Kay가 그린 큰 그림은 **개인용 컴퓨팅**과 **교육적 활용**, **직관적 상호작용**에 대한 비전이었다. 그는 “Dynabook”이라는 휴대 가능한 개인용 컴퓨터 개념을 통해 아이나 성인이 직관적으로 컴퓨터와 상호작용하면서 학습하고 창조할 수 있는 미래를 상상했다. 이 비전에서 객체지향은 단순히 코드를 구조화하는 방법이 아니라, 인간 친화적이고 학습 친화적인 컴퓨팅 환경을 구현하는 핵심 추상화 원리였다. Xerox PARC는 당시 마우스, 고해상도 디스플레이, 그래픽 사용자 인터페이스(GUI), WYSIWYG 편집기 등을 실험하며, **모든 사용자가 그래픽 모니터와 마우스를 사용하게 될 것**이라는 가정을 바탕으로 혁신적 기술을 탐구하고 있었다. Smalltalk 환경은 “모든 것이 객체”인 세계에서 이러한 상호작용 방식을 구현하기에 이상적이었다. 여기서 GUI는 객체지향 철학을 직관적 시각 인터페이스 형태로 실현하는데 중요한 역할을 했으나, GUI 그 자체가 객체지향의 목표는 아니었다. 오히려 객체지향 사고를 통해 상호작용적, 교육적, 개인화된 컴퓨팅 비전을 구현하는 과정에서 GUI는 자연스럽게 부각된 도구였다. > - 당시 Xerox PARC 의 연구 내용들에 관심이 많았던 스티브 잡스가 직접 객체지향에 대해 설명했던 [자료](https://medium.com/curious-burrows/steve-jobs-explains-object-oriented-programming-d29451775afd)도 존재한다. > - 잡스는 애플을 떠난 뒤 넥스트사를 세워 세계 최초의 객체지향 운영체제인 ‘넥스트 스텝’을 개발한 이력도 있다.  > - 넥스트 스텝은 Objective-C 로 개발되었고, Rhapsody 를 거쳐 현재 우리가 널리 사용하는 OS X 으로 발전되었다. ### Smalltalk의 기여 Smalltalk는 메시지 패싱, 동적 바인딩, 통합 개발 환경 등 객체지향 패러다임의 핵심 요소를 순수하고 일관되게 구현한 언어로 꼽힌다. 이후 C++, Objective-C, Java, C# 등 수많은 언어들이 Smalltalk의 아이디어를 받아들이고 변용하면서 객체지향은 소프트웨어 개발의 주류 패러다임으로 성장했다. > 참고 자료: > > - Kay, A. C. (1993). *The Early History of Smalltalk.* ACM SIGPLAN Notices. > - Ingalls, D. H. H. (1981). *Design principles behind Smalltalk.* BYTE. ## 1.4 초기 객체지향 사상의 본질 초기 객체지향 사상은 단순한 기술적 개선을 넘어 다음과 같은 본질적인 변화를 예고했다. - **추상화와 캡슐화**: 객체 단위로 데이터와 행위를 묶고, 내부 구현을 은닉함으로써 복잡성을 통제하고 재사용성을 높였다. - **메시지 중심 상호작용**: 객체가 메시지를 주고받으며 협력하는 모델은, 시스템 유연성과 변경 용이성을 제고한다. - **인간 친화적 모델링**: 현실 세계 개념을 코드로 투영해 문제를 더 자연스럽게 표현하고, 직관적인 시스템 이해를 지원한다. 이러한 특징은 소프트웨어 개발을 **기술적 활동에서 도메인 이해를 통한 복잡성 제어 활동**으로 인식하는 큰 전환점이었다. ## 1.5 이후를 향한 흐름: 도메인 모델링과 DDD로의 진화 객체지향 개념만으로 대규모 엔터프라이즈 도메인 복잡성을 모두 해결할 수는 없었다. 1980~90년대 Grady Booch, James Rumbaugh, Ivar Jacobson 등이 객체지향 분석·설계(OOAD)와 UML(Unified Modeling Language)을 발전시켜 복잡한 도메인을 구조적으로 모델링할 수 있는 방법론을 마련했다. 이로써 **도메인 모델링** 개념이 산업계 전반에 확산되었고, 궁극적으로 Eric Evans가 2003년 제안한 DDD(Domain-Driven Design)가 도메인 지식 중심의 전략적 설계 철학으로 결실을 맺었다. --- # 2장: 객체지향 분석·설계 방법론의 발전과 UML의 탄생 ## 2.1 서론: 언어에서 방법론으로 1장에서 우리는 객체지향 프로그래밍(OOP)의 태동 과정을 살펴보았다. Simula와 Smalltalk는 객체지향 사고방식을 언어 차원에서 구현하고 실험하는 장을 열었다. 그러나 산업 현장에서 규모가 큰 소프트웨어를 개발할 때는 단순히 언어적 특성만으로 복잡한 도메인을 효과적으로 관리하기 어려웠다. 즉, “어떻게 객체를 찾고, 어떻게 이들을 협력하도록 조직화하며, 어떻게 요구사항을 객체 모델로 전환할 것인가?”라는 더 상위 수준의 문제에 답할 필요가 있었다. 1980년대 후반부터 1990년대 중반까지 산업계와 학계는 객체지향을 분석(Analysis) 및 설계(Design) 단계에 본격적으로 적용하기 시작했다. 이 시기는 다양한 객체지향 분석·설계 방법론(OOAD Methodologies)이 등장하고 경쟁한 ‘방법론의 격동기’였다. 이러한 방법론들은 점진적으로 통합되어 마침내 **UML(Unified Modeling Language)** 이라는 산업 표준 시각화 언어로 결실을 맺게 된다. ## 2.2 객체지향 분석·설계 방법론의 부상 ### 2.2.1 Booch 방법론 (Grady Booch) **Grady Booch**는 1980년대 후반부터 객체지향 개발 기법을 정리하여, 1991년 출간한 저서 _Object-Oriented Design with Applications_에서 객체지향 분석·설계 접근법을 제시했다. Booch는 클래스와 객체를 식별하고, 시스템을 오브젝트 단위로 구조화하는 방식을 정립했다. 또한 그가 고안한 그래픽 표기법과 설계 아이콘은 나중에 UML 개발 시 참고 대상이 되었다. Booch 방법론의 특징은 다음과 같다. - **풍부한 표현 요소**: 클래스, 객체, 관계를 나타내는 기호들과 아키텍처를 계층적으로 표현하기 위한 풍부한 노테이션 활용. - **반복적·점진적 접근**: 대규모 시스템을 한 번에 완성하기보다, 설계와 구현을 반복하고 개선하는 개발 사이클을 강조. > **참고 자료:** > > - Booch, G. (1991). *Object-Oriented Design with Applications*. Benjamin/Cummings. ### 2.2.2 OMT(객체모델링기법) - James Rumbaugh **James Rumbaugh**와 그의 동료들이 제안한 OMT(Object Modeling Technique)는 분석 단계에서 도메인의 개념적 모델을 구축하기 위한 시스템적 접근을 제공했다. OMT는 객체 모델, 동적 모델, 기능 모델의 세 가지 관점을 통해 문제를 구조화했다. 특히 **객체 모델**은 클래스, 객체, 속성, 관계 등 도메인의 정적 구조를 잘 드러내도록 설계되어 도메인 중심 사고를 장려했다. Rumbaugh의 방법론은 엔지니어들이 복잡한 문제 영역을 계층적이고 정돈된 객체 다이어그램으로 표현하도록 함으로써, 요구사항을 명확히 하고 나중에 설계 및 구현으로 연결하기 쉽게 했다. > **참고 자료:** > > - Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1991). *Object-Oriented Modeling and Design*. Prentice Hall. ### 2.2.3 OOSE(객체지향 소프트웨어 엔지니어링) - Ivar Jacobson **Ivar Jacobson**은 1992년 저서 _Object-Oriented Software Engineering: A Use Case Driven Approach_를 통해 “Use Case(유즈케이스)” 개념을 소프트웨어 분석의 중심 기법으로 제안했다. 유즈케이스는 사용자(또는 외부 행위자) 관점에서 시스템의 기능적 요구사항을 표현하는 방식으로, 객체 모델을 구축하기 전 사용자 목표와 시스템 반응을 명확하게 기술할 수 있었다. OOSE 방법론에서 유즈케이스는 객체지향 설계로 이어지는 가교 역할을 했으며, 개발팀이 도메인의 요구사항을 이해하고 적절한 객체들을 식별하는 실용적 수단을 제공했다. > **참고 자료:** > > - Jacobson, I., Christerson, M., Jonsson, P., & Övergaard, G. (1992). *Object-Oriented Software Engineering: A Use Case Driven Approach*. Addison-Wesley. ## 2.3 방법론 통합과 UML의 형성 배경 1990년대 초중반, 객체지향 분석·설계 방법론 분야는 Booch, OMT, OOSE 외에도 여러 경쟁 방법론들이 난립한 상태였다. 산업계에서는 어떤 방법론을 채택해야 할지 혼란스러워했고, 상호 호환성도 낮았다. 이때 세 명의 거장인 **Booch, Rumbaugh, Jacobson**—훗날 “Three Amigos”라 불리게 된 이들은 각각의 방법론 장점을 결합하는 통일된 표준 모델링 언어를 만드는 작업에 착수했다. **Rational Software사**(나중에 IBM에 인수)는 세 인물을 영입하여 각 방법론의 베스트 프랙티스를 통합하고, 산업 표준으로 삼을 만한 언어를 개발하도록 지원했다. 이 과정에서 **“통일된”** 모델링 언어, 즉 UML의 초기 버전들이 제안되었다. ## 2.4 UML(Unified Modeling Language)의 탄생과 표준화 ### 2.4.1 UML의 목표와 특징 UML은 1997년 **OMG(Object Management Group)** 에 의해 공식 표준으로 채택되며 객체지향 분석·설계 커뮤니티의 표준 언어가 되었다. UML의 목표는 다음과 같이 요약할 수 있다. 1. **공통 시각화 언어 제공**: 도메인 모델, 설계, 아키텍처를 표현하기 위한 일관된 그래픽 노테이션 세트를 제공. 2. **방법론 중립성**: UML 자체는 특정 개발 프로세스나 방법론에 종속되지 않고, 다양한 객체지향 방법론을 지원할 수 있는 범용 모델링 언어로 설계됨. 3. **표준화된 의미론**: 클래스 다이어그램, 시퀀스 다이어그램, 유즈케이스 다이어그램 등 여러 유형의 다이어그램을 통해 도메인 개념, 객체 상호작용, 시스템 동작 흐름을 정형화된 방식으로 표현. ### 2.4.2 UML의 주요 다이어그램과 도메인 모델링 UML의 핵심 다이어그램 중 **클래스 다이어그램(Class Diagram)** 은 도메인을 객체로 추상화하는 데 핵심적인 역할을 한다. 클래스, 속성, 연관관계, 일반화(상속), 집합(합성, 집약) 등의 요소를 표준화된 기호로 표현함으로써, 도메인 모델은 누구나 이해할 수 있는 형태로 문서화될 수 있었다. 아울러 **유즈케이스 다이어그램(Use Case Diagram)** 은 Jacobson의 유즈케이스 개념을 UML 표준의 일부로 정착시킴으로써 요구사항 분석과 도메인 이해를 지원했다. 이외에도 **시퀀스 다이어그램**, **커뮤니케이션 다이어그램**, **스테이트 머신 다이어그램**, **액티비티 다이어그램** 등 다양한 UML 다이어그램이 시스템 동작과 객체 상호작용을 다각적으로 표현할 수 있도록 했다. > **참고 자료:** > > - Booch, G., Rumbaugh, J., & Jacobson, I. (1999). *The Unified Modeling Language User Guide*. Addison-Wesley. > - OMG 공식 표준 문서: *UML Specification* (초기판은 1997년, 이후 버전 업데이트) ### 2.4.3 산업계 수용과 도구 지원 UML이 OMG 표준으로 채택되자, 수많은 CASE(Computer-Aided Software Engineering) 도구 업체들이 UML 지원을 내세우며 모델링 툴을 출시했다. Rational Rose, TogetherJ, Enterprise Architect 등이 대표적인 예다. 이 도구들은 개발팀이 도메인 모델과 설계 산출물을 일관된 방식으로 유지, 공유, 버전관리하도록 도왔다. 산업계는 UML을 통해 서로 다른 팀, 다른 조직 간에도 공통된 모델 표현 방식을 갖추게 됐다. 이는 대규모 시스템 개발에서 의사소통 비용을 줄이고, 도메인 요구사항을 명료하게 공유하며, 재사용 가능한 설계 자산을 만드는 기반을 마련했다. ## 2.5 UML 이후: 도메인 모델링과 객체지향의 융합 UML의 정착은 객체지향 사상을 단순한 언어 기능 차원을 넘어, **도메인 분석, 시스템 아키텍처 설계, 구현 전 과정**에 녹아들게 하는 데 중요한 이정표였다. 이제 개발자들은 “도메인 모델”을 UML 클래스 다이어그램 등으로 명확히 표현하고, 이를 코드 구현과 연계하는 체계적인 프로세스를 갖추게 되었다. 하지만 UML과 OOAD의 확산에도 불구하고, 여전히 한 가지 문제가 남아 있었다. UML 다이어그램이 아무리 정교해도, 이것이 실제 비즈니스 도메인의 지식과 요구사항 변화를 지속적으로 반영하고 개선하는 메커니즘으로 작동하지 않으면 무용지물이 되는 경우가 많았다. 즉, 단순히 모델링 표기법과 프로세스가 정교해지는 것만으로는 실제 도메인 복잡성을 근본적으로 해결하기 어렵다는 인식이 서서히 확산되었다. 이러한 문제 의식은 2000년대 초반 **Domain-Driven Design(DDD)** 라는 새로운 패러다임이 부상하는 씨앗이 되었다. DDD는 도메인 모델을 설계의 중심에 두고, 모델 자체를 비즈니스 전문가와 개발자가 공유하는 “언어”로 발전시키는 접근을 통해 도메인 복잡성을 해결하고자 한다. --- # 3장: 도메인 모델링의 재발견과 도메인 주도 설계(DDD)의 탄생 ## 3.1 도메인 모델링의 가치 재조명 2장에서 살펴보았듯, 1990년대 후반까지 객체지향 분석·설계와 UML은 소프트웨어 엔지니어링 커뮤니티에 널리 확산되었다. 이로써 개발자들은 도메인을 시각적으로 모델링하고, 아키텍처적으로 체계화하는 수단을 갖추게 되었다. 하지만 대규모 엔터프라이즈 시스템 개발 현장에서는 단지 UML 다이어그램과 객체지향 원칙만으로 복잡한 도메인 문제를 완전히 해결하기는 어려웠다. 1990년대 말~2000년대 초, 기업 시스템(Enterprise Application) 환경은 그 규모와 복잡성이 급증하고 있었다. 전자상거래, 온라인 뱅킹, 글로벌 공급망 관리, 대형 ERP와 CRM 솔루션 등은 수많은 비즈니스 규칙, 프로세스, 예외상황을 다루어야 했고, 이들 요구사항은 빈번하게 바뀌었다. 기술 스택 또한 점차 다양해져 데이터베이스, 메인프레임, 분산 객체, 웹 프레임워크, 메시지 큐 등 복합적 인프라를 다루는 일이 일상화되었다. 이러한 환경에서 “도메인 모델링”은 더 이상 단순한 설계 단계 산출물이 아닌, **개발 전 과정에서 유지·진화해야 할 지식의 집합**으로 간주될 필요가 있었다. 도메인 모델이 현장의 비즈니스 로직을 제대로 반영하지 못하면, 시스템은 요구사항 변화에 취약하고 유지보수 비용이 극도로 커지며, stakeholder(이해관계자) 간 의사소통 문제가 심화되었다. ## 3.2 엔터프라이즈 애플리케이션 패턴과 아키텍처 사상가들 이러한 문제의식을 반영하여, 2000년대 초반 몇몇 사상가들은 엔터프라이즈 개발을 체계화하기 위한 패턴과 원칙을 정리하기 시작했다. 그중 대표적인 인물이 **Martin Fowler**이다. Fowler는 2002년 출간한 *Patterns of Enterprise Application Architecture(EAA)* 에서 레이어드 아키텍처, 도메인 모델 패턴, 데이터 매퍼, 트랜잭션 스크립트, 서비스 레이어 등의 개념을 정리했다. 이 패턴들은 엔터프라이즈 애플리케이션 구현의 복잡한 인프라 문제를 해결하는 데 유용했지만, 정작 비즈니스 도메인 자체를 깊이 파고드는 접근에 대해서는 상대적으로 간략한 언급에 그쳤다. > **참고 자료:** > > - Fowler, M. (2002). *Patterns of Enterprise Application Architecture*. Addison-Wesley. Fowler의 패턴 모음집은 인프라와 아키텍처 층위에서 문제를 해결하는 다양한 모범 사례를 제시했지만, “도메인 로직을 어떻게 더 효과적으로 다룰 것인가?”라는 근본적인 질문에는 한 단계 더 진전된 해답이 필요했다. 엔터프라이즈 개발자들은 여전히 기술적 난제뿐만 아니라, 비즈니스 규칙 이해 및 변경 관리에 대한 어려움과 씨름하고 있었다. ## 3.3 Eric Evans와 DDD의 등장 (2003년) 이런 상황에서 **Eric Evans**가 2003년 출간한 _Domain-Driven Design: Tackling Complexity in the Heart of Software_는 도메인 모델링 접근을 전면적으로 재조명했다. Evans는 소프트웨어 개발의 핵심 문제를 “도메인 복잡성”으로 규정하고, 이를 제대로 다루기 위한 전략적·전술적 패턴을 체계적으로 정리했다. DDD(Domain-Driven Design)는 단순히 새로운 방법론이 아니라, 도메인 지식을 탐구하고, 모델을 통해 그 지식을 코드로 구현하며, 도메인 전문가와 개발자가 긴밀히 협력하는 과정 전반을 가리키는 사상이었다. Evans는 이 책에서 “모델-구현-언어”의 긴밀한 연결을 핵심으로 강조했다. 이는 다음과 같은 개념들로 구체화된다. - **Ubiquitous Language (보편 언어)** : 도메인 전문가와 개발자가 공유하는 공통 언어를 확립하고, 이를 코드와 모델명에 반영함으로써 의사소통 단절을 줄이는 전략. - **Bounded Context (경계(Context)의 설정)** : 하나의 대규모 시스템을 비즈니스 하위 도메인 단위로 나누어 각 컨텍스트 별로 독립적이고 일관성 있는 모델을 유지, 관리하는 구조적 개념. - **Aggregate, Entity, Value Object, Domain Service, Domain Event** 등의 전술적 패턴: 도메인 모델을 어떻게 코드 구조로 명료하게 옮길지에 대한 지침. - **Strategic Design**: 도메인 전반을 조망하여 어떤 부분을 심층적으로 모델링할 것인지, 어디에 어떤 경계를 설정하고 팀 간 협력 방식을 어떻게 할지 결정하는 상위 수준 전략. > **참고 자료:** > > - Evans, E. (2003). *Domain-Driven Design: Tackling Complexity in the Heart of Software*. Addison-Wesley. > - Evans, E. (2004). Domain-Driven Design: A Conversation with Eric Evans and Bruce Eckel. Artima Developer Interview. Evans의 접근은 기술적 관점이 아닌 **지식(knowledge) 중심** 접근을 제안했다. 그는 DDD를 “지식 정제(knowledge crunching)” 과정으로 설명하며, 소프트웨어 개발을 단순히 기능 구현에서 벗어나 도메인 이해를 통해 비즈니스 가치를 극대화하는 학습 과정으로 바라보았다. ## 3.4 DDD의 의의: 도메인 중심 사고의 부활 DDD는 기존 객체지향 분석·설계 방법론과 UML이 제안한 모델링 언어를 활용하되, 그 초점을 **도메인 자체의 이해와 모델 정련(Refinement)** 에 맞추었다. 이 접근은 다음과 같은 의의를 지닌다. 1. **도메인 전문가와 개발자의 협력 강화**: 기존 모델링 활동은 종종 개발자 내부 언어로 끝나거나, 문서화된 모델이 현실 요구사항과 괴리되는 문제가 있었다. DDD는 보편 언어를 통해 도메인 전문가가 이해할 수 있는 모델을 만들고, 이 모델을 기반으로 의사소통함으로써 상시적인 요구사항 정제와 지식 공유를 가능하게 했다. 2. **모델-구현 간 불일치 최소화**: UML 다이어그램이나 분석 단계 산출물이 실제 코드와 멀어지는 “모델 부식(Model Decay)” 문제는 자주 발생했다. DDD는 모델 요소를 코드(클래스, 메서드 명), 테스트 명세, 문서에 일관되게 반영하여, 모델과 구현이 동기화되도록 했다. 3. **복잡성의 전략적 관리**: Bounded Context 개념은 대규모 시스템을 한 번에 해결하려는 시도를 지양하고, 각 하위 도메인을 명확히 경계 지어 독립적으로 모델링하고 발전시키는 전략을 제시했다. 이는 추상화 수준을 올리고, 팀 단위로 관리 가능한 규모로 도메인을 나누어 복잡성을 체계적으로 제어하는 기법을 제공했다. ## 3.5 커뮤니티와 실천 사례의 확산 DDD의 사상은 출간 이후 수년 동안 점진적으로 커뮤니티와 실무진 사이에 스며들었다. 초기에는 새로운 개념에 익숙지 않은 개발자와 기업들이 DDD 적용을 주저했으나, 점차 성공 사례들이 나타나기 시작했다. 온라인 포럼, 컨퍼런스(OOPSLA, QCon, DDD Europe 등), Eric Evans와 다른 DDD 선구자들의 워크숍과 세미나를 통해 DDD는 “복잡한 도메인 문제를 다루는 유용한 사상”으로 자리매김했다. 이후 **Vaughn Vernon**이 2013년 출간한 _Implementing Domain-Driven Design_을 통해 DDD 패턴 적용에 대한 구체적 실무 지침을 제시하며, 커뮤니티가 더욱 확장되었다. Alberto Brandolini의 **Event Storming** 기법은 도메인 이벤트를 시각화하는 워크숍 형식으로, 도메인 전문가와 개발자가 짧은 시간 내에 도메인 이해를 공유하는 실천적 방법을 제시했다. > **참고 자료:** > > - Vernon, V. (2013). *Implementing Domain-Driven Design*. Addison-Wesley. > - Brandolini, A. (2013년경 처음 언급한 Event Storming, 이후 책: *Introducing EventStorming*, 2017). ## 3.6 마이크로서비스 아키텍처와 DDD 2010년대 중반 이후, 클라우드와 DevOps 문화의 확산으로 **마이크로서비스 아키텍처**가 부상했다. 마이크로서비스는 대규모 시스템을 작은 서비스 단위로 나누어 개발·배포·운영하는 방식이다. 이때 Bounded Context 개념은 마이크로서비스를 나누는 기준으로 널리 활용되었고, DDD를 통한 도메인 기반 서비스 분할은 마이크로서비스 아키텍처 설계의 모범 사례 중 하나로 자리 잡았다. Event Sourcing, CQRS(Command-Query Responsibility Segregation) 등의 패턴도 DDD에서 강조하는 도메인 모델링 가치관과 결합하여, 분산 환경에서 복잡한 비즈니스 로직을 다루는 새로운 길을 열었다. 이는 DDD가 2000년대 초반 등장 이래로 단절되지 않고, 산업 환경 변화에 맞추어 확장·적응해 왔음을 보여주는 증거다. --- # 4장: 현대 도메인 모델링의 확장과 진화 ## 4.1 서론: 도메인 모델링의 새로운 시대 3장에서 살펴본 것처럼, DDD(Domain-Driven Design)는 엔터프라이즈 애플리케이션 개발의 복잡성을 도메인 지식을 통해 관리하고, 도메인 전문가와 개발자 간 협업을 강화하는 패러다임으로 자리 잡았다. 2000년대 중반부터 DDD는 점진적으로 업계에 침투했으며, 2010년대 이후 기술 환경이 급격히 변화하면서 DDD 사상은 새로운 아키텍처 스타일, 방법론, 도구와 결합하게 된다. 클라우드 컴퓨팅, 컨테이너 오케스트레이션(Kubernetes), DevOps 문화의 정착은 소프트웨어 릴리스 속도를 높이고, 서비스 단위를 더 작게 쪼개는 마이크로서비스 아키텍처를 탄생시켰다. 이 환경에서 DDD의 Bounded Context 개념은 마이크로서비스의 서비스 경계를 설정하는 유용한 가이드라인으로 널리 활용되며, 도메인 모델링은 더 작고 독립적인 단위로 이루어지게 된다. 이러한 흐름 속에서 이벤트 주도 아키텍처, 이벤트 스토밍, BDD, DSL 같은 다양한 접근법들이 도메인 모델링과 만나 **도메인 중심 사고를 더욱 강화**하고 있다. ## 4.2 마이크로서비스 아키텍처와 DDD의 재해석 ### 4.2.1 Bounded Context와 서비스 경계 마이크로서비스 아키텍처는 2010년대 중반 대두되었으며, Amazon, Netflix 등 대규모 인터넷 기업들이 모놀리식(monolithic) 애플리케이션을 작은 서비스 단위로 나누어 독립적으로 배포하는 전략을 통해 민첩성을 확보한 사례가 주목을 받았다. 이때 **DDD의 Bounded Context 개념**은, 도메인 모델을 특정 하위 도메인 경계 내에서 일관성 있게 유지한다는 점에서 마이크로서비스의 서비스 경계 설정에 이상적인 준거점이 되었다. 이로써 도메인 모델링은 단순한 설계 단계 활동을 넘어, 서비스 아키텍처 설계의 핵심 기준으로 떠올랐다. 마이크로서비스는 독립적으로 배포 가능한 작은 단위일 뿐 아니라, 해당 서비스가 책임지는 도메인 로직의 집합이라는 관점에서 접근할 때, 도메인 모델링은 아키텍처 의사결정과 직결되었다. > **참고 자료:** > > - Newman, S. (2015). *Building Microservices*. O’Reilly. > - Vernon, V. (2016). Reactive DDD. (QCon London 발표) > - Wolff, E. (2016). *Microservices: Flexible Software Architecture*. Addison-Wesley. ### 4.2.2 이벤트 드리븐 아키텍처와 도메인 이벤트 마이크로서비스 환경에서 서비스 간 통신은 종종 비동기 메시징과 이벤트 주도(Event-Driven) 방식으로 이뤄진다. DDD에서 말하는 **Domain Event** 개념은 도메인에서 의미 있는 상태 변화를 나타내며, 이를 시스템 경계를 넘어 공유하는 방식이 이벤트 드리븐 아키텍처(EDA)와 자연스럽게 결합되었다. 도메인 이벤트를 중심으로 한 EDA는 시스템 구성 요소들이 느슨하게 결합되어 변화에 유연하게 대응할 수 있는 환경을 제공한다. > **참고 자료:** > > - Fowler, M. (2017). *What do you mean by “Event-Driven”* (martinfowler.com 블로그 포스팅) > - Newman, S. (2019). *Monolith to Microservices*. O’Reilly. ## 4.3 Event Storming: 도메인 모델링 워크숍의 진화 DDD 커뮤니티는 도메인 전문가와 개발자가 짧은 시간 내에 복잡한 도메인을 시각화하고 이해할 수 있는 기법을 고안했다. **Alberto Brandolini**가 제안한 **Event Storming(이벤트 스토밍)** 은 대형 화이트보드와 포스트잇을 활용해 도메인에서 발생하는 이벤트를 시간축에 따라 나열하면서, 도메인 개념, 액터, 명령, 정책 등을 식별하는 워크숍 기법이다. Event Storming의 장점은 다음과 같다. 1. **빠른 지식 공유**: 도메인 전문가와 개발자가 한 공간에 모여 짧은 시간 내에 도메인 전반의 이벤트 흐름을 파악. 2. **비가시적 규칙 노출**: 비즈니스 규칙이나 프로세스 상의 ‘숨겨진’ 제약사항이 이벤트 흐름을 통해 쉽게 드러난다. 3. **Bounded Context 식별 지원**: 이벤트들의 상호연관성을 통해 자연스럽게 도메인 하위 영역을 구분하고 서비스 경계를 설정할 단서를 얻을 수 있다. > **참고 자료:** > > - Brandolini, A. (2017). *Introducing EventStorming: An act of deliberate collective learning*. Leanpub. > - DDD Europe, DDD Meetup 커뮤니티 발표 자료. Event Storming은 DDD 철학—즉, 도메인 모델은 살아있는 지식 집합이라는 관점—을 실제로 구현하는 도구로 널리 쓰이고 있으며, 이를 통해 팀 단위로 도메인 모델을 형성, 개선하는 문화가 확산되었다. ## 4.4 BDD(Behavior-Driven Development)와 도메인 서술 DDD가 도메인 지식을 설계와 코드에 반영하는 전략이라면, BDD(Behavior-Driven Development)는 도메인 요구사항을 행동(Behavior) 중심의 시나리오로 표현하고 이를 실행 가능한 테스트로 전환함으로써, 개발 전 과정에 비즈니스 가치를 부각하는 접근이다. **Dan North**가 2000년대 중반 제안한 BDD는 “User Story”와 “Scenario”를 통해 사용자 관점에서 시스템의 기대 행위를 명세하고, 이를 자연어에 가까운 DSL(Gherkin 언어 등)로 표현한다. 이렇게 정의된 시나리오는 자동화 테스트로 실행 가능하며, 요구사항 변경 시 빠른 피드백을 제공한다. BDD는 DDD와 궁극적으로 목표를 공유한다: 도메인 이해를 개선하고, 모델과 구현을 정렬하는 것이다. DDD 모델이 도메인 개념에 초점을 맞춘다면, BDD는 그 개념이 실질적으로 어떻게 작동해야 하는지(행위) 테스트 가능한 명세로 만든다. > **참고 자료:** > > - North, D. (2006). *Introducing BDD*. Dan North의 블로그 포스팅. > - Wynne, M., & Hellesoy, A. (2012). *The Cucumber Book: Behaviour-Driven Development for Testers and Developers*. Pragmatic Bookshelf. BDD는 도메인 모델링과 테스트 자동화, 그리고 사용자 요구사항 간을 긴밀히 연결함으로써, 도메인 모델링 결과물을 검증 가능하고 실용적인 형태로 발전시킨다. ## 4.5 DSL(Domain-Specific Language)과 도메인 표현력 향상 도메인 모델이 깊어지고 복잡해질수록, 그 도메인을 표현하는 언어와 표현력이 중요해진다. DDD에서 강조한 “Ubiquitous Language” 개념은 일반 프로그래밍 언어의 표현 한계를 넘어, 도메인 개념을 더 자연스럽게 기술할 수 있는 전용 언어, 즉 DSL(Domain-Specific Language)을 활용하는 시도를 촉진했다. **Martin Fowler**는 *Domain-Specific Languages*(2010)에서 DSL을 정의하고, 내부 DSL(Internal DSL)과 외부 DSL(External DSL)을 비롯한 다양한 구현 패턴을 소개했다. DSL을 도입함으로써 도메인 로직을 더욱 명확하고 간결하게 표현하고, 도메인 전문가가 이해할 수 있는 형태로 구현을 발전시킬 수 있다. 이는 도메인 모델을 코드 차원에서 더욱 풍부하게 표현하고, 변경 요구에도 탄력적으로 대응하는 기반을 제공한다. > **참고 자료:** > > - Fowler, M. (2010). *Domain-Specific Languages*. Addison-Wesley. > - Mernik, M., Heering, J., & Sloane, A. (2005). When and how to develop domain-specific languages. *ACM Computing Surveys*, 37(4). ## 4.6 지식 공유와 커뮤니티 발전 DDD와 현대 도메인 모델링 접근법들은 커뮤니티 활동을 통해 급속히 전파되고 개선되었다. DDD Europe, Explore DDD, QCon, O’Reilly Software Architecture, MicroXchg 등의 국제 컨퍼런스, Meetup 그룹, Slack/Discord 커뮤니티 등은 사례 연구, 워크숍, 세미나를 활발히 진행하며, 도메인 모델링 기법과 패턴을 전 세계로 확산했다. 이를 통해 다양한 산업 도메인(금융, 제조, 의료, 전자상거래, 물류 등)에 적용된 성공 사례가 공유되고, 축적된 경험을 통해 기법들이 성숙해가는 선순환이 이어졌다. ## 4.7 미래를 향한 시사점 현대의 도메인 모델링 패러다임은 DDD를 주축으로 마이크로서비스, 이벤트 주도 아키텍처, BDD, DSL 같은 다양한 방법론 및 기술적 흐름과 결합하며, 도메인 중심 사고를 산업 전반에 확산시키고 있다. 이러한 조류는 몇 가지 중요한 시사점을 가진다. 1. **지속적인 도메인 이해의 중요성**: 기술 스택은 끊임없이 변하지만, 도메인 지식 축적과 모델 정련 활동은 변하지 않는 핵심 자산이다. 2. **확장 가능한 협업 모델**: 이벤트 스토밍이나 BDD와 같은 기법은 도메인 전문가, 디자이너, 개발자, 운영자 등 다양한 역할자가 참여하는 협업 모델을 제시한다. 3. **미래 기술과 도메인 모델링의 융합**: AI, 데이터 사이언스, 머신러닝, 블록체인, IoT 등 새롭게 부상하는 기술 영역에서도 도메인 모델링의 원칙(도메인 중심 사고, 모델 정제, 지식 축적)이 유용하게 적용될 수 있으며, 이에 대한 탐색이 계속되고 있다. --- # 5장: 소프트웨어 개발 패러다임 변화의 의미와 미래 전망 ## 5.1 역사적 흐름의 재조명 1장에서 우리는 객체지향 프로그래밍(OOP)의 기원으로 거슬러 올라가, Simula와 Smalltalk를 통해 객체지향 사상이 어떻게 탄생했는지를 살펴보았다. 이 초기 단계에서 객체지향은 단지 프로그래밍 언어 기능이 아닌, **세계를 객체 상호작용으로 바라보는 새로운 사고방식**을 제시했다. 2장에서는 객체지향 개념이 언어 차원을 넘어 **분석·설계 방법론(OOAD)** 으로 발전하는 과정을 추적했다. Booch, Rumbaugh, Jacobson 등 선구자들의 방법론이 UML로 통합되면서, 도메인 모델을 표준화된 언어로 표현하고 공유하는 기반이 마련되었다. 이 과정에서 객체지향은 단순한 코딩 스타일이 아닌, 시스템 설계와 문서화, 커뮤니케이션의 공용 언어로 자리 잡았다. 3장에서는 UML과 객체지향 분석·설계의 확산에도 불구하고 산업 현장에서 여전히 남아있던 “도메인 복잡성” 문제를 해결하기 위해 등장한 Domain-Driven Design(DDD)을 다루었다. DDD는 도메인 지식에 집중하고 모델-언어-구현을 긴밀히 연결함으로써 도메인 모델링의 본질적 가치를 재조명했다. Eric Evans의 철학은 소프트웨어 개발을 **지식 형성(knowledge crunching)의 과정**으로 바라봄으로써, 개발자와 도메인 전문가가 함께 도메인 이해를 심화하는 학습적, 진화적 프로세스를 제안한 것이다. 4장에서는 DDD 이후 시대를 조망하며, 마이크로서비스, 이벤트 주도 아키텍처(EDA), Event Storming, BDD, DSL 등 현대적 기법들이 DDD 사상과 결합하는 과정을 조명했다. 이로써 도메인 모델링은 대규모 분산 환경, 빠른 릴리스 주기, 다양한 이해관계자 간 협업, 자동화 테스트, 도메인 특화 언어 등과 결합하여 **더욱 실용적이고 생태계화된 패러다임**으로 발전하고 있음을 확인했다. ## 5.2 변화된 소프트웨어 개발 문화 이 일련의 역사는 소프트웨어 개발 문화를 어떻게 바꾸었을까? 1. **개발자 중심에서 도메인 중심으로**: 초기 소프트웨어 개발은 주로 개발자 기술 스택, 프로그래밍 언어 특징, 알고리즘 및 자료구조 중심의 사고방식이었다. 그러나 OOP, UML, DDD를 거치면서 개발 과정은 비즈니스 문제, 도메인 전문가 지식, 모델링 활동에 대한 강조로 옮겨갔다. 기술적 해결책보다 “무엇을 해결하고자 하는가”에 초점을 맞추게 된 것이다. 2. **수직적 지식전달에서 협력적 지식공유로**: 과거에는 요구사항 분석가, 설계자, 개발자가 수직적으로 이어지는 흐름에서 지식을 전달했다. 그러나 DDD, Event Storming, BDD 등을 통해 실무자, 도메인 전문가, 테스트 엔지니어, 운영자 등 다양한 역할자가 한자리에 모여 **공동으로 도메인 지식을 탐구**하고, 모델을 발전시키는 협력 문화가 형성되었다. 이는 팀 조직 구조와 커뮤니케이션 방식을 크게 변화시켰다. 3. **문서에서 실행 가능한 모델로**: 예전에는 분석·설계 문서는 구현 시점에서 점차 쓸모를 잃어가는 경향이 있었다. 그러나 BDD 시나리오, DSL, Event Storming의 결과물, 코드에 반영된 DDD 모델 등은 **실행 가능하고 유지 가능한 모델**로 구현에 긴밀하게 결합되고, 지속적인 검증과 진화를 거치며 실제 개발 흐름에 참여한다. 모델은 정적인 문서가 아니라, 코드와 테스트, 서비스 경계, 워크숍 활동 등으로 살아 움직이는 실체가 되었다. ## 5.3 비즈니스 가치 극대화와 요구사항 변화 대응 도메인 모델링의 진화는 궁극적으로 소프트웨어가 비즈니스 가치를 극대화하는 데 중요한 역할을 한다. - **지속적인 요구사항 변화 대응**: 비즈니스 환경은 늘 변화한다. 새 규제, 시장 트렌드, 경쟁우위 전략에 따라 도메인 규칙이 달라진다. 도메인 모델링 패러다임을 정립한 조직은 이러한 변화에 탄력적으로 대응할 수 있다. 모델-코드-테스트-서비스 구조의 일관된 관리 덕분에 새로운 요구사항을 신속히 반영하고, 시스템 전체가 무너지지 않는 안정성을 확보한다. - **지식 축적을 통한 장기적 경쟁력 강화**: 도메인 지식은 시간과 함께 축적되는 자산이다. DDD와 현대 모델링 접근법을 도입한 팀은 매 릴리스마다 모델을 개선하고, Event Storming 세션마다 새로운 인사이트를 얻으며, BDD 시나리오를 통해 요구사항을 명세화·자동화하는 과정에서 도메인 지식을 체계적으로 쌓는다. 이러한 축적된 지식은 향후 신기술 도입이나 서비스 확장 시에도 강력한 기반이 된다. ## 5.4 새로운 기술 시대와 도메인 모델링 앞으로 다가올 시대에도 도메인 모델링 철학은 변함없이 유효할까? 인공지능, 머신러닝, 데이터 사이언스, 클라우드 네이티브 기술, IoT, 블록체인 등 새로운 패러다임이 계속해서 등장하고 있다. 이들은 각기 독특한 기술적 특성과 요구사항을 갖고 있지만, 결국 “도메인에 맞춰 기술을 적용”하는 기본 원리는 변하지 않는다. DDD와 도메인 모델링 철학은 “복잡성을 인간적이고 이해 가능한 수준으로 관리”하고 “기술보다 문제 자체에 집중”하는 자세를 강조한다. 이는 미래 기술 트렌드에도 여전히 유효한 원칙이다. 예를 들어, 머신러닝 모델을 비즈니스 도메인 맥락에서 이해하고, 모델 출력 결과를 도메인 논리에 일관되게 통합하며, 변경되는 비즈니스 룰에 맞게 AI 모델을 재학습하는 과정도 결국 도메인 모델링 원칙을 필요로 할 것이다. ## 5.5 결론: 도메인 중심 사고의 지속성 이 글이 다룬 객체지향→도메인 모델링→DDD→현대 도메인 모델링에 이르는 흐름은 단순한 기술 발전사가 아니다. 이는 **소프트웨어 개발의 철학적 전환**이며, 인간과 비즈니스 가치를 중심에 두는 문화적 변화다. 도메인 모델링의 역사는 “어떻게 하면 소프트웨어가 현실의 복잡한 문제를 더 충실히 담아내고, 변화와 성장에 적응하며, 사람들과 지식의 흐름을 증진시킬 수 있는가?”라는 질문에 대한 끝없는 모색의 과정이었다. 이 장을 마치며, 우리는 다음과 같이 요약할 수 있다. - 객체지향 사상은 세상을 객체 상호작용으로 바라보는 추상화 철학에서 출발했다. - OOAD와 UML로 대표되는 방법론적 발전은 도메인 모델링을 구조화하고 표준화했다. - DDD는 도메인 중심 사고를 통해 모델·언어·코드의 일체화를 제안하며, 지식 형성 과정으로서 소프트웨어 개발을 재해석했다. - 현대 도메인 모델링 기법은 DDD 철학을 바탕으로 마이크로서비스, EDA, Event Storming, BDD, DSL 등으로 확장·응용되어, 협업과 적응성을 극대화하고 있다. - 이러한 변화는 기술뿐 아니라 소프트웨어 개발 문화, 비즈니스 가치 창출 방식, 협업 생태계 전반에 영향을 미치며, 미래에도 유효할 전망이다. 궁극적으로 이 역사는 “기술을 넘어, 문제 해결에 초점을 둔 도메인 중심 접근”이 어떻게 소프트웨어 산업을 진화시켜 왔는지 보여주는 하나의 긴 흐름이다. 이 글이 독자들에게 그 흐름을 명확히 이해하고, 미래의 도메인 모델링과 소프트웨어 개발 방향성을 모색하는 데 도움이 되길 바라며 글을 마친다.]]> https://hyukjin-lee.github.io/tech/2024/12/객체지향과-도메인-모델링-소프트웨어-설계-사상의-역사적-흐름-1 https://hyukjin-lee.github.io/tech/2024/12/객체지향과-도메인-모델링-소프트웨어-설계-사상의-역사적-흐름-1 Thu, 12 Dec 2024 00:00:00 GMT https://hyukjin-lee.github.io/daily/2023/09/codeopinion https://hyukjin-lee.github.io/daily/2023/09/codeopinion Fri, 15 Sep 2023 00:00:00 GMT