ChatGPT와 코딩하기

라떼는 말이야.. C언어로 블라블라.. 천공카드로 블라블라

Oct 7. 2025

컴퓨터의 진화만큼 빠른게 있을까. Tech의 선방에서, 컴퓨터는, 하드웨어와 소프트웨어는, 데이터와 데이터저장기술은, 기계언어와 사람의 언어는, 아주 빠르게 진화한다. 오죽하면 반도체 집적회로의 성능이 매 2년 2배씩 성장한다는 법칙도 있다. Moore의 법칙이라고.

라떼는 말이야..로 말하자면 IMF 이후 장기간 이공계는 침체의 길을 걸었는데(~~재밌는건 소프트웨어 개발자가 부상한 지금, 체감상 의대인기가 더 많아졌다는 거~~), 2000년대 중반에 굳이굳이 이 전공에 발을 들였던 덕후 사람들은 만나게 된다. 80년대~90년대 초반 전국에서 몇 등 하고 공대 가던 시절 학번의 교수님들을 말이다.

아무튼간에, 그 때는, C언어니 Java 같은 것을 하고, 컴퓨터 구조시간에 어셈블리어도 배우고, 0101010도 배우고 뭐.. 기계의 말과 사람의 말이 엄청나게 다르고, 누구는 기계에 가까운 말을 사람도 할 수 있게 하고, 누구는 기계가 사람에 가까운 말을 이해할 수 있게 하면서 프로그래밍을 발전시켰드랬다. 물론 전산학과든 전산수리학과든 좀 다른 이름의 옛 컴공과를 다녔던 교수님들은 말했다.

제가 공부할때는, 천공카드라고 구멍을 뚫어서 프로그래밍을 했어요.
Java같은게 어디 있어요!

교수님들이야 컴퓨터를 바닥부터 이해하시고, 같이 살아오셔서 사고부터 구현까지 동기화가 돼 있으셨던 건지. 독수리 타법만으로도 어마어마한 프로그램을 만들곤 하셨다.

아무튼 아무리 인간의 말에 가까워지고 있다 해도 프로그래밍이란 어렵고 부담스러운 것. 하, 그 이유를 생각해보면 집착하면 그 퀄리티에 끝도 없다는 점 때문이다. 인간의 글은 정돈해서 명확하기만 하면 이해되는데, 코드는 명확하지 않으면 아예 안돌아가고, 잠재상황에 대한 통제도 필요하다.

생각해보자. 데이터를 쭉 읽어와서 이메일 템플릿에 넣어서 보내는 간단한 로직을 짠다고 가정하자. 데이터는 컴퓨터가 읽는 방식대로 코딩되어 있던가?(=전처리가 필요한가?) 이메일 템플릿에 어떤 변수들을 넣을 것인가? 템플릿에서 은/는/이/가가 앞에 들어오는 단어랑 다르면 어떻게 할 것인가? 이메일은 받는 사람정보만 넣을것이나, 참조에 다른 사람도 넣을 것인가? 회신을 받을 것인가? 이메일을 받은 사람이 또 받는 경우도 있는가? 이메일을 이미 거부한 경우가 있는가? 뭔가 현실 세계 일머리 같은 것 일수도 있는데.. 일상생활에서 우리는 열심히 움직이면서 닷과 닷을 연결하며 n개의 파트너 사이에서 눈치를 보며 이 일머리를 과시하지만, 개발자들은 참으로 우아하게 이 짓을 한다.

일단 큰 흐름을 그리고, 그 흐름에서 주된 경우의 수를 분기 시키고, 잠재적 리스크를 회피한다.

다시 말하지만, 우아한 일이다. 하나하나 발생할 때마다 막는 짓 따위 하지 않는다(~~고 믿는다~~) 컴공과 교수님들은 자주 백조를 소환한다. 물밑에서 발을 열심히 동동 굴리지만 위에는 우아하다고 말이다. 아마도 동동동동 코드가 빠르게 컴퓨터 리소스와 데이터를 돌리고 위는 잘 추상화되어 안정된 모습을 가리킨 것일 거다.

