정말 시작은 단순한 이유였다. 증권사 앱을 오가며 확인하던 정보를 한 화면에서 보고 싶었고, Python은 모르지만 AI에게 코딩을 맡기면 내가 원하는 프로그램을 만들 수 있지 않을까 생각했다.
그런데 MyStock을 계속 만들다 보니 관심사가 조금씩 달라졌고, 프로그램 자체보다 더 궁금한 것이 생겼다. 내가 코드를 직접 작성하지 않고 요구사항과 구조를 정확하게 전달한다면 AI는 실제 소프트웨어 개발을 어디까지 맡을 수 있을까?
그리고 그 과정에서 내가 Codex에게 기능 명세뿐 아니라 변경 범위, 레이어의 역할, 모듈 간 책임, 건드리면 안 되는 영역까지 반복해서 지정하고 있다는 것을 깨달았다. 처음에는 AI가 엉뚱한 곳을 수정하지 못하게 하기 위한 제약이라고 생각했다. 하지만 이야기를 계속하다 보니 그것은 AI 때문에 새로 생긴 습관이 아니었다.
20년 넘게 펌웨어를 개발하면서 몸에 밴 방식이 자연스럽게 AI에게도 나오고 있었다.
제품은 바뀌어도 펌웨어의 기본 골격은 크게 달라지지 않았다
아래 그림은 특정 제품 하나를 위한 구조라기보다 내가 오랫동안 사용해 온 펌웨어의 가장 기본적인 골격에 가깝다. 셋톱박스를 개발할 때도, 지금 충전기를 개발할 때도 제품은 달라졌지만 기본적인 생각은 크게 달라지지 않았다.
셋톱박스는 여러 벤더의 칩셋을 사용하며, 때론 가격 경쟁력 때문에 칩셋을 바꾸기도 하고, 수급이나 EOL 같은 현실적인 이유로 다른 칩셋이나 Peripheral을 선택해야 하는 경우도 흔하다. 하지만 칩셋이 바뀐다고 셋톱박스 본연의 기능까지 바뀌는 것은 아니다.
펌웨어가 구조화 되어 있지 않다면 플래시 하나를 바꿨을 뿐인데 전혀 관계없는 코드까지 영향을 받는다. 칩셋을 변경할 때마다 제품 전체를 다시 흔들어야 한다면 신규 개발뿐 아니라 유지보수도 감당하기 어려워진다.
그래서 Driver Layer의 모듈은 각자 자신의 역할에 충실한 독립 모듈이어야 한다. 다른 Driver가 무엇을 하는지 불필요하게 알 필요가 없다. Manager Layer는 그 독립된 기능들을 통합해서 제품의 동작을 제어한다. 그래야 새로운 기능을 추가하거나 하위 구현을 교체할 때 영향 범위를 통제할 수 있다. UI는 사용자 입력을 전달하고 결과를 정확하게 표시하는 역할에 집중하면 된다.
충전기도 마찬가지다. 저가형 제품에는 LCD가 없고 LEDBar 정도만 있을 수 있다. 기능이 단순하면 가격이 저렴한 메인 칩셋을 사용할 수도 있다. 고가형은 LCD와 추가 UX가 필요하고, 그 때문에 더 높은 사양의 칩셋이나 SDRAM이 필요할 수도 있다. 하지만 하드웨어 구성이 달라졌다고 충전기 본연의 기능이 사라지는 것은 아니다. 충전 Device를 제어하는 Manager가 필요하고, OCPP를 처리하는 Manager가 필요하다. PLC 통신이 필요한 제품이라면 SECC Manager도 필요하다. 하드웨어의 선택은 달라져도 Manager와 UI가 담당해야 하는 제품의 본질적인 책임까지 함께 바뀌어서는 안 된다고 생각한다.
그래서 Codex에게도 자꾸 경계를 먼저 말하게 된다
예전 AI에게 코드를 맡겼을 때는 대부분 모듈 수준의 기본 동작을 확인하는 정도였다. 생성된 코드를 양산 제품에 그대로 넣기보다는 “이런 방식으로 동작하는구나”를 확인하는 용도에 가까웠다. 하지만 지금은 나는 Codex에게 실제 프로젝트의 기능 구현과 수정을 맡기고 있다. 그러다 보니 대화할 때마다 자연스럽게 기능 명세와 레이어 구분이 먼저 나온다. 이 기능은 어디에서 처리해야 하는지, 어느 모듈까지 수정할 수 있는지, 다른 기능에는 영향을 주면 안 된다는 조건을 계속 붙인다.
이것이 특별한 프롬프트 기법인지는 모르겠다. 다른 사람들이 AI에게 어떤 방식으로 개발을 맡기는지도 잘 모르지만, 나에게는 새로운 방법이라기보다 기존 개발 방식의 연장에 가깝다.
임베디드든 웹이든 앱이든 세부 구조와 기술은 다르겠지만, 기능과 책임을 나누고 변경의 영향을 제한하려는 소프트웨어 설계의 기본적인 목적은 크게 다르지 않다고 생각한다. 그래서 Python을 하나도 모르면서도 Python 프로그램을 만드는 Codex에게 이런 요구를 하고 있는지도 모르겠다.
코딩을 맡기는 것과 설계의 결정까지 맡기는 것은 다르다
AI는 빠르게 발전하고 있고, 소프트웨어 설계 이론이나 일반적인 패턴을 지키는 능력은 앞으로 사람보다 더 좋아질 수도 있다. 하지만 계속 마음에 걸리는 질문이 있다.
사용자의 요구 명세가 정확하지 않은 상태에서 AI가 스스로 생각하고 판단해서 설계와 개발까지 결정하는 것이 과연 가능한가?
AI가 요구사항을 바탕으로 좋은 구조를 제안하는 것과, 명확하지 않은 요구사항을 임의로 해석해서 제품의 동작을 결정하는 것은 다른 문제라고 생각한다. 그래서 현재로서는 코딩을 AI에게 맡기더라도 가장 기본적인 골격과 책임의 경계는 사람이 제어해야 한다고 생각한다. AI가 더 좋은 구조를 제안할 수는 있지만 어떤 요구를 제품의 요구사항으로 받아들일지, 어떤 책임을 어디에 둘지, 모호한 요구사항에서 어떤 선택을 할지는 결국 제품을 만드는 사람이 결정해야 하지 않을까 싶다.
오픈소스 문제를 끝까지 사람이 직접 파야 하는가
불과 몇 년 전만 해도 양산 제품에 포함된 오픈소스에서 문제가 발생하면 소스부터 분석할 엄두가 나지 않았다. 먼저 GitHub의 Issue를 뒤지고, 구글링으로 비슷한 사례를 찾았다. 그래도 답을 못 찾으면 결국 직접 재현 범위를 줄여가며 내부 소스를 따라 들어갔다.
그런데 이제는 이 과정도 달라지고 있다. 최근 LVGL에서 한글 문자가 겹치는 문제가 발생했을 때 화면을 보고 LVGL 내부의 폰트 자간 계산 문제일 가능성이 높다고 판단했다. 그리고 배터리정보 관련 약관이 추가되면서 한 페이지에 출력되는 문자가 많아진 뒤 발생한 문제에서는 처음에는 TTF 폰트 렌더링에 사용하는 메모리를 늘려야 하는 것이 아닌가 생각했다.
중요한 것은 내가 직접 LVGL 전체 소스를 파고들지 않았다는 점이다. 증상과 경험을 바탕으로 의심되는 영역과 가설을 제시하고 AI에게 확인을 맡겼다. 그렇게 원인을 좁히고 수정하는 데 긴 시간이 필요하지 않았다. 예전 같으면 내가 직접 호출 경로를 따라가고 로그를 추가하고 내부 구현을 분석했을 것이다. 물론 지금도 필요하다면 그렇게 할 수 있지만 이제는 다른 질문이 생긴다.
내가 직접 분석할 수 있는가?가 아니라 이 분석을 내가 끝까지 직접 하는 것이 가장 효율적인가?
양산 제품이기 때문에 AI의 분석을 그대로 믿고 패치를 넣을 수는 없다. 원인이 실제 증상과 일치하는지, 변경 범위가 적절한지, 다른 기능에 영향이 없는지는 결국 검증해야 한다. 다만 모든 소스 탐색 과정까지 사람이 직접 수행해야 하는지는 다시 생각해볼 수 있게 되었다.
주식 계좌를 보려다 시작한 엉뚱한 실험
처음에는 주식 계좌를 편하게 보기 위한 개인 프로그램이었다. 그런데 개발을 계속하면서 목적이 조금 주객전도되었다. 코드를 직접 작성하지 않고 정확한 명세를 전달했을 때 AI가 어디까지 실제 개발을 수행할 수 있는가. 그리고 그 결과를 보면서 앞으로 내가 개발자로서 무엇에 시간을 써야 하는지를 확인하고 싶어졌다.
새로운 분야를 접할 때마다 새로운 프로그래밍 언어와 프레임워크를 처음부터 익히는 데 많은 시간을 사용하는 것이 앞으로도 항상 최선인지 모르겠다. 언어를 몰라서 개발하지 못하거나, 정작 중요한 제품의 문제보다 문법과 구현 방법을 익히는 데 시간을 소비한다면 그것 역시 다시 생각해볼 문제다.
사실, 웹은 정파의 언어인 C, Java와 다르게 사파적 느낌으로 괴랄스러운 문법으로 도통 적응을 할 수 없었으며, 앱은 iOS나 안드로이드 생태를 이해하는데 많은 시간이 걸려 몇번을 시도했으나 포기하고 그냥 C로만 먹고 살고 있다. 그나마 파이썬은 개발에 필요한 유틸리티나 스크립트 생성에 좋아 조금 익혔으나, 필요한 곳 적용하고 사용하지 않아 기억속에서 사라졌을 뿐이다.
그렇다고 프로그래밍 언어나 소스코드가 중요하지 않다는 뜻도 아니다. AI가 잘못된 방향으로 가고 있는지 판단하고, 결과를 검증하고, 필요할 때 더 깊이 들어가기 위해서는 기존의 개발 경험이 여전히 필요하다. 다만 그 경험을 사용하는 위치가 달라질 수 있다고 생각한다. 예전에는 문제를 직접 찾아내고 직접 코드를 수정하는 데 대부분의 시간을 사용했다면, 앞으로는 문제를 정의하고, 구조와 경계를 결정하고, AI가 분석하고 구현한 결과가 제품에 적합한지를 판단하는 데 더 많은 시간을 사용할 수도 있다.
아직 결론은 없다
이 실험의 결론을 아직 정하지 않았고, AI만으로 개발할 수 있다는 결론을 얻으려는 것도 아니다. 오히려 확인하고 싶은 것은 경계다. 어디까지 AI에게 맡겨도 되는지, 어디부터 사람이 직접 통제해야 하는지, 그리고 앞으로 내가 가진 개발 경험을 어디에 집중해야 하는지 알고 싶다.
MyStock이 작은 개인 프로그램에서 계속 커지고 기능이 늘어나도, 내가 Python 코드를 직접 작성하지 않는 지금의 방식으로 구조와 유지보수성을 계속 지킬 수 있을까. 문제가 생겼을 때 AI와 함께 원인을 찾고 수정하는 방식이 장기간에도 통할까.
처음에는 그저 주식 계좌를 편하게 보려고 시작했다.
그런데 정신 차리고 보니 AI 시대에 나는 앞으로 어떻게 개발해야 하는가를 시험하고 있다.
확실히 주객전도된 것 같다.