엔지니어링

소프트웨어를 만드는 일이 오랫동안 코딩이라는 한 단어로 불렸습니다. 잘하는 사람을 구해 자리에 앉히면 제품이 나온다고 여겼고, 작은 프로그램은 실제로 그렇게 나왔습니다. 어긋나기 시작한 것은 그 프로그램이 팔리고 매일 돌아가면서부터였습니다.

돌아가는 서비스에는 코드 말고도 손이 가는 데가 많습니다. 새 코드를 서버에 올리는 일, 올린 뒤 멀쩡한지 확인하는 일, 새벽에 멈췄을 때 일어나 고치는 일, 사용자가 늘면 서버를 늘리는 일, 남의 계정이 털리지 않게 막는 일이 전부 누군가의 하루를 씁니다. 코딩이라는 말 안에는 이 일들이 들어 있지 않았습니다.

그래서 초기 회사의 금요일 밤은 대개 비슷하게 흘렀습니다. 개발자가 자기 노트북에서 고친 파일을 서버로 직접 밀어 넣고, 화면이 뜨는 것만 보고 퇴근합니다. 월요일에 결제가 안 된다는 연락이 오면 지난주에 무엇이 바뀌었는지부터 알아내야 하는데 바꾼 사람의 기억 말고는 기록이 없습니다. 되돌리려 해도 되돌릴 지점이 없습니다.

엔지니어링이라는 말은 이 일을 개인의 솜씨가 아니라 공정으로 보겠다는 선언입니다. 공학이라는 이름이 붙는 분야에는 공통점이 있습니다. 같은 절차를 밟으면 누가 하든 비슷한 결과가 나오고, 결과가 틀어지면 어느 단계에서 틀어졌는지 짚을 수 있다는 점입니다. 소프트웨어에 그 성질을 넣으려는 시도가 설계·구현·배포·운영이라는 단계를 만들었고, 단계마다 이름 붙은 일과 그 일을 맡는 사람이 생겼습니다.

엔지니어링 아래 묶인 일은 두 질문으로 갈립니다. 누가 하느냐가 역할이고, 무엇을 다루느냐가 나머지 열두 갈래입니다. 열두 갈래는 코드 한 줄이 사용자 화면에 닿기까지의 길을 따라 놓여 있습니다. 아키텍처, 구현 영역, 통신, 데이터 저장, 인프라, 배포, 협업, 품질, 운영, 보안, 성능, AI 순입니다.

역할은 사람을 가르는 갈래입니다. 열한 자리가 있고 하는 일의 성격에 따라 네 묶음으로 나뉩니다.

1. 만드는 자리 — 프론트엔드 개발자는 사용자가 보고 누르는 화면을, 백엔드 개발자는 그 뒤에서 데이터를 꺼내고 규칙을 따지는 서버를 맡습니다. 풀스택 개발자는 둘을 한 사람이 하고, 모바일 개발자는 브라우저가 아니라 아이폰·안드로이드 앱이라는 다른 무대에서 같은 일을 합니다.
2. 굴리는 자리 — 데브옵스 엔지니어는 만든 것을 서버에 올리는 과정을 자동으로 돌아가게 만들고, SRE 는 서비스가 한 달에 몇 분까지 멈춰도 되는지를 숫자로 정해 놓고 그 선을 지킵니다. 데이터 엔지니어는 여기저기 흩어진 기록을 한곳으로 모아 분석에 쓸 수 있는 모양으로 옮겨 둡니다.
3. 지키는 자리 — QA 엔지니어는 나가기 전에 무엇이 깨졌는지 찾아내고, 보안 엔지니어는 공격이 들어올 구멍을 먼저 찾아 막습니다.
4. 이끄는 자리 — 테크 리드는 한 팀의 기술 결정을 책임지고, 최고 기술 책임자는 기술 조직 전체와 채용·예산까지 봅니다.

자리가 열한 개라고 사람이 열한 명 필요하지는 않습니다. 구성원 마흔다섯 명인 페이지덱에는 SRE 도 보안 엔지니어도 따로 없고 그 일을 데브옵스 엔지니어 한 명과 백엔드 개발자들이 나눠 집니다. 자리가 갈라지는 순간은 대개 한 사람이 두 성격의 일을 함께 못 하게 됐을 때입니다. 장애 알림을 받으면서 새 기능을 짜라고 하면 알림 쪽이 먼저 사람을 데려가고 기능은 계속 밀립니다.

