기술 선택 회의에서 '내 의견은 이거야' 못 하는 날들
- 22 Dec, 2025
오늘도 회의
오전 10시. 아키텍처 회의. 신규 프로젝트 기술 스택 결정하는 자리다.
“파트장님 의견은요?”
5초 침묵했다. 20년 차가 5초 침묵했다.
“둘 다 장단점이 있어.”
또 이 말이다. 내가 제일 싫어하는 내 대답이다.
예전엔 안 그랬다
30대 때는 달랐다. “이거 쓰면 됩니다” 단칼에 정했다. 근거도 명확했다. 경험했으니까.
지금은? 경험했는데 확신이 없다.
작년에 Go 도입 회의 때였다. “Go 괜찮습니다. 동시성 처리 좋고요.” 김대리가 말했다. 27살.
나도 Go 안다. 토이 프로젝트로 3개월 써봤다. 근데 실무는 다르잖아.
“음… 러닝 커브는?” “저희 팀원들 금방 배웁니다.”
맞는 말이다. 근데 3년 뒤는? 유지보수는? 이직으로 사람 빠지면?
질문만 10개 했다. 대답은 다 들었다. 그래도 결정 못 했다.
“다음 주까지 검토하고 다시 모이자.”
회의 끝나고 혼자 남았다. 예전엔 내가 답을 줬는데. 지금은 내가 시간을 번다.
확신이 사라진 순간
정확히 언제부턴가. 아마 40 넘어서부터.
새 기술 나올 때마다 공부했다. React, Vue, Next.js, Nest.js. 다 해봤다. 블로그도 읽었다.
근데 실무 투입은 못 해봤다. 회의만 하고, 검토만 하고, 승인만 한다.
이게 문제다. 코드를 안 짜니까 감이 없다.
작년에 React 18 나왔을 때. 김대리가 “Suspense 진짜 좋습니다” 했다. 나는 문서만 읽었다.
“좋긴 한데… 레거시랑 호환은?” “마이그레이션 플랜 세우면 됩니다.” “공수는?” “한 달 정도요.”
한 달. 이 친구 말이 맞을까. 경험해본 나라면 알텐데.
결국 “좀 더 검토해보자” 했다. 김대리 표정이 묘했다. 실망? 답답함?
그날 저녁에 혼자 코드 짜봤다. React 18로 샘플 프로젝트. 3시간 걸렸다.
“아, 이거 괜찮네.”
근데 이미 늦었다. 회의는 끝났고, 검토 기간 2주 잡혔고. 내가 시간 끈 거다.
내가 병목이다
요즘 자주 느낀다. 내가 속도를 늦춘다.
후배들은 빠르다. 새 기술 나오면 주말에 써본다. 월요일에 “이거 좋습니다” 한다.
나는? 월요일에 문서 읽기 시작한다. 수요일에 “검토 중” 이다. 금요일에 “다음 주에” 한다.
2주 지나면 후배들 의욕 떨어진다. 당연하다.
지난달에 TypeScript 5.0 도입 건. 박주임이 제안했다. 29살. “Decorator 개선됐고, Enum 성능 좋아졌습니다.”
나는 4.9까지만 써봤다. 5.0은 릴리즈 노트만 읽었다.
“기존 프로젝트 영향도는?” “CI/CD 파이프라인은?” “타입 체킹 시간은?”
질문만 쏟아냈다. 박주임이 다 조사해서 가져왔다. 그래도 “한 번 더 보자” 했다.
왜? 확신이 없어서.
집에 와서 아내한테 말했다. “나 요즘 일 못 하는 것 같아.” “무슨 소리야. 파트장까지 달았잖아.” “그게 문제야. 파트장이니까 결정해야 하는데.”
아내는 이해 못 한다. 나도 설명 못 한다.
20년 경력의 무게
경력이 길수록 신중해진다. 이게 장점이기도 하고 단점이기도 하다.
실패를 많이 봤다. 잘못된 기술 선택으로 프로젝트 망한 거. 유행 따라갔다가 유지보수 지옥 된 거. 다 겪었다.
2010년에 NoSQL 열풍 때. MongoDB 도입했다가 1년 만에 MySQL 복귀. 마이그레이션에 3개월 걸렸다.
2015년에 마이크로서비스 전환. 모놀리스를 20개 서비스로 쪼갰다. 결과는? 장애 추적 지옥.
이런 거 겪으니까. 새 기술 앞에서 겁이 난다.
근데 후배들은 모른다. 실패를 안 겨봤으니까. 그래서 자신감 넘친다.
누가 맞을까.
솔직히 모르겠다. 실패 경험이 나를 신중하게 만들었는데. 그게 지금은 나를 느리게 만든다.
회의 중 내 모습
요즘 회의 때 내 모습.
- “좋은데, 리스크는?”
- “괜찮은데, 검증은?”
- “나쁘지 않은데, 레퍼런스는?”
부정 먼저 나온다. 의도는 아닌데 습관이다.
김대리가 GraphQL 제안했을 때. “REST보다 유연하고, 오버페칭 없고…”
나는 들으면서 생각했다. ‘쿼리 복잡도 관리는? N+1 문제는? 캐싱은?’
입 밖으로 나왔다. “그런데 말이야…”
김대리 표정 굳었다. 또 시작이구나. 그 표정이었다.
회의 끝나고 복도에서. “파트장님은 뭘 원하세요?”
순간 할 말이 없었다. 나도 모르겠다.
안전한 선택? 검증된 기술? 그럼 계속 Java Spring만?
아니면 새 기술? 배우고 적응하고? 근데 실패하면 책임은 내가?
밤에 혼자 코딩할 때
집에 와서 10시. 아이들 재우고. 노트북 켰다.
GraphQL 튜토리얼. 1시간 따라 했다.
“오, 이거 진짜 편한데?”
근데 이건 토이 프로젝트. 실무는 다르다. 트래픽 1000 RPS 때는? 데이터베이스 10개 조인 때는?
모른다. 해봐야 아는데 해볼 시간이 없다.
새벽 1시. 더 하고 싶은데 내일 회의 있다. 잤다.
다음 날 회의. “GraphQL 제안 건, 좀 더 검토하고…”
또 미뤘다.
김대리가 물었다. “언제까지 검토하세요?”
“2주?”
“파일럿이라도 해보면 안 될까요?”
좋은 제안이다. 근데 파일럿 리소스는 어디서? 실패하면 그 시간은 누가 책임지나?
“검토하고 얘기하자.”
회의실 나오면서 느꼈다. 나는 결정을 회피하고 있다.
파트장의 역설
파트장이 됐다. 의사결정권을 받았다.
근데 결정을 못 한다. 권한은 있는데 확신이 없다.
이게 역설이다.
부장님한테 물어볼까. “GraphQL 도입 어떻게 생각하십니까?”
부장님은 더 모른다. 10년 전에 개발 그만뒀다. 나한테 물어본다. “박 파트장 판단에 맡기지.”
결국 내가 정해야 한다. 근데 못 정한다.
팀원들은 기다린다. 2주, 4주, 6주.
그 사이 다른 팀은 이미 적용했다. 페이스북에 사례 올라온다. “GraphQL 도입 후기”
우리 팀은 아직 검토 중.
어느 금요일 저녁
퇴근 30분 전. 김대리가 들어왔다.
“파트장님, 시간 있으세요?” “어, 말해봐.” “GraphQL 건인데요.”
또 이거다.
“제가 주말에 PoC 만들어봤습니다.” 노트북을 돌렸다. 코드가 보였다.
“기존 REST API랑 성능 비교했고요.” 그래프가 보였다. 응답 속도 30% 개선.
“에러 핸들링도 구현했고.” 코드 설명했다. 진짜 잘 만들었다.
“캐싱 전략도 정리했습니다.” 문서 10페이지. 내가 물었던 것들 다 답했다.
5분 동안 설명 들었다. 할 말이 없었다.
“좋네.”
“그럼 적용해도 될까요?”
여기서 또 막혔다. 좋은데, 그래도, 만약에…
“한 번만 더 보자.”
김대리 표정. 실망을 숨기려고 애쓴다.
“네, 알겠습니다.”
나갔다.
혼자 남았다. 모니터를 봤다.
내가 뭘 하고 있나. 저 친구가 날 믿고 3주 기다렸다. 주말 반납하고 PoC 만들었다. 내가 원하는 걸 다 준비했다.
근데 나는 또 “한 번 더”다.
월요일 아침
출근했다. 김대리한테 슬랙 보냈다.
“GraphQL 적용하자. 파일럿으로 한 API부터.”
답장 10초 만에 왔다. “감사합니다!”
회의 소집했다. “GraphQL 파일럿 프로젝트 시작한다.”
김대리가 발표했다. 일정 2주, 범위 유저 API 3개, 모니터링 1주.
나는 들으면서 생각했다. ‘진작 이렇게 할 걸.’
근데 또 불안하다. 만약 실패하면? 성능 안 나오면? 장애 나면?
고개를 저었다. 그만 생각하자.
후배를 믿어야지. 내가 다 확신할 수는 없다. 20년 경력이 다 아는 게 아니다.
그냥 인정하자. 모르는 게 있다고. 후배가 나보다 잘 아는 게 있다고.
2주 후
GraphQL 파일럿 완료. 결과 보고 회의.
성능 개선 25%. 에러율 0.3% (허용 범위). 응답 속도 평균 150ms → 110ms.
성공이다.
김대리가 보고했다. 나는 옆에서 들었다.
“고생했어.” “감사합니다.”
부장님이 물었다. “다른 API도 확대 적용하죠?”
내가 대답했다. “네, 진행하겠습니다.”
이번엔 확신 있게 말했다. 결과를 봤으니까.
회의 끝나고. 김대리가 커피 사왔다.
“파트장님, 처음엔 왜 그렇게 신중하셨어요?”
솔직하게 말했다. “확신이 없었어. 내가 안 해봐서.”
“그래도 믿어주셔서 감사합니다.”
“너희가 잘해줘서 가능했지.”
둘 다 웃었다.
깨달은 것
나는 모든 걸 알 수 없다. 20년 경력도 마찬가지다.
후배들이 아는 게 있다. 새 기술, 새 트렌드. 그들이 현장에 더 가깝다.
내 역할은 뭘까. 모든 걸 결정하는 게 아니다. 방향을 제시하고, 리스크를 관리하고, 실패를 받아주는 것.
확신 없어도 괜찮다. 대신 믿어줘야 한다.
후배를 믿고. 데이터를 믿고. 결과를 보고 수정하면 된다.
완벽한 결정은 없다. 빠른 실행과 빠른 수정. 이게 답인 것 같다.
요즘 회의에서 바뀐 것. “둘 다 장단점이 있어. 근데 일단 해보자.”
한 줄 추가했다. “일단 해보자.”
이게 내가 할 수 있는 최선이다. 확신은 없어도 실행은 할 수 있다.
경력이 길수록 겸손해진다. 그게 약점일 수도, 강점일 수도 있다. 중요한 건 멈추지 않는 것이다.