부제: 국비지원, 전공, 그리고 현실 속에 생산되는 개발자들
나는 컴퓨터공학을 전공하고, 국비지원 과정을 걸쳐 실무를 경험하고, 프리랜서의 생활과 정규직을 모두 겪었다.
그 과정 속에서 나는 하나의 질문에 계속 부딪쳤다.
나는 지금 기술을 단순히 소비하고 있는가, 아니면 구조를 만들고 있는가?
1. 도입: 기술 소비자로서의 개발자
요즘 개발자들은 종종 기술 이름으로 불린다.
- Java 개발자
- React 개발자
- Node.js 개발자
- Spring Boot 개발자
마치 기술 스택이 곧 그 사람의 정체성인 듯 말이다.
사실 나는 그런 개발자는 그리 달가운 표현방식은 아니라고 느껴진다.
그저 그냥 전문성있는 사람의 호칭일 뿐 결국 배우면 다 할 수 있다.
이런 타이틀은 사람을 기술 스택으로 분류한다.
하지만 나는 다시 이렇게 묻고 싶다.
나는 기술을 '쓰는' 사람인가? 아니면 기술을 '구조화해서 문제를 해결하는' 사람인가?
2. 국비교육에서 탄생하는 ‘정답형 개발자’
이 질문이 떠오른 데에는 이유가 있다.
나는 국비지원 과정을 통해 개발자가 되는 많은 사람이 많다.
그들은 대개 이렇게 배운다.
- Java → JDBC → JSP → MyBatis → Spring → Spring Boot → JPA → 팀 프로젝트
- HTML/CSS → JavaScript → React → Node.js → MySQL → 팀 프로젝트
빠른 시간 안에 스택을 익히고 결과물을 만들어야 한다.
그 과정에서 중요한 건 "왜 이 기술을 쓰는가?"가 아니라 마치 정답을 정해진 시험을 준비하는 것과 같다.
국비 지원의 목적은 제대로 배우기 보다는 과정을 이수했다라는 증명으로 배우는 경우도 있다.
대개 국비 지원에서 하는 수강과정은 6개월이며 이는 제대로 배우기에는 너무 짧고, 진도가 매우 빠르고, 이후 그저 남이 만든 코드를 가이드라인을 배우는 느낌에 훨씬 가깝게 느껴진다.
프로젝트도 마찬가지다.
기획서와 요구사항을 받아 기능을 구현하고 끝난다.
- 도메인 개념?
- 책임 분리?
- SRP, 패턴, 설계 원칙?
이런 내용은 거의 다뤄지지 않는다.
결과적으로 '기술을 배우는' 것이 아니라,
'기술을 소비하는 법'만 배우게 된다.
그렇게 만들어지는 건, 기술을 설계하고 선택할 줄 아는 개발자가 아닌 기술을 그저 쓰는 개발자일 뿐이다.
3. 컴퓨터공학 전공자도 구조는 모른다
“그래도 전공자면 구조적 사고를 하지 않을까?”
그렇지 않다. 오히려 더 헷갈려 한다.
컴공 커리큘럼은 대개 다음과 같다:
- C, C++, Python, Java
- 자료구조와 알고리즘, 컴퓨터 구조, 어셈블리어
- 운영체제, 네트워크, 컴파일러
- DBMS, 시스템 프로그래밍
- 인터넷 실습, 컴파일론 구조, 네트워크 이론
- 소프트웨어 설계 공학, 프로그래밍 언어론
겉으로는 많아 보이지만, 대부분 '맛보기 수준'이다.
깊이 있게 배우기엔 시간도 부족하고, 연결이 약하다.
졸업 프로젝트라는 것이 있다고 한다면 물론 맞는 말이다.
하지만, 방향성을 제대로 정해주는 경우가 본적이 없으며 '완성'만 요구하는 경우가 많다.
교수님이 방관하거나, 주제가 겉핥기에 그치는 경우가 있다.
조금 부끄러운 이야기지만 프로그래밍 언어에서는 학점을 쓸어나간 이력이 있었다. 심지어 장학금도 몇번 받아본 경험도 있었다.
그럼에도 불구하고 실무에 필요한 지식들은 대부분 조각식으로 배우는 것들이 전부였다.
진짜 실무에 필요한 구조적 개발은 커리큘럼 바깥에 있다.
예를 들면 이런 것들이다:
- API는 왜 RESTful해야 하는가?
- 트랜잭션 경계는 어떻게 잡아야 하는가?
- 서비스와 컨트롤러의 책임은 어떻게 나뉘는가?
- 도메인 모델링이란 무엇인가?
- 디자인 패턴을 학습하고 주문 제작 프로그램을 전략 패턴 등을 포함한 3가지 이상 반영해보세요.
전공자라 하더라도 이런 흐름은 직접 부딪혀보지 않으면 모른다.
그래서 많은 신입 개발자들이 기능 구현자는 돼도, 설계자는 되지 못한다.
4. 실무는 빠른 소비를 원한다
실무에 들어오면 더 분명해진다.
구조를 고민하기 전에, 한국 개발 현실은 속도를 원한다.
- "언제 배포돼요?"
- "이거 다음 주까지 가능하죠?"
- "UI는 그냥 따라 하면 되고, 백엔드는 그 API 그대로 쓰면 돼요."
- "기능 오류 안되는거 바로 수정해줄 수 있는거죠?"
실무에서 이런 말들이 너무나도 익숙하다.
특히 일정 중심의 한국 SI 산업 구조를 보면 일정이 빡빡한 곳일수록 더 그렇다.
구조는 사치다.
설계 원칙? 디자인 패턴? 나중에 지금은 돌아가기면 하면 된다.
하지만 시간이 지날 수록 문제는 반드시 드러난다.
- "이 코드 누가 짠 거야?"
- "이거 왜 이렇게 꼬였지?"
- "하나 고치려면 다 건드려야 하네?"
처음부터 구조 생각하지 않고 개발 들어갈 경우 결국 유지보수 지옥이다.
그럼에도 많은 조직은 여전히 빠른 소비를 선택한다
구조는 언제나 뒤로 밀린다.빠르게 돌아가는 게 더 중요하니까.
5. 새로운 기술, 개인적인 실험 목적으로만 활용한다.
기술은 항상 발전한다.
매번 새로운 프레임워크가 쏟아지고,
유튜브에서 "이제 이걸 써야 합니다.!"라는 영상이 넘쳐난다.
하지만 나는 새로운 기술이 나왔다고 해서 결코 좋은 기술은 아니라고 생각하며 검증된 기술은 지양하는 편이다.
왜냐하면, 그 대가는 생각보다 크기 때문이다.
예전에 프론트에서 상태 관리 기법 중 하나인 MobX 라는 것을 써보았다.
하지만 내부 작동 원리가 내가 생각한 것과 다르고, React 프로젝트에서 클래스 컴포넌트형이 강제로 돌아가는 느낌이 들어 지양하는 쪽으로 선택을 하여 필요한 만큼만 만들기도 한다.
또한, Spring 에서도 MSA 설계론을 사용하는데 이 역시 비슷했다.
"요즘은 다들 MSA 하잖아요?"
하지만 나는 MSA 설계론의 대해 가장 관심이 많고 직접 구현해서 적용하는 실험을 진행중이기도 하며 실제 기술 실험실을 통해 특정 도메인에 적용하는 것이 목적이기도 하다.
이것은 내 환경에 맞는 형태로 재구성하는 과정을 먼저 걸치면서 하는 것이다.
결론은 단순하다:
"새로운 기술은 실험실에서 검증한 후 실무에 투입한다."
남들이 좋다고 해도, 내가 책임 못지는 구조면 그건 내 아직 기술이 아니다.
6. 구조 설계자로서의 개발자
처음엔 기능이 잘 돌아가면 그게 최고인 줄 알았다.
사용자도 만족하고, 오류도 없고, 테스트도 통과하고,
하지만 소수는 거기서 멈추지 않는다.
코드가 늘어날수록, 기능이 복잡해질수록
이상하게 속이 불편해지고 무언가가 찝찝한 느낌이 든다.
- "이 구조, 뭔가 잘못된 것 같은데…"
- "이 이름 이상한데…"
- "이거 나중에 큰일 나겠다…"
- "변수명이 왜그래"
- "모듈화 없이 그냥 쌩으로 짰네..."
그들은 코드보다 구조에 관심을 가진다.
공통적으로는
- SRP는 지켜졌는가?
- 트랜잭션은 어디서 관리되는가?
- 서비스와 컨트롤러의 책임은 나뉘었는가?
React를 써도 상태 분리와 리렌더링을 고려하고
Spring을 써도 Bean의 생명주기와 트랜잭션 흐름을 살핀다.
중요한 건 기술 스택이 아니라, 그 기술을 어떻게 구조화할 것인가다.
기술이 아니라 구조에 집착하는 사람들이 있다.
나는 지금, 그 중 하나가 되려고 노력 중이다.
7. 나는 왜 구조를 보기 시작했는가
내가 구조를 보기 시작한 건 어느 프로젝트에서였다.
처음엔 작동하면 그만이다.
React 컴포넌트를 만들고, Spring으로 API를 만들고 기능을 구현했다.
버그만 없으면 잟한 거라고 생각했다.
그런데 이상하게도, 프로젝트가 커질수록 코드가 점점 불편해졌다.
- 같은 API인데도 컨트롤러마다 설계가 다르고
- 서비스 로직에 비즈니스 규칙이 섞여 있고
- 이름 짓기도 얘매하고
- 리팩토링하려고 해도 어디서부터 손대야 할지 몰랐다.
그때부터 고민이 시작되기도 하였다.
- "이게 맞는 구조일까?"
- "왜 이렇게 만들었을까?"
그 후로 기술을 볼때의 기준이 매우 달라졌다.
유명한 기술보다 문제의 적합한 기술을 빠른 구현보다 긴 생명력을 가진 구조를 보게 됬다.
그리고 지금도 같은 질문을 반복한다.
"이 코드, 나중에도 괜찮을까?"
기술을 고르는 기준이 “유명하냐”가 아니라“이 문제에 적합하냐”로 바뀌기 시작했다.
8. 구조 설계자로 가는 길
구조 설계자는 기능을 짜는 사람이 아니다.
그는 "왜?"를 묻는 사람이다.
- 왜 이 로직은 여기에 있어야 하지?
- 왜 이 도메인은 이렇게 나눠야 하지?
- 왜 이 API는 이런 방식으로 호출해야 하지?
이런 질문을 할 줄 아는 사람은 똑같은 기능을 구현해도 접근 방식이 다르다.
예를 들어 같은 게시판 기능이라도
- 컨트롤러에서 모든 로직을 처리하는 사람도 있고
- 도메인 객체로 책임을 분리하고
- 서비스 계층을 리팩토링하는 사람도 있다.
그리고 그 차이는 바로 유지보수에서 드러난다.
구조 설계자는 기능보다 생존력을 본다.
이 시스템이 1년, 3년 뒤에도 살아남을 수 있을지 고민부터 하고 넘어가는 것이다
이는 누가 가르쳐 줄 수 없는 분이이다.
본인 스스로 만들어 내는 것이 그게 바로 실력이고, 이는 훈련과 습관에서 나온다.
9. 지금까지 출시된 기술 스택들은 본인이 만든 언어, 프레임워크, 라이브러리는 타인이 만든 기술을 소비한다.
우리는 매일 새로운 기술을 접하고 사용하기도 한다.
하지만 그 기반은 거의 변하지 않는다.
React, Spring, Nest.js, Express 등
이 모든 기술의 뿌리를 따라가다보면 결국은 C언어, OS, 기계어, 그리고 컴퓨터 구조로 닿는다.
Java 역시 JVM 위에서 동작하고 JVM은 C언어로 구성된 언어 중 하나다.
결국 모든 고급 언어는 기계어 위에 작동하는 인터페이스에 불과하다.
기술은 매일 새롭게 등장하지만
그 아래 구조는 오랜 시간 축적된 패턴 위에서 세워진 것이다.
그래서 나는 이렇게 생각한다.
"기술을 깊이 이해하려면, 항상 '뿌리'를 의식해야 한다."
기술은 단지 도구이고, 그 구조를 이해하는 사람만이 진짜로 '선택' 할 수 있다.
10. 결론: 당신은 어떤 개발자인가?
수많은 기술이 쏟아진다.
매일 새로운 프레임워크와 방법론이 등장한다.
하지만 그 속에서 진짜 중요한 건
"기술을 얼마나 많이 아느냐"가 아니라
"기술을 얼마나 깊이 이해하고, 구조화할 수 있느냐"다.
기술을 소비하는 개발자로 남을 것인가,
기술을 선택하고 설계하는 개발자가 될 것인가?
당신은 어떤 개발자인가?
