중소기업·웹에이전시 개발자의 현실: 무엇이든 해야 하는 멀티플레이어의 세계

중소기업·웹에이전시 개발자의 현실: 무엇이든 해야 하는 멀티플레이어의 세계#

오전 9시 12분.

출근한 지 10분도 지나지 않았는데 메신저가 울린다.

"OO쇼핑몰에서 결제가 안 된다고 합니다."

코드를 열어본다.

PHP다.

그런데 평소 보던 Laravel이나 Symfony 같은 프레임워크가 아니다.

파일 상단에는 이런 코드가 보인다.

include_once("./_common.php");

조금 아래에는 SQL이 직접 들어 있다.

$sql = "select * from g5_member where mb_id = '$mb_id'";

익숙한 냄새가 난다.

그누보드다.

몇 줄 아래로 내려가니 2013년에 작성된 주석이 나온다.

// 임시 수정 - 나중에 정리 필요

그 코드를 작성한 개발자가 누구인지 아무도 모른다.

Git 기록도 없다.

문서는 더더욱 없다.

당시에는 분명 '임시'였겠지만 13년이 지난 지금까지 운영되고 있다.

문제를 겨우 수정하고 나니 이번에는 전화가 온다.

"고객사에서 메인 페이지 배너 위치 좀 바꿔달라고 합니다."

CSS를 수정한다.

잠시 후 또 다른 메시지가 온다.

"서버 용량이 꽉 찼어요."

SSH로 접속한다.

로그 파일을 찾는다.

용량을 정리한다.

오후에는 새로운 기업 홈페이지 견적을 위해 기획자와 회의한다.

퇴근 직전에는 고객이 말한다.

"모바일에서 글자가 조금 작아 보이는데요."

결국 다시 CSS를 연다.

하루 동안 PHP 개발자였다.

프런트엔드 개발자였다.

서버 관리자였다.

DB 관리자였다.

고객 지원 담당자였다.

때로는 기획자까지 된다.

이곳이 바로 중소기업·웹에이전시 개발자의 세계다.

화려한 기술 콘퍼런스에서 이야기하는 쿠버네티스나 수십억 건의 데이터 처리와는 조금 다른 세계다.

여기에서 가장 중요한 질문은

"어떤 기술이 가장 우아한가?"

가 아니다.

대부분 다음과 같다.

"오늘 안에 해결할 수 있는가?"

1.1 중소기업·웹에이전시는 하나의 회사 유형이 아니다#

먼저 한 가지를 구분할 필요가 있다.

중소기업과 웹에이전시는 매우 넓은 범위의 회사들을 포함한다.

직원 세 명이 홈페이지를 제작하는 작은 업체도 있다.

수십 명의 개발자가 기업 시스템을 만드는 회사도 있다.

자체 솔루션을 판매하는 회사도 있다.

쇼핑몰 구축 전문 업체도 있다.

디지털 마케팅과 웹 개발을 함께 하는 에이전시도 있다.

따라서

"중소기업 개발자는 다 이렇다."

라고 단정할 수는 없다.

하지만 규모가 작은 개발 조직에서는 공통적으로 나타나는 특징이 있다.

한 사람이 담당해야 하는 업무의 범위가 넓다.

1.2 웹에이전시 개발자는 무엇을 만드는가#

웹에이전시는 기업이나 기관의 의뢰를 받아 웹사이트와 서비스를 만들어주는 회사다.

대표적인 프로젝트는 다음과 같다.

  • 기업 홈페이지
  • 쇼핑몰
  • 병원 홈페이지
  • 학교 사이트
  • 예약 시스템
  • 관리자 페이지
  • 이벤트 사이트
  • 랜딩 페이지
  • 회원관리 시스템
  • 내부 업무 사이트

프로젝트 규모가 작을수록 한 개발자가 담당하는 범위가 넓어진다.

프런트엔드를 별도 팀에서 만들지 않는다.

백엔드를 별도 팀에서 만들지 않는다.

DevOps 팀도 없다.

DBA도 없다.

결국 개발자가 상당 부분을 처리한다.

그래서 중소 웹에이전시의 개발자는 자연스럽게 풀스택 개발자가 된다.

하지만 여기에서 말하는 풀스택은 최신 웹 개발에서 이야기하는

React + Node.js + AWS

같은 의미와 조금 다를 수 있다.

실제로는

HTML + CSS + JavaScript + PHP + MySQL + Linux + FTP + Apache

를 모두 다루는 형태에 가까울 수도 있다.

1.3 첫 번째 특징: PHP는 아직도 살아 있다#

개발 커뮤니티를 보면 가끔 이런 이야기가 나온다.

"요즘 누가 PHP를 써?"

하지만 현실 세계는 조금 다르다.

오랫동안 운영된 기업 홈페이지, 쇼핑몰, 커뮤니티 사이트 상당수는 PHP 기반이다.

