과거에는 구현 능력 자체가 가장 큰 병목이었다. 이제는 구현 일부를 모델이 대신할 수 있다. 대신 다른 병목이 더 크게 드러난다. 무엇을 맡기고, 어떤 맥락을 주고, 어떤 제약을 걸고, 어디까지를 모델의 자율성으로 둘지를 설계하는 문제가 훨씬 중요해졌다. 즉 Agentic AI는 개발을 쉽게 만든 것이 아니라, 개발자의 통제 지점을 바꿨다. 구현 난이도의 일부는 낮아졌지만, 지시 난이도와 운영 난이도는 오히려 더 높아졌다고 보는 편이 정확하다.

이 변화의 핵심에는 제한된 컨텍스트 윈도우가 있다. 모델은 아무리 똑똑해 보여도 주어진 맥락 안에서만 판단한다. 필요한 정보가 빠져 있으면 자신감 있게 틀리고, 불필요한 정보가 많으면 중요한 제약을 놓친다. 결국 정확한 답변과 안정적인 결과를 얻으려면 컨텍스트의 품질과 토큰 제어가 결정적이다. 어떤 정보를 앞에 두고, 무엇을 생략하고, 어떤 순서로 배치할지에 따라 결과의 수준이 크게 달라진다. Agentic AI를 잘 쓴다는 것은 좋은 질문을 하는 것만이 아니라, 좋은 실행 문맥을 설계하는 일에 가깝다.

그래서 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링이라는 말이 자연스럽게 등장했다. skills, MCP, agent 구성에 대한 공유가 활발한 것도 같은 맥락이다. 어떤 도구를 연결할지, 어떤 역할 분리를 할지, 어떤 제약을 시스템적으로 강제할지에 대한 논의는 점점 더 실무적이 되고 있다. 이 흐름은 필요하다. 하지만 나는 여기서 한 걸음 더 들어가야 한다고 생각한다. 결국 전역 환경과 현재 프로젝트를 함께 설명하는 AGENTS.md 같은 문서가 운영의 중심에 놓여야 한다.

왜 하필 AGENTS.md일까. 단순한 프롬프트 한 덩어리나 README만으로는 부족하기 때문이다. 모델은 매번 프로젝트의 우선순위, 금지사항, 작업 습관, 도구 사용 원칙을 새로 추측하려 든다. 그 추측은 자주 틀린다. AGENTS.md는 이런 추측 비용을 줄이는 장치다. 전역적인 작업 원칙과 프로젝트 특화 규칙이 만나는 지점이며, 반복적으로 설명해야 할 실행 규약을 축적하는 인터페이스다. 다시 말해 사람의 습관, 프로젝트의 제약, 모델의 한계를 함께 문서화하는 운영 계층에 가깝다.

중요한 점은 이 문서를 한 번 잘 써두는 것으로 끝낼 수 없다는 것이다. AGENTS.md는 정적인 안내문이 아니라 계속 수정해야 하는 운영 코드다. 프로젝트가 바뀌면 필요한 맥락이 바뀌고, 모델이 바뀌면 반응 방식이 달라지고, 사용자의 습관이 바뀌면 지시 체계도 달라진다. 처음에는 잘 먹히던 규칙이 어느 순간부터는 오히려 성능을 떨어뜨릴 수도 있다. 그래서 강한 규칙을 많이 적는 것만으로는 충분하지 않다. 규칙은 필요하지만, 완성본이 아니라 관찰 결과에 따라 계속 보정해야 하는 초안에 가깝다.

여기서 놓치기 쉬운 점이 하나 더 있다. AGENTS.md는 모델을 위한 문서이면서 동시에 사용자를 교정하는 문서이기도 하다. 사람도 늘 같은 방식으로 지시하지 못한다. 어떤 날은 세밀하게 설명하고, 어떤 날은 생략하고, 어떤 날은 본인이 중요하게 생각하는 제약조차 빠뜨린다. 결국 문제가 반복되면 모델만 탓할 일이 아니라, 사용자의 작업 습관과 지시 방식도 함께 표준화해야 한다. 그런 점에서 AGENTS.md는 모델을 통제하는 장치이면서, 사용자 자신을 통제하는 장치이기도 하다.

