SI 개발자의 세계: 압축 성장의 기회인가, 커리어의 함정인가?

SI 개발자의 세계: 압축 성장의 기회인가, 커리어의 함정인가#

개발자 커뮤니티나 현직자의 블로그를 조금만 둘러봐도 'SI'라는 두 글자를 둘러싼 극단적인 평가를 어렵지 않게 만날 수 있다.

어떤 개발자는 말한다.

"SI는 개발자의 무덤이다. 빨리 탈출해야 한다."

반대로 다른 개발자는 이렇게 회상한다.

"SI에서 구른 몇 년이 지금의 나를 만들었다."

한쪽에서는 야근, 파견, 기술 부채, 낡은 시스템을 이야기한다. 다른 한쪽에서는 다양한 프로젝트 경험, 빠른 성장, 강력한 문제 해결 능력을 이야기한다.

도대체 어느 쪽이 맞는 것일까?

흥미로운 점은 둘 다 맞을 수 있다는 것이다.

SI는 회사 이름 하나만 보고 좋은 환경과 나쁜 환경을 단순하게 구분하기 어려운 분야다. 어떤 회사를 선택했는지뿐 아니라 어떤 고객사를 만나는지, 어떤 프로젝트에 들어가는지, 어떤 역할을 맡는지, 프로젝트 관리자가 누구인지에 따라 개발자의 경험이 크게 달라진다.

SI는 '우리 서비스' 하나를 몇 년 동안 가꾸는 제품 개발 조직과도 성격이 다르다.

정해진 기간 안에 고객이 요구한 시스템을 분석하고 설계하고 개발하고 테스트한 뒤 약속한 시점에 오픈해야 한다. 하나의 프로젝트가 끝나면 또 다른 고객과 또 다른 시스템을 만난다.

그래서 SI 개발자를 비유한다면 한 지역에 정착한 농부보다는 새로운 전장을 계속 이동하는 전문 용병에 가깝다.

이번 장에서는 SI를 막연히 좋다거나 나쁘다고 평가하지 않는다.

SI에서 실제로 무엇을 배우게 되는지, 왜 빠르게 성장할 수 있는지, 반대로 어떤 이유로 경력이 정체될 수 있는지, 그리고 SI 경험을 자신의 커리어 자산으로 만들려면 무엇을 준비해야 하는지를 현실적으로 살펴본다.

1.1 SI란 무엇인가#

SI는 System Integration의 약자로, 기업이나 기관이 필요로 하는 정보 시스템을 분석하고 설계하고 구축하는 사업을 의미한다.

예를 들어 다음과 같은 시스템이 SI 프로젝트가 될 수 있다.

  • 은행의 계정계·정보계 시스템
  • 카드사의 결제 시스템
  • 대학의 학사관리 시스템
  • 병원의 의료정보 시스템
  • 제조기업의 생산관리 시스템
  • 물류기업의 창고관리 시스템
  • 공공기관의 행정정보 시스템
  • 기업의 전사적 자원관리 시스템
  • 모바일·웹 기반 업무 시스템
  • 기존 시스템의 클라우드 전환 사업

최근에는 전통적인 웹 시스템 구축에만 머무르지 않는다.

클라우드 전환, 데이터 플랫폼, 인공지능 연계, 마이크로서비스 전환, 컨테이너 환경 구축, 데이터 분석 플랫폼, 업무 자동화까지 SI 프로젝트의 범위가 넓어지고 있다.

실제로 2026년에도 공공 부문에서 기존 시스템을 클라우드 네이티브 구조로 전환하는 사업이 진행되고 있다. 따라서 오늘날의 SI를 단순히 'JSP와 오래된 Java 시스템을 만드는 곳'이라고 보는 것은 현실과 맞지 않는다.

다만 오래된 시스템을 유지하거나 현대화하는 프로젝트 역시 여전히 존재한다.

결국 현대의 SI는 최신 시스템 구축과 레거시 현대화가 동시에 존재하는 시장이라고 보는 것이 더 정확하다.

1.2 왜 SI에 대한 평가는 극단적으로 갈릴까#

SI의 특징을 이해하려면 먼저 한 가지 표현을 기억할 필요가 있다.

프로젝트에 따라 모든 것이 달라진다.

같은 회사에 다니는 두 개발자도 전혀 다른 경험을 할 수 있다.

한 개발자는 클라우드 기반 신규 시스템을 구축하면서 Kubernetes, Spring Boot, Kafka, Redis, CI/CD를 경험할 수 있다.

반면 같은 회사의 다른 개발자는 몇 년 동안 오래된 시스템의 기능 개선만 담당할 수도 있다.

개발자의 경험을 결정하는 것은 다음 요소들의 조합이다.

  • 소속 SI 회사
  • 고객사
  • 프로젝트 성격
  • 신규 구축인지 유지보수인지
  • 프로젝트 관리자
  • 개발팀 구성
  • 고객의 요구사항 관리 수준
  • 개발 기간
  • 기술 스택
  • 개발자의 담당 업무