WordPress도 PHP 기반이고, 국내에서는 그누보드나 영카트 같은 솔루션도 오랫동안 사용되어 왔다.

그래서 웹에이전시나 유지보수 회사에서는 여전히 PHP 코드를 만날 가능성이 있다.

문제는 PHP라는 언어 자체가 아니다.

어떤 시대의 PHP를 만나느냐다.

최신 PHP와 Composer, 테스트, 프레임워크를 사용하는 환경도 있다.

반면 이런 코드도 만날 수 있다.

mysql_query($sql);

또는 하나의 PHP 파일 안에

HTML,

SQL,

JavaScript,

비즈니스 로직

이 모두 들어 있을 수도 있다.

개발자는 한숨을 쉰다.

"이걸 어디서부터 고쳐야 하지?"

1.4 ASP와 ASP.NET, 그리고 아직 살아 있는 오래된 시스템#

또 하나 자주 만나는 것이 ASP 계열이다.

여기서 구분이 필요하다.

현대적인 ASP.NET Core와 오래된 Classic ASP는 완전히 다른 세대의 기술이다.

하지만 오래 운영된 기업 사이트나 업무 시스템에서는 여전히 Classic ASP 기반 코드를 만날 가능성이 있다.

코드를 열면 이런 모습이다.

<%
Set rs = Server.CreateObject("ADODB.Recordset")
sql = "SELECT * FROM MEMBER"
rs.Open sql, db
%>

개발자는 생각한다.

"이 코드가 언제 만들어진 거지?"

파일 수정 날짜를 확인한다.

2009년.

그런데 여전히 회사 매출과 연결되어 있다.

바꿀 수도 없다.

잘못 수정하면 서비스가 멈춘다.

결국 개발자는 새로운 시스템을 만드는 것이 아니라 과거의 개발자와 대화하는 고고학자가 된다.

1.5 그누보드와의 사투#

한국 중소 웹 개발 환경을 이야기하면서 그누보드를 빼놓기 어렵다.

그누보드는 빠르게 게시판과 회원 시스템을 구축하기에 편리하다.

특히 예산이 제한된 프로젝트에서는 강력한 장점이 있다.

문제는 시간이 흐르면서 발생한다.

처음에는 기본 그누보드였다.

고객이 기능을 요청한다.

개발자가 수정한다.

다른 고객 요구가 들어온다.

또 수정한다.

몇 년 뒤 다시 다른 개발자가 수정한다.

플러그인이 들어간다.

직접 만든 코드가 들어간다.

원본 파일도 수정한다.

몇 년이 지나면 누구도 정확한 구조를 모르는 시스템이 된다.

업데이트하려고 하면 문제가 발생한다.

"이 파일은 원본인가요?"

"아니요. 예전에 커스터마이징한 것 같습니다."

"누가 했나요?"

"퇴사한 개발자 같습니다."

바로 이 순간부터 레거시 탐험이 시작된다.

1.6 레거시 코드는 나쁜 코드만을 의미하지 않는다#

레거시라는 말을 들으면 흔히 이런 모습을 떠올린다.

변수명이 이상하다.

함수가 수천 줄이다.

SQL이 곳곳에 흩어져 있다.

주석이 없다.

테스트도 없다.

물론 실제로 그런 코드도 존재한다.

하지만 레거시 코드의 본질은 조금 다르다.

현재 비즈니스가 의존하고 있지만 쉽게 변경하기 어려운 코드다.

코드는 낡았지만 회사 매출을 만들어내고 있다.

개발자는 마음대로 갈아엎을 수 없다.

결국 중요한 능력은

"이 코드는 쓰레기니까 새로 만들어야 합니다."

라고 말하는 것이 아니다.

서비스를 멈추지 않고 안전하게 개선하는 능력이다.

1.7 첫 번째 장점: 취업의 현실적인 첫 관문이 될 수 있다#

최근 개발자 채용 시장에서는 신입 채용이 경력직보다 훨씬 적은 구조가 계속 나타나고 있다.

2026년 초 공개된 국내 개발자 채용시장 분석에서도 백엔드와 프런트엔드 모두 경력직 수요에 비해 신입 공고 비율이 낮은 것으로 조사됐다.

대기업이나 플랫폼 기업에 신입으로 입사하려면 경쟁이 매우 치열하다.

코딩 테스트.

CS 지식.

프로젝트.

포트폴리오.

인턴 경험.

여러 조건을 요구한다.

반면 규모가 작은 웹 개발 회사에서는 상대적으로 실무 투입 가능성을 더 중요하게 보는 경우가 있다.

PHP 할 줄 아세요?

MySQL 사용할 수 있나요?

HTML/CSS 수정할 수 있나요?

Linux 조금 볼 수 있나요?

쇼핑몰 만들어본 적 있나요?

이 질문에 답할 수 있다면 첫 실무 기회를 얻을 가능성이 있다.

그래서 중소 웹 개발 회사는 개발자로 진입하기 위한 현실적인 첫 발판이 되기도 한다.