그래서 나는 AGENTS.md를 설정 파일처럼 보지 않는다. 오히려 머신마다, 환경마다, 사용자마다 다르게 컴파일해야 하는 소스코드에 가깝다고 생각한다. 같은 철학을 담고 있어도 어떤 모델을 쓰는지, 어떤 IDE와 도구 체인을 붙였는지, 어떤 프로젝트 구조를 갖고 있는지에 따라 최적의 형태는 달라진다. 그래서 다른 사람이 잘 써둔 AGENTS.md를 그대로 복붙하는 방식은 오래가지 못한다. 중요한 것은 좋은 문서를 가져오는 일이 아니라, 지금 내 환경에서 잘 작동하도록 계속 컴파일하고 다시 빌드하는 일이다.

Agentic AI 시대의 생산성은 모델의 지능만으로 결정되지 않는다. 더 정확히는, 모델이 일할 문맥을 얼마나 잘 설계하고 유지하느냐에 더 크게 좌우된다. 그 문맥 설계의 중심에는 결국 계속 손봐야 하는 AGENTS.md가 있다. 문서처럼 보이지만 실제로는 운영 코드에 더 가깝다. 그리고 운영 코드는 언제나, 현실에 맞게 계속 수정되어야 한다.

하지만 나는 이 변화를 조금 다르게 본다. 개발자의 역할이 사라진다기보다, 개발자가 책임져야 할 영역이 이동하고 있다고 느낀다. 단순 코드를 작성하는 사람에서 아키텍처를 설계하고, 여러 도구와 시스템을 연결하고, AI가 낸 결과를 검토하고 조율하는 사람으로 무게 중심이 옮겨간다는 해석은 이미 많이 나온다. 그리고 그 방향 자체는 충분히 예상 가능한 이야기다.

내가 더 중요하게 보는 것은 그 다음에 생기는 역할이다. 앞으로 개발자는 단지 AI를 잘 쓰는 사람에 머무르지 않고, 팀 안에서 AI 수용성의 격차를 줄이는 사람의 역할까지 맡게 될 가능성이 크다고 생각한다. 특히 신입 개발자와 기존 개발자 사이에서 이 차이는 생각보다 크게 드러날 수 있다.

기존 개발자들은 대개 레거시 시스템, 오래된 기술 스택, 운영 환경, 협업 방식, 장애 대응 경험을 어느 정도 몸으로 알고 있다. 이런 경험은 단지 옛 기술을 안다는 의미에 그치지 않는다. 무엇이 중요한 맥락인지, 어떤 정보가 빠지면 AI가 엉뚱한 결과를 내는지, 어디까지 자동화에 맡기고 어디서부터 사람이 개입해야 하는지를 판단하게 해준다. 그래서 AI를 사용할 때도 질문을 더 구체적으로 만들고, 결과를 더 비판적으로 읽고, 필요한 제약 조건을 더 잘 붙일 수 있다.

반면 신입 개발자들은 분명 새로운 도구에 대한 거부감은 적을 수 있다. 하지만 그것이 곧 AI를 잘 활용한다는 뜻은 아니라고 본다. 오히려 프롬프팅 자체를 어려워하는 경우도 충분히 생길 수 있다. 무엇을 요청해야 하는지, 어떤 전제를 알려줘야 하는지, AI가 내놓은 답변에서 무엇을 의심해야 하는지에 대한 기준이 아직 없기 때문이다. 표면적으로는 AI를 더 자연스럽게 받아들일 것 같지만, 실제 업무 문맥 안에서는 필요한 질문을 만드는 능력이 부족할 수 있다.