아키텍처는 짓기 전에 그리는 갈래입니다. 소프트웨어 아키텍처는 시스템을 어떤 덩어리로 자르고 덩어리끼리 어떻게 말을 걸지를 정합니다. 결제와 알림과 문서 저장을 한 덩어리에 넣을지 셋으로 나눌지 같은 결정이고, 한 번 정하면 나중에 바꾸는 값이 큽니다. 기능 하나를 고치는 데는 하루가 들지만 덩어리를 다시 자르는 데는 분기가 듭니다.

구현 영역은 만든 것을 층으로 가르는 갈래입니다. 프론트엔드는 브라우저 안에서 도는 쪽, 백엔드는 회사 서버에서 도는 쪽입니다. 저장 버튼 하나에도 두 층이 다 걸립니다. 누르는 순간 버튼이 회색으로 바뀌는 것은 프론트엔드 몫이고, 그 내용이 진짜로 남아 다음 날에도 열리는 것은 백엔드 몫입니다.

통신은 두 층과 두 시스템을 잇는 갈래입니다. API는 프로그램끼리 무엇을 어떤 모양으로 주고받을지 미리 맞춰 둔 약속입니다. 약속이 문서로 남아 있으면 화면 쪽과 서버 쪽이 서로를 기다리지 않고 동시에 일할 수 있고, 다른 회사 서비스를 끌어다 쓰는 것도 이 창구를 통합니다.

데이터 저장은 남겨야 할 것을 남기는 갈래입니다. 데이터베이스는 문서 한 건, 결제 한 건, 계정 하나를 정해진 자리에 넣어 두고 필요할 때 빠르게 꺼내 줍니다. 백만 건 중 하나를 0.01초에 찾아내는 일이 저절로 되지 않아서 따로 다룹니다.

인프라는 이 모든 것이 올라앉는 바닥입니다. 인프라는 서버와 네트워크와 저장 장치처럼 서비스를 실제로 돌리는 기반을 가리킵니다. 쓰는 사람이 열 명일 때와 십만 명일 때 필요한 바닥이 다르고, 늘리고 줄이는 방식을 미리 정해 두지 않으면 하필 잘되는 날에 서비스가 멈춥니다.

배포와 협업은 만든 것을 합쳐 내보내는 갈래입니다. 버전 관리는 누가 언제 무엇을 바꿨는지 남기고 여러 사람의 수정을 충돌 없이 합칩니다. CI/CD는 그렇게 합쳐진 코드를 자동으로 검사하고 문제가 없으면 서버까지 올립니다. 앞에 나온 금요일 밤 이야기를 없앤 것이 이 둘입니다.

품질은 나가기 전과 나간 뒤를 지키는 갈래입니다. 테스트는 코드가 의도대로 도는지 기계가 대신 확인하게 만드는 일이고, 코드 품질은 그 코드를 반년 뒤의 남이 읽고 고칠 수 있는 상태로 두는 일입니다. 앞엣것은 지금 깨진 것을 잡고 뒤엣것은 나중에 깨질 확률을 낮춥니다.

운영은 돌아가는 동안을 보는 갈래입니다. 관측성은 지금 시스템 안에서 무슨 일이 벌어지는지 밖에서 알 수 있게 기록과 지표를 미리 심어 두는 일입니다. 장애 대응은 실제로 멈췄을 때 누가 먼저 움직이고 무엇부터 되살리는지 정해 둔 절차이고, DORA 지표는 이 조직이 얼마나 자주 안전하게 내보내는지를 배포 횟수·변경 소요 시간·실패율·복구 시간 네 값으로 잽니다.

보안은 밖에서 오는 것을 막는 갈래입니다. 애플리케이션 보안은 남의 계정으로 들어가거나 남의 문서를 열어 보는 길이 코드에 남아 있지 않게 만드는 일입니다. 한 번 뚫리면 그때까지 쌓은 신뢰가 한꺼번에 사라져서, 기능이 다 된 뒤에 덧붙이는 대신 설계 단계부터 끼워 넣습니다.