1.8 두 번째 장점: 매우 빠르게 실무를 경험한다#

직원이 적기 때문에 신입이라고 오랫동안 옆에서 구경만 하고 있을 수 없다.

입사한 첫 주부터 업무가 주어진다.

"이 게시판 수정해주세요."

다음 주에는

"회원가입에 휴대폰 인증 붙여주세요."

한 달 뒤에는

"쇼핑몰 하나 맡아주세요."

세 달 뒤에는 고객과 직접 통화할 수도 있다.

다른 회사에서 1년 후에 경험할 일을 몇 달 만에 경험하기도 한다.

이것은 매우 강력한 장점이다.

1.9 멀티플레이어가 되는 과정#

작은 개발 조직에서는 담당자가 없다는 이유로 문제가 사라지지 않는다.

서버가 느리다.

누군가는 확인해야 한다.

DB가 느리다.

누군가는 SQL을 본다.

DNS를 바꿔야 한다.

개발자가 확인한다.

SSL 인증서가 만료됐다.

개발자가 갱신한다.

메일이 안 간다.

SMTP를 본다.

고객이 화면을 수정해달라고 한다.

CSS를 수정한다.

검색 노출이 안 된다고 한다.

SEO도 확인한다.

결국 몇 년 지나면 개발자는 굉장히 넓은 영역을 다루게 된다.

  • HTML
  • CSS
  • JavaScript
  • PHP
  • ASP
  • MySQL
  • MariaDB
  • Linux
  • Apache
  • Nginx
  • DNS
  • SSL
  • 서버 이전
  • 백업
  • SEO
  • 웹 접근성
  • 고객 응대

명함에는 개발자라고 적혀 있지만 실제로는 웹 서비스를 운영하기 위해 필요한 거의 모든 일을 해본 사람이 된다.

1.10 세 번째 장점: 장애 대응 능력이 빠르게 생긴다#

오후 4시.

고객이 전화한다.

"홈페이지가 안 열려요."

이 순간부터 개발자의 머리는 빠르게 돌아간다.

서버가 죽었나?

DNS 문제인가?

DB가 죽었나?

디스크가 꽉 찼나?

SSL 인증서가 만료됐나?

PHP 오류인가?

외부 API 문제인가?

처음에는 어디를 봐야 할지 모른다.

하지만 이런 일을 반복하면 장애를 보는 순서가 생긴다.

서비스 확인.

로그 확인.

서버 상태 확인.

DB 확인.

최근 변경 사항 확인.

외부 연동 확인.

이것이 실무 경험이다.

책만 읽어서는 쉽게 얻기 어려운 능력이다.

1.11 고객과 직접 이야기하면서 요구사항을 배우게 된다#

웹에이전시 개발자의 숨겨진 장점 중 하나는 고객과의 거리가 가깝다는 것이다.

고객이 말한다.

"홈페이지를 좀 고급스럽게 만들어주세요."

개발자는 당황한다.

고급스럽다는 것은 무엇인가?

색상인가?

폰트인가?

레이아웃인가?

애니메이션인가?

다시 질문한다.

이 과정을 반복하다 보면 개발자는 모호한 고객 요구를 실제 기능으로 바꾸는 능력을 배우게 된다.

또 다른 고객은 말한다.

"로그인하면 고객별로 가격을 다르게 보여주세요."

처음에는 간단해 보인다.

하지만 질문이 생긴다.

고객 등급은 몇 개인가?

가격은 누가 관리하는가?

상품별로 다른가?

할인과 중복되는가?

세금 계산은 어떻게 하는가?

개발자는 자연스럽게 요구사항 분석 능력을 익힌다.

1.12 네 번째 장점: 한 프로젝트의 처음과 끝을 경험한다#

대규모 회사에서는 개발자가 서비스의 일부만 담당할 가능성이 높다.

웹에이전시에서는 작은 프로젝트 하나를 처음부터 끝까지 경험할 수 있다.

고객 미팅.

요구사항.

DB 설계.

퍼블리싱.

개발.

테스트.

서버 세팅.

도메인 연결.

배포.

유지보수.

서비스 생명주기 전체를 경험한다.

규모는 작지만 A부터 Z까지 직접 해봤다는 경험은 상당히 가치가 있다.

특히 향후 프리랜서나 창업을 생각한다면 큰 자산이 된다.

1.13 그러나 이 경험이 다른 회사에서도 인정될까#

여기서 가장 중요한 문제가 시작된다.

경험은 많다.

PHP도 해봤다.

JavaScript도 했다.

Linux도 만졌다.

DB도 관리했다.

고객도 상대했다.

쇼핑몰도 만들었다.

그런데 플랫폼 회사 면접에 갔다.

질문이 나온다.

"대규모 트래픽을 처리해본 경험이 있나요?"

없다.

"CI/CD 환경은 어떻게 구축했나요?"

