AI 시대의 직관과 취향

AI 시대의 직관과 취향
AI가 반복을 대신 해주면, 어디서 경험을 쌓나..

AI 코딩이 발전할수록 나의 가치가 무엇인지 고민하게 됩니다.

최근에 Google Antigravity나 Claude Code 같은 새로운 "Agentic" Coding 도구들을 업무와 취미 프로젝트에 동시에 사용해보고 있는데, 정말 매일 기존의 관념이 부서지는 경험을 하고 있습니다.

보통 가족과 시간을 보내느라 바쁜 주말에 한 시간 정도 여유가 생겨서 장보기 영수증 기록 툴을 만들어보기로 했습니다. 보통은 한 시간이면 뭔가 시작하기도 애매한 시간인데, Claude Code (CC)를 너무 써보고 싶었거든요.

Claude가 영수증 이미지를 읽고, 품목을 분류해서 가격, 수량 등을 DB에 저장하는 아주 간단한 툴이었죠. 나중에 이번 달 고기에 얼마 썼어?, 어느 마트가 쌀이 제일 싸?, 이 만두 가격 괜찮은 거야? 같은 질문을 할 수 있도록 하고 싶었습니다.

제 경험상, 이건 SQLite DB와 함께 MCP(Model Context Protocol) 서버를 만들면 되겠다 싶어서, 간단히 알아보니 Claude Desktop이 MacOS에서 로컬 MCP 서버에 연결할 수 있다는 걸 알게 됐죠.

좋아, 시작해볼까! 첫 프롬프트를 작성하기 시작습니다. 마치 디자인 문서(Design Doc)를 작성하는 느낌이었습니다. 원하는 기능이 뭔지, 입력과 출력은 뭔지, 지원하고 싶은 최종 사용 케이스가 뭔지 정리했죠. 그리고 엔터를 눌렀습니다.

Boom! CC가 MCP 서버를 쓰고, 서버를 시작하는 명령까지 실행해, 나오는 에러를 보고 수정하고, 코드를 완성했습니다. 저는 코드를 리뷰하고 몇 가지 제안을 했을 뿐익도요. 약 5번의 대화만에 MCP 서버가 완성되어 Claude Desktop에서 돌아가기 시작했습니다.

첫 엔터를 누른지 15분 지난 시점. 그 다음 15분 동안은 이 서버를 온라인에 배포해 모바일에서도 쓰고 싶었습니다. Claude가 무료 티어 서비스 몇 가지를 장단점과 함께 추천해줬습니다. 저는 한 서비스가 마음에 들었는데, DB와 서버 노드가 같은 서비스 안에 함께 있으면 나중에 골치 아픈 일이 줄어들 것 같다는 느낌이 들었거든요. 약 20분 후, 서버가 완전히 배포되어 모바일 앱에서 사용할 수 있게 됐습니다.


다음 가족 일정으로 가기 전 아직 15분 정도 남아서, 뭘 더 하면 좋을지 생각해봤습니다. 품목 이름에 Fuzzy String 매칭을 추가하면 도움이 될 것 같아서 이렇게 프롬프트를 입력했죠.

nice, that worked. let's go back to feature development. Should we add fuzzy matching to query item_price or query_spending for robustness?

(대충 새로운 기능 구현해보는게 어떻게 물어보는 내용)


제 대화를 다시 읽어보니 제 자신이 흥미로웠던 건 그냥 구현해!가 아니라 어떨까?라고 의견을 물어봤다는겁니다. 직감적으로 꼭 필요한지 확신이 들지 않았던 상태고, CC의 첫인상이 너무 좋아서 신뢰가 갔었나 봅니다.

그랬더니 CC가 이렇게 말했습니다:

Good question. Currently we use SQL LIKE %term% which handles partial matches but not typos. My recommendation: Skip fuzzy matching for now.Claude is already pretty good at normalizing input before calling tools. If you say "banannas", Claude will likely call the tool with "bananas".

(대충 새로운 기능은 이미 있는거로 충분하니 만들지 말자고 거부하는 내용)

와, 이렇게 "이대로는 충분하다"라는 의견은 좋은 주니어 엔지니어에게 기대되는 부분인데, CC가 이렇게 논리적으로 의견을 내다니!