그래서 SI 업계에서는 흔히 프로젝트 복불복이라는 표현이 등장한다.

좋은 프로젝트를 만나면 짧은 기간에 엄청난 경험을 얻는다.

반대로 좋지 않은 프로젝트를 반복해서 만나면 경력 연차는 늘어났는데 실력은 크게 증가하지 않는 상황도 생긴다.

SI 커리어에서 가장 중요한 것은 단순히 프로젝트를 많이 하는 것이 아니다.

어떤 문제를 해결했고 무엇을 배웠는지를 관리하는 것이다.

1.3 SI의 가장 큰 장점: 다양한 실전 경험#

SI가 주니어 개발자에게 매력적인 가장 큰 이유 중 하나는 다양한 산업을 직접 경험할 가능성이 높다는 점이다.

자사 서비스를 개발하는 조직에서는 하나의 서비스를 오랫동안 담당한다.

쇼핑몰 회사에 입사하면 몇 년 동안 커머스를 경험할 가능성이 높고, 금융회사에 입사하면 금융 시스템을 깊게 경험할 가능성이 높다.

반면 SI 개발자는 프로젝트가 바뀔 때마다 산업 자체가 바뀔 수 있다.

가상의 신입 개발자 '김주니어'의 2년을 따라가 보자.

1.3.1 첫 번째 프로젝트: 카드사 결제 시스템#

첫 프로젝트는 카드사의 결제 시스템 구축이다.

김주니어는 처음으로 실제 돈의 흐름을 처리하는 프로그램을 만난다.

단순히 데이터베이스에 값을 저장하는 것과는 차원이 다르다.

결제가 승인되었는데 데이터베이스 저장에 실패하면 어떻게 할 것인가?

결제 요청이 두 번 들어오면 어떻게 막을 것인가?

외부 기관과 통신하다 연결이 끊어지면 어떻게 복구할 것인가?

하나의 거래가 여러 시스템에 걸쳐 처리된다면 어느 시점까지 성공해야 정상 거래로 판단할 것인가?

학교에서 배웠던 트랜잭션과 동시성 제어가 실제 돈과 연결되기 시작한다.

commit

rollback

timeout

retry

idempotency

교재에서 보던 단어들이 실제 장애와 연결된다.

이 과정에서 개발자는 중요한 사실 하나를 깨닫는다.

코드가 실행되는 것과 시스템이 안전하게 운영되는 것은 완전히 다른 문제다.

1.3.2 두 번째 프로젝트: 대학 학사관리 시스템#

다음 프로젝트에서는 대학의 학사관리 시스템을 구축하게 되었다.

이번에는 금융 시스템과 전혀 다른 문제가 등장한다.

수강신청 하나만 해도 규칙이 단순하지 않다.

  • 최대 신청 학점
  • 선수 과목
  • 재수강 여부
  • 학과별 제한
  • 학년별 제한
  • 강의 정원
  • 시간표 중복
  • 교환학생 예외
  • 졸업 예정자 예외

처음에는 간단해 보였던 요구사항이 수십 개의 조건으로 변한다.

이때 김주니어는 프로그램 개발에서 어려운 것이 알고리즘만은 아니라는 사실을 배운다.

고객이 말하는 업무 규칙을 이해하고 그것을 데이터 구조와 프로그램 로직으로 변환해야 한다.

여기에서 중요한 능력이 만들어진다.

업무를 코드로 번역하는 능력이다.

1.3.3 세 번째 프로젝트: 물류 창고관리 시스템#

2년 차에는 물류기업의 창고관리 시스템 구축에 참여한다.

이번에는 화면과 데이터베이스만 상대하지 않는다.

바코드 스캐너와 PDA가 등장하고 재고가 실시간으로 움직인다.

상품이 창고에 입고된다.

검수가 이루어진다.

적치 위치가 결정된다.

피킹 작업자가 상품을 가져간다.

포장된다.

출고된다.

시스템 데이터와 실제 창고의 상품 수량이 달라지면 업무가 멈출 수 있다.

김주니어는 이 프로젝트에서 처음으로 소프트웨어가 현실 세계를 움직이는 시스템이라는 사실을 체감한다.

1.4 넓은 도메인 경험이 만드는 힘#

불과 몇 년 사이 금융, 교육, 물류를 경험했다면 단순히 프로그래밍 언어를 여러 개 사용했다는 것보다 훨씬 큰 자산을 얻을 수 있다.

바로 도메인 이해력이다.

개발자는 시간이 지날수록 단순 구현 능력보다 문제의 구조를 파악하는 능력이 중요해진다.

신입 개발자는 이런 질문을 한다.

"이 기능은 어떻게 구현하지?"

경험이 쌓인 개발자는 먼저 다른 질문을 한다.

"왜 이 기능이 필요한가?"