FTP로 올렸다.

"자동화 테스트 경험은요?"

거의 없다.

"컨테이너 환경을 운영해봤나요?"

없다.

순간 깨닫는다.

많은 경험을 했지만 시장에서 요구하는 경험과 정확하게 겹치지 않을 수 있다.

1.14 넓은 경험과 시장성이 높은 경험은 다르다#

웹에이전시에서 3년 일한 개발자와 플랫폼 기업에서 3년 일한 개발자를 비교해보자.

웹에이전시 개발자는

30개 사이트를 만들었을 수도 있다.

수십 개 DB를 만졌다.

서버 이전도 했다.

고객도 직접 상대했다.

하지만 대부분 사용자가 하루 수백 명인 서비스였다.

플랫폼 개발자는

서비스 하나만 담당했을 수 있다.

하지만 사용자 수가 수백만 명이다.

대규모 트래픽.

분산 시스템.

자동화 테스트.

CI/CD.

모니터링.

클라우드.

이런 경험을 깊게 했다.

누가 더 뛰어난 개발자인가?

단순하게 비교할 수 없다.

경험의 종류가 다르다.

문제는 이직하려는 회사가 어느 경험을 원하는지다.

1.15 다섯 번째 장점: 이직할 회사의 숫자는 많을 수 있다#

웹 개발을 필요로 하는 회사는 매우 많다.

모든 회사가 대규모 플랫폼을 만드는 것은 아니다.

기업 홈페이지가 필요하다.

쇼핑몰이 필요하다.

예약 시스템이 필요하다.

내부 관리 페이지가 필요하다.

기존 PHP 사이트를 유지해야 한다.

그래서 웹 개발 실무 경험이 있으면 비슷한 규모와 성격의 회사 사이에서는 비교적 이동하기 쉬울 수 있다.

특히 다음 경험은 바로 활용될 가능성이 높다.

  • PHP
  • MySQL
  • WordPress
  • 그누보드
  • 쇼핑몰 구축
  • 웹 유지보수
  • Linux
  • 웹 서버 관리

즉 같은 생태계 안에서는 이동성이 높은 편일 수 있다.

1.16 하지만 위로 이동하는 이직은 별개의 문제다#

문제는 다음 단계다.

웹에이전시에서

제품 회사.

플랫폼 기업.

대기업 개발 조직.

클라우드 회사.

같은 환경으로 이동하려 하면 요구 역량이 달라진다.

단순 PHP 경험만으로는 부족할 수 있다.

다음 역량을 요구할 가능성이 높아진다.

  • CS 기본기
  • 테스트 자동화
  • Git 기반 협업
  • API 설계
  • 객체지향 설계
  • 클라우드
  • Docker
  • CI/CD
  • 모니터링
  • 시스템 설계
  • 성능 최적화

그래서 웹에이전시에서 일할 때 가장 위험한 생각은 이것이다.

"회사에서 하는 일만 열심히 하면 언젠가 자연스럽게 더 좋은 회사로 갈 수 있겠지."

반드시 그렇지는 않다.

다음 시장에서 필요한 기술을 별도로 준비해야 할 수도 있다.

1.17 첫 번째 단점: 상대적으로 낮은 보상#

중소기업과 웹에이전시의 가장 현실적인 단점 가운데 하나가 보상이다.

물론 회사별 편차가 매우 크다.

좋은 기술 회사도 있고 경쟁력 있는 연봉을 주는 중소기업도 있다.

하지만 전체적으로 보면 기업 규모와 업종은 개발자 보상에 상당한 영향을 준다.

2026년 한국 개발자 대상 소규모 설문에서도 경력 연차뿐 아니라 고용주 유형에 따라 보상 수준 차이가 크게 나타났다.

작은 웹에이전시는 사업 구조 자체가 높은 개발자 연봉을 지급하기 어려운 경우도 많다.

고객이 홈페이지 제작에 1,000만 원을 지급한다.

기획자.

디자이너.

퍼블리셔.

개발자.

영업.

회사 운영비.

모두 이 금액 안에서 해결해야 한다.

개발자 한 명에게 높은 인건비를 지급하기 어려운 구조다.

1.18 프로젝트 단가가 개발 환경을 결정하기도 한다#

고객이 말한다.

"홈페이지 하나 만드는 데 왜 3개월이나 걸리나요?"

"다른 회사는 절반 가격에 해준다고 하던데요."

가격 경쟁이 심해진다.

회사에서는 프로젝트를 빨리 끝내야 한다.

그러면 어떤 일이 발생할까?

기존 솔루션을 재사용한다.

코드를 복사한다.

테스트 시간을 줄인다.

문서화를 줄인다.

일정을 줄인다.

결국 개발자가 경험하게 되는 환경 역시 프로젝트 단가의 영향을 받는다.

저가 프로젝트가 반복되면

좋은 코드를 만드는 것보다 빨리 납품하는 능력이 더 중요해질 수 있다.

