나는 비개잘자다. 비엔지니어다. 그냥 기획자였고, 편집자였고, 테크니컬라이터였다. 그리고 지금은 시스템 운영자(?) 느낌이 첨부된 기술(활용) 전반을 책임지고 있다.
조각의 시작일까
우연히 그동안 몸담았던 업계와 직무와 내 책상의 자리가 개발자 모니터의 검은 배경과 흰 글자가 매우 잘 보이는 자리였다.
이후에는 편집했던 콘텐츠에 개발 관련 내용이 많았고, 직접 외우거나 익혀서 쓰진 못했지만 보고 따라 하는 건 크게 어렵지 않았다.
아마도 맨 처음 만들었던 대고객용 공개 웹페이지는 부트스트랩 템플릿으로 만든 HTML 페이지였던 것으로 기억한다. 그때는 로컬에서 작업하고 FTP로 파일을 복붙해서 올렸었다. 내가 창업한 회사를 소개하는 페이지였는데, 지금도 그 홈페이지 파일은 남아있다. 어차피 `index.html` 파일 이외 이미지 몇 개와 부트스트랩 파일뿐이니, 보관할 파일 자체가 양이 많지 않다. DB도 없으니까... 그때 처음으로 웹 호스팅 업체에 가입해서 도메인도 사보고, FTP로 파일을 올려보기도 했다. 직접 내 카드를 AWS나 GCP에 등록해서 인스턴스 발급도 해봤고, 도메인도 사봤고, 구글 워크스페이스 세팅도 해봤다.
그땐 사실 웹페이지가 돌아가는 것보단, 아두이노 작업에 더 집중했고 시간도 더 많이 넣었었다. 지금 돌이켜보면 우물 안 개구리였다. 대학교때 깔짝깔짝 수강했던 C++이 왜 HTML보다 자신 있었던 걸까. 이후로 다시는 C++을 만질 일은 없었다. 그냥 아두이노 작업을 위해 만든 코드 파일은 잔뜩 남아있고, 그때 그 하드웨어 킷만 구하면 다시 재현은 해볼 수 있을 만큼 아직도 기억은 난다. 근데 다시 만질 일은 안 생기더라.
조각이 두 개가 되고, 세 개가 되고...
다시 내 손에 떨어진 미션은 압축 파일과 DB 파일 하나씩이었다. 워드프레스 사이트 파일이라면서 다시 올려서 쓰면 된다고 전달받고 그 이상의 정보는 받지 못했다. 애초에 줄 수 있는 것도 더 없었을 것이다.
워드프레스는 재미 삼아 윈도우PC에서 설치했었는데, 압축 파일 이름 자체가 윈도우에서 풀면 안 되게 생겼었다. 아마 `tar.gz` 였던 것 같다. 윈도우에서 압축을 풀면 파일 이름이 깨져서 이상하게 풀렸었다. 어떻게 했었는지 상세히 기억나진 않지만, 구글링의 연속이었다. 찾고 붙이고 찾고 붙이고. 그러다가 마지막에 복구한 상태는 절대 살릴 수 없는 이미지 파일 한 뭉치 가득과 포스팅 한 묶음이었다.
최대한 빨리 복구하는 게 목표였으니, 그냥 포기했다. 살릴 수 없거나 갈 길 잃은 이미지는 그냥 포기했다. 살릴 수 있는 것, 클릭할 수 있는 것만 남겼다. 기획자로 살았던 내 철학은 클릭할 수 없는 버튼은 존재하지 않거나 비활성화로 보여야 한다는 것이었다.
(나중에 살리지 못한 포스트와 이미지 묶음은 쓸데없는 외적 분란(?)을 야기하긴 했지만, 어쨌든 그때는 그렇게라도 복구하는 게 최선이었다.)
그렇게 뭔가 지식으로 정리되지 못한 조각이 또 생겼다.
다시 새 웹빌더를 설치하고 개편하면서 사이트를 많이 정리했다. 새로 콘텐츠를 계속 업데이트하는 팀원도 생겼고, 서버 안에 들어가서 파일을 열고 수정하는 것도 점점 익숙해졌다. 그러던 어느 날 세상에 WSL이 나왔다.
더 이상 putty를 쓰지 않아도 됐다.(물론 다시 또 몇년이 지나, putty를 다시 만났지만...) WSL로 서버에 접속해서 작업할 수 있었던 자체가 너무 행복했다. 왜 편집자가 그거에 행복해하는진 아이러니하지만, 그때는 정말 행복했다.
그리고 윈도우 터미널이 다시 태어났고, 이제는 윈도우 터미널을 실행하고 WSL2로 우분투에 들어가서 다른 서버에 `ssh`로 접속한다. 맥은 불편해해도, WSL로 돌아가는 터미널 화면 속 우분투는 어색하지 않다.
요즘 AI에서 뭔가 찾으면 리눅스 편집기를 기본으로 `nano`를 넣어주는데, 나는 `nano`보다 `vi`가 익숙하다. 첫 만남이 `vi`였고 그냥 계속 `vi`만 버릇처럼 썼다.
DB도 들어가서 SQL을 직접 쳐서 데이터를 조회하거나 업데이트를 해본 적이 있다. 예전엔 DB툴 중 워크벤치를 썼었는데 요즘은 DBeaver를 쓰고 있다. DBeaver를 주로 쓴다.
결국 이 조각조각은 모아보면, 서버를 발급받아 워드프레스를 설치하고 운영하는 정도의 수준이 된다. 물론 매번 할 때마다 시행착오를 겪었지만, 그때마다 구글링을 통해 문제를 해결했다. (혹은 메시지 보내서 물어볼 지인이 꼭 있었다.)
어떤 조각은 완성된 퍼즐이 되기도 했다.
단편적인 명령어와 기능만 계속 썼기에, 조금만 복잡하거나 2개 이상의 명령어를 조합해야 하는 상황이 되면, 구글링이 필요했다. 리눅스 명령어든 SQL이든...
종종 CSS나 PHP 코드는 뭔가 문법을 정확히 알고서 쓰는 것이 아니라, 기존 파일의 생긴 모양과 패턴을 토대로 구글링한 것과 조합해서 경우의 수를 실행하며 고쳤다. 근데 그게 되더라. 일단 됐으면 좋은 거라며, 그렇게 고쳐서 운영해 왔다. (혹은 이때도 메시지 보내서 물어볼 지인이 꼭 있었다.)
협업툴이나 커뮤니케이션 툴도 마찬가지였다. 구글 워크스페이스, MS 365, 슬랙, 트렐로, 지라, 컨플루언스 외 많은 서비스를 계속 열어보고 환경설정 하기를 반복했다. 필요한 기능은 구글링해서 찾아보고, 익혀서 쓰는 식이었다.
그런데 이때부턴 이 조각들이 조금씩 모이면서 남들에게 설명하고 전파할 수 있는 수준이 됐다. 내가 직접 만든 서비스가 아니라서 계속 서비스 업데이트를 팔로우해야 했지만, 기본 동작을 위한 개념과 방침은 거의 바뀌지 않았기에 그걸 익히는 건 크게 어렵지 않았다. 과감하게 고객센터에 영어로 문의도 남겨보고, 피드백도 남겨봤다. (남기고 나서보니 그 회사는 독일회사라 보낸 나도 어설픈 영어였지만, 답변을 준 그들도 어설픈 영어였었다.)
남은 조각은 ChatGPT가 채우기 시작했다.
ChatGPT는 모두에게 그렇겠지만, 내게도 엄청난 전환점이었다.
사실, 초기엔 구글링을 줄여주진 못했다. 단편적인 명령어와 기능을 조합하는 경우의 수를 줄여줬다. 몇몇 부분은 초기에도 잘 대응해 줬다. 내가 쓰던 CSS는 엄청난 애니메이션이 있진 않았다. 그래서 ChatGPT에게 물어보면 바로 답변이 나왔다.
물론 CSS ID나 CSS Class까지 조합하는 부분은 내 몫이었지만, 그래도 에러 나지 않는 문법을 한 번에 완성해 주는 것만으로도 엄청난 도움이 됐다. 결정적으로 나는 아직도 CSS 선언자를 거의 못 외운다. `margin: 10 10 10 10`일 때 뒤에 나오는 숫자의 순서는 여전히 헷갈린다. 누가 왜 그 순서로 정한 건지도 모르고...
SQL은 조금 더 예술이었다. 내가 필요로 하던 쿼리는 쿼리 타임이 오래 걸리거나 매우 복잡한 조합이 필요한 쿼리는 아니었다. 적당한 GROUP BY와 JOIN을 쓰는 정도였다. 그리고 주로 쓰던 건 그냥 테이블 조회와 업데이트 그리고 DB 백업과 복원 정도였다.
ChatGPT는 초기에 셸 스크립트도 잘 만들어줬기에, DB 백업과 복원 스크립트를 만들어서 실제 업무 프로세스를 줄여주기도 했다. DB 백업과 복원은 매번 명령어를 쳐서 했었는데, 스크립트를 만들어서 실행하기만 하면 되니까 훨씬 편했다.
그렇게 반년쯤 흘렀나... ChatGPT가 업데이트를 몇 번 거친 후, ChatGPT와 PHP 파일을 같이 짜기 시작했다. PHP는 내가 패턴을 벗어나면 수정하지 못하던 영역이었다. 초기 ChatGPT가 주는 답은 사실 패턴을 파악하고 비교하기가 힘들었다. 그래서 이게 맞는 건지 아닌 건지 넣고 돌려보면 완전히 아닌 결과였고, 그래서 포기했었다. 하지만 업데이트를 거친 후엔 입력량을 더 많이 받아주게 바뀌니 내가 애초에 코드를 많이 넣어주고 수정을 요청하면, 나도 나온 결과에서 어디가 어떻게 수정된 건지 패턴을 볼 수 있었고, 그 패턴을 볼 수 있었기에 ChatGPT가 해주는 설명도 이해가 되기 시작했다.
결국 조각조각의 빈틈을 ChatGPT가 채우기 시작했다. 떨어져 있던 조각은 붙이고, 모자란 부분은 채우고... 결국 혼자 작업할 수 있는 커버 범위가 늘었다.
말 그대로 서비스 자체의 규모가 빅테크나 대기업급의 초대형이 아니라면, AI가 어시스턴트로 붙은 상태로 대부분 커버할 수 있게 됐다.
Garbage in, Garbage out
위에서 말했던 시기들은 어느덧 다 3년이 넘은 과거의 이야기다. 그때도 지금도 AI에게 묻고 받은 답을 실행해서 원하는 결과를 보지 못하면 성능이 좋지 못한 AI라고 다들 말을 한다. 하물며 이젠 LLM 서비스끼리도 갈아타고 비교할 수 있는 시대가 됐다.
그때마다 특정 AI의 성능이 좋지 못하다고 말하는 사람들도 많아졌다. 하지만 나는 그렇게 생각하지 않는다. AI는 내가 묻는 질문과 내가 주는 정보에 따라 답이 달라진다. 내가 묻는 질문이 명확하지 않거나, 내가 주는 정보가 부족하거나, 내가 원하는 결과를 정확히 표현하지 못한다면, AI가 좋은 답을 내놓기 어렵다.
혹자들은 제로 샷(Zero-Shot), 퓨 샷(Few-Shot), 롤 프롬프팅(Role Prompting) 같은 네이밍도 붙이더라. 결국 입력할 정보를 어떤 방식과 패턴으로 주느냐의 문제다. 물론 이 정보를 받아주는 AI의 성능도 중요하다. 토큰 소화량이라거나, 연산속도라거나...
그래서 나는 중요한 문제를 해소하려고 할 땐 AI에게 묻기 전에, 내가 묻고자 하는 질문과 내가 주고자 하는 정보를 최대한 명확하게 정리하려고 노력한다. 그래야 AI가 더 좋은 답을 내놓을 수 있다. 결국 AI는 "Garbage in, Garbage out"이다.
나는 제미나이에 Gems를 등록해서 쓰고 있다. 2026년 2월 기준, 다른 개발자들이 말하는 에이전트 코딩이니 뭐니 하는 수준까지 가지도 못했다. 그냥 묻고 받은 답 확인하는 수준에서 아직 그치는 수준이다. 그런데 이것조차 제대로 활용하지 못하는 이들도 아직 많은 것 같다. 안타깝다. 누군가는 AI 에이전트를 수십 개 돌린다고 자랑도 하는데... 물론 수십 개 돌린다고 자랑하는 이들이 돌리는 에이전트가 그만큼까지 필요한 건지 제대로 하는 건지는 나는 알 방법이 없다. 그냥 그렇게 쓰는 방법이 있구나 할 뿐이다.
새 조각이 등장했다. OpenClaw.
애초에 2026년이 시작할 때, 아직 내가 익숙하지 못한 깃허브와 VSCode 등과 익숙해자고 마음 먹었다. 제미나이에 이미 그걸 내게 가르칠 역할을 하나 넣어놨고, 하나씩 해보는 중이다. 뭔가 조각으로 남아있는 파편을 줄일 수 있으리라 생각했는데, 지난주부터 내 귀에 들려온 그 이름은 "OpenClaw".
그리고 정리를 시작하지도 못했는데 숙제가 더 쌓여가는 기분이다. OpenClaw를 설치하고 세팅하는 과정에서 이미 무수한 새 조각이 쌓였다. 휘발되기 전에 이곳에 남기도록 의지를 다져본다.