소프트웨어 선정, 처음엔 남들이 쓰는 걸 따라갔다

소프트웨어를 고를 때, 처음 기준은 솔직히 단순했다.
좋은 회사들은 뭘 쓰지?

채용 공고를 보면 비슷한 이름이 반복됐다. Jira, Git, IntelliJ, Slack, AWS…
커뮤니티가 크고, 검색하면 답이 나오고, 팀장님들이 이미 쓰고 계신 도구.
리소스를 구하기 어려운 상황에서는 낯선 선택보다, 따라갈 수 있는 선택이 안전해 보였다.

왜 따라갔는가 (이유)

소규모 팀에 이 도구 써본 사람을 바로 채용하기 어려웠다. 시장에 흔한 스택이 곧 채용 가능성이었다.
레거시 전산·결제·인프라가 한곳에 있어, 실험 비용이 컸다. 유행이 아니라 이미 검증된 것을 먼저 깔고 싶었다.
팀장·파트장이 선택하고 쓰던 것을 무작정 반영했다. 처음엔 이유보다 신뢰가 앞섰다. “왜 이걸 쓰는지”는 나중에 찾아도 된다고 봤다.

그래서 선정 기준의 1차안은 이랬다.

IT 대기업 채용 공고에 자주 나오는가
커뮤니티·문서·예제가 충분한가
IDE·협업·CI 등 팀 전체가 같은 화면을 볼 수 있는가
우리 팀장님들이 이미 쓰고 있는가

따라가며 깔았던 것들 (당시 결론)

처음엔 ‘맞춤형 최적 조합’이 아니라, ‘겹치는 교집합’을 깔았다.

영역	처음 따라간 선택	당시 생각
협업	Jira · Confluence · Slack	이슈·문서·대화가 한 흐름으로 이어질 것
IDE	IntelliJ IDEA (+ 상황별 VS Code)	Java/Spring 중심 실무와 맞음
품질	Prettier · ESLint	스타일 논쟁을 도구로 제거
인프라	Jenkins · AWS(EC2/S3)	배포·운영 자동화의 출발점
AI 보조	Cursor · Claude Code	리뷰 전 정리·반복 작업 보완

“유행이라서”가 아니라, 채용·운영·협업 비용을 동시에 줄이려는 선택이었다.
다만 처음엔 이유를 문장으로 설명하기 어려웠다. 써 보면서 이해가 쌓였다.

써 보면서 찾은 이유

Jira · Confluence · Slack

이유를 찾은 순간: 반복 질문이 이슈 번호와 문서 링크로 바뀔 때. “그거 어디 있어요?”가 줄었다.
한계: 우리 팀 규모에 설정·라이선스·관리가 무거울 수 있었다. 그래서 이후 Discord·Notion으로 가볍게 재구성했다. 습관은 남기고 도구만 바꾼 셈이다.

IntelliJ · VS Code

이유: 레거시 Java/Spring과 React/TypeScript를 한 사람이 오가며 볼 때, IDE 전환 비용이 컸다. IntelliJ는 백엔드·DB, VS Code는 프론트·설정 파일에 유리했다.
기준: “하나로 통일”보다 역할별 최적이 전체 속도를 올렸다.

Prettier · ESLint

클린코드 플레이북에서 적었듯, 사람이 매번 같은 지적을 반복하지 않게 하려고 도입했다.
이유: 리뷰 에너지를 스타일이 아니라 설계에 쓰기 위함.

Cursor · Claude

AI 코드 리뷰 글과 같다. 대체가 아니라 1차 정리 도구.
이유: 속도는 올리되, 결제·인증·배치는 사람이 본다는 선을 그었을 때 비로소 쓸 만했다.

비슷한 경험 — 무작정가 아니라 “반영하며 수정”

처음 도입은 거의 복제에 가까웠다.
그다음 단계에서야 개발자센터를 만들고, Discord·Notion으로 옮기고, blue & green 배포를 붙이는 식으로 우리 팀에 맞게 잘라냈다.

당시 결론: 선정 기준 1.0은 “남들이 쓰는가”였고, 2.0은 우리 운영 부담을 줄이는가가 됐다.
팀장님들이 고른 도구를 존중했기 때문에, 현장 저항이 적었다. 거기서 출발해 이유를 찾고 기준을 세우는 쪽으로 나아갈 수 있었다.

아직 부족한 것 (개선점)

도구 목록은 늘었지만, 선정·폐기 기준 문서가 약하다. “왜 들였는지”는 사람 머리에 남아 있다.
채용 공고 기준과 실제 팀 생산성이 항상 일치하진 않는다. 안 쓰는 기능·라이선스가 남을 수 있다.
팀마다 익숙한 도구가 달라, 온보딩 경로가 아직 통일되지 않았다.

지금 쓰는 선정 기준 (2.0)

채용·커뮤니티 — 새 인원이 들어왔을 때 설명 비용이 낮은가
팀장·현장 신뢰 — 이미 검증된 사용 맥락이 있는가
운영 부담 — 도구 관리에 쓰는 시간이 일을 줄인 만큼 돌아오는가
기록·자동화 — 개발자센터·CI·린트와 연결되는가
되돌리기 — 잘못 골랐을 때 바꿀 비용이 감당 가능한가

앞으로 나가야 할 방향

도구 선정·변경마다 한 줄 이유를 개발자센터에 남겨, “팀장님이 쓰셔서”가 아니라 팀 기준으로 설명 가능하게 한다.
채용 우대 스택과 실제 스택의 차이를 주기적으로 점검해, 안 쓰는 도구는 과감히 내린다.
AI·IDE·협업 도구는 클린코드·AI 리뷰 기준과 묶어, 사람이 볼 것 / 도구가 막을 것을 분리한다.
애자일 주기(애자일과 성장) 안에서 도구 실험을 짧게·되돌릴 수 있게 한다.

처음엔 남들을 따라갔다. 그건 나약함이 아니라, 리소스가 적은 팀의 현실적인 출발점이었다.
중요한 건 따라가기를 끝내지 않고, 써 보면서 우리만의 이유와 기준으로 바꿔 나가는 것이었다. 그리고 그 과정은 아직도 계속되고 있다.