1.19 두 번째 단점: 사수가 없을 가능성이 높다#

작은 회사에서 신입 개발자가 입사했다.

개발팀은 세 명이다.

한 명은 팀장이다.

하지만 팀장은 프로젝트 세 개를 동시에 관리한다.

다른 한 명은 다음 달 퇴사 예정이다.

결국 신입 개발자가 혼자 코드를 수정한다.

모르면 인터넷에서 찾는다.

2026년에는 AI에게 물어보는 경우도 많다.

AI가 코드를 만들어준다.

작동한다.

그런데 좋은 코드인지는 모른다.

몇 년 동안 이런 방식으로 개발하면 문제가 생길 수 있다.

잘못된 습관을 교정해주는 사람이 없기 때문이다.

1.20 AI 시대에는 이 문제가 더 커질 수도 있다#

AI 코딩 도구는 작은 개발 조직에서 매우 강력하다.

예전에는 혼자 만들기 어려웠던 기능도 빠르게 구현할 수 있다.

하지만 AI가 생성한 코드를 이해하지 않고 붙여 넣는 방식이 반복되면 또 다른 형태의 레거시가 만들어질 수 있다.

특히 기존 PHP나 ASP 시스템에서

"이 코드 고쳐줘."

라고 AI에게 요청하고 결과를 계속 붙이다 보면 시스템 전체 구조는 더욱 복잡해질 수 있다.

AI 시대의 중소기업 개발자에게 중요한 것은

코드를 생성하는 능력보다 생성된 코드를 판단하고 정리하는 능력이다.

1.21 세 번째 단점: 기술 선택권이 없을 수도 있다#

개발자가 말한다.

"이번에는 Next.js로 새로 만들어보죠."

회사가 대답한다.

"우리 고객 서버가 PHP 호스팅인데?"

개발자가 말한다.

"Docker 환경을 구축하면 어떨까요?"

회사에서는 말한다.

"고객이 FTP로 파일 올리는 방식만 사용할 수 있대."

결국 기존 방식을 따라간다.

웹에이전시에서는 고객 인프라와 예산이 기술 선택을 결정하는 경우가 많다.

최신 기술이 더 좋아도 사용할 수 없다.

그래서 새로운 기술을 배우고 싶다면 회사 프로젝트만 기다리지 말고 별도의 프로젝트를 만들어야 할 수도 있다.

1.22 네 번째 단점: 복붙 개발의 유혹#

비슷한 홈페이지를 계속 만든다.

회원가입.

로그인.

게시판.

관리자.

문의 폼.

프로젝트마다 요구사항은 조금씩 다르지만 구조는 비슷하다.

시간이 부족하다.

개발자는 생각한다.

"지난번 프로젝트 코드 가져오면 되겠는데?"

복사한다.

조금 수정한다.

다음 프로젝트에서도 다시 복사한다.

몇 년 지나면 회사 서버에는

project_final
project_final2
project_final_real
project_new
project_new2

같은 폴더가 쌓인다.

개발자는 많은 프로젝트를 했지만 실제로는 같은 코드를 계속 수정했을 수도 있다.

이것이 웹에이전시 경력에서 가장 경계해야 하는 함정이다.

프로젝트 수와 성장량은 비례하지 않는다.

1.23 다섯 번째 단점: 내가 개발자인지 잡무 담당자인지 헷갈릴 수 있다#

작은 조직에서는 모든 IT 문제가 개발자에게 온다.

프린터가 안 된다.

"개발팀에 물어봐."

메일이 안 간다.

"개발자한테 물어봐."

공유기가 이상하다.

"개발자면 알지 않을까?"

도메인이 만료됐다.

"개발자한테 알려줘."

엑셀 매크로가 안 된다.

"개발팀에서 좀 봐주세요."

어느 순간 생각한다.

"내가 백엔드 개발자인가? 전산 담당자인가?"

멀티플레이 경험이 장점이지만 선을 넘으면 전문성을 쌓을 시간이 사라진다.

1.24 반대로 이 경험은 창업이나 프리랜서에 매우 강하다#

재미있는 점은 다른 테크 기업에서는 높게 평가되지 않을 수 있는 경험이 어떤 경로에서는 엄청난 경쟁력이 된다는 것이다.

예를 들어 프리랜서가 된다고 해보자.

고객이 묻는다.

"도메인도 연결해줄 수 있나요?"

할 수 있다.

"서버도 세팅해주실 수 있나요?"

할 수 있다.

"결제도 붙일 수 있나요?"

해봤다.

"SEO도 조금 봐주실 수 있나요?"

해봤다.

"기존 PHP 사이트도 고칠 수 있나요?"

할 수 있다.

이 개발자는 한 사람으로 프로젝트 하나를 끝낼 수 있다.

이것은 상당히 강력하다.

스타트업 창업에서도 마찬가지다.

아이디어가 있다.

혼자 MVP를 만든다.

