2009년, SI 업계에 처음 발을 들였을 때 선배가 해준 말이 아직도 생생하다. "야, 신입이 코드부터 짜면 망한다. 먼저 물어보는 습관을 들여." 그 말을 무시했다가 3개월짜리 프로젝트를 8개월 만에 끝낸 적이 있다. 고객이 진짜 원하는 게 아니라, 내가 만들고 싶은 기능부터 코딩했기 때문이었다. 이후 15년 동안 대형 SI 프로젝트를 거치며 깨달은, 지금 신입들에게 진짜 도움이 될 5가지 원칙을 정리했다.
첫째, 절대 기술 스택부터 고르지 마라
면접 보러 오는 신입들 중에 "저는 React가 주력입니다"라고 말하는 사람이 있다. 틀린 말은 아니지만, SI 현장에서는 위험한 태도다. 고객사에 따라 Angular를 써야 할 수도, jQuery를 유지보수해야 할 수도 있다. 문제를 먼저 보고 도구를 정해라. "저는 고객이 원하는 게 뭔지 먼저 묻는 사람입니다" — 이 한 마디가 "React 주력입니다"보다 열 배 강력하다.
둘째, 문서화는 사치가 아니라 생존이다
2015년, 모 대기업 물류 시스템 장애가 터졌다. 새벽 2시였다. 원인을 찾는 데 4시간이 걸렸다. 전임자가 퇴사하면서 남긴 인수인계 문서가 "잘 부탁드립니다" 한 줄이었기 때문이다. 반면 작년에 함께한 SK C&C 협력사 신입은 달랐다. 그가 맡은 작은 배치 모듈에 대해 "왜 이 로직을 썼는지, 어떤 예외 케이스가 있었는지, 테스트 데이터는 어디 있는지"까지 README에 정리해뒀다. 그 신입은 1년 만에 PL(Project Leader)로 승진했다. 문서는 신입이 시니어에게 자기 존재를 증명하는 가장 빠른 길이다.
셋째, 모르는 건 부끄러운 게 아니라, 모르는 채로 가만히 있는 게 문제다
신입 시절 나를 가장 힘들게 했던 건 기술이 아니라, "이걸 물어봐도 되나?"라는 망설임이었다. 그런데 10년차가 되어 깨달았다. 시니어들이 진짜 짜증 내는 건 모르는 신입이 아니라, 모르는데도 질문하지 않고 혼자 끙끙대다가 마감일 당일 "안 될 것 같아요"라고 말하는 신입이다.
신입이 질문할 때 지키면 좋은 원칙은 단 하나다. "이 문제 때문에 지금 몇 시간째 막혀 있고, 구글에서 A, B, C 키워드로 검색해봤지만 해결이 안 됩니다" — 이렇게 시도한 흔적을 먼저 말한 뒤에 질문하는 것. 그러면 어떤 시니어도 귀찮아하지 않는다.
넷째, AI를 동료로 써라 — 하지만 설명할 수 있어야 한다
GitHub Copilot이 짜준 코드를 그대로 커밋하는 신입이 있다. 위험하다. 나는 신입들에게 이렇게 말한다. "Copilot이 짠 코드를 주석까지 달아서 동료에게 설명할 수 있으면 써도 된다. 못 하겠으면 쓰지 마라." AI는 속도는 올려주지만, 그 코드에 대한 책임은 결국 네 몫이기 때문이다.
실제로 얼마 전 한 프로젝트에서, Copilot이 생성한 정규표현식이 특정 엣지 케이스에서만 실패하는 걸 신입이 발견했다. 그 신입은 단순히 "AI가 틀렸습니다"가 아니라, "이런 입력값에서 이렇게 실패하고, 이렇게 고치면 해결됩니다"라고 이슈에 정리했다. 그 날로 그 신입에 대한 평가가 확 바뀌었다.
다섯째, SI는 결국 사람과 사람 사이의 일이다
15년 동안 수많은 프로젝트를 하면서 깨달은 마지막 진실이다. 고객사 담당자가 화를 내도, 협력사 일정이 밀려도, 팀원이 실수를 해도 — 결국 해결하는 건 기술이 아니라 커뮤니케이션이다. 내가 만난 최고의 시니어들은 코딩보다 대화를 더 잘했다. 신입에게 바라는 건 뛰어난 코딩 실력이 아니다. 막혔을 때 혼자 끙끙대지 않고, "도와주세요"라고 말할 수 있는 용기 하나. 그걸 가진 신입은 어느 회사를 가든 반드시 산다.
그래서 오늘 당장, 뭘 해야 할까
아까 말한 대로, 본인이 참여한 프로젝트 하나를 골라서 A4 한 장짜리 "실패 보고서"를 써보라. 거기에 이번 주 안에 Copilot이나 Cursor로 사이드 프로젝트를 하나 만들고, README에 "왜 만들었는지"를 반드시 적어라. 그 두 가지면 충분하다.
SI 현장에서 버텨본 분들 — 신입에게 해주고 싶은 진짜 조언이 있다면 댓글로 남겨주세요. 후배들에게 큰 힘이 됩니다.