나는 여기서 앞으로 숙련된 개발자의 새로운 역할이 생긴다고 본다. 단지 시스템 구조를 잡는 사람, 코드 품질을 검토하는 사람을 넘어서서, 팀이 AI를 제대로 쓰도록 학습시키는 사람 말이다. 어떤 문제를 AI에 맡길 수 있는지, 어떤 정보까지 제공해야 의미 있는 답을 얻을 수 있는지, AI의 결과를 어떻게 검증해야 하는지, 그리고 결국 사람의 판단은 어디에 남겨야 하는지를 팀 안에서 설명하고 정리해 주는 역할이다.

이 역할은 생각보다 중요해질 가능성이 크다. AI 도구는 같은 팀 안에서도 누군가에게는 강력한 생산성 도구가 되지만, 다른 누군가에게는 그럴듯한 답을 뱉어내는 불안정한 도구에 머무를 수 있다. 그 차이는 단순히 도구 사용 여부가 아니라, 질문의 수준과 검증의 수준에서 갈린다. 결국 생산성 격차는 개인의 타이핑 속도보다, 누가 더 좋은 맥락을 제공하고 더 나은 판단을 할 수 있느냐에서 벌어질 가능성이 높다.

그래서 나는 AI 시대의 개발자를 이야기할 때, 단순 코더에서 아키텍트나 오케스트레이터로 바뀐다는 설명만으로는 조금 부족하다고 느낀다. 물론 그 변화도 맞다. 하지만 실제 현장에서는 그에 더해 사람 사이의 기술 이해도 차이, AI 활용 방식의 차이, 프롬프팅과 검증 능력의 차이를 메우는 역할이 점점 더 중요해질 것이다.

결국 앞으로의 개발자는 코드만 만드는 사람이 아니라, 맥락을 다루는 사람이 될 가능성이 크다. 시스템의 맥락, 업무의 맥락, 그리고 사람의 학습 맥락까지 함께 이해해야 한다. AI가 발전할수록 오히려 더 중요해지는 것은 질문의 질과 판단의 질일 수 있다. 그렇다면 개발자의 새로운 영역은 기계와 경쟁하는 자리가 아니라, 사람과 도구 사이의 간극을 줄이고 더 나은 협업 방식을 만드는 자리일지도 모른다.

나는 한국에서 반도체 산업에 몸담고 있다. 오래 한 자리에만 머물러 온 것은 아니지만, 결국 내가 계속 붙들고 있는 것은 일이 움직이는 방식과 사람이 배우는 방식이다. 기술이 현장에서 어떻게 작동하는지, 복잡한 일은 어떤 구조로 굴러가는지, 사람은 어떻게 배우고 판단하고 협업하는지에 오래 관심을 가져왔다.

나는 한 가지 정체성으로만 설명되는 사람은 아니다. 반도체 산업에서 일하지만 소프트웨어 도구를 좋아하고, 새로운 기술을 익히는 과정에서 자주 살아 있음을 느낀다. 글로 생각을 정리하고, 구조를 나누어 보고, 도구를 손에 익을 때까지 써보는 일을 좋아한다. 생산성과 학습 시스템을 스스로 설계하는 일에도 자연스럽게 끌린다. 특히 AI를 비롯한 새로운 도구가 개인의 사고 방식과 업무 흐름을 어떻게 바꾸는지 오래 들여다보고 있다.

반도체 산업은 빠르게 움직이지만, 동시에 아주 느린 책임을 요구하는 세계이기도 하다. 작은 판단 하나가 긴 시간 뒤에 더 큰 결과로 돌아오기도 하고, 눈에 잘 보이지 않는 변수들이 실제 현장을 좌우하기도 한다. 나는 그런 환경 안에서 일하면서, 결국 중요한 것은 표면적인 속도보다 구조를 이해하는 힘과 끝까지 버티는 사고력이라는 점을 자주 배운다.

