AI가 아키텍처까지 설계하면 개발자는 무엇을 해야 할까

문화 충격 같던 AI 코딩을 처음 접한 뒤, 나는 이를 조금씩 실무에 적용하기 시작했다. 테크 회사에서 하는 엔지니어링 업무에서 처음부터 시스템을 새롭게 구축하는 경우는 별로 없다. 대개는 사내에 이미 존재하는 시스템을 분석하고, 확장, 리팩토링, 유지보수 하는 일 등이다. 따라서 규모가 큰 덩치 큰 시스템을 이해하거나, 기존 시스템을 이해하거나 기능을 수정할 때 AI를 활용했다.

AI를 활용해 코드베이스의 구조를 파악하고 요약한 개요를 읽으며 시스템의 대략적인 구조를 파악하곤 했다. 이와 함께 이미 축적한 도메인 지식을 적절히 활용하여 시스템을 빠르게 이해했다. 필요하면 AI에게 추가 질문을 던지며, 관심 영역으로 좁혀 들어갔다. 새로운 기능을 추가할 때면, 필요한 블록을 찾아 어떻게 고쳐야 할지 대략적인 구조를 머릿속으로 스케치했다.

그다음에 할 일은 간단했다. 정리된 아이디어를 잘 기술해 AI에 던져주기만 하면 됐다. AI는 나를 위해 미친 듯이 일했다. 코드 작성부터 빌드와 테스트까지 맡았다. 물론 한 번에 일사천리로 되는 것은 아니었다. 중간중간 내게 확인을 구했고, 에러가 발생하면 보고하고 상의했다. 이러한 과정을 반복하며 단계별로 완성품을 만들었다. AI가 짠 코드를 읽고 검수는 했지만, 내가 직접 코드를 작성하는 일은 거의 없었다.

그렇게 몇 번 일을 해보니 내 역할이 점차 바뀌고 있다는 생각이 들었다. 내가 직접 구현하기보다 문제를 정의하고, 구조를 잡고, 결과를 검토하는 시간이 늘어났다.

반도체 설계와 닮은 에이전트 코딩

AI와 실무를 진행하면서, 한편으로 이때까지 내가 해오던 아키텍트 업무와도 묘하게 닮았다는 생각을 했다. 하나의 반도체 완제품을 개발하기 위해선 무수한 단계를 거치게 된다. 그중 앞부분 '설계'에도 몇 가지 세부 단계가 있다. 그리고 각 단계를 전담하는 팀과 엔지니어 직군들이 존재한다.

반도체 설계, 개발, 양산의 플로우

우선 나와 같은 아키텍트들은 요구사항을 분석해, 전체 구조를 잡고, 기능 블록 수준에서 시스템을 설계하게 된다. 그리고 설계된 구조의 청사진과 동작 방식, 원리 등을 자세하게 스펙으로 기술해 구현팀(회로 설계팀)에게 넘겨주게 된다. 구현팀은 전달받은 스펙에 의거해 한 단계 아래에서, 즉 회로 수준에서 시스템(마이크로 아키텍처)을 설계하고 실제로 구현한다. 이후 검증팀의 회로 검증 과정을 거쳐, 공정과 양산 단계로 넘어간다.

반도체 설계와 유사한 에이전트 기반 SW 개발 플로우. 실제 개발에서는 역할의 경계가 이렇게 명확히 나뉘지는 않지만, 설명을 위해 단순화했다.

즉 아키텍트 → 스펙 → 회로 설계 엔지니어 → 구현에 이르는 과정이, 현재 내 화면에 보이는, 나 → 프롬프트/스펙 → AI 에이전트 → 코드의 과정과 상당히 유사해 보였던 것이다. 그렇다면, 'SW 개발 업계에서도 기존의 개발자들은 모두 조금씩 아키텍트가 되어가지 않을까'라고 생각했다. 소프트웨어 아키텍트: 상위 수준에서 요구사항을 분석해 시스템을 적절한 모듈로 나누고, 각 모듈의 역할과 인터페이스를 정의하며, 성능이나 확장성 같은 여러 조건을 고려해 전체 구조를 설계하는 사람 말이다. 이제 그 아래의 구체적인 구현은 AI에게 맡길 수 있게 되었기 때문이다.