"이 업무에서 정말 중요한 데이터는 무엇인가?"

"장애가 발생하면 어느 업무가 멈추는가?"

"데이터 정합성이 깨지면 어떤 일이 발생하는가?"

다양한 산업을 경험하면 새로운 프로젝트에 들어갔을 때 핵심 구조를 빠르게 파악하는 능력이 생긴다.

이것이 좋은 SI 경험이 만들어주는 기술적 맷집이다.

1.5 두 번째 장점: 데드라인이 만드는 압축 성장#

SI 프로젝트에는 대부분 명확한 오픈 일정이 존재한다.

"준비가 끝나면 출시하겠습니다."

라는 식으로 무기한 연기하기 어렵다.

계약된 일정이 있고 고객의 업무 일정이 있으며 기존 시스템 교체 일정까지 연결되어 있기 때문이다.

그래서 SI에서 일정은 단순한 목표가 아니다.

프로젝트 전체를 움직이는 강력한 제약 조건이다.

1.5.1 결국 해결해야 하는 문제를 만난다#

개발을 하다 보면 처음 보는 문제를 계속 만난다.

API가 예상대로 작동하지 않는다.

데이터가 맞지 않는다.

특정 환경에서만 장애가 발생한다.

외부 시스템과 통신이 끊긴다.

사용자가 동시에 접속하면 오류가 발생한다.

SI에서는 이런 문제를 다음 스프린트로 계속 미룰 수 없는 경우가 많다.

결국 원인을 찾아야 한다.

과거에는 개발자들이 Stack Overflow, 기술 블로그, 공식 문서를 뒤지며 문제를 해결했다.

2026년의 개발자는 여기에 또 하나의 강력한 도구를 가지고 있다.

인공지능 개발 도구다.

코드 설명, 로그 분석, SQL 작성, 테스트 코드 생성, 라이브러리 사용법 탐색 등에 AI를 활용하는 것이 일반적인 개발 방식으로 자리 잡고 있다. 2025년 Stack Overflow 개발자 설문에서는 응답자의 84%가 개발 과정에서 AI 도구를 사용하거나 사용할 계획이라고 답했다.

그러나 AI가 SI 개발자의 문제를 대신 해결해 주는 것은 아니다.

같은 조사에서 AI 출력의 정확성을 신뢰하지 않는 개발자가 신뢰하는 개발자보다 많았으며, 많은 개발자가 "거의 맞지만 완전히 맞지는 않는 답"을 AI 사용의 가장 큰 문제로 꼽았다.

결국 중요한 능력은 AI에게 코드를 만들어달라고 요청하는 것이 아니다.

AI가 만든 답이 맞는지 판단하는 능력이다.

특히 금융, 공공, 제조처럼 장애 비용이 큰 시스템에서는 이 능력이 더욱 중요해진다.

1.5.2 빠르게 배우는 법을 배운다#

SI에서는 프로젝트가 바뀌면 기술도 바뀔 수 있다.

어제까지 Oracle을 사용했다가 다음 프로젝트에서는 PostgreSQL을 사용할 수 있다.

REST API만 만들다가 메시지 기반 시스템을 만날 수도 있다.

Spring MVC를 사용하다가 Spring Boot 기반 시스템으로 이동할 수도 있다.

온프레미스 환경을 다루다가 Kubernetes 기반 시스템을 만날 수도 있다.

이 과정에서 개발자는 특정 기술보다 더 중요한 능력을 익힌다.

새로운 기술을 빠르게 습득하는 방법이다.

좋은 개발자는 모든 기술을 알고 있는 사람이 아니다.

처음 보는 기술을 만났을 때 무엇부터 확인해야 하는지 아는 사람이다.

공식 문서를 찾는다.

샘플 프로젝트를 실행한다.

핵심 개념을 파악한다.

최소 기능을 구현한다.

테스트한다.

실제 시스템에 적용한다.

이 과정을 반복하면서 학습 속도 자체가 개발자의 경쟁력이 된다.

1.6 세 번째 장점: 커뮤니케이션 능력이 빠르게 성장한다#

많은 신입 개발자가 처음에는 이렇게 생각한다.

"개발자는 코딩만 잘하면 되는 것 아닌가?"

SI에 들어가면 이 생각이 빠르게 깨진다.

프로젝트에는 수많은 사람이 참여한다.

  • 고객사 담당자
  • 현업 사용자
  • 프로젝트 관리자
  • 프로젝트 리더
  • 기획자
  • 디자이너
  • 개발자
  • 데이터베이스 관리자
  • 인프라 담당자
  • 보안 담당자
  • 외부 솔루션 업체

개발자는 이들 사이에서 끊임없이 정보를 주고받는다.

그래서 커뮤니케이션 능력이 부족하면 코딩을 아무리 잘해도 프로젝트가 어려워질 수 있다.

1.6.1 고객의 말을 기술 언어로 변환한다#