내가 중요하게 생각하는 것은 거창한 구호가 아니라 실제로 도움이 되는 방식이다. 더 잘 이해하는 법, 더 잘 정리하는 법, 더 나은 질문을 만드는 법, 그리고 결국 더 나은 결정을 내리는 법에 관심이 있다. 그래서 나는 이론 자체보다 이론이 현실의 일과 맞닿는 지점을 더 중요하게 본다. 머리로만 그럴듯한 설명보다, 실제 삶과 일 속에서 버티는 생각을 더 신뢰한다.

지금 내가 가진 기술은 아주 화려한 종류의 것은 아닐지 몰라도, 일과 학습을 이어주는 데에는 충분히 실용적이다. 글을 쓰며 생각을 구조화하는 일, 디지털 도구를 조합해 작업 흐름을 정리하는 일, 새로운 기술을 빠르게 익혀 내 일에 맞게 바꾸어 쓰는 일에 비교적 익숙하다. 복잡한 내용을 한 번 더 이해하기 쉬운 언어로 바꾸는 과정도 좋아한다.

반대로 앞으로 더 깊게 배우고 싶은 것도 분명하다. AI를 더 실질적인 업무 도구로 연결하는 방법, 소프트웨어와 자동화를 더 능숙하게 다루는 방법, 그리고 기술을 단순한 정보가 아니라 실제 판단과 실행으로 바꾸는 방법을 계속 배우고 싶다. 나에게 학습은 부족함의 증거라기보다, 아직 더 넓어질 수 있다는 감각에 가깝다.

이 블로그는 그런 관심사를 쌓아두는 장소다. 어떤 글은 반도체 산업에 대한 관찰일 것이고, 어떤 글은 기술 도구에 대한 메모일 것이다. 또 어떤 글은 일하면서 배운 점, 글을 쓰며 겨우 붙잡아낸 생각, AI를 실무에 적용하며 얻은 감각에 대한 기록이 될 것이다.

나는 완성된 답을 가진 사람이라기보다 계속 배우고 정리하는 사람에 가깝다. 그래서 이곳의 글도 선언문보다는 작업 노트에 가까울 것이다. 확신보다는 탐구에, 과장보다는 정확함에, 화려함보다는 유용함에 더 가까운 글을 남기고 싶다. 쉽게 소비되고 금방 잊히는 말보다, 늦게 읽혀도 오래 남는 문장을 쓰고 싶다.

앞으로 이 블로그에는 내가 일하며 부딪히는 문제, 배우는 기술, 오래 붙들고 싶은 생각을 차근차근 쌓아갈 것이다. 이 글은 그 출발점으로 남겨둔다.

표면적으로 보면 해야 할 일은 단순하다. PyTorch나 TensorFlow를 설치하고, GPU나 가속기를 잡고, 학습이 잘 도는지만 확인하면 된다. 하지만 실제로는 그렇게 단순하지 않다. 어떤 환경에서는 CUDA 버전을 먼저 맞춰야 하고, 어떤 환경에서는 드라이버와 라이브러리 조합이 중요하고, 또 어떤 환경에서는 Metal 지원 범위와 동작 방식부터 다시 확인해야 한다. 코드 자체보다 환경 조건을 먼저 읽게 되는 순간이 생각보다 많다.

이런 차이는 처음에는 그저 번거로운 정도로 느껴진다. 하지만 시간이 지날수록 더 큰 문제는 설정의 복잡함보다 맥락이 자꾸 끊긴다는 데 있다는 생각이 든다. 회사에서는 CUDA 환경을 전제로 버전과 의존성을 맞추는 데 익숙해져 있는데, 집에 와서는 Mac과 Metal에 맞는 방식으로 다시 생각해야 한다. 같은 모델을 돌리는 일인데도 머릿속에서 준비해야 하는 전제가 달라진다. 작업이 이어지는 것이 아니라, 매번 다시 시작되는 느낌에 가깝다.