그런 의미에서 앞으로의 개발자는 자의 반 타의 반 모두 아키텍트의 길을 걷게 되지 않을까 싶었다. 아니 그래야 한다고 생각한다. 에이전틱 AI 시대에는 사람이 구조를 설계하고, 스펙을 주고, AI가 구현한다. 그러니 개발자는 점점 아키텍트처럼 일해야 한다는 것이다.

개발자의 아키텍트 역할로의 확대

아키텍트의 영역까지 올라오기 시작한 AI

그런데 최근 컴퓨터 아키텍처 연구를 보면 이 구분도 벌써 흐려지고 있다. AI에게 단순히 RTL 구현을 맡기는 수준을 넘어, 아키텍처 자체의 설계 공간을 탐색하게 하는 연구가 등장하고 있다 [1][2]. 인간은 목표와 제약조건, 평가 방법을 주고 AI가 여러 설계안을 만들고 성능을 비교하며 더 나은 구조를 찾아간다. 심지어 연구의 재현을 위해 AI에게 어떤 프롬프트를 주었는지 자체가 연구 방법론의 일부로 제시된다. 즉, 논문에 프롬프트 자체를 게시한 것이다.

Agentic Architect [1] 논문에서 게시한 프롬프트

위 그림은 Agentic Architect라는 논문에 저자가 실은 실제 프롬프트이다. 첫 줄부터 재미있다.

"너는 C++ 프로그래밍 전문가이자 참신한 캐시 교체 정바카라을 발명하는데 특화된 컴퓨터 아키텍트야"

이후 목표 정의, 타깃 시스템을 명시, 기존 방법들을 열거한뒤, 마지막에 할 일을 명확히 지시해 준다. 지시문도 재미있다.

"기존 방식을 그냥 베끼지 말고, 새로운 정바카라을 합성하라!"

흥미로운 것은 AI가 코드를 작성했다는 사실이 아니었다. 논문의 저자는 AI에게 목표와 시스템 조건, 기존 설계 방법, 평가 기준을 제공하고 새로운 캐시 교체 정바카라을 설계하라고 요구했다. 프롬프트는 단순한 명령문이라기보다 하나의 설계 요구 사항처럼 보였다. 사실상 시니어 아키텍트가 주니어 아키텍트에게 설계 과제를 던지는 방식과 거의 같았다.

내가 AI에게 구현을 맡기며 "앞으로 개발자는 아키텍트가 되어야 한다"라고 생각했던 바로 그 순간, 학계에서는 이미 AI에게 아키텍트의 일을 맡기는 방법을 연구하고 있었던 것이다. 심지어 그 결과도 나쁘지 않았다. AI에게 탐색 시킨 것은 캐시 교체 정바카라(cache replacement), 메모리 선인출(prefetching), 분기 예측(branch predictor)과 같이 전통적인 컴퓨터 아키텍처 설계 문제였다. 기존 설계를 바탕으로 반복적으로 변형하고 시뮬레이션해서 평가했는데, 세 분야 모두 기존의 가장 좋은 설계와 맞먹거나 넘어선 결과를 냈다. 최소한 아키텍처 아이디어를 사람이 만들고 AI는 RTL 구현만 한다의 단계는 이미 넘어설 수 있다는 결론에 도달한 것이다.

물론 아직까지 한계는 있다. 이 논문에서 AI가 설계한 것은 프로세서 전체의 아키텍처가 아니라, 캐시 교체 정바카라이나 선인출, 분기 예측기처럼 비교적 문제와 평가 방법이 잘 정의된 마이크로아키텍처 영역이다. 더구나 AI가 아무것도 없는 상태에서 혼자 문제를 찾아 설계한 것도 아니다. 어디서부터 탐색을 시작할지, 무엇을 좋은 설계로 평가할지, 어떤 워크로드로 검증할지, 어떤 제약조건을 둘지는 여전히 사람이 정했다. 실제로 출발점이 되는 설계가 좋지 않으면 AI도 이를 완전히 극복하지 못했다. 아직까지는 AI가 아키텍트를 대체했다기보다, 사람이 정해놓은 설계 공간 안에서 훨씬 빠르게 후보를 만들고 탐색하는 수준이다.

하지만 오히려 이 점이 더 흥미로웠다. 아키텍트의 역할이 사라지지 않았다고 안심하기에는, 이미 역할의 경계가 한 단계 위로 이동했기 때문이다. 예전에는 아키텍트가 직접 설계안을 만들고 구현팀에 넘겼다면, 이제는 사람이 어떤 문제를 풀 것인지, 무엇을 최적화할 것인지, 어떤 답을 좋은 답으로 볼 것인지를 정하고 AI가 그 아래의 설계 공간을 탐색한다. 다시 말해 사람의 일은 좋은 설계를 직접 만들어내는 것에서, 좋은 설계가 나올 수 있는 문제와 탐색 공간을 정의하는 것으로 조금씩 이동하고 있었던 것이다.

