AI가 많은 일을 해주는 시대, 우리는 무엇을 알아야 할까

AI를 활용한 서비스를 개발하고 있어요. 직접 만든 앱을 출시하고 사이트를 운영하면서, 요즘은 AI와 함께 일한다는 게 어떤 의미인지 자주 생각하게 됩니다.

개발을 시작한 건 정말 우연한 계기였어요. 어느 날 웹사이트 만드는 법을 알려주는 무료 영상 강의를 보게 됐는데, 재미있어 보여서 따라 해봤습니다. 화면에 나오는 코드를 입력하니 정말 웹사이트가 만들어지더라고요. 조금 고치면 화면도 달라졌어요. 제가 늘 사용하기만 하던 것들을 저도 만들 수 있다는 게 신기했습니다.

그러다 AI를 공부에 쓰기 시작했어요. 처음에는 제 생각을 읽고 대답해주는 것처럼 느껴졌습니다. 검색어를 넣고 알맞은 문서를 찾아다니던 것과는 달랐어요. 잘 모르겠다고 하면 다시 설명해줬고, 거기서 생긴 궁금증을 물으면 이야기가 이어졌습니다. 물어볼 게 끝도 없었는데, 받아주는 쪽도 지치지 않았어요.

배울수록 욕심이 생겼습니다. 개발을 더 잘 알고 싶기도 했고, 한편으로는 공부가 충분히 끝날 때까지 기다리지 않고 제 사이트부터 갖고 싶었어요. 그래서 두 가지를 같이 했습니다.

공부할 때는 자바와 스프링의 코드가 왜 그렇게 동작하는지 계속 물었어요. 이 어노테이션은 무슨 역할인지, DTO는 왜 따로 만드는지, 강의를 따라 입력한 코드에서 이해되지 않는 것을 하나씩 짚었습니다. 그런데 제 사이트를 만들 때는 태도가 전혀 달랐어요. 무엇을 만들고 싶은지만 말하고, 어떻게 만드는지는 거의 전부 AI에게 맡겼습니다. 한쪽에서는 원리를 알고 싶어 하면서, 다른 한쪽에서는 결과만 빨리 보고 싶었던 거죠.

그렇게 만든 첫 사이트가 devcom.kr이었어요. 개발자들이 이야기를 나눌 수 있는 커뮤니티를 만들고 싶었습니다. 지금 다시 시작한다면 그렇게 구현하지는 않을 것 같아요. 물론 지금도 다 뜯어고치고 싶습니다. 공부를 할수록 고치고 싶은 목록도 같이 늘어나더라고요.

지금 생각해보면 ‘나만의 사이트를 갖고 싶다’는 목표에 마음이 쏠려 있어서, 거기까지 가는 중간 과정은 참 신경 쓰지 않았어요. AI가 된다고 하면 되는 줄 알았고, 화면에 기능이 나타나면 다음 기능을 만들었습니다. 제가 무엇을 이해하지 못한 채 넘어가고 있는지도 잘 몰랐어요.

그런데 시키는 대로 해도 안 되는 일이 자꾸 생겼습니다. 이렇게 배포하면 된다고 해서 했는데 안 되고, 이렇게 수정하면 된다고 해서 고쳤는데 다른 곳이 깨졌어요. 다시 물어보면 “죄송합니다”와 함께 새로운 설명이 나왔습니다. 사과는 충분히 받았는데, 제가 무엇을 잘못 이해했는지는 여전히 흐릿했어요.

사이트 규모에 비해 자산을 관리하는 곳이 여러 군데로 나뉘어 참조가 깨지기도 했습니다. 공개 커뮤니티와 그룹 커뮤니티에는 같은 오픈소스 텍스트 에디터를 쓰면서도 각각 따로 붙여두었어요. 비슷한 것을 고치려면 여러 곳을 손대야 했죠. 처음에는 그것도 그렇게 하는 게 맞다는 설명을 믿었습니다. 에디터 자체가 어떻게 동작하는지, 어디까지 함께 쓰고 무엇을 구분해야 하는지 판단할 기준이 없었으니까요.

뒤늦게 돌아보니, 정답이 하나로 정해져 있지 않은 문제에 정답이 있다고 생각했던 것 같아요. 어떤 구성이 가능하다는 말과 지금 제 상황에 그 구성이 적절하다는 말은 다른데, 당시에는 그 차이를 잘 몰랐습니다. 혼자 운영한다는 것, 지금의 규모, 자주 바꾸고 싶은 부분, 감당할 수 있는 복잡성 같은 배경도 충분히 전달하지 않았고요.

그때와 지금의 차이를 가장 실감하는 건 코드를 볼 때보다, 무언가를 시작하려고 할 때입니다.

