나는 검색도 같이 한다.

2025. 11. 13. 11:13·서버 개발(생각과 구현)/서버 생각
반응형

부제: AI는 정답을 알지만, 경험을 알려주지 않는다.

안녕하세요, 3년차 주니어 백엔드 개발자입니다. 이 글은 AI가 코드를 생성하고, 버그를 디버깅해주는 2025년에도 불구하고 왜 제가 여전히 검색이라는 고전적인 행위에 먼저 접근하는지에 대한 개인적인 고찰입니다.

1. 나의 문제 해결 프로세스

저의 업무는 궁금증에서 시작됩니다. "이 새로운 기술 스택을 왜 도입해야 할까?", "운영 환경에서 발생한 이 로그는 정확히 무엇을 의미할까?", "더 효율적인 아키텍처는 없을까?"

 

이런 질문이 생기면 저는 먼저 문제의 본질을 파악하려 합니다. 문제를 명확히 정의하고, 키워드를 뽑아냅니다. 그리고 바로 이 지점에서, 2025년의 개발자인 저에게는 두 가지 선택지가 주어집니다. AI에게 질문하기 또는 검색 엔진에 입력하기.

 

많은 경우 저는 두 가지를 모두 사용하지만, 최종적인 확신을 얻는 곳은 언제나 후자였습니다. 그 이유를 지금부터 데이터와 함께 설명하려 합니다.

2. AI의 위력: 완벽한 미시적 정답 탐색기

저는 AI의 강력함을 부정하지 않습니다. 오히려 적극적으로 활용합니다. 제미나이, ChatGPT, 클로드, Copilot은 이제 저의 개발 워크플로우에서 빼놓을 수 없는 동료가 되었습니다.

  • "Java 17의 record 문법 알려줘."
  • "이 정규표현식 좀 고쳐줘."
  • "Spring Boot에서 CORS 설정하는 보일러플레이트 코드 짜줘."

이런 명확한 정답이 있는(Right-there) 질문, 즉 미시적 관점의 지식을 얻는 데 AI는 압도적인 효율을 보여줍니다.

실제로도 데이터는 이를 증명합니다. 2025년 JetBrains의 개발자 생태계 보고서에 따르면, 개발자의 85%가 코딩과 개발에 AI 도구를 정기적으로 사용하고 있으며, 가장 많이 위임하는 작업 중 하나가 바로 개발 관련 정보 검색과 보일러플레이트 코드 작성이었습니다. 2025년 Stack Overflow 설문조사 역시 전문 개발자의 51%가 매일 AI 도구를 사용한다고 응답했습니다.

 

AI는 개념을 학습하고, 문법을 찾고, 간단한 코드를 생성하는 데 걸리는 시간을 획기적으로 줄여주었습니다. 하지만 저의 고민은 그다음 단계에서 시작되었습니다.

3. AI의 공백: 경험은 어떻게 얻나요?

AI는 무엇(What)과 어떻게(How)는 알려주지만, 왜(Why)에 대해서는 깊이 있는 답을 주지 못했습니다.

AI는 "A 기술은 B보다 빠르다"고 말하지만, "사실 우리 팀은 B를 선택했는데, 그 이유는 A의 라이선스 문제가 발목을 잡았고, 예상치 못한 트래픽 패턴에서 B가 더 안정적이었기 때문"이라는 이야기를 들려주지 못합니다.

 

제가 AI에게 얻을 수 없었던 것, 그것은 바로 피와 땀이 섞인 시니어의 경험이었습니다.

  • 새벽 3시에 터진 장애를 복구하며 얻은 교훈
  • 특정 기술을 도입했다가 1년 만에 걷어낸 실패의 기록
  • 수백만 트래픽을 감당하며 내린 현실적인 아키텍처 트레이드오프

이러한 경험은 대부분 훈련 데이터셋에 존재하지 않습니다. AI는 코드를 리뷰할 수는 있지만, "그 코드가 비즈니스 맥락상 어떤 잠재적 위험을 가지고 있는지"에 대한 통찰은 부족합니다. 2025년 JetBrains 보고서에서 개발자들이 AI에 대해 갖는 가장 큰 우려사항이 복잡한 코드와 로직에 대한 이해 부족과 컨텍스트 인식 부족이라는 점은 결코 우연이 아닙니다.

 