더구나 논문은 여기서 멈추지 않는다. 현재 사람이 정하고 있는 평가 함수나 프롬프트, 워크로드 선택 방식까지 앞으로는 AI가 제안할 수 있다고 전망한다. 그렇다면 인간 아키텍트는 또 한 단계 위에서 그것들이 타당한지를 판단하는 역할로 밀려날 수 있다. 구현을 AI에게 넘기면 아키텍트가 되면 된다고 생각했는데, 정작 AI도 아키텍트의 영역을 따라 올라오기 시작한 셈이다.

소프트웨어에서는 이미 시작되고 있었다

소프트웨어 분야로 돌아와 보자. 이쪽에서는 이미 상용 코딩 에이전트가 개발자의 역할 경계를 흔들고 있다. 클로드 코드, 코덱스 같은 도구는 이제 단순히 지시받은 코드를 작성하는 데 그치지 않는다. 코드베이스를 탐색해 관련 부분을 찾고, 큰 변경에서는 구현 계획을 세우며, 여러 파일에 걸친 수정과 테스트까지 수행한다. 이 과정에서 어떤 파일을 바꾸고 기존 구조를 어떻게 활용할지와 같은 세부 설계와 구현상의 판단도 일정 부분 AI가 맡고 있다 [3-5].

하지만 최신 연구에서는 이미 그다음 단계, 소프트웨어 아키텍처 자체를 AI에게 맡기려는 시도까지 등장하고 있다. 그중 흥미로운 논문의 제목은 아예 <Architecture Without Architects>, '아키텍트 없는 아키텍처'다 [6][7]. 저자들은 코딩 에이전트가 프레임워크를 선택하고, 필요한 인프라를 구성하고, 외부 시스템과의 연결 방식을 정하는 과정에서 이미 수많은 아키텍처 결정을 내리고 있다고 지적한다. 개발자가 일일이 구조를 지정하지 않아도, AI가 구현하는 과정에서 시스템의 구조가 자연스럽게 결정되고 있다는 것이다.

더 재미있는 것은 프롬프트를 어떻게 쓰느냐에 따라 같은 문제에서도 서로 다른 구조의 소프트웨어가 만들어졌다는 점이다. 저자들은 이를 'vibe architecting'이라고 이름 붙였다. 개발자가 명시적인 아키텍처를 먼저 설계하고 구현을 지시하는 것이 아니라, 자연어로 요구사항을 던지고 AI가 구현해 나가는 과정에서 아키텍처가 만들어지는 현상을 말한다.

물론 이것이 한두 편의 실험적인 연구인지 살펴볼 필요가 있다. 2026년 Journal of Systems and Software에 발표된 리뷰 논문은 학술 논문, 산업계의 기술 문서, 보고서를 모아 생성형 AI가 소프트웨어 아키텍처 분야에서 어떻게 활용되고 있는지를 조사했다 [7]. 그 결과 AI는 이미 아키텍처 의사결정 지원, 기존 시스템의 아키텍처 복원, 요구사항으로부터 아키텍처를 만드는 작업, 아키텍처에서 코드로 이어지는 작업 등에 활용되고 있었다. 아직 구현이나 문서 생성에 비해 연구 규모는 작지만, AI의 적용 영역이 코드 아래쪽에만 머물러 있지 않다는 점은 분명했다.

그렇다고 AI가 소프트웨어 아키텍트를 대체했다고 말하기에는 아직 이르다. 같은 리뷰에서도 생성형 AI를 이용한 아키텍처 연구는 여전히 초기 단계이며, 복잡한 시스템 수준의 추론이나 트레이드오프 분석, 성능 모델링을 제대로 다룬 사례는 많지 않다고 지적한다. 무엇보다 AI가 만들어낸 아키텍처를 엄밀하게 평가하는 방법 자체가 아직 충분히 갖춰져 있지 않다 [7].

따라서 지금 벌어지는 일을 '아키텍트의 종말'이라고 부르는 것은 과장이다. 하지만 아키텍처가 사람만의 전유물이라고 단정하기도 어려워졌다. 얼마 전까지 AI가 침범한 영역은 코드 작성이었다. 이제는 세부 설계를 거쳐, 아키텍처를 만들고 판단하는 영역에서도 경계가 움직이기 시작했다.