사회가 고도화되고 스펙이 고도화되면서 옛날처럼, 모델링만 하면 무조건 작동하는 시대가 아니게 됐다. 말그대로 이젠 개발만 하면 되는 시대가 아니다. 너무 많은 선택과 너무 유연한 비지니스가 공존하고, 게다가, 이미 투자되어서 잘 돌아가는 비효율적인 시스템도 산재하고 있는 가운데, 무엇을 개발할 지 고르는 기획력도 굉장히 중요하다. 물과 공기로 이분화된 시대가 아니고, 물과 공기가 혼재한 지금의 어느 중간지대에서 뾰족하게 기획을 해낸 후에야, 우아한 시스템을 위한 초석을 다질 수 있다.

그래서 창업자가 이 중간지대에서 무엇을 개발할 지 잘 고르고, 구조를 잘 짜는 개발자가 안정적인 스펙 위에서 시스템을 짜야, 스타트업이 커진다. 시스템 추상화의 수준이 회사의 크기와 갚이를 결정한다.

그런 의미에서 ChatGPT는 개발자 그 자체보다도, 개발기획 영역에서 탁월한 도움이 된다.

추석 내 한 작업의 일부를 생각해본다.

1. 화장품 제조프로세스는 그 단계만 수 십 개로, 동시다발적으로 진행시 내용 전달과 follow up에 문제가 생긴다.

2. 이 때문에 대부분의 중개업자들은 몇 개의 큰 놈만 관리하는 식으로 아웃풋을 관리한다. 내가 측정컨대, 그 수치는 똑똑하고 부지런한 영업사원을 기준으로 1인당 연간 최대 20억 원이다. 2000만원짜리 제조를 연간 x개 하는 셈인데, 다음과 같이 가정하고 계산해본다.

해당 품목의 재발주 전환율이 10% 수준이고, 재발주 시에는 2배 물량을 주문하고 3%의 할인을 받는다고 감안할 때, 2000만* 0.9x + 4000만*0.97*0.1x = 20억 원, x는 91~92사이의 값이 나온다. 1인당 91개의 프로젝트를 관리하고, 이 중 10%인 9.1개는 재발주이므로 신경을 덜 쓰는 기존 프로젝트라고 감안하면, 새롭게 관여되어 셋업해야하는 프로젝트는 연간 약 81~82개..? 월로 나누어 보면 6.75개이다.

3. 내용 전달과 follow up에 가장 문제를 일으키는 부문은 바로 서류작업이다. 제조라는 거 자체가 실제조 자체는 용기생산-후가공-제형생산-충진-포장 이라는 단순한 형태로 이뤄지는 거 같지만, 이게 몸에 바르는 것과 관계되다보니.. 이 모든 곳에 서류작업이 필요하다. 예정을 위한 서류, 확인을 위한 서류, 종료를 안내하는 서류 등 말이다. 프로젝트당 평균 23개의 서류가 필요하다. 이중에는 여러번 변경해 발급하는 서류도 있다.

럭키비키하게 프로젝트가 한달안에 끝난다고 해도, 서류를 최소 155.25개 준비해야한다.

4. 각각의 파트너십들은 이 서류작업을 미루는 경향이 있다. 비슷한 양식이 있다고 해도 서류를 작성하고 리뷰하는 일은 가장 피곤한 일 중 하나인데다, 생산보다는 덜 긴급하고, 고객 서비스에 가까운 일이지만 눈에 보이는 일도 아니기 때문이다. 크고 긴급한 건 위주로 마지못해 진행해준다.

5. 어떤 사람이 쓰고, 다른 사람이 검토한다.

문제는 프로젝트의 평균 duration은 6개월이다. 월로 나누는 기준은 틀렸고, 6개월에 40.5개 프로젝트에 대한 931.5개 서류를 준비해야한다.

이 것을 디지털 전환한다고 했을 때 서류를 어떻게 고객에게 전달할 것인가?

아마 추후에 우리 플랫폼에서 좀 더 고객이 원하는 시간대에 원하는 형태로 유연하게 전달하게 되는 것을 가정했을 때, 이메일이나 whatsapp같이 단발적인 메시지에 서류를 띄우는 것은 한계가 있다. 어떤 지점에서 다운받을 수 있게 하는 것이 좋을 거 같다.