고객은 항상 완벽한 요구사항을 전달하지 않는다.

예를 들어 고객이 이렇게 말할 수 있다.

"검색이 좀 더 빨랐으면 좋겠습니다."

개발자는 다시 질문해야 한다.

현재 검색 시간이 몇 초인가?

목표 응답 시간은 얼마인가?

검색 대상 데이터는 몇 건인가?

동시 사용자는 몇 명인가?

검색 조건은 무엇인가?

실시간 데이터가 필요한가?

캐시를 사용할 수 있는가?

단순한 한 문장이 실제 개발 요구사항으로 바뀌려면 수많은 질문이 필요하다.

좋은 SI 개발자는 고객의 표현을 그대로 코드로 옮기지 않는다.

모호한 요구를 검증 가능한 요구사항으로 바꾸는 능력을 갖게 된다.

1.6.2 안 되는 이유보다 가능한 대안을 설명한다#

고객이 기술적으로 좋지 않은 방법을 요구할 수도 있다.

초보 개발자는 말한다.

"그건 안 됩니다."

조금 경험이 생기면 이렇게 말한다.

"요청하신 방식으로 구현할 수는 있지만 이런 문제가 발생할 가능성이 있습니다."

더 경험이 많은 개발자는 한 단계 더 나아간다.

"원하시는 목적은 유지하면서 이 방법으로 구현하면 성능과 유지보수 측면에서 더 안전합니다."

개발자의 가치가 단순 구현자에서 기술 전문가로 올라가는 순간이다.

거절하는 능력보다 대안을 제시하는 능력이 중요하다.

1.7 네 번째 장점: 기록의 중요성을 몸으로 배운다#

SI 프로젝트를 경험하면 문서화가 왜 중요한지 자연스럽게 배우게 된다.

월요일 회의에서 고객이 말했다.

"A 방식으로 개발해 주세요."

개발팀은 일주일 동안 A 방식으로 개발했다.

그런데 다음 회의에서 고객이 말한다.

"제가 언제 A 방식으로 하라고 했습니까? B 방식으로 하기로 했잖아요."

회의록이 없다면 기억 싸움이 시작된다.

그래서 경험 있는 개발자는 기록한다.

  • 회의록
  • 요구사항
  • 변경 요청
  • 결정 사항
  • 장애 원인
  • 테스트 결과
  • 배포 기록

그리고 Jira, Redmine, GitHub Issues, GitLab, Confluence, Notion 등의 협업 도구를 활용해 변경 이력을 남긴다.

좋은 기록은 단순한 행정 업무가 아니다.

프로젝트의 기억 장치다.

동시에 자신의 업무를 보호하는 장치이기도 하다.

1.8 SI의 가장 큰 단점: 오픈 중심의 개발#

SI 프로젝트의 중요한 목표 중 하나는 정해진 날짜에 시스템을 오픈하는 것이다.

문제는 일정이 부족해질수록 장기적인 코드 품질보다 당장 기능을 완성하는 것이 우선될 수 있다는 것이다.

처음에는 이렇게 시작한다.

"일단 구현하고 나중에 정리하자."

하지만 프로젝트가 바빠지면 그 '나중'은 오지 않을 가능성이 높다.

그 결과 다음과 같은 코드가 쌓인다.

if (customerType.equals("A")) {
    // 임시 처리
}
// TODO 오픈 이후 리팩터링 필요
String temp1;
String temp2;
String temp3;

처음에는 작은 편법이었지만 시간이 지나면 시스템 곳곳에 누적된다.

이것이 기술 부채다.

1.9 기술 부채가 왜 문제가 되는가#

기술 부채는 단순히 코드가 지저분하다는 문제가 아니다.

새로운 기능 하나를 추가할 때 기존 기능 세 개가 깨진다.

어떤 코드를 수정하면 어디까지 영향을 미치는지 알 수 없다.

테스트 코드가 부족해 개발자가 직접 모든 화면을 확인해야 한다.

문서를 보지 않고 코드를 이해하기 어렵다.

결국 작은 기능 하나를 수정하는 데도 시간이 오래 걸린다.

개발 속도가 느려진다.

장애가 늘어난다.

다시 급하게 수정한다.

기술 부채가 더 늘어난다.

악순환이다.

SI 개발자에게 중요한 것은 기술 부채가 존재한다는 사실 자체가 아니다.

기술 부채를 당연한 개발 방식으로 받아들이지 않는 것이다.

프로젝트 일정이 아무리 촉박해도 최소한 다음 원칙 정도는 지킬 필요가 있다.

  • 의미 있는 변수명 사용
  • 핵심 로직 주석 작성
  • 반복 코드 제거
  • Git 커밋 기록 관리
  • 핵심 비즈니스 로직 테스트
  • 설정값과 코드 분리
  • 장애 원인 기록

이 작은 습관들이 몇 년 뒤 개발자의 수준을 크게 갈라놓는다.

