LLM 챗봇과의 페어 프로그래밍, 가능할까?

소프트웨어 개발자의 세계에는 다양한 유형이 존재합니다.

최신 라이브러리와 프로젝트를 끊임없이 공유하며 아이디어를 주고받는 외향적인 개발자가 있는가 하면, 혼자만의 생각 속에서 문제를 해결하고 깊이 고민한 후에야 코드를 작성하는 내향적인 개발자도 있습니다.

이러한 개발자 유형의 차이는 관리자가 강요하는 ‘최적화’ 전략, 특히 페어 프로그래밍 도입 시 흥미로운 시나리오를 만들어냅니다.

이론적으로는 두 명의 개발자가 같은 컴퓨터와 키보드를 공유하며 생산성을 두 배로 끌어올릴 수 있지만, 실제로는 그렇지 않은 경우가 많습니다.

특히 내향적인 개발자에게 강제된 페어 프로그래밍은 어색함과 소외감을 유발하기 쉽습니다.

저 역시 내향적인 개발자로서, LLM 챗봇을 코딩 도우미로 사용하는 아이디어는 강요된 페어 프로그래밍의 불쾌한 기억을 떠올리게 했습니다.

하지만 어쩌면 LLM 챗봇은 불필요한 사회적 상호작용 없이 코딩에만 집중할 수 있다는 점에서 더 나은 경험을 제공할 수도 있습니다.

이를 확인하기 위해 LLM 기반 코딩 어시스턴트가 페어 프로그래밍과 달리 제가 받아들일 수 있는 도구가 될 수 있을지, 작은 실험을 진행해 보았습니다.

실험 목표 및 기대치 설정

성공적인 실험은 명확한 목표와 매개변수를 설정하는 것에서 시작합니다.

저는 다소 부정적인 시각으로 이 실험에 임했기에, LLM 챗봇의 도움을 받을 두 가지 명확하고 직관적인 시나리오를 선정했습니다.

첫째는 STM32와 CMSIS를 활용한 C++ 임베디드 코딩이고, 둘째는 Ada 언어 네트워크 개발입니다.

이 주제들은 제가 충분히 숙지하고 있어 어떤 질문을 해야 할지, 그리고 어떤 결과물을 기대할 수 있을지 미리 파악하고 있었습니다.

챗봇은 주로 StackOverflow나 IRC 채널에 질문하는 방식과 유사하게 활용할 계획이며, 가장 큰 우려는 챗봇이 지나치게 예의를 차리는 태도를 요구하는 것이었습니다.

최소한 검색 엔진에 욕설을 퍼붓는 것보다는 나은 결과를 기대했습니다.

기대하는 바는, 제가 가진 질문에 대해 챗봇이 유용한 답변을 제공하고, 제가 쉽게 이해하고 기존 문서와 대조하여 검증할 수 있는 절반 정도는 사용할 수 있는 코드를 생성하는 것입니다.

이제 어떤 LLM 챗봇을 선택하고 어떻게 활용할 것인지가 남은 질문입니다.

LLM 챗봇 선정: GitHub Copilot

LLM 기반 프로그래밍 도구에 관심 있는 많은 사람들이 Claude를 추천하지만, 저는 새로운 서비스에 가입하는 것을 꺼렸습니다.

따라서 이미 접근 권한이 있는 GitHub Copilot을 선택했습니다.

이 LLM 챗봇에 대해 이미 여러 차례 작성한 경험이 있으며, 대체로 이러한 도구에 대한 부정적인 감정을 뒷받침하는 연구 결과들을 접해왔습니다.

비록 편향된 시각일 수 있으나, 과학적인 실험을 위해서는 이러한 편견을 배제하고 새로운 증거에 직면해야 합니다.

이러한 모든 편견과 의심을 뒤로하고, 오직 전문적인 태도로 본론으로 들어가겠습니다.

STM32 임베디드 코딩에서의 경험

STM32 관련 프로그래밍에 대한 제 개인적인 프로젝트는 Nodate 프로젝트입니다.

이 프로젝트는 CMSIS 표준 헤더와 해당 매크로를 사용하여 시작 코드부터 Dhrystone 벤치마크 실행, 그리고 다양한 실시간 시계 해석까지 포함합니다.

이 과정에서 데이터시트, 참조 매뉴얼, 방대한 양의 참조 코드를 탐색하고, 검색 엔진에 질의하여 유용한 정보를 찾아내야 합니다.

동료 STM32 개발자들이 포럼 스레드 등에서 겪는 어려움과 성공 경험을 접하는 것은 때로는 격려가 되기도 하고, 때로는 좌절감을 주기도 하지만, 결국 프로젝트 진행에 도움이 되는 정보로 집약됩니다.

아이러니하게도, 브라우저에서 챗봇을 사용하려는 순간 GitHub 상태 페이지에 오류가 발생하며 Copilot을 포함한 일부 시스템이 다운되었음을 알리는 메시지가 나타났습니다.