아마 여러분 중 많은 분들이 이런 새로운 도구들을 저보다 훨씬 더 광범위하고 복잡하게 (그리고 훨씬 일찍) 사용해보셨을 것이라고 생각된다만, 저처럼 본업과 가족 일에 치여서 아직 읽기만 하고 뭔가 해보시지 못한 분들도 있을거라고 생각됩니다.

정말 짧은 한시간이었지만 저는 이 경험이 많은 생각을 하게 만들면서 머리가 열리는 경험이었죠. CC와 잠깐 한시간 일했을 때 마치 매일매일 발전하고 엄청나게 빠르고 똑똑한 인턴을 고용한 것 같았거든요.

그렇다면 나는 이 인턴을 잘 활용하려면 어떻게 해야 할까? 라는 고민이 자연스럽게 들었습니다.

항상 한 단계 더 높은 추상적인 단계에서 놀아야겠구나. 동시에 프로덕트 매니저 (PM), 테크 리드 (tech lead), UX 디자이너처럼

PM은 무엇을 만들지 결정합니다. 테크 리드는 어떻게 설계할지 결정합니다. UX 디자이너는 어떻게 경험이 흘러갈지 결정합니다.

직관


이 셋의 공통점은? 경정을 내려야 한다는 점이죠. 그렇다면 어떻게 "좋은" 결정을 내릴 수 있을까요? 지금까지 제가 본 최고의 의사결정자들은 두 가지를 잘 합니다:

1. 많은 아이디어를 모으고 (diverge),
2. 어떤 것을 적용할지 빠르게 결정합니다(converge)

그리고 직관에 많이 의존합니다. 대부분의 실상황에서는 모든 데이터를 가지고 분석할 시간이 없거나 모든 정보가 손 안에 없을 확률이 높죠.

곰곰이 생각해보면, 제 소프트웨어 엔지니어링에 대한 직관은 20년 이상 직접 짜면서 쌓인 것 같습니다. 공부를 위해, 재미를 위해, 그리고 일을 위해 했던 프로젝트들.
처음 작성했던 코드들의 기억이 아직도 생생합니다. 커맨드 라인에서 만든 블랙잭과 오목 게임, 학교 커뮤니티를 위해 만들고 운영했던 ASP.NET 웹사이트, 첫 유급 인턴십에서 작성한 안드로이드 클라이언트 코드, 대학원 NLP 연구실에서 GPU 1개로 돌렸던 첫 Tensorflow Keras 코드, Google 첫 팀에서 작성한 수많은 데이터 파이프라인, 그리고 최근에 출시한 AI 제품 Pomelli까지.

대학교 2학년 때 들었던 컴퓨터 구조라는 수업이 기억납니다. 어셈블리를 배웠죠. 정말 고대의 언어로 0,1 Bit를 조작해야 했습니다. 그 당시에는 이 수업의 의미를 잘 몰랐던 것 같습니다. 필수과목이라 들었을 뿐이죠. 돌이켜보면, 그 수업이 제 스킬 자체에는 큰 영향을 주지 않았을 수도 있지만, 컴퓨터가 내부적으로 어떻게 작동하는지에 대한 직관을 기르는 데 기여했습니다. 비슷하게, C++은 객체지향 프로그래밍을, Ruby on Rails는 웹 프로그래밍의 기초를 가르쳐줬죠.

취향

취향은 직관의 또 다른 일부분인데, 직접 해보고 디테일을 맞추려고 노력하면서 쌓인다고 생각합니다. 소프트웨어 엔지니어에게 "취향"이 있다고 말하는 게 이상하게 들릴 수 있지만, 소프트웨어 엔지니어링의 일부는 예술의 형태라고 믿기 때문에, 분명히 취향이 존재하고 정답이 없는 상황에서는 중요하다고 생각합니다.

아직까지는 자동으로 생성된 코드를 통해서 취향을 기르는 것은 쉽지 않은 것 같습니다. 적어도 직접 작성하는 것만큼 효과적이지는 않죠. 마치 Spotify 알고리즘에서 나오는 음악만 들었을 때 새로운 음악 취향이 길러지지 않는 것처럼요.

직관과 취향은 자신의 작업을 실제로 하나한 느끼고 호기심이 있어 깊게 파볼 의지가 있을 때 더 효과적으로 쌓이지 않나 싶습니다.