1.10 두 번째 단점: 제품 오너십을 느끼기 어렵다#

SI 개발자는 시스템을 만들어 고객에게 전달한 뒤 다음 프로젝트로 이동하는 경우가 많다.

반면 서비스 회사의 개발자는 하나의 서비스를 오랫동안 개선한다.

기능을 만든다.

사용자에게 배포한다.

사용 데이터를 본다.

문제를 발견한다.

다시 개선한다.

이 과정을 반복한다.

이 과정에서 개발자는 제품이 성장하는 과정을 직접 경험한다.

SI에서는 이 경험이 상대적으로 부족할 수 있다.

몇 달 동안 밤낮없이 만든 시스템이 성공적으로 오픈됐는데 그 이후 사용자가 어떻게 이용하는지 알지 못한 채 다음 프로젝트로 이동할 수도 있다.

그래서 어떤 개발자는 이런 감정을 느낀다.

"나는 시스템을 만들었지만 이 서비스의 주인은 아니구나."

제품 성장에서 보람을 얻는 개발자라면 이러한 오너십 부족이 큰 단점이 될 수 있다.

반대로 하나의 서비스를 오래 관리하는 것보다 새로운 문제를 해결하는 데 재미를 느끼는 개발자라면 큰 문제가 아닐 수도 있다.

1.11 세 번째 단점: 기술 선택권이 제한될 수 있다#

SI에서는 개발자가 마음대로 기술을 선택할 수 없는 경우가 많다.

고객사가 정한 표준이 있기 때문이다.

예를 들어 다음과 같은 요구가 있을 수 있다.

  • 특정 Java 버전 사용
  • 지정된 데이터베이스 사용
  • 지정된 프레임워크 사용
  • 특정 상용 솔루션 사용
  • 폐쇄망 환경 개발
  • 외부 오픈소스 사용 제한

개발자 입장에서는 답답할 수 있다.

"더 좋은 기술이 있는데 왜 이것을 사용해야 하지?"

라는 생각이 들 수도 있다.

하지만 고객 입장에서는 다른 문제가 존재한다.

시스템을 앞으로 10년 이상 운영해야 할 수도 있다.

수십 개 시스템의 기술 표준을 통일해야 할 수도 있다.

보안 검증을 거쳐야 할 수도 있다.

운영 인력이 익숙한 기술을 사용해야 할 수도 있다.

따라서 SI의 기술 선택은 최신 기술과 운영 안정성 사이의 타협인 경우가 많다.

1.12 2026년에도 SI는 오래된 기술만 사용하는가#

반드시 그렇지는 않다.

과거 공공 SI를 설명할 때 흔히 등장하던 대표적인 표현이 전자정부 표준프레임워크, JSP, XML, 오래된 JDK였다.

하지만 이 역시 계속 변화하고 있다.

전자정부 표준프레임워크 5.0 개발 가이드 기준으로 실행 환경은 Spring 6.2 계열과 JDK 17 이상을 기반으로 하고 있으며 개발 환경에는 JDK 21이 사용된다. Jakarta EE 환경 역시 반영됐다.

공공기관의 클라우드 네이티브 전환 사업도 계속 진행되고 있다.

따라서 현재 SI 시장을 단순히

SI = JSP + Oracle + 오래된 Java

라고 정의하는 것은 적절하지 않다.

현실은 훨씬 복잡하다.

한쪽에는 오래된 시스템이 있고 다른 한쪽에는 다음과 같은 기술이 들어오는 프로젝트가 존재한다.

  • Spring Boot
  • Kubernetes
  • Docker
  • Kafka
  • Redis
  • PostgreSQL
  • 클라우드
  • 마이크로서비스
  • DevOps
  • CI/CD
  • 데이터 플랫폼
  • 생성형 AI 연계

결국 중요한 것은 SI냐 아니냐가 아니다.

어떤 프로젝트에 참여하느냐다.

1.13 네 번째 단점: 넓지만 얕은 개발자가 될 위험#

프로젝트가 계속 바뀌는 것은 장점이면서 동시에 위험이다.

6개월 동안 Java를 한다.

다음 프로젝트에서는 C#을 한다.

그다음에는 JavaScript를 한다.

또 다른 프로젝트에서는 Python을 사용한다.

이력서에는 기술이 점점 많아진다.

Java, Spring, C#, .NET, Python, React, Oracle, PostgreSQL, AWS, Docker….

겉으로 보면 화려하다.

하지만 면접관이 질문한다.

"가장 자신 있는 기술은 무엇인가요?"

"Spring의 트랜잭션이 내부적으로 어떻게 동작하는지 설명해보세요."

"데이터베이스 인덱스가 실제로 어떤 방식으로 검색 성능을 높이는지 설명해주세요."

대답하지 못한다.

이것이 SI 개발자가 빠지기 쉬운 기술 쇼핑의 함정이다.