이는 LLM 챗봇이 좋은 프로그래밍 파트너가 될 수 있는지 여부와는 별개로, 실제 인간 파트너는 작업 도중에 갑자기 응답 불능 상태가 되지 않는다는 점을 시사합니다.

만약 그런 일이 발생한다면, 이는 명백한 의료 응급 상황이며 즉시 911이나 해당 지역의 응급 번호로 연락해야 할 것입니다.

서비스가 복구된 후, 저는 STM32F411 MCU의 클럭 속도를 올바르게 설정하는 방법에 대해 챗봇에 질문할 수 있었습니다.

이전에는 특정 고클럭 설정을 위해 레귤레이터 전압 스케일링(VOS)을 파워 컨트롤 레지스터(PWR_CR)에 설정해야 한다는 사실을 간과하여 어려움을 겪었습니다.

이는 특정 고전력 소비 클럭을 달성하기 위해 조정이 필요한 전력 절약 기능입니다.

놀랍게도, 챗봇은 ‘CMSIS’ 부분을 무시하고 ST HAL 코드를 제공했습니다.

물론 ST HAL이 내부적으로 CMSIS를 사용할 수 있다고 주장할 수도 있겠지만, 많은 MCU의 Arduino 코드도 마찬가지입니다.

챗봇은 ‘주요 CMSIS 요구사항’ 목록에 PWR_REGULATOR_VOLTAGE_SCALE1 설정을 언급했지만, 어디에 설정해야 하는지에 대한 추가적인 세부 정보는 제공하지 않았습니다.

또한, 이는 CMSIS 매크로조차 아니며, 양쪽 비트를 모두 설정하여 전체 범위를 다루는 PWR_CR_VOS가 실제 매크로입니다.

다행히도 챗봇에게 원하는 것을 정확히 지시하여 CMSIS 버전을 제공하도록 할 수 있었습니다.

하지만 결과는 또 다른 충격이었습니다.

챗봇은 CMSIS 헤더를 포함하는 대신, 사용된 모든 구조체 정의 등을 코드에 복사하여 코드를 비대하게 만들었습니다.

물론 이것이 제가 요청한 방식일 수도 있습니다.

이는 #define 매크로를 사용해야 할 상황에서 매우 성가신 일이며, 챗봇은 <cstdint>를 포함하는 것을 보아 포함 문을 생성할 수 있음에도 불구하고 이러한 방식을 택했습니다.

가장 치명적인 문제는 이 코드가 STM32F411에서 작동하지 않는다는 것입니다.

PWR_CR_VOS_SCALE1이라는 값의 출처를 정확히 알 수 없으며, 친절한 검색 엔진에 질문해도 해당 코드에 대한 몇 개의 결과만 나왔을 뿐입니다.

그중 하나는 최대 168MHz에서 실행되는 STM32F407에 대한 것이었습니다.

이는 코드 바로 위의 주석과 대조해 볼 때 매우 아이러니합니다.

챗봇이 어떤 예제 코드를 도용했는지 의문이 듭니다.

이 시점에서 생성된 코드를 계속해서 분석할 수 있겠지만, 저는 생성된 코드와 전반적인 출력에 대한 신뢰도가 ‘낮음’에서 ‘블랙홀 바닥’ 사이를 맴돌고 있다고 단언할 수 있습니다.

이 시점에서 실험을 중단하고 정신 건강을 지키는 것이 현명하다고 판단했습니다.

결론: LLM 챗봇은 페어 프로그래밍 파트너가 될 수 있는가?

원래는 Ada로 C++ 네트워킹 코드를 포팅하는 재미있는 작업도 Copilot과 함께 진행하려 했지만, 이미 제 신경은 충분히 예민해졌고 순전히 믿을 수 없다는 생각에 터져 나오는 거의 히스테리컬한 웃음은 이 시도를 중단하게 만들기에 충분했습니다.

또한, GitHub Copilot이 최소한 좋은 페어 프로그래밍 파트너가 되지 못하며, 프로그래밍 도구로서도, 검색 엔진으로서도, 혹은 그 외의 어떤 것으로도 기능하지 못한다는 점을 더욱 확고히 할 뿐이라는 생각이 듭니다.

챗봇이 제공한 유일한 ‘결과’는 그 출력을 확인해야 한다는 것이었습니다.

결론적으로, LLM 챗봇은 현재로서는 인간 개발자와의 페어 프로그래밍을 대체하기는 어렵습니다.

특히 전문적인 코드 생성이나 복잡한 문제 해결에 있어서는 더욱 그렇습니다.

하지만 특정 질문에 대한 빠른 정보 검색이나 간단한 코드 스니펫 생성 등 보조적인 도구로서의 가능성은 여전히 존재합니다.

앞으로 LLM 기술이 발전함에 따라 이러한 한계점들이 극복될 수 있을지 지켜볼 필요가 있습니다.

출처: https://hackaday.com/2026/04/27/trying-pair-programming-with-an-llm-chatbot/