AI는 발산에는 강하지만, 원하는 결과로 수렴시키는 건 결국 명세와 검증을 설계하는 사람의 책임이라고 생각해요
AI 교육 서비스를 만드는 개발자는 AI를 어떻게 활용하고 있을까요?
쏘카인드에서 백엔드를 담당하고 있는 김민수님을 만났습니다.
민수님은 클로드 코드를 활용해 여러 작업을 병렬로 분리하고, 각 작업을 독립적으로 구현·검증하는 방식으로 개발을 진행하고 있는데요.
이 방식은 개발 속도를 높이는 데에는 효과적이었지만, 동시에 검수 비용과 컨텍스트 관리라는 새로운 고민을 만들어냈습니다.
동시에 민수님은 단순히 작업 속도가 빨라진 것을 넘어, 개발 방식 자체의 변화를 경험하고 있다고 해요.
특히 AI를 활용하는 환경에서는 기존의 코드 재사용성과 일관성뿐 아니라, "AI가 이해하기 쉬운 구조인가"라는 새로운 기준으로 설계를 다시 바라보게 되었다고 합니다.
AI와 함께 개발하는 환경에서, 개발자는 무엇을 더 고민해야 할까요?
그 변화에 대한 이야기를 들어봤습니다.
Q. 쏘카인드에 합류하게 된 계기가 궁금해요.
첫 직장이었기 때문에 이미 잘 구축되어 안정적인 환경에서 시작하는 것도 고민했어요.
하지만 저에게는 "내가 고민해본 구조를 실제 서비스에서 적용하고 검증해볼 수 있는 환경인가"가 더 중요했어요.
입사 전에는 프로젝트를 하면서 인증 구조를 설계하고, CI/CD나 네트워크 분리 같은 것들을 직접 구성해보면서 단순히 기능을 만드는 것보다 "이 서비스가 어떻게 동작해야 하는지"를 생각해보는 경험을 했어요.
다만 이런 설계들이 실제 서비스 환경에서도 유효한지에 대해서는 검증해보지 못했다는 한계가 있었어요.
그래서 스타트업을 선택하게 됐고, 규모가 작은 조직에서는 백엔드뿐 아니라 서비스 전반을 직접 개선해볼 수 있다고 생각했어요.
쏘카인드는 단순히 맡은 일을 수행하는 것을 넘어, 구조를 고민하고 실제로 적용해보며 검증할 수 있는 환경이라고 느꼈고, 그 점이 합류를 결정하게 된 가장 큰 이유였어요.
Q. AI를 업무에 어떻게 활용하고 계세요?
첫 직장에서 업무를 시작하면서 새로운 기술을 빠르게 익혀야 하는 환경이었고, 자연스럽게 Claude Code를 도입하게 됐는데요. 처음에는 단순히 코드 생성을 보조하는 도구처럼 사용했지만, 점점 개발 과정 전반에 활용하게 되면서 사용 방식도 많이 달라졌어요.
초기에는 기능 단위로 요청을 주고 결과를 받아보는 방식이었는데, 명세가 조금만 부족해도 의도와 다른 결과가 나오는 경우가 많았기 때문인데요.
이 경험을 통해 "AI에게 무엇을 시킬 것인가"보다 "어떤 정보를 얼마나 정확하게 전달하느냐"가 결과를 결정한다는 걸 알게 됐어요.
이후부터는 개발 방식을 처음부터 다시 보게 됐습니다. 기존에는 코드를 어떻게 작성할지에 집중했다면, 이제는 작업을 어떤 단위로 나누고, 어떤 수준까지 명세를 정의할 것인가가 더 중요한 문제가 되더라고요. 그래서 현재는 작업의 성격에 따라 흐름을 나눠서 개발하고 있어요.
병렬로 수행할 수 있는 작업은 git worktree를 활용해서 분리하고, 각 기능을 독립적으로 구현하고 검증하는 방식으로 개발을 진행하고 있어요. 작업 간 의존성을 줄여서 동시에 여러 기능을 처리할 수 있도록 구조를 만든 거죠.
반대로 순차적으로 진행해야 하는 작업은, AI에게 기능 명세를 전달해 구현을 맡기는 동안, 다음 작업에 대한 명세를 미리 정리하는 방식으로 흐름을 이어가고 있어요.
이런 방식은 개발 속도를 높이는 데에는 확실히 효과가 있었어요. 직접 코드를 작성하는 시간이 줄어들면서 더 많은 작업을 처리할 수 있게 됐거든요.
다만 생산성이 올라간 만큼, 이전과는 다른 종류의 부담도 생기긴 했습니다. 예전에는 코드 자체의 오류를 수정하는 데 집중했다면, 이제는 결과가 의도와 맞는지 검증하는 비용이 더 크게 느껴졌다는 점이에요. AI는 주어진 정보를 기반으로 코드를 생성하다 보니, 명세가 조금만 어긋나도 전혀 다른 방향의 결과가 나오기도 하더라고요. 그래서 결과를 검증하는 것도 중요하지만, 그보다 앞에서 어떤 명세를 전달하느냐가 결과의 품질을 좌우한다는 걸 더 강하게 느끼게 됐어요.
이 과정에서 하나의 기준이 명확해졌습니다. AI는 다양한 결과를 만들어내는 데에는 강하지만, 그 결과를 판단하고 선택하는 역할은 결국 사람이 해야 한다고 생각해요. 그리고 그보다 앞서, 어떤 결과가 나오도록 만들지에 대한 입력과 명세를 설계하는 것 역시 사람의 역할이라고 느꼈어요.
요즘은 기능을 바로 구현하기보다는, 먼저 도메인과 API 단위로 요구사항을 정리하고, 이 과정에서도 AI를 활용해 누락된 부분이나 모호한 지점이 없는지 한 번 더 점검한 뒤 이를 기반으로 구현 계획을 세우고 있어요. 이렇게 명세를 먼저 정리하고 개발을 진행하다 보니, AI에게 전달되는 정보가 더 명확해지고 결과의 일관성도 확실히 좋아졌어요.
AI를 활용하면서 개발 방식 자체가 많이 바뀌고 있다는 걸 체감하고 있어요. 이제는 코드를 얼마나 빠르게 작성하느냐보다, 어떤 정보를 어떻게 전달하고, 생성된 결과를 어떻게 검증할 것인지가 더 중요한 문제가 됐다고 느끼고 있어요.
이런 변화는 생산성 향상으로 이어졌지만, 그만큼 더 많은 일을 해내야 한다는 부담도 함께 생겼습니다. 또 여러 작업을 병렬로 진행하다 보니 컨텍스트 전환이 잦아지는 부분도 있었고요.
그래서 단순히 AI를 활용하는 것을 넘어 이제는 작업 자체를 어떻게 설계할 것인가가 개발자의 핵심 역할이 되고 있다고 느끼고 있어요.
Q. AI 서비스를 개발하면서 기술적으로 가장 어려웠던 문제와, 이를 어떻게 해결했나요?
AI 서비스를 개발하면서 어려웠던 부분은 장애를 빠르게 인지하고 원인을 파악하는 과정이었어요.
초기에는 애플리케이션 레벨에서 메트릭이나 모니터링 체계가 충분하지 않아서, AI 서버 응답이 지연되거나 실패하더라도 문제를 즉시 인지하기 어려운 상황이었는데요. 특히 AI 요청은 비동기적으로 처리되다 보니, 문제가 발생했을 때 AI 서버의 문제인지, 백엔드의 문제인지, 네트워크 이슈인지 구분하기 어려운 상황이었어요. 이로 인해 장애 대응이 늦어지고, 원인을 추적하는 데에도 많은 시간이 소요되는 문제가 있었어요.
그래서 서비스 전반의 상태를 더 명확하게 파악할 수 있도록, Spring Actuator와 Prometheus를 활용해 요청 지연, 에러율 등의 메트릭을 수집하고, Grafana를 통해 이를 시각화하는 방식으로 모니터링 환경을 개선하게 됐습니다.
또한 AI 서버 응답 지연이나 실패 상황을 빠르게 감지할 수 있도록 Slack Webhook 기반 알림을 추가해, 장애를 인지하고 대응하는 시간을 줄일 수 있었어요.
이런 경험을 통해서 단순히 기능을 구현하는 것뿐만 아니라, 문제를 빠르게 탐지하고 원인을 파악할 수 있는 구조를 만드는 것이 서비스 운영에서 매우 중요하다는 걸 느끼게 됐어요.
다음 목표가 있어요
현재 구조도 안정적으로 동작하고 있지만, 여전히 개선해야 할 부분이 있다고 생각하고 있어요. 지금은 실시간 통신을 위해 LiveKit을 중심으로 구조가 구성되어 있는데, 이 과정에서 통신 흐름과 상태를 백엔드에서 완전히 제어하기 어렵다는 한계가 있었는데요. 그래서 다음 단계에서는 백엔드가 중간에서 흐름을 더 명확하게 제어할 수 있는 구조로 개선해보려고 하고 있습니다.
단순히 통신을 연결하는 역할을 넘어서, 요청의 상태와 흐름을 서버에서 관리할 수 있게 되면 더 안정적인 서비스 운영과 세밀한 제어가 가능해질 거라고 생각하고 있어요.
Q. AI 서비스는 상대적으로 신기술이라 참고할 레퍼런스가 마땅히 없을 때도 있을 텐데, 그럴 때는 어떻게 문제를 해결하나요?
일반적인 일대일 채팅 기능은 레퍼런스가 많은 편인데, 저희처럼 실시간 AI 음성 대화 기반 서비스는 참고할 만한 사례가 많지 않았어요. 그래서 특정 기술이나 구조를 그대로 따라가기보다는, 문제를 정의하고 여러 가지 방식을 비교하면서 방향을 잡아가는 경우가 많았던 것 같습니다.
이 과정에서 AI를 단순히 코드 생성 도구로 쓰기보다는, 설계에 대한 피드백을 주고받는 역할로 활용하고 있어요.
예를 들어 제가 생각한 구조를 먼저 정리한 뒤, “이 방식에서 문제가 될 수 있는 부분은 무엇인지”, “다른 대안이 있다면 어떤 게 있는지” 같은 질문을 던지면, AI가 다양한 관점에서 피드백을 주고, 그걸 바탕으로 다시 구조를 검토하는 식이에요.
특히 중요한 건, 상황에 맞는 컨텍스트를 충분히 전달하는 거라고 느꼈어요. AI는 서비스 규모나 트래픽을 알지 못하기 때문에, “현재 사용자 수나 요청량이 어느 정도인지”, “실시간성이 얼마나 중요한지” 같은 조건을 함께 주면 그에 맞는 현실적인 선택지를 제안해주더라고요.
이렇게 여러 가설을 놓고 비교하면서 점점 방향을 좁혀가는 방식으로 문제를 해결하고 있는데요. 결국 AI는 다양한 가능성을 빠르게 제시해주는 도구이고, 그 중에서 어떤 선택을 할지는 여전히 사람이 판단해야 한다고 생각합니다.
Q. 팀에서 받은 피드백 중 기억에 남는 게 있으세요?
기존에는 어드민과 앱이 각각 별도의 리포지토리로 분리되어 있었는데, 실제로는 유저나 교육 같은 핵심 도메인은 두 서비스에서 공통으로 사용되고 있었어요. 그래서 동일한 도메인 로직이 각각 중복으로 구현되어 있는 구조였고, 이 부분을 하나의 도메인 모듈로 통합해서 재사용하는 방향으로 개선하자는 피드백을 받았어요.
처음에는 단순히 구조를 나누는 게 더 명확하다고 생각했는데, 해당 구조를 적용하고 구현하는 과정에 참여하면서 도메인 로직을 한 곳에서 관리할 수 있기 때문에 수정 시 양쪽 서비스에 동시에 반영되고, 중복 구현을 줄일 수 있다는 장점을 직접 경험할 수 있었어요. 이 경험으로 코드 재사용성과 일관성을 높이는 구조가 왜 중요한지 이해하게 됐다는 점이 기억에 남네요.
그런데 AI를 적극적으로 활용하면서 다시 생각해보게 됐어요
요즘 AI를 활용한 개발을 하면서, 기존에 효율적이라고 생각했던 구조에 대해 다시 고민하게 됐어요. 도메인 모듈을 하나로 통합하면 사람 입장에서는 재사용성과 일관성을 유지하기에 좋은 구조였어요. 그런데 AI를 활용하는 관점에서 보면, 이 구조를 다르게 바라보게 되더라고요.
앱 기능만 구현하려고 해도, 도메인 모듈이 하나로 통합되어 있는 구조에서는 AI가 해당 모듈 전체를 컨텍스트로 참고하게 될 가능성이 있다고 생각했어요. 이 경우 어드민에서만 사용하는 로직까지 함께 포함되면서 불필요한 정보가 늘어나고, 결과적으로 의도를 정확하게 전달하기 어려운 구조가 아닐까 하는 고민이 들었어요.
그래서 최근에는 단순히 구조를 통합하는 것이 아니라, 불필요한 정보를 줄이고, AI가 의도를 정확하게 이해할 수 있는 컨텍스트를 제공하는 것이 더 중요한 설계 기준이 될 수 있지 않을까 고민하고 있습니다. 즉, 기존에는 재사용성과 일관성이 중심이었다면, 이제는 AI가 이해하기 쉬운 구조인지까지 함께 고려해야 하는 상황이 된 것 같아요.
아직 정답은 없지만, AI를 전제로 한 개발 환경에서는 코드 구조를 바라보는 기준 자체가 달라질 수 있겠다는 걸 느끼게 된 계기였어요.
Q. 쏘카인드에 관심 있는 분들에게 하고 싶은 말이 있다면요?
“동료가 좋습니다.”
한마디로 요약하면 이 말이 가장 잘 맞는 것 같아요.
팀원분들 모두 제품을 더 좋은 방향으로 만들고 싶다는 공통된 목표를 가지고 있어서, 자연스럽게 의견을 나누고 피드백을 주고받는 문화가 자리 잡혀 있어요.
의견을 나눌 때도 각자의 근거를 바탕으로 논의하는 과정은 있지만, 누가 맞는지를 가리는 것보다 더 나은 선택을 함께 찾는 데 집중하는 분위기예요. 그래서 피드백이 부담으로 느껴지기보다는, 오히려 생각을 확장할 수 있는 계기가 되는 경우가 많았어요.
이런 환경 덕분에 자연스럽게 더 고민하게 되고, 더 좋은 방향을 제안하고 싶다는 동기부여도 커졌어요. 서로가 서로를 성장하게 만드는 구조라고 느꼈어요.
첫 직장이라 다른 회사와 직접 비교할 수는 없지만, 이렇게 서로의 성장을 돕는 동료들과 함께 일할 수 있다는 점이 가장 큰 장점이라고 생각해요.