그렇다면 구글드라이브의 어떤 위치를 생각하게 된다. URL로 공유하는 게 익숙해지면, 나중에 프로젝트 디테일 페이지에서 확인하는 것도 어렵지 않게 랜딩시킬 수 있다.

그러면 어떻게 고객에게 구글드라이브 폴더 속 서류를 제공할 것인가?

사람이 한다면,

1. 서류를 생성한다.

2. 폴더에 올린다.

3. 폴더 Sharing한다.

이 단순해 보이는 과정을 구현하려면...

0. 서류에 필요한 정보를 선택한다.

1. 해당 정보가 DB어디에 있는지 찾는다.

2. 행단위로 하나의 정보를 처리할 수 있도록 각종 전처리한다.

3. 서류템플릿을 만든다.

4. 서류템플릿에 연동될 아이디를 새로 선언한다.

5. 아이디를 넣으면 서류템플릿에 적합한 정보가 들어갈 수 있도록 한다.

6. 정보가 PDF로 추출되도록한다.

7. 구글드라이브 폴더를 생성한다.

8. 구글드라이브 폴더의 ID를 도출한다.

9. PDF파일이 구글드라이브 폴더에 저장되도록 한다.

10. 고객에게 sharing notification이 이메일로 가도록한다.

약간 더 나아가면 아이디를 포함한 고객정보를 받는 방법.. 구글드라이브 폴더의 구조를 만드는 방법... 중복을 막고 생성하는 방법 등 여러가지 플로우 연장이나 리스크 회피방법이 떠오르긴 하지만 나는 개발자가 아니고 막무가내 개발행위자라 일단 패스한다.

1~4는 밑작업이고 5~10은 실제 서류발급 루틴이다. 1~4가 정의에 해당하는 일들로 훨씬 중요하고 오래걸리는 작업이라서, 5~10은 누구에게나 가르쳐줘도 상관없다고 생각한다 ㅎ

밑작업은 적당히 생략하고 5번! 아이디를 넣으면 정보가 채워지는 포맷들을 만들었다! 참고로, 코딩으로 자동 엑셀이나 PDF출력 서류를 만들려면 너무 노가다여서, 왠만하면 모든 항목이 fix되고, 법적으로 아무 문제가 없을 때 개발에 착수하는 게 좋다.

자, 이제 6~10을 구현해야한다. 어떻게 할 것인가?

일단 큰 축을 결정해 본다. n8n을 써서 큰 축을 정의해봤다. 새로 데이터가 입력되면, 프로젝트 폴더를 만들고, 하위에 도큐먼트, 디자인폴더를 만들고 슬랙에 노티를 해주는 플로우다. 테스트기간에 Share 이메일이 마구 가면 안되니 일단 꺼놓는다. (참고로 n8n은 최근 가장 좋다고 느끼는 SaaS다. 개발을 매우 잘하는 사람은 그냥 만들면 되지만, 조금만 아는 나같은 막무가내 개발행위자가 상이한 인프라를 통합해서 뭘 하기가 어려울 때 아주 간편하게 이 닷과 저 닷을 연결할 수 있는 방법을 제공한다. OpenAPI가 n8n같은 것을 만들어 배포했다고 하는데 써보고 리뷰할 예정! 과금제가 통일되니 메리트가 있다.)

구조는 이렇게 만들고, sampleID는 처음부터 전달받고, folderID는 프로젝트 폴더를 만들 때 부여된다. 그러면 이 모든 작업이 마쳐져야(적어도 Merge까지는 도달해야), 서류 생성이 가능해짐을 알 수 있다.

시트 특정 위치에 값을 넣고, 서류를 완성한 뒤 PDF로 export하는 로직을 구현하기 위해서는 Apps Script를 써보기로 한다. sampleID와 저장될 위치 folderID를 외부로 부터 받는 방법은, 스크립트에서 URL을 통해 넘어오는 GET Parameter를 사용하는 수밖에 없어 보였기 때문이다.