예전에 심리상담 앱을 만들어 구글에 출시하려다가 심사에서 거절된 적이 있어요. 의료 관련 앱으로 분류되는 문제와 개발자 계정 요건을 만나게 됐습니다. 처음에는 AI가 안내하는 대로 이름을 바꾸고, 관련 표현을 고쳤어요. 백엔드의 DTO 이름까지 바꿨습니다. 지금 돌아보면 심사 문제와 어떤 관계가 있는지도 확인하지 않고 꽤 많은 곳을 고친 셈이에요.

이후 새 앱으로 등록했을 때는 심사를 통과했습니다. 그 경험만으로 어떤 변경이 결정적인 이유였다고 단정할 수는 없어요. 다만 당시의 저는 거절 사유와 실제 심사 대상을 먼저 좁혀보는 대신, 제안받은 수정을 전부 하는 쪽으로 움직이고 있었습니다.

사주 앱도 출시해봤어요. 그래서 지금 누군가 사주 앱을 만들겠다고 하면, 어떤 기능을 넣을지보다 어느 플랫폼에 출시할지, 해당 유형의 앱에 어떤 심사 조건이 있는지부터 확인하게 됩니다. 코드가 동작하는 것과 사람들이 실제로 내려받을 수 있는 것은 다른 문제라는 걸 겪어봤으니까요.

앱을 운영하면서는 업데이트 방식도 다르게 보였습니다. 네이티브 앱으로 만들고 나니 바꾸고 싶은 것이 생겨도 빌드와 배포, 필요한 심사 과정을 생각해야 했어요. 처음에는 네이티브의 성능이 좋다는 설명이 크게 들렸는데, 나중에는 ‘내 앱의 사용자가 그 차이를 느끼는가’와 ‘내가 얼마나 자주 바꾸고 싶은가’가 더 크게 다가왔습니다. 웹 중심으로 만들었으면 어땠을까 싶기도 했어요. 물론 그것도 모든 제약을 없애주는 답은 아니겠지만요.

리소스가 무한하다면 좋은 선택은 많겠죠. 현실의 저는 혼자 관리할 수 있는 범위가 있고, 먼저 확인하고 싶은 것이 있고, 자주 바꾸고 싶은 부분이 있습니다. 장점 목록을 아는 것과 그중 지금 필요한 장점을 고르는 것은 꽤 다른 일이었어요.

그래서 같은 AI를 쓰는데도 결과가 다른 이유를 생각하게 됩니다. AI는 저보다 훨씬 많은 기술을 알고 있어요. 그런데 그 지식이 제 상황에서 어떤 의미인지는 제가 더 구체적으로 알려줘야 했습니다. 사용자도 많지 않은 제 서비스에 Redis가 제안됐을 때, 예전에는 좋은 기술이라는 설명만 들었습니다. 지금은 어떤 병목을 해결하려는 건지, 운영 부담을 늘릴 만큼 필요한지부터 물어볼 것 같아요. 사용자 수 하나만으로 정할 일은 아니지만, 적어도 필요를 확인하지 않은 채 넣지는 않겠죠.

제가 말하는 도메인 지식은 이런 감각까지 포함합니다. 이 일을 해봤기 때문에 먼저 확인하는 것, 설명에 빠진 조건을 알아차리는 것, 그럴듯한 장점이 지금은 별 의미가 없다는 걸 판단하는 것들이요. AI의 지식보다 더 많이 외우게 돼서 달라졌다기보다, 그 답을 제 현실에 놓고 볼 수 있게 된 쪽에 가까워요.

이런 질문을 받으면 저는 피라미드를 짓는 일에 빗대어 설명하는 편입니다. 설계도 필요하고, 사람과 자원을 배분하는 일도 필요하고, 실제로 돌을 옮기는 일도 필요하잖아요. 예전에는 각 역할을 맡은 사람들을 모아야 했다면, 지금은 한 사람이 AI에게 여러 역할을 맡기며 훨씬 많은 일을 진행해볼 수 있게 됐다고 느껴요.

그렇다고 제가 손을 놓고 있어도 되는 건 아니었습니다. 설계를 맡겨도 설계가 목적에 맞는지는 봐야 하고, 자원을 나눠 맡겨도 어디가 막혀 있는지는 알아야 해요. 돌을 잘 옮기도록 시키려면 적어도 무엇을 조심해야 하는지 정도는 알아야겠죠. 여러 일을 맡길 수 있게 된 만큼, 그 사이를 이어서 판단하는 일이 제 쪽에 남는 것 같았습니다.