AI는 코드 자동완성에서 시작해 구현, 세부 설계, 그리고 이제 연구 단계에서는 아키텍처 탐색까지 올라오고 있다. 말하자면 추상화의 사다리를 한 칸씩 오르는 중이다. 그렇다면 "AI가 코딩하면 개발자는 아키텍트가 되면 된다"는 답 역시 잠정적일 수 있다.

아키텍트의 일도 나뉘기 시작했다

내가 해온 아키텍트의 일을 크게 나누면 두 가지다. 하나는 해답을 탐색하는 일이다. 여러 설계 후보를 만들고, 대안을 비교하고, trade-off를 분석하며 더 나은 구조를 찾아간다. 필요하면 benchmark를 반복하고, 결과를 보며 다시 설계를 수정한다. 지금 AI가 빠르게 들어오고 있는 영역이 바로 이쪽이다.

다른 하나는 그보다 앞에 있다. 무엇을 풀어야 할 문제로 정의할지, 어떤 제약과 우선순위를 둘지, 무엇을 좋은 결과라고 판단할지 결정하는 일이다. 기존 시스템의 역사와 고객 요구, 조직의 사정 같은 맥락을 고려하고, 마지막 선택을 내리고 그 결정에 바카라임지는 일도 여기에 포함된다.

둘 다 원래 아키텍트가 해오던 일이다. 다만 AI가 두 번째 단계, 즉 설계안을 만들고 탐색하고 비교하는 업무를 점점 맡기 시작하면서, 인간 아키텍트에게는 문제를 정의하고 제약과 우선순위를 정하며 결과를 판단하는 역할의 비중이 상대적으로 커지고 있다.

그런데 여기까지 생각하고 나니 한 가지가 걸렸다. 그런 판단력은 대체 어디서 생기는가?

여기 또 하나의 역설이 있다

나는 어떻게 아키텍트가 되었을까? 2년 전 '아키텍트의 길'이라는 연재를 쓰면서 나는 이런 문장을 남겼다.

"아키텍트는 길러지는 것이 아니라 쌓이는 것."

되돌아보면 나는 아키텍트가 되기 전에 손에 온갖 더러운 것을 묻혀가며 일을 배웠다. 전산병 때 코딩을 본격적으로 시작해, 대학원 시절 아무것도 없는 상태에서 맨땅에 헤딩하듯 그래픽 가속기 시뮬레이터를 구현했고, 드라이버를 만들고, FPGA를 만지고, 회로 설계를 위해 RTL 코딩을 배웠다. 남이 쓴 스펙을 읽으며 아키텍트 업무를 귀동냥했다. 그렇게 저렇게 업계에서 구르다가 이제 겨우 직접 스펙을 쓰는 사람이 되었다.

가만히 돌아보니, 내가 이제 AI에게 맡기고 있는 일들 중 상당수가 실제로는 나를 아키텍트로 만들어준 일이었다. 직접 코드를 짜고, 구현에 실패하고, 디버깅하고, 남이 만든 시스템을 뜯어보면서 나는 설계가 실제로 어디에서 무너지는지를 배웠다. 무엇이 구현하기 어려운지, 어떤 구조가 성능 문제를 일으키는지, 스펙에 한 줄 잘못 적은 결정이 아래 단계에서 얼마나 큰 비용으로 돌아오는지도 그런 경험 속에서 알게 됐다.

그다음 단계가 있었다. 구현을 어느 정도 알게 된 뒤에는 직접 설계안을 만들고, 여러 방법을 비교하고, 실패한 설계를 버리고 다시 고쳤다. 성능과 비용 사이에서 타협하고, 구현팀과 부딪히며 내가 생각한 구조가 실제 시스템에서 어떻게 작동하는지도 배웠다.

그렇게 아래에서 쌓인 경험들이 조금씩 위의 판단으로 변했다. 무엇을 풀어야 할 문제로 정의할지, 어떤 제약을 우선해야 할지, 수많은 설계안 가운데 무엇을 선택할지. 지금 내가 아키텍트로서 내리는 판단은 어느 날 갑자기 생긴 능력이 아니었다. 구현하고, 설계하고, 실패하고, 다시 고친 경험이 오랜 시간 압축된 결과였다.