(사실 이에 대한 접근으로는 양질의 테크 블로그를 참고 하거나 컨퍼런스에 참여해서 발표를 듣는 등으로 접근해볼 수 있기도 합니다. 그리고 결국 경험이라는 것은 해보지 않으면 인지하기 어렵기 때문에 가지고 있던 고민을 직접적으로 구현하거나 기술로 풀어내보는 과정을 거쳐 해답에 가까워질 수 있다는 결론에 도달하게 되었습니다. AI 어시스턴트를 이용해서 하면 기술로 풀어내기 쉽다고 생각합니다. 하지만 과정과 경험에서는 당연히 차이가 날 수 밖에 없다고 느낍니다.)

4. 경험의 아카이브가 사라지고 있다 (개인적인 생각)

제가 생각하는 문제는, 제가 원하는 경험의 원천, 즉 양질의 테크 블로그와 포럼의 글이 줄어들고 있는 것 같은데?라는 점입니다.

이 부분에 대한 통계 자료를 발견했습니다. 2023년 말부터 2024년을 거치며 ChatGPT가 폭발적으로 보급되자, 개발자들의 질문 장소가 바뀌었습니다. 간단한 질문은 모두 AI가 흡수해 갔고, 그 결과 전통적인 Q&A 플랫폼은 유례없는 위기를 맞았습니다.

[주요 통계 자료] Stack Overflow의 질문 감소

  • 한 GitHub Gist에 공개된 분석 자료에 따르면, Stack Overflow에 게시되는 신규 질문 수는 2023년 3월 약 87,000건에서 2024년 12월 약 25,500건으로 무려 70.7%나 급감했습니다.
  • 전년 동기 대비(2023년 12월 vs 2024년 12월)로도 40.2%가 감소한 수치입니다.

 

이 수치가 의미하는 바는 명확합니다. 간단한 질문이 사라지면서, 그 질문에 답변을 달던 경험이나 길잡이에 대한 공유 역시 사라지고 있는 것입니다. AI가 답변할 수 없는 복잡한 아키텍처 질문이나 운영 경험을 공유하던 커뮤니티 자체가 줄고 있다고 느꼈습니다. 경험의 아카이브가 줄고 있지 않나? 라는 생각을 하게 되었습니다.

5. 예시로 "Redis 분산 락, 왜 Redisson인가요?"

이러한 문제의식은 제가 최근 Redis 분산 락을 사용할 때 절정에 달했습니다.

AI에게 "Redis 분산 락 구현 방법"을 물으면, 십중팔구 Redisson을 추천합니다. "Lettuce의 Spin Lock은 Redis에 부하를 줄 수 있으니, Pub/Sub 기반의 Redisson이 더 효율적"이라는 모범 답안과 함께요. 또한, 검색을 하여도 대부분 개론적인 개념을 다루는 내용이나, 최신글은 대부분 찾아볼 수 없습니다. 또한, Redisson이 좋다는 글이 상당수 차지하는 것을 볼 수 있습니다.

 

하지만 저에게는 더 깊은 질문이 있었습니다.

  1. "Spin Lock이 정말 우리 서비스의 트래픽 수준에서 유의미한 부하를 주나요?"
  2. "Redisson이 의존하는 Pub/Sub 채널이 많아졌을 때의 오버헤드나, 브로커 장애 시의 복구 시나리오는 어떤가요?"
  3. "초당 수백/수천 건의 락 획득/해제가 필요한 환경에서, Redisson의 구현체가 정말 Spin Lock보다 항상 우월한가요?"
  4. “애초에 분산 락을 잡아야 하는 행위 인가? Atomic한 Redis의 Lua Script를 사용하는 방법은?”
  5. "Spin Lock의 부하를 경험해 보고, 이래서 Redisson을 써야 했다고 말하는 실제 경험담은 없나요?"

저는 이런 고민의 흔적이 담긴 글을 찾고 싶었습니다. 하지만 작성된 글들은 Redisson이 좋다는 결론뿐, 그 결론에 도달하기까지의 치열한 과정이나 트레이드오프를 다룬 글은 찾기 어려웠습니다. 물론 저도 이것에 대해 고민을 하고 직접 구현해서 답을 찾아가 보는 과정을 거쳤습니다. 과정 자체는 고민을 그대로 구현하면 됐지만, 좀 더 많은 경험을 찾아보고 싶었습니다.

 

이는 2025년 DEV Community의 한 기사가 지적한 바와 같습니다. "개발자들은 AI를 이기려 하지만, 그들의 신뢰를 잃고 있다." 이 기사에 따르면, 개발자들은 여전히 장애물에 부딪혔을 때 AI보다 인간 동료에게 묻는 것을 선호하며, AI의 답변을 신뢰하지 못합니다. 우리는 정답이 아니라 맥락과 신뢰를 원합니다.