새로운 세대의 소프트웨어 엔지니어

저는 이미 프로그래밍을 시작한지 오래 되었기에 직관과 취향을 쌓을 기회가 많이 있었습니다만, 새로운 프로그래머들이 어떻게 직관과 취향을 기를 수 있을지 살짝 걱정됩니다.

AI가 대신 해줄 수 있는데 디테일을 배워야 할까요?

하지만 그게 바로 함정이 아닐까 싶습니다.

좋은 엔지니어는 스스로 언제 더 낮은 레벨로 깊이 파고들지, 언제 멈추고 높은 레벨에서 머물지 결정할 줄 알아야 합니다. 그리고 직관을 기를 기회를 적극적으로 찾아야 합니다.

어쩌면 이제는 좋은 소프트웨어 엔지니어가 되는 것은 무엇을 아느냐 (지식)보다 어떻게 하느냐 (규율과 철학)가 더 중요한 세상이 되지 않았나 싶습니다.

굳이 안 해도 될 때 깊게 파고 들어 이해하려는 건강한 고집. 어쩌면 코딩을 배우는 것보다 훨씬 더 어렵지 않을까요.

그래도 부정적으로만 생각하는 것은 아닙니다.

어셈블리가 파이썬이 됐다고 우리가 더 나쁜 엔지니어가 된 건 아니었고, 백과사전이 구글링과 위키피디아로 옮겨갔다고 우리 모두가 바보가 된 것도 아니고요.

우리는 항상 새로운 기술에 적응해왔고, 새로운 세대의 엔지니어들은 또다른 차원의 엔지니어링을 만들며 발전해왔습니다.


그럼에도 불구하고 "AI가 어려운 부분을 지름길로 해결해줄 수 있는 세상에서 어떻게 직관을 기를 수 있을까?" 우리 모두 계속 고민해봐야 할 질문입니다.

사실 이건 코딩에만 해당되는 이야기가 아닌 것 같습니다. 작가, 디자이너, 음악가, 많은 지식 노동자 - 반복 경험을 통해 기술과 직감이 쌓이는 모든 분야의 사람들이 같은 질문에 직면하지 않을까요?

Read more

더이상 (인간) 프로그래머는 필요 없다고?

더이상 (인간) 프로그래머는 필요 없다고?

초등학교 미술 시간에 장래 희망을 그려서 교실 뒤에 붙여 놓았던 기억이 납니다. 학교 끝나고 컴키드 라는 학원에 가서 PPT나 나모 웹에디터를 가지고 놀던(?) 저는 "프로그래머"라는 직업을 그려 넣었었습니다. 그리고 그 아이는 지금은 그렇게 프로그래머가 되었습니다. 어쩌면 이 글은 프로그래머를 꿈꾸는 학생 또는 개발팀을 모두 해고하고 LLM 코딩

By Park Ji Ho
AI 코딩 툴을 사용할 때의 나의 원칙

AI 코딩 툴을 사용할 때의 나의 원칙

지난 글에서는 어떤 AI 코딩 툴을 어떻게 쓰는지 공유했었습니다. 이번에는 툴을 계속 사용하면서 머리 속에 쌓인 원칙들을 적어보았습니다. 항상 이러한 생각들을 하며 툴을 사용해야 좀 더 체계적으로, 생산적인 방향으로 일이 진행되는 것 같습니다. 사분면 (Quadrants) 현재 하고 있는 일이 4개의 사분면 중 어디에 있는지 생각한다. * 사분면 1 - 높은 임팩트

By Park Ji Ho
AI 코딩 툴 어떤 거 쓰세요?

AI 코딩 툴 어떤 거 쓰세요?

구글 IO 2023은 제 커리어에서 정말 기억에 남는 순간이었습니다. 구글 CEO 순다 피차이가 무대에서 보여준 데모 코드의 일부는 제가 리뷰했던 코드였거든요. 당시 구글의 플래그쉽 모델이었던 PaLM이 버그를 고쳐줄 뿐만 아니라, 주석을 한국어로도 달아줄 수 있다는 데모였습니다. 당시 Bard(현 Gemini App)가 처음으로 지원하는 외국어로 한국어와 일본어로 발표되기도 했습니다. 이

By Park Ji Ho