PyTorch와 TensorFlow 모두 이런 문제를 완전히 없애주지는 못한다. 둘 다 강력한 프레임워크이지만, 실제 사용 경험은 운영체제와 하드웨어에 크게 좌우된다. Windows나 Linux에서는 비교적 익숙한 방식으로 환경을 잡을 수 있어도, Mac에서는 지원 방식이 다르고 최적화 포인트도 다르다. 어떤 기능은 자연스럽게 돌아가고, 어떤 기능은 생각보다 제한적이거나 우회가 필요하다. 그러다 보면 프레임워크를 배우는 일과, 프레임워크가 각 환경에서 어떻게 다르게 동작하는지를 배우는 일이 동시에 생긴다.

나는 여기서 적지 않은 피로를 느낀다. 배우는 일 자체는 원래 피곤하다. 하지만 그 피로는 보통 앞으로 나아가는 감각과 함께 온다. 반면 환경 차이에서 오는 피로는 종종 제자리걸음처럼 느껴진다. 어제는 분명히 되었던 것이 오늘은 다른 머신에서 안 되고, 분명히 같은 코드를 돌리는데도 설치 방식과 설정 방식이 달라진다. 이런 차이는 기술적으로 이해할 수 있어도, 실제 체감은 “왜 이걸 또 배워야 하지”에 가깝다.

특히 개인적으로 아쉬운 점은, 이 과정이 학습의 본질과는 조금 비껴나 있다는 것이다. 내가 더 잘 배우고 싶은 것은 모델의 구조, 데이터의 의미, 실험 설계, 결과 해석 같은 것들이다. 그런데 실제 시간은 종종 패키지 충돌, 가속기 인식 여부, 백엔드 설정, 버전 호환성 같은 문제에 먼저 쓰인다. 물론 이런 것도 실무에서는 중요한 능력이다. 하지만 중요하다는 것과, 반복적으로 소모된다는 것은 다른 문제다.

그래서 요즘은 환경을 완벽히 통일하려 하기보다, 차이를 인정한 채 관리 가능한 수준으로 줄이는 쪽이 더 현실적이라고 느낀다. 회사에서는 회사 환경에 맞는 재현 가능한 CUDA 중심 설정을 분명히 두고, 집에서는 Mac과 Metal에 맞는 별도 경량 환경을 두는 방식이 오히려 낫다. 모든 곳에서 완전히 같은 경험을 만들려는 시도는 이상적으로 보이지만, 실제로는 그 통일 비용이 더 클 때가 많다.

결국 이 문제는 기술의 문제가 아니라 작업 방식의 문제이기도 하다. 내가 정말 줄이고 싶은 것은 설치 명령어 몇 줄이 아니라, 환경이 바뀔 때마다 사고의 흐름까지 같이 끊기는 경험이다. AI를 배우는 일이 환경을 맞추는 일보다 앞에 있어야 하는데, 현실에서는 종종 그 순서가 뒤집힌다.

아마 앞으로도 Windows, Linux, Mac을 모두 오가며 일하게 될 가능성이 크다. 그렇다면 중요한 것은 어느 하나의 정답을 찾는 것이 아니라, 환경 차이를 덜 고통스럽게 다루는 나만의 기준을 만드는 일일 것이다. 같은 목표를 향해 가고 있다는 감각만 유지할 수 있다면, 적어도 불필요한 소모를 조금은 줄일 수 있다고 믿는다.

내가 Streamlit에서 가장 좋게 본 점은 진입 장벽이 낮다는 것이다. 파이썬을 쓰는 사람이라면 복잡한 프론트엔드 지식 없이도 금방 화면을 만들 수 있다. 데이터프레임을 보여주고, 입력창을 만들고, 버튼을 달고, 결과를 다시 출력하는 흐름이 매우 직관적이다. 무엇보다 아이디어를 떠올린 뒤 실제로 동작하는 형태로 옮겨가는 시간이 짧다. 이 점은 생각보다 중요하다. 어떤 도구는 구현에 들어가기 전부터 구조와 설정에 너무 많은 에너지를 요구하는데, Streamlit은 일단 만들어보게 한다.

