CS 지식은 실무 문제를 해결할 때 역량이 된다

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

컴퓨터 과학을 공부하면 개발 역량은 높아진다. 다만 CS는 역량의 한 부분이며, 그 비중은 하는 일에 따라 달라진다. 운영체제나 엔진 개발에는 일반적인 백엔드 업무보다 깊은 기초가 필요할 수 있다. 서버 개발에서도 서비스가 커질수록 CS 지식이 분명 도움이 되지만, 과목을 안다는 사실이 업무 역량의 전부는 아니다.

더 유용한 질문은 그 지식이 실제 엔지니어링 문제를 푸는 방식을 바꿨는가이다.

이 질문은 전공 여부를 단순한 가산점과 감점으로 다루는 일에서도 벗어나게 한다. 정규 CS 교육을 받은 사람에게 기대하는 기초와 그렇지 않은 사람에게 기대하는 출발점은 다를 수 있다. 그러나 학력만으로 실제 문제를 어떻게 다루는지까지 알 수는 없다. 전공자는 배운 개념을 적용하지 못할 수 있고, 비전공자는 일의 제약을 풀면서 필요한 원리를 익혔을 수 있다. 결국 확인할 것은 배경의 이름이 아니라 지식이 판단과 행동으로 이어졌는지다.

업무가 필요한 공부를 드러내게 하라

내 첫 업무는 하드웨어와 펌웨어에 가까웠다. LED 하나를 일정한 주기로 깜빡이게 하는 작은 작업도 하드웨어 명세를 읽고 CPU 클럭을 생각하게 했다. 제한된 메모리를 다루면서 휘발성 메모리와 비휘발성 메모리의 차이도 구체적으로 배웠다. 준비된 교육 과정으로만 배운 것이 아니다. 일하면서 계속 질문이 생겼다. 왜 이렇게 동작할까? 제대로 만들려면 무엇을 알아야 할까?

그 과정에는 납땜과 펌웨어 구현, 오실로스코프로 신호를 확인하는 일도 있었다. 데이터시트와 CPU 사양을 읽고, 정해진 주기를 만들기 위해 클럭을 살피고, 디스크를 붙이기 어려운 장치에서 한정된 메모리를 효율적으로 써야 했다. RTOS 같은 실행 환경을 확인하는 일도 추상적인 과목 공부와 분리되어 있지 않았다. 당장 장치를 동작시키려면 알아야 했고, 구현 결과로 이해가 맞는지 확인할 수 있었다.

이런 경험은 체계적인 학습이 필요 없다는 주장이 아니다. 책으로 개념을 정리하는 일도 분명 도움이 된다. 다만 구체적인 제약은 무엇을 왜 공부할지 정해 주고, 이해한 내용을 바로 시험하게 한다. 모든 과목을 같은 깊이로 먼저 끝내려 하기보다 현재 문제에서 설명할 수 없는 지점을 찾아 학습하고 다시 동작을 확인하는 방식이다.

서버 개발에서도 같은 흐름이 이어진다. 엑셀 업로드나 다운로드를 개선하다 보면 메모리 사용량, 네트워크 전송, 처리 시간을 생각하게 된다. 데이터베이스 업무는 인덱스와 트랜잭션에 관한 질문으로 이어진다. 서비스 속도를 높이려는 작업에는 연산, 메모리, 네트워크 효율에 관한 고민이 자연스럽게 들어간다.

평범해 보이는 업무도 충분한 출발점이 된다. 엑셀 업로드의 효율을 높이려면 데이터 처리 방식과 자원 사용을 살펴야 하고, 서비스가 느리다면 시간이 어디에서 소비되는지 나누어 봐야 한다. 이 과정에서 메모리나 네트워크라는 용어를 많이 말하는 것이 중요한 게 아니다. 어떤 제약을 발견했고 그것 때문에 구현을 어떻게 바꿨는지가 중요하다. 문제와 선택 사이의 연결이 있어야 지식이 실제 엔지니어링에 쓰였다고 말할 수 있다.

CS는 이미 이런 판단 안에 있다. 그 사실을 알아차리고, 부족한 부분을 공부한 뒤, 눈앞의 업무에 적용하면 된다. 책도 도움이 되지만 구체적인 문제는 지식을 배울 이유를 만들어 준다.

왜와 어떻게를 계속 묻기

내가 특히 자주 쓰는 질문은 두 가지다.

1. 왜 이렇게 만들었을까?
2. 나라면 어떻게 만들까?