서버를 올린다.

도메인을 연결한다.

결제를 붙인다.

서비스를 출시한다.

중소 웹 개발 환경에서 얻은 끝까지 만들어내는 능력이 엄청난 장점이 된다.

1.25 결국 중요한 것은 어디로 갈 것인가다#

웹에이전시 경험 자체가 좋은 경력인지 나쁜 경력인지 단순하게 판단할 수 없다.

목적지에 따라 달라진다.

계속 웹 구축 분야에서 일하고 싶다면#

매우 직접적인 경험이다.

프리랜서를 하고 싶다면#

강력한 경험이다.

작은 사업을 직접 만들고 싶다면#

상당히 유용하다.

플랫폼 백엔드 개발자로 이동하고 싶다면#

추가적인 준비가 필요하다.

클라우드나 DevOps로 가고 싶다면#

기존 서버 경험을 현대적인 기술로 확장해야 한다.

경험의 가치는 어디에 사용할 것인가에 따라 달라진다.

1.26 중소기업·웹에이전시에서 물경력을 피하는 방법#

가장 중요한 부분이다.

회사가 최신 기술을 사용하지 않는다고 해서 반드시 물경력이 되는 것은 아니다.

문제는 자신의 경험을 그대로 방치하는 것이다.

예를 들어 PHP 프로젝트를 하고 있다고 해보자.

단순히 PHP 코드만 수정하지 않는다.

API 설계를 공부한다.

SQL을 최적화한다.

Git을 제대로 사용한다.

테스트 코드를 만들어본다.

Docker로 개발 환경을 만들어본다.

CI/CD를 개인적으로 구축해본다.

AWS나 다른 클라우드에 올려본다.

즉 기존 업무를 현대적인 개발 방식과 연결한다.

1.27 레거시 경험을 현대화 경험으로 바꿔라#

예를 들어 15년 된 PHP 시스템을 담당한다.

그냥 유지보수했다고 쓰면 경력은 이렇게 보인다.

PHP 홈페이지 유지보수

하지만 실제로 다음 일을 했다면 완전히 달라진다.

PHP 5 기반 레거시 시스템을 분석해 PHP 8 환경으로 단계적으로 이전

직접 SQL이 섞여 있던 코드를 서비스 계층으로 분리

Git 기반 버전 관리 도입

Docker 개발 환경 구축

반복 배포 작업 자동화

오래된 jQuery 화면을 일부 현대화

이것은 단순 유지보수가 아니다.

레거시 현대화 경험이다.

같은 회사에서도 어떤 시각으로 일하느냐에 따라 경력의 가치가 달라진다.

1.28 PHP를 버리는 것이 답은 아니다#

커리어를 걱정하면서 이런 결론을 내리기도 한다.

"PHP가 문제니까 Java로 바꿔야겠다."

하지만 언어 하나만 바꾼다고 경력이 바뀌지는 않는다.

PHP에서도 좋은 설계를 할 수 있다.

테스트를 만들 수 있다.

CI/CD를 구축할 수 있다.

클라우드를 사용할 수 있다.

대규모 시스템도 만들 수 있다.

반대로 Java를 사용해도 단순 CRUD만 몇 년 동안 반복하면 성장하지 않을 수 있다.

중요한 것은 언어보다 어떤 수준의 문제를 해결하는가다.

1.29 그래도 시장에서 많이 쓰이는 기술은 준비해야 한다#

그렇다고 기술 시장을 무시하라는 뜻은 아니다.

2026년 개발 채용 시장은 특히 신입과 저연차 개발자에게 경쟁이 강하고, 기업은 단순히 언어 사용 경험보다 실무 문제 해결 능력을 더 많이 요구하는 방향으로 움직이고 있다.

따라서 장기적인 이직 가능성을 유지하려면 최소한 다음 영역은 준비해두는 것이 좋다.

  • Git
  • REST API
  • SQL
  • Linux
  • Docker
  • 클라우드 기초
  • 테스트
  • CI/CD
  • HTTP와 네트워크
  • 자료구조와 기본 CS

현재 회사에서 쓰지 않더라도 개인적으로 경험해두면 다음 이직에서 차이가 생긴다.

1.30 어떤 사람에게 중소기업·웹에이전시가 잘 맞을까#

무엇이든 직접 해보는 것을 좋아하는 사람#

역할이 명확하게 나뉜 환경보다 다양한 문제를 해결하는 것을 좋아한다면 재미있을 수 있다.

빠르게 실무를 경험하고 싶은 사람#

처음부터 실제 프로젝트에 참여할 가능성이 높다.

결과물을 빠르게 만드는 것을 좋아하는 사람#

웹사이트 하나가 몇 주 또는 몇 달 만에 완성되는 모습을 직접 볼 수 있다.

고객과 가까운 개발을 좋아하는 사람#

자신이 만든 결과에 대한 고객 반응을 빠르게 확인할 수 있다.