이 장점은 특히 개인 프로젝트나 내부용 도구에서 크게 드러난다. 분석 결과를 빠르게 공유해야 하거나, 작은 실험용 인터페이스가 필요하거나, 누군가에게 개념을 보여주기 위한 프로토타입이 필요한 경우 Streamlit은 매우 강력하다. 완성도 높은 제품이 아니어도 괜찮은 상황에서는 생산성이 압도적으로 높다. 한 사람이 짧은 시간 안에 눈에 보이는 결과를 만들 수 있다는 점은 분명한 장점이다.

또 하나 좋았던 점은 파이썬 생태계와의 연결이 자연스럽다는 것이다. 데이터 처리, 시각화, 간단한 모델 추론, 파일 입출력 같은 작업을 같은 언어 안에서 매끄럽게 이어갈 수 있다. 별도의 계층을 많이 나누지 않아도 되기 때문에, 코드를 읽고 수정하는 흐름도 비교적 단순하다. 데이터 중심의 작업을 하는 사람에게는 이 단순함 자체가 큰 힘이 된다.

하지만 Streamlit을 오래 쓰다 보면 분명한 한계도 보인다. 가장 먼저 느끼는 것은 화면과 상태를 정교하게 다루는 데 제약이 있다는 점이다. 작은 도구를 만들 때는 단순함이 장점이지만, 화면이 복잡해지고 사용자 흐름이 길어질수록 그 단순함이 오히려 답답함으로 바뀌기도 한다. 세밀한 상호작용, 복잡한 권한 처리, 정교한 UI 설계가 필요한 순간이 오면 Streamlit은 다소 거칠게 느껴진다.

구조를 잘 잡지 않으면 코드가 빠르게 비대해지는 점도 아쉽다. 처음에는 한 파일에 술술 써 내려가도 괜찮지만, 기능이 조금만 늘어나도 상태 관리와 로직 분리가 생각보다 까다로워진다. 앱이 커질수록 “빠르게 만든 코드”의 대가를 나중에 치르게 되는 경우가 많다. Streamlit의 문제라기보다, 빠른 개발 도구가 대체로 갖는 숙명에 가깝다.

배포와 운영 측면에서도 생각할 점이 있다. 작은 서비스나 데모에는 잘 맞지만, 사용자가 많아지고 안정성 요구가 커지는 순간부터는 고민이 깊어진다. 성능, 인증, 장기 운영, 복잡한 협업 구조까지 고려해야 한다면 Streamlit만으로는 부족하다고 느끼게 된다. 결국 이 도구는 “무엇이든 가능한 웹 프레임워크”라기보다, 특정한 종류의 문제를 아주 빠르게 풀어주는 도구에 가깝다.

그래도 나는 Streamlit을 좋게 본다. 이유는 간단하다. 이 도구는 생각을 너무 늦기 전에 구현하게 만든다. 머릿속에만 있던 아이디어를 실제 화면으로 끌어내고, 손으로 만져보게 하고, 빠르게 검증하게 만든다. 완벽한 구조를 약속하지는 않지만, 시작할 수 있게 해준다는 점에서 충분히 가치가 있다.

결국 Streamlit의 장점과 단점은 같은 뿌리에서 나온다. 단순해서 빠르고, 빠르기 때문에 멀리 가기 전에 구조적 한계가 드러난다. 그래서 내게 Streamlit은 “처음부터 끝까지 책임지는 도구”라기보다, 생각을 현실로 꺼내는 첫 번째 작업대에 가깝다. 그 역할만으로도 이 프레임워크는 충분히 의미가 있다.