GET Parameter는 흔하게 보고 알 수 있는 값이다. https://어쩌고 입력하는 URL에 ?를 붙이고 쭉 이어붙는 값으로 아래 메잌주소를 보면, cleanser로 분류되는 카테고리의 제형카탈로그에 접근했음을 알 수 있다. 페이스북 마케팅 추적처럼 의미를 알 수 없는 랜덤문자를 쓰는 경우도 있고, 메잌처럼 자명하게 쓰는 경우도 있다.

아무튼 GET Parameter로 정의되는 sampleID와 folderID 두 개를 받아서 sampleID를 이용해 특정 시트의 양식에 채운 뒤, 완성된 시트를, PDF export해서 구글 드라이브 folderID에 채우는 코딩을 해봤다. 서류를 생성하려는 사람들은 이 Apps Script의 실행코드+?sampleID=blarblar&folderID=blarblar로 원하는 서류를 원하는 위치에 저장할 수 있다.

처음에 20줄 정도 직관적으로 코딩을 했고, 에러가 났다ㅎㅎ

s8번 샘플을 입력하고 s8번 샘플과 관련한 서류가 저장돼야하는 폴더 아이디를 입력했는데,

해당 폴더에 가보면 s7번 샘플에 대한 서류가 저장돼 있고 그런것이다.

그래서 ChatGPT에게 코드를 보여주면서 에러메시지를 알려줬다. 45초 동안 생각하고 다음과 같이 답을 줬다.

그리고 60줄짜리 코드를 뱉어줬다.

아! 참 싶어서 PDF생성 완료시 액션도 추가해달라고 했더니 15줄이 추가됐다.

그리고 HTTP 429 오류가 났다.

그리고 150줄짜리 코드를 뱉어줬다..

150줄짜리 코드는 또다시 에러를 냈다.

그리고 230줄짜리 코드가 나왔다.

이대로 끝났으면 좋았을텐데..ㅎ 또다시 에러가 났다.

그리고 270줄짜리 코드가나왔고 나는 "아직도 안되는디"라고 말했다.

또 코드가 나왔고 실행해보니, ERROR: 문서의 모든 시트를 삭제할 수 없습니다. 에러가 나왔다.

그리고 VLOOKUP이 적용되지 않는 문제도 해결되지 않았다.

느낌상 멈춰야할 것 같아서 60줄 정도 코드, 두번째 레슨정도로 돌아갔다ㅎ

함수 부를 때 좀 기다리게 하는 코드 한줄을 추가하고 실행환경을 바꿔 문제를 해결하고 배포했다.

아마 내가 스스로 60~70줄을 짜고 디버그를 하려면 몇시간 썼어야 할거 같은데, ChatGPT로 30~60초 생각할 시간을 주고 5번 정도를 반복해서 스크립트 배포까지 한시간이 안 걸린 것이다. 개발을 기획하는 사람이 이리저리 시간을 많이 쓰며 했어야 할 비정식 구현을 1/3~1/5로 줄여주는 느낌!

가장 강점으로 느낀 건, 코딩 같지도 않게 코드를 얻는 동시에, 배경지식과 사고력을 이용하면 더 빠르게 방법을 찾을 수 있다는 점이다. ChatGPT가 더 많고 많고 긴 코드를 뱉어내기 전에 적당히 멈춰서 빨리 해결할 수 있었던 이유는 내가 솔루션을 알았기 때문인 것 같긴하다. 누군가 ChatGPT의 도움을 받는다고 가정할 때도 천공카드 101010부터 코딩을 했던 교수님들이 가장 정확한 물음으로 draft 코드에서 정확한 솔루션을 빠르게 찾아낼 것 같은 느낌. 반대로 초보자에게는 못하던 코딩을 코딩less하게 코드를 얻을 수 있게 한다는 점에서 장벽을 넘어주는 거 같고.

요컨대, AI는 중간지대를 탁월하게 채워주고 개발기획(더 폭넓게는 개발서포트..?)을 도와준다. AI로 코딩하려면 컴퓨터를 더 전문적으로 알거나, 아예 전혀 모르고 비지니스 맥락만 아는게 좋지 않겠나. 하지만 그 중간에서 뭔가를 개발하며 스타트업을 하고 있는 우리팀은 중간지대 전문가로 스터디를 해야겠다고 생각했다!