AI 시대, 컴퓨터공학과 소프트웨어공학적 사고의 가치
조회 1,536 · 공감 1 · 댓글 1
AI가 빠르게 발전하면서 대학에서 컴퓨터공학을 전공하는 것이 무의미하다는 주장을 하는 사람들이 많아지고 있다. 바이브 코딩이니 AI니 하면서, 업무를 잘 아는 실무자가 직접 요구사항을 정의하고 AI를 통해 프로그램을 개발하면 더 이상 개발자가 필요하지 않을 것이라는 주장이다.
나는 어린 시절 빌 게이츠를 보면서 부자가 되고 싶다는 생각에 컴퓨터공학이라는 한 방향만 바라보며 살아왔다. 그렇다고 대학 때 배운 지식 그 자체를 무기로 삼아 지금까지 프로그래밍을 해온 것은 아니다. 하지만 4년간의 학사과정에서 내가 얻은 것은 컴퓨터공학을 직업으로 삼는 것이 나에게 맞는 일인지를 깨닫고, 프로그래밍할 때 어떻게 논리적으로 사고해야 하는지를 배웠다는 점이라고 생각한다.
실제 기술적 지식과 역량은 취업 후 일을 하면서 쌓아왔다. 새로운 문제를 마주할 때마다 소프트웨어 관점에서 문제를 바라보고 해결책을 찾아내는 과정을 반복해 온 것이다.
Gemini와 ChatGPT를 사용해 본 입장에서, 특정 문제를 해결하기 위해 단순히 답을 구하거나 명확하게 정의된 기능을 프로그래밍하는 일은 정보 분석과 추론 능력이 뛰어난 AI가 충분히 해결할 수 있다고 생각한다. 하지만 무엇을, 어떠한 방법으로 해결해야 하는지를 고민하는 소프트웨어공학적 문제는 다르다.
실제 산업 현장에서는 최초에 모든 업무 사례와 처리 조건을 정의하는 것이 불가능하다. 그렇기 때문에 오히려 컴퓨터공학적 관점에서 다양한 아키텍처를 고민하고, 실제로 설계하고 구현해 본 숙련된 전문가들의 역할이 더욱 중요해질 것이라고 생각한다.
여기서 중요한 것은 단순히 현재 정의된 요구사항을 충족하는 프로그램을 만드는 것이 아니다. 앞으로 발생할 수 있는 업무의 변화와 예외 상황, 데이터 증가, 다른 시스템과의 연계 등을 고려하여 어플리케이션이 지속적으로 확장되고 유지될 수 있는 구조를 설계하는 것이다.
물론 AI 역시 이러한 아키텍처를 분석하고 설계하는 데 활용될 수 있을 것이다. 그러나 AI가 다양한 설계 안을 제시할 수 있다는 것과 실제 업무 환경에서 어떤 설계가 적합한지 판단하고, 그 결과에 책임지는 것은 별개의 문제라고 생각한다.
우리나라는 그동안 산업 현장의 인력 수요에 맞춰 국비지원 등 국가 정책을 통해 프로그래밍 인력을 대규모로 양성해 왔다고 생각한다. 그러나 이러한 양적 확대 과정에서 컴퓨터공학적 사고와 소프트웨어 설계 역량의 중요성이 충분히 고려되었는지는 의문이다. 단기간에 많은 기술인력을 양성하기 위해서는 현실적으로 프로그래밍 기술의 습득과 기능 구현에 집중하는 방향으로 교육과정을 운영할 수밖에 없다고 생각한다. 이러한 교육과정에서는 소프트웨어공학적 관점에서 문제를 분석하고 설계하는 방법을 충분히 학습하기 어려울 수 있다.
반면 상당수의 컴퓨터공학 전공자들은 4년이라는 상대적으로 긴 시간 동안 단순한 기능 구현이나 기술적 지식뿐 아니라, 소프트웨어공학적 관점에서 문제를 바라보고 접근하는 방법을 직간접적으로 배울 기회를 제공받는다.
나는 이 부분에서 상당한 차이가 존재한다고 생각한다. 물론 비전공자와 전공자 간에 개별적인 역량의 절대적 차이가 존재한다고 주장하는 것은 아니다. 교육과 경험의 구조적 차이로 인해 소프트웨어를 바라보고 문제에 접근하는 관점이 다르게 형성될 가능성이 높다는 것을 말하고 싶은 것이다. 또한 컴퓨터공학을 전공했다고 해서 누구나 소프트웨어 아키텍처를 설계할 수 있는 것도 아니다. 실제 산업 현장에서 다양한 문제를 경험하고, 그 문제를 해결하기 위한 구조를 고민하고 구현하는 과정을 통해 이러한 역량이 발전한다고 생각한다.
나는 이러한 전문성을 산업 현장에서 어떻게 이해하고 평가해야 하는지에 대해서도 생각해 볼 필요가 있다고 본다.
기업용 어플리케이션의 구축과 운영에 관한 의사결정에서는 기능적 요구사항의 충족 여부, 품질, 일정, 예산 등 다양한 요소를 고려해야 한다. 이러한 요소들은 프로젝트의 성공을 위해 반드시 필요한 판단 기준이다. 다만 여기에 더해 어플리케이션의 아키텍처가 갖는 구조적 품질과 그것이 장기적인 운영에 미치는 영향도 중요한 평가 요소로 다뤄져야 한다고 생각한다. 어플리케이션의 품질은 현재 요구된 기능이 정상적으로 동작하는지뿐 아니라, 향후 발생할 수 있는 변화와 문제에 얼마나 효율적으로 대응할 수 있는지에 따라서도 달라질 수 있기 때문이다.
따라서 중요한 것은 기존의 품질 평가 기준을 부정하는 것이 아니라, 아키텍처가 만들어내는 구조적 품질과 장기적인 경제적 가치까지 함께 이해하고 평가할 수 있는 역량을 발전시키는 것이라고 생각한다. 이는 단순히 의사결정권자들에게만 해당하는 문제가 아니다. 실제 프로젝트에 참여하는 컨설턴트와 개발자들 역시 자신이 담당하는 업무나 기능의 구현에는 능숙하더라도, 어플리케이션 전체의 구조적 품질이나 다른 수행자가 설계한 아키텍처의 가치를 이해하고 평가하는 능력은 서로 다를 수 있다. 같은 프로젝트에 참여하고 동일한 어플리케이션을 사용한다고 해서 그 구조가 갖는 의미와 가치를 모두가 동일하게 이해하는 것은 아니다.
예를 들어 어떤 어플리케이션에서 결함이 발생했을 때, 대부분의 관심은 결함의 원인과 조치 여부, 그리고 언제까지 해결할 수 있는지에 집중된다. 이는 장애를 신속하게 해결하고 업무의 연속성을 확보하기 위해 당연히 필요한 과정이다. 그러나 여기에서 한 걸음 더 나아가, 왜 특정 어플리케이션은 결함의 원인을 빠르게 파악하고 조치할 수 있는지, 왜 새로운 요구사항에 상대적으로 쉽게 대응할 수 있는지, 그러한 결과를 가능하게 하는 구조적 차이가 무엇인지에 대해서도 관심을 가질 필요가 있다고 생각한다.
이는 단순히 개별 설계자나 개발자의 문제 해결 능력만으로 평가할 수 있는 것이 아니다. 어플리케이션이 어떠한 구조로 설계되어 있는지에 따라 결함의 분석과 조치, 새로운 기능의 확장, 반복적인 개발에 필요한 자원이 달라질 수 있기 때문이다. 좋은 아키텍처의 가치는 단순히 프로그램이 정상적으로 작동한다는 사실만으로 드러나지 않는다. 반복적인 개발을 줄이고, 결함을 신속하게 분석하고 조치할 수 있도록 하며, 새로운 요구사항에 대응하는 과정에서 기존 어플리케이션에 미치는 영향을 최소화하는 데 있다.
결국 아키텍처의 가치는 기술적인 완성도뿐 아니라 개발과 운영에 투입되는 자원을 얼마나 효율적으로 활용할 수 있도록 하는가라는 경제적 관점에서도 평가되어야 한다고 생각한다. 그런데 이러한 차이를 이해하고 평가할 수 없다면, 동일한 기능을 구현한 두 어플리케이션의 구조적 품질이 다르더라도 그 차이를 구분하기 어렵다. 또한 그러한 구조를 설계하고 구현할 수 있는 수행자의 전문성 역시 제대로 평가받기 어렵다. 이는 좋은 아키텍처를 설계할 수 있는 인력이 부족하다는 문제와는 별개로, 그 가치를 알아보고 적절하게 활용할 수 있는 역량이 산업 현장에 존재하는가의 문제이기도 하다.
산업계와 국가 정책 결정권자들은 그동안 산업 현장에서 필요로 하는 개발인력을 확보하기 위해 다양한 교육 및 인력 양성 정책을 추진해 왔다. 이러한 정책은 소프트웨어 산업에 필요한 인력을 공급하고 프로그래밍 기술에 대한 접근성을 높이는 데 기여했을 것이다. 그러나 개발인력의 양적인 확대와 함께, 서로 다른 수준의 전문성과 역량을 구분하고 평가할 수 있는 기준도 충분히 발전해 왔는지는 생각해 볼 필요가 있다고 본다.
특히 나는 국가기술자격인 정보처리기사의 가치에 대해서도 아쉬움이 있다. 다른 기술 분야에서는 관련 전공이나 실무경력 등을 통해 응시자격을 제한하고 있으며, 공인회계사와 같은 전문자격은 일정한 전공 관련 과목의 이수를 요구하기도 한다. 반면 정보처리기사는 일정한 응시자격만 충족하면 전공과 관계없이 취득할 수 있고, 기출문제 중심의 학습으로도 합격을 준비할 수 있다. 이러한 자격제도가 컴퓨터공학 전공자의 학문적 깊이와 소프트웨어공학적 전문성을 얼마나 충분히 인정하고 평가할 수 있는지 의문이다. 물론 비전공자의 자격 취득 기회를 부정하는 것은 아니다. 다만 다른 전문 분야와 비교했을 때, 국가가 컴퓨터공학 전공의 전문적 가치를 충분히 인정하고 있는지에 대해서는 개인적으로 실망감을 느낀다.
개발자의 전문성을 평가할 때는 전공 여부나 교육 경로, 자격 보유 여부뿐 아니라 실제로 수행할 수 있는 역할과 문제 해결 능력, 설계 역량 등을 종합적으로 고려할 필요가 있다. 다양한 경로를 통해 소프트웨어 산업에 진입할 수 있다는 것은 긍정적인 측면이 있지만, 그만큼 서로 다른 전문성과 역량을 올바르게 구분하고 평가할 수 있는 기준도 중요해진다고 생각한다.
특히 산업 현장에서 소프트웨어의 가치를 기능 구현 여부와 개발에 투입된 비용을 중심으로 평가한다면, 구조적 품질을 높이기 위해 노력하는 수행자와 현재 요구된 기능을 구현하는 데 집중하는 수행자 사이의 전문성 차이를 충분히 평가하기 어려울 수 있다. 따라서 기능적 품질과 생산성뿐 아니라 구조적 품질, 유지보수성, 확장성, 장기적인 운영 효율성까지 함께 고려하는 평가 관점이 필요하다고 생각한다. 이러한 평가 기준이 발전해야 소프트웨어공학적 역량을 갖춘 전문가의 가치를 적절하게 인정하고, 그러한 역량을 발전시키려는 동기와 산업적 수요도 함께 높아질 수 있을 것이다.
여러 조건이나 상황을 복잡하게 정의할 필요 없이 단순한 기능 정의만으로 개발할 수 있는 어플리케이션의 경우, AI가 기능 요구사항을 충족하는 결과물을 만들어내면서 당장은 개발자를 대체할 수 있다는 인식이 점차 확산될 것이라고 예상한다. 하지만 소프트웨어 생명주기의 상당 부분을 차지하는 운영 기간, 즉 구축 이후부터 폐기 또는 대체되기까지의 과정에서는 다양한 요구사항의 변화와 데이터 증가 등으로 인해 사용자와 운영자가 예상하지 못했던 문제를 빈번하게 마주하게 된다.
이러한 문제를 그때마다 AI를 통해 개별적으로 해결하는 방식에 의존하다 보면, 소프트웨어를 구조적으로 이해하고 관리하는 전문성의 중요성이 상대적으로 간과될 수 있다. 또한 사용자들은 당장 필요한 개별 요구사항을 처리하는 데 익숙해지고, 전체적인 구조보다는 단위 기능의 구현에 더 많은 관심을 갖게 될 가능성이 있다고 생각한다. 이러한 상황이 반복되면 개별 기능의 처리에는 문제가 없더라도 어플리케이션 전체의 구조적 품질은 점차 저하될 수 있으며, 결과적으로 장기적인 운영과 유지보수에 어려움을 겪게 될 수 있다.
문제는 이러한 상황이 발생한 이후에야 아키텍처의 중요성을 인식하더라도, 이미 수많은 기능과 데이터가 복잡하게 얽혀 있는 어플리케이션의 구조를 변경하는 데 상당한 비용과 위험이 수반될 수 있다는 점이다. 그렇기 때문에 최초에 모든 요구사항을 예측할 수 없다는 사실은 아키텍처 설계의 필요성을 낮추는 이유가 아니라, 오히려 구축 초기부터 변화와 확장을 수용할 수 있는 구조를 고민해야 하는 이유가 된다고 생각한다.
물론 AI의 발전으로 이러한 문제 역시 AI를 통해 해결할 수 있을 것이라는 기대도 가능하다. 실제로 AI는 앞으로 복잡한 어플리케이션의 구조를 분석하고 개선하는 데 더욱 뛰어난 능력을 발휘할 수 있을 것이다.
그러나 AI로 프로그래밍을 하더라도 결국 그것을 사용하는 것은 사람이며, 실제 업무 환경에서는 기능적인 요구사항만으로 설명할 수 없는 다양한 문제와 변화가 발생한다. 또한 수많은 어플리케이션이 각각 운영 과정에서 마주하게 될 문제를 AI로 해결하려면 그 과정에도 자원이 필요하다. 이러한 문제를 개별적으로 해결하는 방식이 반복된다면 오히려 더 많은 비용을 지출해야 하는 상황으로 이어질 수도 있다고 생각한다.
AI도 하나의 자원이고, 자원은 유한하기 때문이다.
물론 AI의 발전으로 개별 프로그램의 개발과 유지보수에 필요한 비용이 지속적으로 감소할 가능성도 있다. 그러나 개별 기능을 구현하는 비용이 감소한다는 것과 어플리케이션 전체의 생명주기에 필요한 비용이 감소한다는 것은 동일한 문제가 아니다. 오히려 AI를 통해 더 많은 프로그램을 빠르게 만들어낼 수 있게 될수록, 그 프로그램들이 일관된 구조와 설계 원칙 안에서 개발되고 유지될 수 있도록 하는 것이 중요해질 수 있다.
단순한 기능 구현을 중심으로 수행해 온 개발 업무의 상당 부분은 AI에 의해 자동화되거나 변화할 가능성이 높아질 것이다. 하지만 내가 예상하는 이러한 미래의 문제들로 인해, 결국 소프트웨어공학적 관점에서 요구사항을 분석하고 어플리케이션을 설계할 수 있는 사람들의 역할이 다시 주목받게 될 것이라고 생각한다.
그러나 이러한 전문가들이 존재한다는 사실만으로 문제가 해결되는 것은 아니다.
아키텍처의 가치를 이해하고 평가할 수 있는 역량이 충분히 갖춰져 있지 않다면, 아무리 뛰어난 설계 역량을 갖춘 전문가가 존재하더라도 그 역량을 효과적으로 활용하기 어렵다. 또한 그들이 만들어낸 구조적 품질과 장기적인 경제적 가치를 적절하게 평가할 수 없다면, 산업 현장에서 그러한 전문성을 확보하고 유지해야 할 필요성도 충분히 인식되기 어려울 것이다.
결국 중요한 것은 소프트웨어공학적 역량을 갖춘 전문가를 양성하는 것뿐만 아니라, 그들의 역량과 설계 결과물의 가치를 이해하고 평가할 수 있는 사람과 조직의 역량도 함께 발전해야 한다는 것이다.
앞으로 AI를 통해 더 많은 프로그램을 빠르게 생산할 수 있게 될수록, 의사결정 과정에서 어플리케이션의 구조적 품질과 장기적인 운영 효율성을 함께 고려하는 일이 더욱 중요해질 것이라고 생각한다. 그렇지 않다면 AI가 생산한 수많은 프로그램이 점점 더 복잡하게 얽히면서, 장기적인 유지보수와 구조 변경에 상당한 비용과 위험이 발생할 수도 있다.
AI가 아무리 발전하더라도 소프트웨어의 가치를 기능 구현에 필요한 비용과 시간만으로 판단한다면, 산업 현장에서 반복되어 온 구조적 문제는 충분히 해결되기 어려울 것이다. 따라서 사회는 단순히 프로그래밍 기술을 익힌 인력을 양성하는 것을 넘어, 컴퓨터공학적 사고 역량을 갖춘 전문 인력을 길러내기 위한 노력을 놓쳐서는 안 된다고 생각한다.
그리고 그에 못지않게 중요한 것은 그러한 전문성이 만들어내는 구조적 품질과 장기적인 경제적 가치를 알아보고, 올바르게 평가하며, 실제 의사결정에 반영할 수 있는 산업환경을 만드는 것이라고 생각한다.
댓글 1
아직 AI 파급력의 초기이다 보니.. 그 동안 과잉 공급에 따른 혼란이 있는 것 뿐이죠. 제자리를 찾을 겁니다.
사람들은 AI가 다 해줄거라고 보지만.. 막상 직접 해보면.. 백그라운드 지식 무시 못하죠.