프리랜서나 창업을 생각하는 사람#

웹서비스 전체를 직접 만들어본 경험은 큰 자산이 된다.

1.31 반대로 어떤 사람에게는 힘들 수 있을까#

특정 기술을 아주 깊게 연구하고 싶은 사람.

대규모 시스템을 경험하고 싶은 사람.

최신 인프라 환경에서만 일하고 싶은 사람.

체계적인 코드 리뷰와 멘토링을 중요하게 생각하는 사람.

명확한 직무 범위를 선호하는 사람.

높은 보상을 가장 중요한 기준으로 생각하는 사람.

이런 성향이라면 중소 웹 개발 환경에서 빠르게 한계를 느낄 수도 있다.

1.32 첫 회사를 선택할 때 무엇을 확인해야 할까#

모든 중소기업과 웹에이전시가 같은 것은 아니다.

좋은 회사를 구별하려면 면접에서 몇 가지를 확인해야 한다.

버전 관리#

Git을 사용하는가?

아니면 FTP로 서버 파일을 직접 수정하는가?

개발 환경#

로컬 개발 환경이 있는가?

운영 서버에서 직접 수정하지 않는가?

코드 리뷰#

다른 개발자가 내 코드를 봐주는가?

기술 부채#

오래된 시스템을 개선하려는 계획이 있는가?

업무 범위#

개발 업무와 전산 잡무의 비율은 어느 정도인가?

사수#

실제로 질문할 수 있는 시니어 개발자가 있는가?

프로젝트#

홈페이지 구축만 하는가?

자체 서비스나 솔루션도 있는가?

이 질문 몇 개만으로 개발자로서 성장 가능한 회사인지 어느 정도 판단할 수 있다.

1.33 가장 위험한 환경의 신호#

다음과 같은 상황이 반복된다면 주의할 필요가 있다.

  • 운영 서버에서 직접 코드를 수정한다
  • Git을 사용하지 않는다
  • 소스 백업이 ZIP 파일이다
  • 이전 개발자가 만든 코드를 아무도 이해하지 못한다
  • 테스트 서버가 없다
  • 고객 요청이 전화로만 전달된다
  • 일정이 항상 당일 또는 다음 날이다
  • 개발자가 모든 전산 업무를 담당한다
  • 몇 년째 같은 방식으로 복붙 개발만 한다
  • 성장이나 기술 개선에 대한 계획이 없다

이런 환경에서는 일을 많이 해도 기술적 성장 속도가 생각보다 낮을 수 있다.

1.34 반대로 좋은 중소 개발 조직은 의외로 강하다#

작은 회사라고 개발 문화가 반드시 나쁜 것은 아니다.

오히려 잘 운영되는 작은 조직에서는 큰 회사보다 빠르게 성장할 수도 있다.

Git을 제대로 사용한다.

코드 리뷰를 한다.

자동 배포를 구축한다.

레거시를 조금씩 개선한다.

새로운 기술을 실험한다.

개발자에게 의사결정 권한을 준다.

이런 회사에서는 작은 조직의 장점과 현대적인 개발문화의 장점을 동시에 얻을 수 있다.

그래서 회사 규모만 보고 판단하면 안 된다.

개발팀이 어떤 방식으로 일하는지가 더 중요하다.

1.35 3년을 보낸다면 반드시 가져와야 할 것#

중소 웹 개발 회사에서 3년을 일한다고 가정해보자.

단순히

PHP 3년

을 만드는 것은 위험하다.

대신 이런 경력을 만드는 것이 좋다.

1년 차#

  • HTML/CSS/JavaScript
  • PHP 또는 주력 언어
  • SQL
  • Git
  • Linux
  • 기본적인 서버 운영
  • 고객 요구사항 이해

2년 차#

  • API 설계
  • DB 구조 개선
  • 성능 튜닝
  • 보안
  • 테스트
  • Docker
  • 배포 자동화

3년 차#

  • 레거시 현대화
  • 클라우드
  • CI/CD
  • 시스템 설계
  • 프로젝트 전체 책임
  • 후배 코드 리뷰

같은 회사에서도 이런 식으로 자신의 역할을 확장해야 한다.

1.36 쉬운 취업보다 중요한 것은 다음 이직이다#

첫 취업이 어렵다면 중소기업이나 웹에이전시에서 시작하는 것은 충분히 현실적인 선택이다.

문제는 들어가는 것이 아니다.

그곳에 들어간 뒤 아무 계획 없이 시간이 흐르는 것이다.

입사할 때부터 다음을 생각해두는 것이 좋다.

여기에서 무엇을 배울 것인가?

몇 년 뒤 어떤 개발자가 되고 싶은가?

지금 하는 업무 중 다음 회사에서도 사용할 수 있는 경험은 무엇인가?

부족한 부분은 무엇을 따로 공부해야 하는가?

이 질문이 있으면 작은 회사에서도 강한 경력을 만들 수 있다.