기술을 많이 사용한 것과 기술을 잘 이해하는 것은 다르다.

1.14 물경력을 피하는 가장 중요한 방법#

물경력은 특정 회사에 다녔다고 자동으로 생기는 것이 아니다.

SI에 있다고 반드시 물경력이 되는 것도 아니다.

문제는 몇 년 동안 비슷한 작업만 반복하면서 자신의 역할이 확장되지 않을 때 발생한다.

1년 차에 화면과 CRUD를 만든다.

3년 차에도 화면과 CRUD만 만든다.

5년 차에도 화면과 CRUD만 만든다.

경력은 5년이지만 문제 해결 범위는 1년 차와 크게 달라지지 않는다.

이것이 위험한 상태다.

반대로 SI에 있더라도 다음과 같이 성장한다면 이야기가 달라진다.

1년 차에는 기능을 구현한다.

2년 차에는 데이터 모델과 API를 설계한다.

3년 차에는 성능 문제와 장애를 해결한다.

4년 차에는 시스템 구조를 설계한다.

5년 차에는 프로젝트의 기술 의사결정을 담당한다.

같은 SI 경력이라도 전혀 다른 개발자가 된다.

따라서 연차보다 중요한 질문은 이것이다.

작년보다 더 어려운 문제를 해결하고 있는가?

1.15 다섯 번째 단점: 프로젝트별 근무 환경 차이#

SI 개발자의 삶을 설명할 때 자주 등장하는 표현이 있다.

프로젝트마다 다르다.

어떤 프로젝트는 일정이 안정적이고 고객과의 관계도 좋다.

정시 퇴근이 가능하고 기술적으로도 배울 것이 많다.

반대로 어떤 프로젝트는 요구사항이 계속 변경되고 일정은 촉박하며 관리가 제대로 되지 않을 수도 있다.

같은 회사에서도 완전히 다른 경험이 발생한다.

따라서 SI 회사를 선택할 때 연봉과 회사 이름만 보면 부족하다.

실제로 확인해야 할 것은 다음과 같다.

  • 어떤 고객사가 많은가
  • 구축과 운영 비중이 어떻게 되는가
  • 자체 개발 인력이 얼마나 되는가
  • 하도급 구조가 어떤가
  • 프로젝트 평균 기간은 어느 정도인가
  • 상주 근무 비율은 어느 정도인가
  • 프로젝트 종료 후 대기 기간은 어떻게 관리되는가
  • 교육과 기술 지원이 있는가
  • 프로젝트를 선택하거나 변경할 수 있는가

SI에서는 회사보다 프로젝트 배치 정책이 개발자의 삶에 더 큰 영향을 미칠 수도 있다.

1.16 파견과 상주 근무의 현실#

SI 프로젝트는 고객 시스템에 직접 접근해야 하는 경우가 많다.

특히 금융, 공공, 제조 시스템은 보안상의 이유로 외부 접근이 제한되는 경우가 있다.

이 때문에 고객사 사무실이나 지정된 개발 공간에서 근무하는 상주 형태가 발생한다.

이것을 무조건 나쁘다고 볼 필요는 없다.

현업 담당자와 가까이 있기 때문에 업무를 빠르게 이해할 수 있다는 장점도 있다.

하지만 단점도 분명하다.

회사 구성원과 떨어져 일하면서 소속감이 약해질 수 있다.

프로젝트가 변경될 때마다 근무지가 바뀔 수 있다.

출퇴근 거리가 크게 달라질 수도 있다.

따라서 근무 위치와 상주 정책은 입사 전에 반드시 확인해야 하는 요소다.

1.17 SI에서 AI 시대에 더 중요해진 능력#

AI 코딩 도구의 확산은 SI 개발자의 역할도 바꾸고 있다.

단순한 CRUD 코드 작성이나 반복적인 테스트 코드 생성은 AI가 빠르게 지원할 수 있다.

SQL 초안을 만들고 API 샘플을 만들고 로그를 분석하는 작업도 AI의 도움을 받을 수 있다.

그렇다면 SI 개발자의 가치가 줄어들까?

오히려 반대 방향으로 볼 수도 있다.

AI가 코드 생성을 빠르게 해줄수록 사람에게 남는 중요한 업무는 다음과 같다.

  • 고객 요구사항 이해
  • 업무 프로세스 분석
  • 시스템 구조 설계
  • 데이터 모델링
  • 기존 시스템 분석
  • 보안 판단
  • 장애 대응
  • 테스트와 검증
  • 시스템 간 통합
  • 기술적 의사결정

AI는 "코드를 어떻게 작성하는가"에는 강해지고 있다.

하지만

"이 고객이 실제로 무엇을 원하는가?"

"이 시스템을 변경하면 어느 업무에 영향을 미치는가?"

"이 요구사항이 기존 시스템과 충돌하지 않는가?"

와 같은 문제는 여전히 깊은 업무 이해와 경험을 필요로 한다.