인덱스나 트랜잭션을 익숙한 용어로 알아보는 데서 멈추지 않는다. 어떤 문제 때문에 이런 장치가 생겼는지, 같은 문제를 내가 풀면 어떻게 접근할지 생각한다. 동작을 설명할 수 없다면 다음에 공부할 부분을 찾은 셈이다. 업무에서 이 질문을 반복하면 지식은 외운 단어 목록이 아니라 기술적 사고와 엔지니어링적 사고로 바뀐다.

첫 번째 질문은 이미 존재하는 설계를 무작정 복사하지 않게 한다. 인덱스가 있다는 사실만 보는 대신 왜 이 조회에 필요했는지, 트랜잭션 경계가 왜 이 위치인지 생각한다. 두 번째 질문은 이해했다고 착각하지 않게 한다. 같은 조건을 받았을 때 자신의 대안을 설명할 수 있어야 하고, 그 대안이 자원과 동작의 제약을 놓치지 않았는지 다시 확인해야 하기 때문이다.

답을 바로 찾지 못해도 괜찮다. “왜 이렇게 만들었는지 모르겠다”는 발견이 다음 학습 주제를 구체화한다. 자료와 책을 찾아본 뒤 실제 코드나 실행 결과로 돌아오면 개념이 업무 맥락과 연결된다. 이런 반복이 쌓이면 새로운 문제에서도 무엇을 관찰하고 어떤 원리를 확인할지 스스로 정할 수 있다.

이 과정만으로 자신을 CS 전문가라고 말하려는 것은 아니다. 나 역시 일마다 필요한 내용을 공부하며 많은 부분을 배웠고, 여전히 모르는 것이 많다. 주장하려는 범위는 더 좁다. 실제 시스템의 동작을 계속 질문하면 개발자는 CS 지식을 체득하고 사용할 수 있다.

공부했다는 말보다 업무를 보여 주기

전형적인 CS 전공 과정을 거치지 않은 개발자는 CS를 공부했다는 사실을 강조하고 싶을 수 있다. 그러나 학습 사실만으로는 가장 강한 증거가 되기 어렵다. 실제로 한 업무에서 시작하는 설명이 낫다. 무엇을 더 빠르거나 효율적으로 만들려고 했는지, 왜 그 방법을 골랐는지, 결과가 어떻게 달라졌는지를 말하자.

설명에는 생각의 순서를 남기는 편이 좋다. 처음 관찰한 문제는 무엇이었는지, 효율을 높이기 위해 어떤 부분을 확인했는지, 선택 가능한 방법 가운데 왜 하나를 골랐는지, 적용 뒤에는 무엇으로 동작을 확인했는지를 이어서 말한다. 그러면 면접관이나 동료는 용어 암기량이 아니라 문제를 기술적으로 분해하고 개선한 능력을 볼 수 있다.

업로드 개선 경험에는 메모리나 네트워크를 고려한 방식이 드러날 수 있다. 데이터베이스 결정을 설명하면 인덱스나 트랜잭션에 대한 이해가 보일 수 있다. 굳이 별도의 “CS 업무”라고 이름 붙이지 않아도 지식과 적용 능력을 함께 보여 줄 수 있다.

반대로 이력서에 공부한 과목만 길게 나열하면 그 지식을 어느 정도 사용할 수 있는지 알기 어렵다. “비전공자지만 CS를 공부했다”는 문장도 배경과 노력을 말해 줄 뿐 적용의 증거까지 되지는 않는다. 실제 업무를 더 잘하려고 고민한 흔적 안에 CS가 자연스럽게 드러나게 하는 편이 강하다. 공부를 숨기라는 뜻이 아니라 공부와 일 사이의 인과관계를 보여 주자는 뜻이다.

특정 주제를 보여 줄 업무 사례가 아직 없다고 해서 곧바로 치명적인 문제는 아니다. 역할마다 요구하는 깊이는 다르고, 어떤 직무는 훨씬 더 많은 기초를 요구한다. 공부는 계속하되 그 지식을 만나는 엔지니어링 문제와 연결하자. CS는 실제 업무를 이해하고 개선하는 방식에 나타날 때 신뢰할 만한 역량이 된다.

그래서 목표 직무의 성격을 먼저 봐야 한다. 운영체제나 엔진, 계산 집약적인 영역이라면 CS 기초가 역량에서 차지하는 비중이 크고 더 엄격한 준비가 필요하다. 일반적인 서버 개발에서는 CS와 함께 요구사항 이해, 구현의 완수, 운영과 검증 같은 능력도 평가된다. 모든 개발자에게 같은 학습 비율을 처방하기보다 자신이 풀 문제에 필요한 깊이를 정하고, 배운 내용을 실제 판단으로 바꾸는 것이 현실적인 접근이다.