그렇다면 앞으로는 어떻게 될까. AI는 가장 먼저 구현의 일부를 가져갔다. 이제는 설계 후보를 만들고 비교하며 최적화하는 일까지 조금씩 맡기 시작했다. 인간에게는 문제를 정의하고, 제약과 우선순위를 정하고, AI가 내놓은 결과를 판별하고, 마지막 결정을 내리는 능력이 더욱 중요해질 것이다.

그런데 바로 여기에서 역설이 생긴다. AI가 대신하기 시작한 아래 단계의 경험들이, 인간에게 앞으로 더 중요해질 위 단계의 판단력을 만들어주던 훈련장이었기 때문이다. 신입 개발자가 처음부터 AI와 함께 일하는 세상은 이미 시작됐다. 코드를 처음부터 끝까지 직접 짜지 않아도 되고, 에러 메시지를 붙들고 몇 시간을 헤매지 않아도 된다. 모르는 코드는 AI가 설명해 주고, 구현 방법뿐 아니라 설계안까지 제안한다. 내가 몇 년에 걸쳐 시행착오로 익혔던 것들을 훨씬 빠르게 건너갈 수 있는 셈이다.

분명 좋은 일이다. 굳이 내가 했던 삽질을 다음 세대까지 똑같이 반복할 필요는 없다. 나부터도 AI가 대신해 줄 수 있는 일을 굳이 손으로 붙들고 있을 생각은 없다. 그런데 그 삽질이 모두 쓸모없는 낭비였던 것도 아니다. 그래서 AI가 없애는 것은 단순한 반복 작업만이 아닐지도 모른다. 그 반복과 실패 속에 숨어 있던 훈련까지 함께 사라질 수 있다.

그런데 AI는 지금 그 사다리의 아래쪽 계단부터 하나씩 건너뛰게 해주고 있다. 문제는 앞으로 사람에게 더 중요해질 일이 바로 그 사다리의 위쪽에 있다는 것이다. 문제를 제대로 정의하고, 수많은 대안의 장단점을 판단하고, AI가 내놓은 답 가운데 하나를 선택하려면 오히려 더 깊은 경험이 필요하다.

그렇다고 신입 개발자에게 AI를 쓰지 말라고 할 수도 없다. 나부터 이렇게 잘 쓰고 있는데, 후배들에게는 직접 코드를 짜며 개고생부터 하라고 말하는 것도 이상하다. 그렇다고 아래 단계를 모두 건너뛴 채 곧바로 좋은 판단을 할 수 있다고 자신 있게 말하기도 어렵다.

그래서 무엇을 배워야 하는가

훈련의 기회가 사라진 주니어 개발자들을 걱정하며 흔히 나오는 조언 중 하나는 "최소한 시스템 하나쯤은 AI의 도움 없이 처음부터 끝까지 직접 만들어보라"는 것이다. 틀린 말은 아니다. 아무것도 없는 상태에서 구조를 잡고, 구현하고, 수없이 실패해 보는 것만큼 시스템을 깊게 이해하게 만드는 방법도 없다. 우리 세대는 모두 그런 경험을 통해 많은 것을 배웠다.

하지만 그것만으로 답이 될 수 있을지는 잘 모르겠다. 학교에서 비교적 자유롭게 시간을 쓸 때라면 몰라도, 실무에서 복잡한 시스템 하나를 학습을 위해 처음부터 끝까지 다시 만드는 것은 현실적으로 쉽지 않다. 더구나 시스템 하나를 직접 만들어봤다고 해서 앞에서 이야기한 판단력이 저절로 생기는 것도 아니다. 내가 돌아보기에 중요한 것은 단순히 얼마나 많은 코드를 손으로 썼느냐보다, 수많은 선택을 직접 해보고 그 선택이 어떤 결과로 돌아왔는지를 반복해서 경험한 일이었다.

그렇다면 AI 시대에는 그런 경험을 어떻게 쌓아야 할까. 솔직히 나도 아직 답을 모른다. 나 역시 이제 막 에이전트와 일하는 방식을 익히고 있는 사람이고, 지금의 주니어들이 몇 년 뒤 어떤 개발자로 성장할지는 아직 누구도 충분히 경험해보지 못했다.