그래서 AI 시대의 SI 개발자는 단순 코더보다 기술과 업무를 연결하는 엔지니어로 성장해야 한다.

1.18 어떤 사람에게 SI가 잘 맞을까#

SI가 모든 개발자에게 좋은 환경은 아니다.

하지만 특정 성향의 개발자에게는 매우 강력한 성장 환경이 될 수 있다.

1.18.1 다양한 문제를 경험하고 싶은 사람#

한 가지 서비스를 오랫동안 개발하는 것보다 새로운 산업과 새로운 문제를 계속 만나는 것을 좋아한다면 SI가 잘 맞을 수 있다.

금융을 경험하고 제조를 경험하고 물류를 경험하다 보면 기술뿐 아니라 산업 전체를 바라보는 시야가 넓어진다.

장기적으로 다음과 같은 역할을 생각하는 사람에게 특히 도움이 될 수 있다.

  • 기술 리더
  • 솔루션 아키텍트
  • 시스템 아키텍트
  • 프로젝트 관리자
  • 기술 프로젝트 관리자
  • 정보기술 컨설턴트

1.18.2 스스로 공부하는 사람#

SI에서는 모든 기술을 회사에서 교육해주기를 기대하기 어렵다.

프로젝트에 필요한 기술이 생기면 빠르게 학습해야 한다.

따라서 스스로 공식 문서를 읽고 테스트하고 문제를 해결하는 사람에게 유리하다.

특히 AI 도구가 발달한 현재는 학습 속도를 크게 높일 수 있다.

하지만 AI의 답을 그대로 복사하는 사람과 AI를 활용하면서 원리를 이해하는 사람 사이의 실력 차이는 시간이 갈수록 커질 가능성이 높다.

1.18.3 제품보다 문제 해결을 좋아하는 사람#

하나의 제품을 몇 년 동안 키우는 일보다 새로운 문제를 해결하는 과정에서 즐거움을 느끼는 사람이 있다.

장애 원인을 찾아냈을 때 재미를 느낀다.

복잡한 업무를 시스템으로 만드는 것이 재미있다.

모두 어렵다고 하던 문제를 해결했을 때 성취감을 느낀다.

이런 사람은 SI의 다양한 프로젝트 환경을 즐길 가능성이 높다.

1.19 신입에게 SI는 좋은 선택일까#

조건이 맞는다면 좋은 출발점이 될 수 있다.

다만 중요한 전제가 있다.

SI 회사라는 이름만 보고 선택해서는 안 된다.

신입이라면 다음을 확인하는 것이 좋다.

프로젝트#

신규 구축 프로젝트가 많은가?

운영·유지보수 프로젝트가 많은가?

기술#

최근 프로젝트에서 어떤 기술을 사용했는가?

Java와 Spring만 이야기하는 것이 아니라 실제 버전까지 확인하는 것이 좋다.

역할#

신입 개발자가 실제 개발을 하는가?

아니면 문서 작성과 단순 테스트 업무만 담당하는가?

개발 문화#

Git을 사용하는가?

코드 리뷰를 하는가?

테스트 코드를 작성하는가?

CI/CD 환경이 있는가?

성장#

프로젝트가 끝난 뒤 다른 분야로 이동할 기회가 있는가?

기술 교육이나 스터디 지원이 있는가?

이 질문에 대한 답을 확인하면 SI 회사의 실제 개발 환경을 훨씬 정확하게 파악할 수 있다.

1.20 SI에서 3년을 보낸다면 무엇을 얻어야 하는가#

SI에서 중요한 것은 몇 년을 버티는 것이 아니다.

그 기간 동안 무엇을 가져가느냐가 중요하다.

예를 들어 3년 동안 다음과 같은 목표를 세울 수 있다.

1년 차#

  • Java 또는 주력 언어 숙련
  • Spring Boot 이해
  • SQL 능력 향상
  • Git 사용
  • REST API 개발
  • 기본적인 Linux 사용
  • 요구사항 이해

2년 차#

  • 데이터베이스 설계
  • 트랜잭션 이해
  • 성능 튜닝
  • 장애 분석
  • 외부 시스템 연동
  • 테스트 자동화
  • Docker 경험

3년 차#

  • 시스템 설계
  • 클라우드 경험
  • CI/CD
  • 메시징 시스템
  • 모니터링
  • 기술 의사결정
  • 후배 개발자 코드 리뷰

이렇게 경력을 설계하면 프로젝트가 바뀌더라도 자신의 성장 방향을 유지할 수 있다.

1.21 가장 위험한 것은 SI가 아니라 목표 없는 경력이다#

개발자 커뮤니티에서는 종종 이런 질문이 나온다.

"SI 가면 커리어 망하나요?"

하지만 더 중요한 질문이 있다.

"그곳에서 무엇을 배울 것인가?"

서비스 회사에서도 몇 년 동안 단순 유지보수만 반복하면 성장하지 못할 수 있다.