한 분야를 깊게 아는 사람의 가치가 줄었다는 뜻은 아니에요. 오히려 깊이 알아야만 보이는 문제가 있을 겁니다. 다만 저처럼 혼자 아이디어를 제품으로 만들어보는 사람에게는, 여러 분야의 지식을 어느 정도 이해하고 필요한 전문성을 연결하는 능력도 점점 중요해지는 것 같아요. 모든 일을 직접 잘하는 것과, 어떤 일을 맡기고 무엇을 확인해야 하는지 아는 것은 다르니까요.

이렇게 생각하다 보니, 무언가를 시작하는 순서도 바뀌었습니다.

저는 예전보다 코드가 싸졌다고 느껴요. 서비스 운영이나 유지보수까지 공짜가 됐다는 이야기는 아닙니다. 머릿속의 아이디어를 일단 돌아가는 형태로 만들어보는 데 필요한 비용이 제게는 크게 낮아졌다는 뜻이에요. 그래서 처음부터 많은 기능을 채우기보다, 이 아이디어가 실제로 쓸모 있는지를 먼저 확인하는 데 더 마음이 갑니다.

작은 PoC를 자주 해보고 싶어졌어요. PoC는 아이디어의 핵심이 실제로 가능한지 작게 만들어 확인하는 과정입니다. 제가 증명하고 싶은 것 하나를 먼저 증명해보는 거예요. 그게 되면 거기에 살을 붙이면 되지 않을까 싶었습니다.

가령 반복되는 문서 검토를 AI가 도와줄 수 있는지 궁금하다고 해볼게요. 완성된 서비스에는 로그인도 필요하고, 권한별 화면도 필요하고, 관리 기능도 필요하겠죠. 하지만 처음 확인하고 싶은 것은 AI의 검토 결과가 실제로 쓸 만한가 하는 점입니다. 예시 문서로 그 부분부터 확인할 수 있는데, 주변 기능을 다 만들고 나서야 핵심 결과가 마음에 들지 않는다는 걸 알게 되면 순서가 아쉽잖아요.

실제 사람들의 정보나 업무에 적용할 때 필요한 보호 장치는 당연히 갖춰야 합니다. 다만 작은 검증을 할 때까지 완성된 서비스의 모든 기능을 먼저 갖출 필요는 없다는 생각이에요. 무엇을 확인하려고 시작했는지 잊지 않는 게 중요해졌습니다.

지금 운영하는 baeksang.dev도 그렇게 시작했어요. 첫 커뮤니티를 만들었던 때보다 훨씬 나중의 이야기입니다. 매번 여러 사이트를 돌아다니며 AI 뉴스를 찾는 게 귀찮았어요. 영어 원문까지 읽으려니 시간도 많이 들었고요. ‘이걸 모아서 내가 읽기 편하게 정리해줄 수 없을까’라는 작은 불편이 출발점이었습니다.

처음부터 지금의 사이트를 기획한 건 아니었어요. 뉴스를 수집하고 정리한 결과를 제가 읽어봤을 때 괴리감이 없는지, 실제로 읽을 만한지가 먼저였습니다. 수집이 실패하는 일이 생기니 로그를 남기기 시작했고, 계속 쓰면서 인증과 관리자 페이지, 소개 같은 기능도 붙었습니다. 지금은 중요한 기능들이지만, 처음의 질문은 훨씬 작았어요.

처음에는 저를 위해 만들었는데, 공유하고 나니 매일 읽는 분들이 생겼습니다. 잘 읽고 있다는 메일도 받았어요. 제 귀찮음을 줄이려고 시작한 것이 누군가의 하루에도 들어가게 된 셈이라, 그런 연락을 받으면 아직도 좀 신기합니다.

진행하다 멈춘 아이디어도 많아요. 그래도 그 과정에서 ‘여기까지는 구현할 수 있구나’라는 감각이 남았습니다. 지금 운영하지 않는다고 해서 그 가능성까지 사라지는 건 아니더라고요. 나중에 비슷한 문제가 생기면 무엇을 어떻게 설명해야 하는지, 어디부터 확인하면 되는지 조금은 알고 다시 시작할 수 있으니까요.

그렇다고 이제 AI에게 맡기면 언제나 제 마음에 들게 나오는 건 아닙니다. 기능은 동작하는데 실제 사람이 쓰면 어색할 것 같은 흐름도 있고, 자동으로 검증을 돌려도 제가 직접 보면 걸리는 부분이 있어요. 마지막에 읽어보고 사용해보는 일은 여전히 제 몫으로 남아 있습니다.

원하는 결과가 나오지 않았을 때도 예전과는 조금 다르게 보려고 해요. 제가 요구사항을 충분히 설명했는지, 확인할 조건을 명확히 줬는지, 중간에 잘못된 방향을 발견할 기회가 있었는지부터 돌아봅니다. AI가 할 수 없는 문제도 있겠지만, 제가 작업 환경이나 검증 과정을 바꿔서 나아진 경험이 있었거든요. 실패를 전부 제 설명 탓으로 돌리기보다는, 제가 바꿀 수 있는 부분부터 살펴보는 셈입니다.