성능은 빠르기를 다루는 갈래입니다. 웹 성능은 화면이 몇 초 만에 뜨고 눌렀을 때 얼마나 빨리 반응하는지를 재고 줄입니다. 첫 화면이 1초에서 3초로 밀리면 그사이에 나가 버리는 사람이 눈에 띄게 늘어서, 느린 것은 불편이 아니라 매출 문제로 다룹니다.

AI 는 가장 나중에 붙은 갈래입니다. AI 개발은 언어 모델을 제품 안에 끌어다 쓰는 일을 다룹니다. 앞의 갈래들과 성질이 하나 다릅니다. 같은 입력에 늘 같은 출력이 나오지 않아서 맞는지 틀렸는지 판정하는 방법부터 따로 만들어야 합니다.

열세 갈래는 줄 세워 둔 단계가 아니라 서로를 먹입니다. 아키텍처를 어떻게 잘랐느냐가 배포 단위를 정하고, 배포가 잦아지면 테스트와 관측성 없이는 못 버티고, 관측성이 남긴 기록이 다음 장애의 원인 추적과 성능 개선의 재료가 됩니다.

"이건 제품 결정이 아니라 엔지니어링 판단입니다. 두 방식 중 어느 쪽으로 만들지는 저희가 정할게요."

무엇을 만들지는 제품 쪽이, 어떻게 만들지는 기술 쪽이 정한다는 경계 긋기입니다.

"이번 분기 엔지니어링 리소스는 두 명분이에요. 우선순위 다시 봐야 합니다."

사람 수를 쓸 수 있는 시간으로 환산해 담을 수 있는 일의 총량을 말하는 표현입니다.

"이번 분기 엔지니어링 과제는 새 기능이 아니라 배포 파이프라인입니다."

화면에 보이는 결과가 없는 일에 한 분기를 쓰겠다는 선언입니다.

페이지덱에서는 태오가 기능 회의에 들어가 두 가지를 확인합니다. 하나는 무엇을 만들어야 하는지고, 다른 하나는 그것을 지금 구조 위에서 어떻게 만들 수 있는지입니다. 지현이 문서 공유 링크에 만료 기한을 붙이자고 하면 태오는 그 자리에서 화면이 몇 개 바뀌는지, 서버 쪽 약속을 고쳐야 하는지, 이미 나가 있는 링크 수백만 건을 어떻게 처리할지를 따져 봅니다. 셋 중 마지막이 대개 가장 오래 걸립니다.

분기 계획 회의에서는 규원이 기능과 기반 중 어디에 사람을 얼마나 붙일지 묻습니다. 기능만 계속 얹으면 그 분기 숫자는 좋지만 다음 분기에 같은 일을 하는 데 두 배가 듭니다. 태오는 이 대화를 꺼낼 때 배포 한 번 나가는 데 걸리는 시간이나 지난 분기 장애 시간처럼 숫자로 말합니다.

엔지니어링을 코드 짜는 일과 같은 말로 여기는 오해가 가장 흔합니다. 눈에 보이는 산출물이 코드뿐이니 그렇게 읽히기 쉽습니다. 실제로는 개발자의 하루에서 새 코드를 쓰는 시간은 일부이고, 나머지는 남이 쓴 코드를 읽고, 왜 안 되는지 찾고, 어떻게 만들지 정하고, 이미 나간 것을 지키는 데 들어갑니다. 이 오해를 그대로 두면 일정이 코드 쓰는 시간만으로 잡힙니다. 리뷰와 테스트와 배포와 장애 대응은 일정표에 자리가 없으니 야근으로 밀려나고, 그게 몇 분기 쌓이면 사람이 나갑니다.

엔지니어링을 요청받은 기능을 처리하는 부서로 보는 것도 자주 보입니다. 밖에서 보이는 것이 기능이니 기능을 얼마나 빨리 냈는지로 이 조직을 재고 싶어집니다. 하지만 기술 결정은 제품의 수명을 정합니다. 처음에 한 덩어리로 지은 시스템을 2년 뒤에 쪼개려면 그때는 새로 짓는 값에 가까운 돈이 듭니다. 기술 쪽을 주문받는 자리로만 두면 이런 결정을 아무도 미리 하지 않고, 어느 분기부터 기능 하나 내는 데 걸리는 시간이 조용히 두 배가 됩니다.