반대로 SI에서도 대규모 시스템과 다양한 산업을 경험하면서 뛰어난 엔지니어로 성장할 수 있다.

결국 회사를 구분하는 간판보다 중요한 것은 경험의 질이다.

좋은 경력은 단순히 오래 일했다고 만들어지지 않는다.

어떤 문제를 만났는가.

어떤 책임을 맡았는가.

어떤 실패를 경험했는가.

그 문제를 어떻게 해결했는가.

그 과정에서 무엇을 배웠는가.

이것들이 쌓여 개발자의 경력이 된다.

1.22 SI를 커리어 점프대로 활용하는 방법#

SI를 전략적으로 활용하려면 프로젝트가 주어지는 대로 일하기만 해서는 부족하다.

자신의 경력을 의식적으로 관리해야 한다.

예를 들어 금융 프로젝트를 하고 있다면 단순히 화면 개발만 하고 끝내지 않는다.

금융 시스템에서 트랜잭션이 어떻게 처리되는지 공부한다.

대량 거래가 들어올 때 어떤 문제가 발생하는지 살펴본다.

장애가 발생했을 때 어떤 방식으로 복구하는지 알아본다.

DB 구조를 이해한다.

메시징 구조를 살펴본다.

이렇게 하면 프로젝트 하나가 단순 경력 한 줄이 아니라 전문성이 된다.

물류 프로젝트에 참여했다면 물류 도메인을 공부한다.

제조 프로젝트를 했다면 생산관리 시스템의 구조를 이해한다.

SI의 가장 큰 장점인 다양한 경험을 전문 지식으로 변환하는 과정이 필요하다.

1.23 결국 SI는 양날의 검이다#

SI에는 분명한 단점이 있다.

프로젝트에 따라 근무 환경이 크게 달라질 수 있다.

기술 선택권이 제한될 수 있다.

제품 오너십을 느끼기 어려울 수 있다.

일정에 쫓기면 기술 부채가 만들어질 가능성도 있다.

프로젝트를 계속 옮기면서 기술의 깊이를 놓칠 위험도 존재한다.

하지만 동시에 강력한 장점도 있다.

다양한 산업을 경험할 수 있다.

복잡한 업무를 이해하는 능력이 생긴다.

문제 해결 능력이 빠르게 성장한다.

고객과 커뮤니케이션하는 법을 배운다.

시스템이 실제 기업에서 어떻게 운영되는지 경험한다.

그리고 좋은 프로젝트를 반복해서 경험한다면 짧은 기간에도 상당한 실무 능력을 확보할 수 있다.

그래서 SI를 단순하게

"좋은 곳"

또는

"나쁜 곳"

이라고 정의하는 것은 큰 의미가 없다.

더 중요한 것은 세 가지 질문이다.

나는 이 프로젝트에서 무엇을 배우고 있는가?

작년보다 더 어려운 문제를 해결하고 있는가?

지금의 경험이 다음 커리어에서 어떤 가치가 있는가?

이 세 질문에 계속 답할 수 있다면 SI는 개발자의 커리어를 망치는 장소가 아니라 강력한 훈련장이 될 수 있다.

반대로 아무 생각 없이 프로젝트를 옮겨 다니며 비슷한 일만 반복한다면 경력 연차만 늘어날 수도 있다.

SI의 진짜 생존 법칙은 의외로 단순하다.

프로젝트에 끌려다니지 말고 프로젝트를 자신의 경력으로 만들어라.

SI라는 정글에서 가장 중요한 무기는 특정 프로그래밍 언어나 프레임워크가 아니다.

새로운 환경에 빠르게 적응하는 능력, 복잡한 문제의 핵심을 찾아내는 능력, 사람과 기술을 연결하는 능력, 그리고 자신의 경력을 스스로 설계하는 능력이다.

그 무기를 갖춘 개발자에게 SI는 단순한 외주 개발 현장이 아니다.

수많은 산업과 시스템을 경험하며 개발자로서의 전투력을 빠르게 끌어올릴 수 있는 거대한 실전 훈련장이 된다.

#관련 참고 도서#

개발자라고 다 같은 개발자가 아니다#

SI, 스타트업, 대기업, 빅테크, 게임회사 등 개발자가 일하게 되는 다양한 환경의 차이와 커리어 선택 기준을 현실적으로 다루는 개발자 커리어 가이드입니다.

단순히 코딩 기술을 배우는 데서 그치지 않고, 어떤 회사와 조직에서 어떤 방식으로 성장해야 하는지, 좋은 개발 문화를 어떻게 구별하는지, '코더'가 아닌 '엔지니어'로 성장하려면 무엇이 필요한지를 살펴봅니다. 신입·주니어 개발자가 첫 직장을 선택하거나 이직 방향을 고민할 때 참고하기 좋은 내용으로 구성되어 있습니다.

교보문고에서 전자책 보기

이 페이지의 목차