요즘 이야기하는 하네스도 제게는 그런 맥락이에요. AI가 사용할 도구와 지침, 결과를 확인하는 과정을 갖춰두는 것. 한 번에 끝까지 맡기기보다 어느 조건을 통과해야 다음으로 갈지 정해두는 것도 포함됩니다. 좋은 문장 하나로 모든 것이 해결되기보다는, 잘못된 방향으로 갔을 때 알아차리고 돌아올 수 있게 만드는 일이 필요하더라고요.

요즘 가장 많이 고민하는 건, 제가 생각한 것과 실제로 만들어진 결과 사이의 거리를 어떻게 줄일 수 있을까 하는 거예요.

분명히 설명했다고 생각했는데 결과를 보면 어딘가 다를 때가 있습니다. 기능은 있는데 사용 흐름이 어색하거나, 제가 중요하게 생각한 부분보다 다른 곳에 공이 더 들어가 있기도 해요. 그러면 제가 당연하게 여겼던 조건을 설명하지 않았는지, 중간에 확인해야 할 것을 마지막까지 미뤄둔 건 아닌지 돌아보게 됩니다.

이런 경험이 쌓이면서 원하는 결과만 말하는 것에 더해, 제가 무엇을 중요하게 보는지도 전달하려고 해요. 지금 확인하려는 것은 무엇인지, 어떤 복잡성은 아직 필요하지 않은지, 어디까지 됐을 때 다음 단계로 넘어가도 되는지 같은 것들이요.

처음부터 제 생각을 빠짐없이 전달하는 방법이 있는지는 아직 모르겠습니다. 지금은 작은 결과를 먼저 보고, 차이를 설명하고, 그 과정에서 알게 된 기준을 다음 작업에 남기는 식으로 조금씩 맞춰가고 있어요. 제 페르소나를 만들고 싶다는 생각도 말투를 닮게 하는 것보다는, 이런 판단 기준을 함께 갖고 일하고 싶다는 마음에 가깝습니다.

아이디어를 놓치지 않으려는 방식도 조금 바뀌었어요. 폰과 컴퓨터에서 늘 연결해두는 에이전트에게 생각이 떠오를 때 바로 메모를 남기고, 확인할 일을 시킵니다. 음성으로 이야기할 때도 있지만, 중요한 건 음성이라는 방식보다 아이디어가 휘발되기 전에 작은 행동으로 이어진다는 점인 것 같아요.

저는 AI를 쓰는 일이 수영과 좀 닮았다고 느낍니다. 교본을 읽는 것과 물에 들어가 직접 물장구를 쳐보는 것은 다르잖아요. 설명을 들을 때는 알 것 같다가도, 제 문제를 가지고 해보면 다른 곳에서 막힙니다. 몇 번 해봐야 어디까지 맡길 수 있고 어디서 제가 봐야 하는지 조금씩 감이 생겨요.

그래서 아직도 제가 모르는 가능성이 많을 거라고 생각합니다. 제가 안 된다고 여긴 일을 누군가는 이미 해결했을 수도 있고, 반대로 쉽게 될 줄 알았던 일이 제 상황에서는 어려울 수도 있겠죠. 누구에게나 맞는 사용법을 찾기보다, 제 주변의 작은 불편을 하나씩 가져와 직접 부딪혀보는 쪽이 지금의 저에게는 잘 맞았습니다.

돌아보면 운이 좋았어요. 우연히 본 영상이 재미있었고, 배우고 싶고 만들고 싶은 것이 많아지던 시기에 AI를 만났습니다. 덕분에 머릿속에만 뒀을지도 모르는 것들을 실제로 만들어볼 수 있었어요.

예전 코드를 보면 여전히 고치고 싶은 곳이 많습니다. 다만 이제는 그 안에서 당시의 제가 무엇을 몰랐고, 무엇을 만들고 싶어 했는지도 보여요. 그때는 믿고 넘어갔던 곳에서 지금은 질문을 하나 더 할 수 있게 됐고요. 앞으로도 만들고 고치다 보면, 지금은 보이지 않는 것들이 또 보이겠죠.

개발을 시작한 이야기를 하려다가 요즘의 고민까지 길어졌네요. 한 번쯤은 제가 어떤 과정을 지나왔고 무슨 생각을 하고 있는지 남겨보고 싶었습니다.

끝까지 읽어주셨다면, 두서없는 긴 이야기에 시간 내주셔서 감사합니다.