AI 협업, 개인 프로젝트와 실무는 달랐다

개인 프로젝트에서 AI를 사용하기 시작했을 때의 목적은 단순했다. Python을 모르는 상태에서 구현에 단 1%도 관여하지 않고 프로그램을 어디까지 개발할 수 있을지 확인하는 것이었다. 요구사항과 설계 방향을 내가 결정하고, ChatGPT가 이를 Codex용 작업 지시로 정리한 뒤, Codex의 구현 결과를 다시 설명받는 방식이었다. 작은 프로젝트에서는 이 구조가 꽤 잘 작동했다.

그런데 MyStock에 데이터베이스와 클라우드 동기화 등 익숙하지 않은 기술이 쌓이면서 문제가 달라졌다. AI가 작성한 코드가 실행되는 것과 그 구조가 올바른지는 별개의 일이었고, 정작 구현을 모르는 내가 내부 판단을 확인하기는 쉽지 않았다. 반면 회사의 임베디드 개발 업무에 AI를 적용하자 전혀 다른 결과가 나왔다. 내가 코드와 제품의 이력을 알고 있는 만큼 중간의 ChatGPT가 오히려 불필요했고, Codex와 직접 대화하면서 작업 범위를 통제하는 편이 수월했다.

구분	개인 프로젝트	회사 업무
개발 환경	Python 기반 개인 프로젝트	임베디드 C 펌웨어
코드·도메인 이해	익숙하지 않은 기술 영역 다수	전체 코드 구조 및 필드 이력 이해
협업 구조	나 → ChatGPT → Codex	나 → Codex
구현 참여	Python 구현에 직접 개입하지 않음	모듈별 수정 범위·계획 직접 통제
방향 결정	요구사항과 설계 방향 결정	해결 방안과 변경 범위까지 직접 결정
주요 고민	구현 결과와 내부 구조 검증	기존 기능 안정성과 유지보수

Python 개인 프로젝트와 AI 구현 위임

나는 임베디드 소프트웨어 개발자지만 Python은 모른다. Python을 익히는 것부터 시작했다면 이런 실험의 취지가 달라졌을 것이다. 그래서 요구사항과 설계 방향만 결정하고, 구현은 ChatGPT와 Codex의 협업 구조에 맡겼다. ChatGPT는 요구사항을 구체화하고 Codex에 전달할 프롬프트를 작성하며, Codex가 보고한 작업 결과를 내가 이해할 수 있게 설명했다. 이 과정에서 내가 직접 Python 코드를 수정하지 않는다는 원칙은 유지했다.

MyStock이 커지면서 이 원칙의 부담도 커졌다. 외부 API, SQLite, Dropbox 동기화, GUI 내부 구조까지 다루게 되자 코드가 정상 동작한다는 결과만으로 설계 적절성을 판단하기 어려웠다. ChatGPT와 Codex가 서로 다른 정보를 가지고 있다는 문제도 있었다. ChatGPT는 이전 대화의 판단 맥락을 알고 있지만 현재 저장소의 모든 코드를 보고 있는 것은 아니고, Codex는 저장소를 보더라도 그동안 내려온 모든 결정을 알고 있다고 볼 수 없다. 결과 보고서를 옮기는 과정에서 정보가 압축되고, 틀린 전제 위에서 그럴듯한 설명이 나오는 일도 생겼다.

그렇다고 직접 구현에 뛰어들 생각은 없다. MyStock에서는 여전히 구현에 개입하지 않는 조건을 유지하면서 어떻게 검증 체계를 강화할지 실험하고 있다. 이 문제는 이전에 쓴 AI에게 구현을 맡겼더니 프로젝트 전체를 아는 사람이 없어졌다에서도 다뤘다.

임베디드 개발과 Codex 직접 협업

회사 업무는 정반대다. 개발 중인 제품의 전체적인 코드 구조와 모듈 사이의 관계를 알고 있고, 오랫동안 개발·유지보수하면서 겪은 필드 이력도 기억하고 있다. 처음에는 개인 프로젝트에서 하던 대로 ChatGPT를 중간에 두었지만, 내가 이미 알고 있는 내용을 다시 설명하고 그것을 또 Codex의 작업 지시로 바꾸는 과정이 불편했다. 실제 코드를 모르는 중간 매개체가 엉뚱한 가정을 덧붙이기도 했다. 그래서 회사에서는 ChatGPT를 제외하고 Codex와 직접 협업한다.

그렇다고 AI에 개발을 전부 맡기는 것은 아니다. 내가 수정할 모듈과 스코프를 먼저 지정하고, 그 범위 밖은 절대 건드리지 말라고 명시한다. 구현 전에 현재 코드와 영향 범위를 검토하고 어떻게 수정할지 먼저 보고하게 한다. 그 계획을 내가 판단한 후 승인한 범위에서만 구현한다. 다른 영역까지 손대는 구조적 개선은 요청하지 않는다. 기존 제품의 설계 의도와 양산 이력, 과거 필드 문제를 소스코드만으로 모두 알 수 없기 때문이다.