1.37 경력을 자산으로 바꾸는 방법#

프로젝트 하나가 끝났다.

그냥 다음 프로젝트로 넘어가지 않는다.

정리한다.

어떤 문제가 있었는가?

어떻게 해결했는가?

성능이 얼마나 개선됐는가?

어떤 장애를 해결했는가?

어떤 구조를 개선했는가?

예를 들어

쇼핑몰 개발

보다

기존 상품 조회 SQL을 개선해 평균 응답시간 1.8초에서 0.3초로 단축

이 훨씬 강한 경력이다.

서버 관리

보다

수동 배포 방식을 Git 기반 자동 배포 구조로 개선

이 훨씬 좋은 경험이다.

같은 일을 해도 문제와 개선 결과를 기록하면 경력의 가치가 달라진다.

1.38 중소기업·웹에이전시는 개발자의 야전학교다#

웹에이전시는 최신 개발 기술을 가장 먼저 경험하는 곳이 아닐 수도 있다.

연봉이 가장 높은 곳도 아닐 수 있다.

최고 수준의 복지를 제공하는 곳도 아닐 가능성이 높다.

그러나 다른 곳에서 쉽게 얻기 어려운 경험도 있다.

고객을 직접 만난다.

요구사항을 듣는다.

처음부터 끝까지 서비스를 만든다.

서버를 올린다.

장애를 해결한다.

DB를 고친다.

오래된 코드를 해석한다.

어쩔 때는 디자인도 만진다.

어쩔 때는 도메인도 연결한다.

그 과정에서 개발자는 매우 강한 현장 대응력을 얻을 수 있다.

그래서 중소기업·웹에이전시를 군대에 비유한다면 화려한 특수부대보다는 장비가 부족한 상황에서도 어떻게든 임무를 완수해야 하는 야전부대에 가깝다.

좋은 장비가 없을 수도 있다.

완벽한 매뉴얼도 없다.

전문 인력이 부족할 수도 있다.

그럼에도 결과를 만들어야 한다.

이 과정은 분명 개발자를 강하게 만들 수 있다.

1.39 하지만 야전 경험만으로는 충분하지 않다#

가장 중요한 것은 여기다.

야전 경험은 강력하다.

하지만 현대적인 개발 조직으로 이동하려면 그 경험을 시장 언어로 변환해야 한다.

PHP를 했다면 API와 아키텍처를 공부한다.

MySQL을 했다면 인덱스와 트랜잭션을 깊게 이해한다.

서버를 관리했다면 Docker와 클라우드로 확장한다.

FTP 배포를 했다면 CI/CD를 배운다.

레거시를 다뤘다면 리팩터링과 테스트를 공부한다.

고객을 상대했다면 요구사항 분석과 제품 사고로 연결한다.

기존 경험을 버리는 것이 아니다.

기존 경험 위에 현대적인 개발 방식을 쌓는 것이다.

1.40 결국 중소기업 경력의 가치는 스스로 만들어야 한다#

대기업은 회사 이름 자체가 어느 정도 경력을 설명해준다.

플랫폼 기업도 서비스 규모가 경력을 설명해줄 수 있다.

중소기업이나 웹에이전시는 그렇지 않은 경우가 많다.

회사 이름을 말해도 면접관이 모를 수 있다.

그래서 개발자가 직접 설명해야 한다.

어떤 시스템을 만들었는지.

어떤 문제를 해결했는지.

어느 정도 사용자가 있었는지.

어떤 기술적 개선을 했는지.

무엇을 혼자 책임졌는지.

그 경험에서 무엇을 배웠는지.

결국 중소기업 개발자의 경력은 회사가 대신 만들어주는 것이 아니다.

개발자가 자신의 경험을 스스로 자산으로 만들어야 한다.

중소기업·웹에이전시는 누군가에게는 개발자로 들어가는 가장 현실적인 첫 문이다.

누군가에게는 프리랜서와 창업으로 가는 최고의 훈련장이 될 수 있다.

또 누군가에게는 오래 머물수록 다음 단계로 이동하기 어려운 정체 구간이 될 수도 있다.

차이를 만드는 것은 회사 규모가 아니다.

그 환경에서

얼마나 많은 일을 했는가가 아니라, 얼마나 더 어려운 문제를 해결할 수 있는 사람으로 성장했는가다.

PHP와 그누보드로 시작했다고 해서 커리어의 한계가 정해지는 것은 아니다.

10년 된 ASP 시스템을 맡았다고 해서 경력이 낡아지는 것도 아니다.

그 코드에서 무엇을 이해했고, 무엇을 개선했고, 그 경험을 다음 기술로 어떻게 연결했는지가 중요하다.

결국 개발자의 커리어를 결정하는 것은 첫 번째 회사의 기술 스택이 아니다.

그 환경을 이용해 다음 단계로 올라갈 수 있는 능력을 만들었느냐다.

이 페이지의 목차