다만 몇 가지 방향은 생각해 볼 수 있을 것 같다. 개발자 개인으로서는 AI를 쓰지 않는 것보다 판단까지 통째로 AI에게 넘기지 않는 것이 중요하지 않을까. AI에게 구현을 맡기더라도, 그전에 자신이 먼저 문제를 정의해 보고 가능한 방법을 생각해 볼 수 있다. AI가 설계안을 제시하면 그대로 받아들이기보다 왜 그런 선택을 했는지 묻고, 다른 방법과 비교해 볼 수도 있다. 에러가 발생했을 때도 곧바로 "고쳐줘"라고 하기 전에 잠시 원인을 추측해 보고, 자신의 가설과 AI의 분석을 비교해 볼 수 있을 것이다.

요즘은 하네스, 루프 엔지니어링처럼 AI와 더 잘 일하기 위한 새로운 방법론이 빠르게 등장하고 있다. 이런 기술을 익히고 따라가는 것도 분명 중요하다. 나 역시 계속 배워야 한다고 생각한다. 하지만 그보다 한 단계 더 오래 남는 능력이 있다면, 어쩌면 무엇을 AI에게 맡기고 무엇은 직접 판단해야 하는지 구분하는 능력 아닐까. 문제를 어떻게 정의할지, 어떤 제약을 둘지, 어떤 결과를 믿을지, 언제 AI의 답을 의심해야 할지를 판단하는 능력 말이다.

조직의 역할도 있을 것이다. 회사가 생산성만을 이유로 주니어에게 돌아가던 구현과 디버깅 업무를 빠르게 AI로 대체한다면, 개인의 의지만으로 경험을 쌓기는 어려워진다. 작은 설계 결정을 직접 맡겨보거나, AI가 만든 결과를 왜 받아들였는지 설명하게 하거나, 디자인 리뷰와 장애 분석에 참여시키는 방식으로 새로운 경험의 경로를 만들어볼 수 있지 않을까.

예전에는 이런 훈련이 일을 하다 보면 자연스럽게 따라왔다. 구현하고, 실패하고, 디버깅하고, 다시 설계하다 보면 어느 순간 조금씩 판단하는 법을 배웠다. AI가 그 과정의 많은 부분을 건너뛰게 해 준다면, 앞으로는 그 안에 숨어 있던 학습의 기회를 조금 더 의식적으로 찾아야 할지도 모른다. 어쩌면 AI 시대에 개발자의 능력은 얼마나 많은 코드를 생산했느냐가 아니라, 얼마나 많이 직접 판단하고 바카라임을 져봤느냐로 평가받을지 모른다.

2년 전 나는 이렇게 썼다.

“아키텍트는 길러지는 것이 아니라 쌓이는 것.”

AI 시대에도 아키텍트는 여전히 무언가를 쌓으며 만들어질 것이다. 다만 지금의 나는 아직 잘 모르겠다. 앞으로 우리는 무엇을 쌓아야 할까.

- 예나빠

* 참고문헌

[1] Blasberg, A., Kypriotis, V., & Skarlatos, D. (2026). Agentic Architect: An agentic AI framework for architecture design exploration and optimization [Preprint]. arXiv.

https://doi.org/10.48550/arXiv.2604.25083

[2] Gupta, R., Jain, A., Gonzalez, A., Novikov, A., Huang, P.-S., Balog, M., Eisenberger, M., Shirobokov, S., Vũ, N., Dixon, M., Nikolić, B., Ranganathan, P., & Karandikar, S. (2026). ArchAgent: Agentic AI-driven computer architecture discovery [Preprint]. arXiv.

https://doi.org/10.48550/arXiv.2602.22425

[3] https://www.anthropic.com/webinars/claude-code-foundations

[4] https://www.anthropic.com/research/claude-code-expertise?src_trk=em67ed76512686f3.435449232057658369

[5] https://openai.com/business/solutions/engineering/

[6] Konrad, P. M., Adam, T. L., Terrenzi, R., & Ayvaz, S. (2026). Architecture without architects: How AI coding agents shape software architecture. In 2026 IEEE 23rd International Conference on Software Architecture Companion (ICSA-C) (pp. 463–468). IEEE.

https://doi.org/10.1109/ICSA-C68850.2026.00087

[7] Esposito, M., Li, X., Moreschini, S., Ahmad, N., Cerny, T., Vaidhyanathan, K., Lenarduzzi, V., & Taibi, D. (2026). Generative AI for software architecture: Applications, challenges, and future directions. Journal of Systems and Software, 231, Article 112607.

https://doi.org/10.1016/j.jss.2025.112607

* 표지 이미지 출처 = unsplash