6. AI 검색 엔진(Perplexity, Etc)도 결국 소스가 필요하다

누군가는 Perplexity.ai 같은 AI 기반 검색 엔진이 이 문제를 해결해 줄 것이라 말합니다. 저도 Pro로 사용중입니다.

 

하지만 Perplexity 역시 만능이 아닙니다. 이 도구들은 결국 웹에 존재하는 원본 소스를 요약하고 재구성할 뿐입니다.

만약 원본이 되는 시니어의 경험담 자체가 웹에 존재하지 않는다면 AI 검색 엔진도 답을 창조해낼 수는 없습니다. 검색 도구의 문제가 아니라, 검색 대상의 문제이지 않을까라는 생각을 하게 되었습니다.

7. 더 많은 날것의 경험을 찾고싶다

AI는 훌륭한 조수이지만, 선배가 될 수는 없습니다.

그래서 저는 이 글을 통해 느낀 부분은 다음과 같습니다. 이름 모를 수많은 중니어, 시니어 개발자님들의 도움이 필요하다고 느꼈습니다.

 

"우리는 OOO 기술을 써서 성공했다"는 멋진 결과물도 좋지만, "사실 OOO를 도입하려다 XXX 문제로 실패했고, 플랜 B로 YYY를 선택할 수밖에 없었던 이유"와 같은 실패의 기록과 고민의 과정을 더 많이 찾고싶습니다. (특히 저는 제가 고민했던 부분을 풀어내주신 테크 블로그 혹은 개발자 분들의 글을 찾으면 기본적으로 다회독하는 습관이 있습니다. 그 경험을 다 저의 것으로 만들고 싶기 때문입니다.)

 

AI가 정답을 알려주는 시대일수록, 우리는 정답이 없는 문제에 대한 당신의 경험을 읽고 싶습니다. 저 또한, 3년차 주니어로서 제가 겪은 작은 실패와 고민들을 기록으로 남기려 합니다.

 

저는 오늘도, 지식의 저변을 넓히기 위해 누군가의 경험을 찾아 검색을 합니다.

 

출처

https://blog.jetbrains.com/research/2025/10/state-of-developer-ecosystem-2025/

https://survey.stackoverflow.co/2025/

https://gist.github.com/hopeseekr/f522e380e35745bd5bdc3269a9f0b132

https://stackoverflow.blog/2025/07/29/developers-remain-willing-but-reluctant-to-use-ai-the-2025-developer-survey-results-are-here/

반응형

'서버 개발(생각과 구현) > 서버 생각' 카테고리의 다른 글

OOM(Out Of Memory)이 발생하는 상황을 만들어보자  (0) 2025.11.13
보여지는 시간대(타임존)은 누구의 책임인가  (0) 2025.01.03
단일 프로젝트 구조와 멀티 모듈 구조  (0) 2025.01.01
Custom Swagger를 통해 협업, 업무 효율성 동시에 잡기  (0) 2024.12.27
JPA N+1의 의도와 문제 해결  (0) 2024.12.26
'서버 개발(생각과 구현)/서버 생각' 카테고리의 다른 글
  • OOM(Out Of Memory)이 발생하는 상황을 만들어보자
  • 보여지는 시간대(타임존)은 누구의 책임인가
  • 단일 프로젝트 구조와 멀티 모듈 구조
  • Custom Swagger를 통해 협업, 업무 효율성 동시에 잡기
dev.JJ
dev.JJ
Software Programming
  • dev.JJ
    끊임없이 생각하자
    dev.JJ
  • 전체
    오늘
    어제
    • 분류 전체보기 (45)
      • 서버 개발(생각과 구현) (16)
        • 코틀린 (0)
        • 서버 생각 (16)
      • 머신러닝 (24)
        • 신경망 첫걸음 (2)
        • 모두를 위한 딥러닝 (12)
        • 딥러닝을 이용한 자연어처리 입문 (9)
        • AI 프로젝트 (1)
      • 수학 (5)
        • 기초 선형대수학 (4)
        • 기초수학 (1)
  • 블로그 메뉴

    • 홈
    • 태그
    • 미디어로그
    • 위치로그
    • 방명록
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    수학
    벡터
    ai
    머신러닝
    프로젝트
    코로나 바이러스 예측
    ML
    자연어처리
  • 최근 댓글

  • 최근 글

  • 반응형
  • hELLO· Designed By정상우.v4.10.3
dev.JJ
나는 검색도 같이 한다.
상단으로

티스토리툴바