AI가 코드 자체를 분석하거나 디버깅하는 능력은 도움이 됐다. 하지만 분석을 시킨다고 시스템에 맞는 해결 방향이 저절로 나오는 것은 아니었다. 해결 방향을 물었다면 대안을 제안했을 수 있겠지만, 그 대안이 전체 코드를 흔드는 변경으로 이어질 가능성까지 감수할 필요는 없었다. 회사에서는 문제와 해결 방안, 변경 범위를 내가 정한다. Codex는 지정된 모듈 안에서 그 방안이 가능한지 검토하고 승인된 수정만 구현한다.

STM32 SRAM 확보와 모듈 단위 검토

최근 STM32에서 PnC 기능을 위한 SRAM을 확보하는 작업은 이 협업 방식을 잘 보여준다. 메모리를 더 확보해야 한다는 문제뿐 아니라 어떤 방향으로 확보할지, 구체적으로 무엇을 바꿀지도 내가 생각하고 결정했다. 다만 전체 메모리 사용 현황과 코드의 연결 관계를 확인하려면 분석량이 상당했다. 그래서 Astra에 전체 코드를 깊이 분석하게 하고 그 결과를 검토했다.

그 다음부터는 모듈 단위였다. 내가 제시한 메모리 확보 방안이 지정된 코드 범위에서 가능한지 Codex에 검토시키고, 수정 예상 영향과 구현 계획을 보고받았다. 적절하다고 판단한 항목만 단계적으로 수정하고 결과를 확인했다. AI가 메모리 확보 전략을 결정한 것도 아니고, AI가 찾아낸 해결책을 내가 선택한 과정도 아니다. 개발자인 내가 해결 방안을 제시했고 AI는 분석, 타당성 검토, 제한된 구현을 담당했다.

이번 글에서는 세부 구현보다 왜 분석 범위와 실제 수정 범위를 분리했는지가 중요하다.

Codex 코드 가독성과 유지보수 기준

Codex와 직접 작업하면서 겪은 또 다른 문제는 코드 스타일이었다. 때로는 조건을 압축하고 시프트나 비트 연산을 활용해 짧고 최적화된 듯한 코드를 작성했다. 물론 레지스터 제어나 프로토콜 처리처럼 비트 연산이 필요한 부분도 있고, 실행 시간이나 메모리가 제한된 구간에서는 최적화가 우선일 수 있다. 그렇다고 일반적인 충전기 제어 로직까지 그렇게 작성할 이유는 없다.

실제로 의미 있는 성능 차이가 없다면 몇 줄을 아낀 코드보다 사람이 빠르게 읽을 수 있는 코드가 낫다. 필드 문제를 분석하거나 몇 년 뒤 기능을 변경할 때 연산의 의미를 다시 해석하는 데 시간이 들어가기 때문이다. 그래서 Codex에게 불필요한 축약과 최적화를 피하고, 조건과 변수의 의도가 드러나는 코드로 작성하라고 요구했다. 내가 중요하게 생각하는 코드 품질은 AI가 똑똑하게 줄인 코드가 아니라 사람이 계속 유지보수할 수 있는 코드다.

신규 MCU 선정과 AI의 기술 조사

회사에서 AI를 사용하며 특히 만족스러웠던 일은 코딩 외의 기술 조사였다. 신규 칩셋을 검토하거나 프로젝트 조건에 맞는 MCU를 선정할 때는 제조사별 제품군을 찾고 인터페이스, 메모리, 주변장치와 제약조건을 대조하는 데 시간이 많이 든다. 지금은 프로젝트 요구사항을 AI에 먼저 전달해 후보군과 확인할 사항을 좁힌다.

물론 AI의 답변으로 칩셋을 최종 결정하지 않는다. 후보가 나오면 데이터시트를 확인하고 판매처나 대리점에 원하는 기능이 실제로 가능한지, 유사하게 사용하는 업체나 적용 사례가 있는지 문의한다. AI를 통해 얻는 것은 최종 확답이 아니라 현실적인 검증 단계에 빠르게 도달할 수 있는 초기 조사 결과다.

이 과정에서 조사에 들이는 시간이 상당히 줄었다. 코드를 대신 작성하는 능력만큼이나 분석과 조사 시간을 줄여주는 능력이 실무에서 유용하다는 것을 느꼈다.

두 가지 AI 협업 방식의 현재

개인 프로젝트에서는 내가 모르는 구현을 AI에게 위임하는 구조를 계속 실험하고 있다. 회사에서는 내가 알고 있는 시스템의 문제와 해결 방안을 직접 정한 뒤 AI를 코드 분석, 타당성 검토, 제한된 구현에 활용한다. 같은 Codex를 사용하더라도 결정권과 구현 통제 방식은 전혀 다르다.

이제 AI가 코드를 얼마나 많이 작성할 수 있는지보다, 어떤 업무를 맡겨야 개발이 수월해지는지가 더 궁금하다. MyStock에서는 검증 방식을 더 고민해야 하고, 회사에서는 현재의 통제 원칙을 유지하면서 필요한 곳에 AI를 사용할 생각이다. 지금의 협업 방식이 최선인지는 아직 모르겠다. 다만 개인 프로젝트와 실제 업무에서 서로 다른 방법이 필요하다는 점은 분명히 경험했다.

저작자표시 비영리 동일조건 (새창열림)