두려움으로 배운 3년, 즐거움으로 만든 3년

보안 침해대응에서 소프트웨어 개발로, 다시 새로운 길을 찾기까지

"개발자가 아닌 나도 하는데 너희는 더 잘해야지?"
"개발자가 아닌 나도 하는데 누구라도 해낼 수 있어."

안랩 인공지능팀에서 개발 직군으로 입사한 후배들에게 종종 했던 말이다. 지금 돌아보면 첫 번째 말은 조금 도발적이었을지도 모르겠다. 하지만 두 번째 말에는 지금도 변함없는 믿음이 있다. 개발자로 커리어를 시작하지 않았다고 해서 개발을 할 수 없는 것은 아니다. 처음부터 잘하지 못한다고 해서 앞으로도 잘할 수 없는 것도 아니다.

나는 컴퓨터공학을 전공했지만, 처음부터 소프트웨어 개발자로 일한 사람은 아니었다. 안랩에 입사한 뒤 오랜 시간 악성코드 침해사고 대응과 보안 분석 업무를 수행했다. 개발에 대한 기초 지식은 있었지만, 전문 개발 조직에서 요구사항을 정의하고 설계하고 구현하며 협업하는 경험은 부족했다. 

그러다 개발부서로 이동했고, 그곳에서 약 3년을 보냈다. 다시 대응팀으로 돌아온 뒤에는 직접 개발 인프라를 만들고, 자동화 시스템과 데이터 처리 플랫폼을 구축했다. 돌아보면 두 시기는 나를 전혀 다른 방식으로 성장시켰다. 하나는 두려움 속에서 어떻게든 따라가야 했던 시간이었다. 다른 하나는 내가 생각하고 설계한 것을 직접 구현하는 즐거움으로 가득했던 시간이었다.

이 글은 그 과정에 대한 개인적인 기록이다. 동시에 비개발 직군에서 개발자로 전환하거나, 지금 있는 조직에서 새로운 기술을 시도하려는 사람들에게 작은 도움이 되었으면 하는 마음으로 남긴다.

---

1. 개발부서에서 일해보고 싶었다

보안 대응 업무를 하면서도 늘 일을 더 잘하고 싶었다. 반복되는 업무를 어떻게 개선할 수 있을지, 조직은 어떤 방식으로 일해야 할지, 개인의 경험에 의존하지 않고 일정한 품질을 유지하려면 무엇이 필요할지 고민했다. 그 과정에서 소프트웨어 공학과 개발 프로세스에 관심을 갖게 됐다.

책에서 접했던 개발 방법론은 상당히 인상적이었다. 요구사항을 명확하게 정의하고, 설계 결과를 문서화하고, 코드를 검토하고, 테스트와 배포를 체계적으로 관리하는 방식. 이런 과정들이 실제 개발 조직에서는 어떻게 작동하는지 직접 경험해보고 싶었다.

마침 안랩에는 그런 개발문화를 상당히 엄격하게 적용하는 부서가 있었다. 그래서 인공지능팀으로 이동했다. 개발부서에서 일해보고 싶다는 기대는 현실이 됐다. 하지만 그 환경에 적응하는 과정이 그렇게 힘들 줄은 몰랐다.

2. 기대했던 개발문화와 감당하기 어려웠던 업무 강도

인공지능팀은 기대했던 것처럼 체계적으로 일했다. 문서 양식부터 개발 절차, 개발 도구와 빌드 환경까지 표준을 맞추려고 했다. 개발자마다 방식이 제각각인 것이 아니라, 조직 차원의 원칙과 기준을 따르는 환경이었다.

하지만 업무 강도는 매우 높았다. 당시 팀장님은 스스로 엄청난 양의 일을 처리하는 분이었다. 폭력적이거나 강압적인 분은 아니었지만, 본인의 업무 속도와 품질 기준이 매우 높았다. 일정 역시 상당히 공격적으로 수립됐다. 그 속도를 따라가는 것만으로도 벅찼다. 특히 개발부서로 막 이동한 나에게는 모든 것이 낯설었다.

초기에 맡았던 비즈니스 아키텍처와 요구사항·설계 문서 작성은 정말 힘든 경험이었다. 팀장님과 아키텍트가 기대하는 수준에 도달하지 못해 계속 문서를 다시 작성해야 했다. Confluence의 문서 버전이 수없이 쌓였다. 참고할 수 있는 자료는 제한적이었고, 어떤 부분을 어떻게 보완해야 하는지 명확하게 이해하기 어려운 순간도 많았다. 몇 달 동안 문서를 작성하고 수정하고 다시 작성하는 일을 반복했다. 매일 야근했고, 새벽에 택시를 타고 귀가했다가 아침에 다시 출근했다.

그때 가장 힘들었던 것은 업무 자체만이 아니었다. '못해서 쫓겨나면 어떡하지?' '나 혼자 뒤처지면 어떡하지?' '다른 사람들에게 민폐를 끼치고 있는 건 아닐까?' 그런 두려움이 있었다. 당시에는 내가 개발부서로 옮긴 선택이 잘못된 것은 아닌지 고민하기도 했다. 하지만 포기하고 싶지는 않았다. 내가 배우고 싶었던 것이 바로 그곳에 있었기 때문이다.

3. 성장했다고 해서 그 과정이 모두 옳았던 것은 아니다

결국 설계 문서는 기대 수준에 어느 정도 근접했고, 지연된 다음 일정을 진행하기 위해 기능 설계로 넘어갔다. 흥미로운 것은 그 이후였다. 처음에는 설계 문서 하나 작성하는 것도 버거웠지만, 이후 다른 문서들은 훨씬 빠르게 작성할 수 있었다. 오히려 나중에는 문서를 그만 작성하라는 이야기를 듣기도 했다. 개발 속도도 점차 빨라졌다. 요구사항을 분석하고, 문제를 구조화하고, 구현으로 연결하는 방법을 조금씩 체득했던 것 같다. 그 경험은 이후의 커리어에서도 큰 자산이 됐다.

하지만 지금도 그때의 방식이 최선이었다고 생각하지는 않는다. 높은 품질 기준이 필요한 것과 그 기준을 구성원에게 어떻게 전달할 것인지는 다른 문제다. 좋은 참고 자료와 명확한 피드백이 있었다면 더 효율적으로 배울 수 있지 않았을까 하는 아쉬움도 남는다. 힘든 환경에서 성장했다는 사실이, 성장하기 위해 반드시 그렇게 힘들어야 한다는 의미는 아니다. 나중에 다른 사람을 가르치게 되면서 이 점을 더 많이 생각하게 됐다.

4. 개발팀에서 성공만 경험한 것은 아니었다

인공지능팀에서는 다양한 데이터 처리와 연구개발 프로젝트에 참여했다. 대규모 행위 데이터를 처리하는 ETL 파이프라인을 개발하고 운영하면서 분산 처리 시스템에 대한 경험을 쌓았다. 기존 보안 분석 업무에서 접하던 데이터와는 규모도 다르고, 설계와 운영 과정에서 고려해야 할 요소도 많았다.

또한 보안 도메인 지식과 새로운 데이터 기술을 결합하는 여러 시도에도 참여했다. 그중에는 그래프 데이터베이스를 활용한 악성코드 탐지 연구와 피싱 이메일 탐지 기술 개발 프로젝트도 있었다. 하지만 두 프로젝트는 결과적으로 원하는 성과를 내지 못했다. 성공한 프로젝트처럼 포장하고 싶지는 않다. 기술적으로 가능성을 검토하고 실제로 구현해보는 것과, 그것이 유의미한 결과물로 이어지는 것은 별개의 문제였다. 물론 당시 각 프로젝트가 왜 성공하지 못했는지는 기술적인 문제뿐 아니라 여러 조건을 함께 살펴봐야 할 것이다.

다만 내게는 중요한 경험이었다. 프로젝트가 실패했다고 해서 그 과정에서 습득한 기술과 경험까지 사라지는 것은 아니었다. 반대로 새로운 기술을 적용하고 무언가를 구현했다는 사실만으로 프로젝트가 성공한 것도 아니었다. 기술을 구현하는 능력과 문제를 제대로 해결하는 능력은 서로 연결돼 있지만, 같은 것은 아니라는 사실을 배웠다. 개발팀에서의 시간은 단순히 좋은 개발 방법을 배우는 과정이 아니었다. 잘못된 선택, 실패한 시도, 높은 기준, 협업의 어려움까지 경험하는 시간이었다.

5. 결국 다시 대응팀으로 돌아왔다

개발팀에서 보낸 시간은 분명 값진 경험이었다. 하지만 업무 강도는 여전히 높았고, 더 이상 버티기 어렵다는 생각도 들었다. 한편으로는 다른 욕구도 있었다. 누군가 정해준 업무를 수행하는 것뿐 아니라, 내가 문제를 정의하고 설계한 시스템을 직접 구현해보고 싶었다. 그렇게 여러 생각이 겹친 끝에 대응팀으로 복귀했다. 당시에는 조금 더 여유 있는 환경에서 생활할 수 있겠다는 기대도 있었다.

하지만 막상 여유 시간이 생기자 쉬기보다 무언가를 만들어보고 싶은 마음이 더 컸다. 개발팀에서 배웠던 기술과 프로세스를 내 손으로 다시 구현해보고 싶었다. 그리고 그것을 실제 대응 업무에 적용할 수 있는지 확인하고 싶었다. 돌아보면 나는 개발을 그만두기 위해 대응팀으로 돌아간 것이 아니었다. 배웠던 것을 내 방식으로 활용할 수 있는 환경을 찾아간 것에 가까웠다.

6. 개발 서버도 없던 조직에서 시작하다

대응팀으로 돌아왔을 당시에는 제대로 된 개발 인프라가 없었다. 소스코드를 체계적으로 관리하고, 빌드와 배포를 자동화하고, 여러 실험을 진행할 서버 환경이 부족했다. 하지만 기존 장비와 사용하지 않는 자원을 활용할 가능성은 있었다. 처음부터 큰 예산을 요구하지 않았다. 일단 사용하지 않는 서버를 확보하고, 도태된 장비를 구해 개발 환경을 만들기 시작했다.

이후에는 매년 사용하지 않은 예산 중 일부를 활용할 수 있도록 팀장님께 양해를 구했다. 그렇게 조금씩 서버를 추가했다. 당시 이런 시도를 지원해주셨던 팀장님께 지금도 감사하게 생각한다. 서버를 확보한 뒤에는 개발팀에서 경험했던 환경을 다시 만들어보기 시작했다. 형상관리 시스템을 구축하고, 빌드와 배포 과정을 자동화하고, 개발에 필요한 도구와 문서를 정리했다.

직접 개발하기도 했지만, 다른 팀원들도 개발 프로젝트를 수행할 수 있는 환경을 만드는 데 관심이 있었다. 그래서 프로젝트 진행 절차와 문서 템플릿, 코드 리뷰와 테스트 방법도 팀의 상황에 맞춰 정리했다. 개발부서에서 경험했던 엄격한 프로세스를 그대로 옮기는 것이 목적은 아니었다. 그 과정에서 무엇이 중요했고, 어떤 부분이 지나치게 부담스러웠는지를 경험했기 때문이다. 필요한 원칙은 유지하되, 조직의 업무 특성과 규모에 맞게 적용하고 싶었다.

예전에는 다른 사람이 만든 개발 프로세스를 따라가는 입장이었다. 이번에는 직접 프로세스를 선택하고 적용하는 입장이 됐다.

7. 이제 내가 생각한 것을 직접 만들어볼 수 있었다

개발 환경이 갖춰지자 하고 싶은 일이 많아졌다. 반복적으로 수행하던 데이터 수집 업무를 자동화하고, 여러 출처의 정보를 정리하는 시스템을 만들었다. 대용량 데이터를 처리하기 위해 분산 처리 플랫폼을 구성하고, 분석과 통계 작성 업무를 자동화하기도 했다. 기존에는 사람이 직접 확인하고 정리하던 일을 프로그램이 반복적으로 수행하도록 만들면서 업무 방식을 개선하려고 했다. 이런 프로젝트를 진행하면서 기획, 설계, 구현, 배포, 운영을 연결하는 경험을 쌓을 수 있었다.

물론 모든 일을 혼자 수행했던 것은 아니다. 혼자 진행한 프로젝트도 있었고, 다른 팀원들과 함께하면서 개발 방법과 경험을 공유한 프로젝트도 있었다. 하지만 가장 즐거웠던 것은 내가 생각한 것을 직접 구현할 수 있다는 사실이었다. 누군가 요구사항을 내려주기를 기다릴 필요가 없었다. 업무를 하다 불편한 점이 보이면 해결 방법을 고민했다. 필요한 기술을 찾아보고, 환경을 구성하고, 프로그램을 작성하고, 실제로 동작하는지 확인했다. 실패하면 다시 고쳤다. 그 과정 자체가 정말 즐거웠다.

8. 혼자 있는 시간의 의미가 달라졌다

개발팀에서 야근할 때는 사무실에 나 혼자 남아 있는 경우가 많았다. 하지만 그 시간은 해야 할 일을 끝내기 위해 버텨야 하는 시간이었다. 대응팀으로 돌아온 뒤에도 야간 대응이나 주말·명절 대응 업무를 하면서 혼자 사무실을 지키는 일이 있었다. 이슈가 많지 않은 날에는 상대적으로 여유 시간이 생겼다. 그 시간에는 쉬면서 재충전할 수도 있었다. 하지만 나는 무언가 하나라도 더 해보고 싶었다.

새로운 도구를 설치하고, 개발팀에서 경험했던 환경을 재현하고, 궁금했던 기술을 실험했다. 잘 모르는 내용은 찾아보고, 문제가 생기면 원인을 분석했다. 그렇게 경험한 내용을 블로그에 기록했다. 누군가에게 보여주기 위해서라기보다, 직접 겪은 시행착오를 남기고 나중에 다시 활용하기 위해서였다. 그 기록들이 조금씩 쌓이면서 블로그도 성장했다. 그때 비로소 혼자 있는 시간이 얼마나 즐거울 수 있는지 알게 됐다.

개발팀에 있을 때는 뒤처지지 않기 위해 공부했다. 대응팀에서는 내가 궁금하고 해보고 싶어서 공부했다. 두 경험 모두 성장에 도움이 됐지만, 내게 더 큰 즐거움을 준 것은 후자였다.

9. 개발자는 직함만으로 결정되지 않는다

물론 비개발 부서에서 개발 활동을 한다는 것이 항상 환영받았던 것은 아니다. 당시에는 개발 직군과 비개발 직군 사이에 보이지 않는 경계가 있다고 느꼈던 순간들이 있었다. 개발부서에서 경험을 쌓고 돌아왔음에도, 소속 직군이 다르다는 이유로 기술적인 시도를 낮게 평가받는다고 느끼기도 했다. 그럴 때마다 불편했던 것도 사실이다.

하지만 개발자의 전문성과 직무에 대한 존중은 분명히 필요하다. 개발을 조금 할 수 있다고 해서 소프트웨어 엔지니어가 오랜 시간 쌓아온 전문성을 모두 갖췄다고 말할 수는 없다. 내가 말하고 싶은 것은 그 반대의 문제다. 개발자가 아니라는 이유로 개발을 배우거나 기술적 문제를 해결할 기회까지 제한받아서는 안 된다는 것이다.

보안 분석가도 개발을 배울 수 있고, 운영 담당자도 자동화 시스템을 만들 수 있다. 자신의 업무를 깊이 이해하는 사람이 개발 역량까지 갖추면, 기존과는 다른 방식으로 문제를 해결할 수 있다. 나는 그것을 직접 경험했다.

10. 새로운 직군에 도전하려는 사람들에게

내 경험을 모든 사람에게 적용할 수 있는 성공 공식이라고 생각하지는 않는다. 나는 컴퓨터공학을 전공했고, 오랜 시간 보안 분석 업무를 수행하며 기술적 기반을 쌓았다. 개발부서로 옮긴 뒤에는 체계적인 개발 프로세스를 경험할 기회도 있었다. 완전히 다른 배경에서 출발하는 사람보다 유리한 점이 있었던 것은 사실이다. 그럼에도 전환을 고민하는 사람들에게 전하고 싶은 이야기가 있다.

지금까지의 경험을 버리지 않았으면 한다

새로운 직군으로 옮긴다고 기존 업무에서 배운 것이 모두 무의미해지는 것은 아니다. 내게는 보안 분석 경험이 데이터 처리와 탐지 기술을 이해하는 기반이 됐다. 기존 업무의 문제를 잘 이해하는 사람은 그 문제를 해결하기 위한 요구사항도 구체적으로 정의할 수 있다. 새로운 기술은 기존의 경험을 대체하기도 하지만, 그 경험을 더 가치 있게 만들 수도 있다.

프로그래밍 언어만 배우려고 하지 않았으면 한다

개발은 단순히 코드를 작성하는 일이 아니다. 문제를 정의하고, 요구사항을 이해하고, 설계하고, 구현하고, 테스트하고, 운영하는 과정이다. 혼자 실행되는 프로그램을 만드는 것과 다른 사람이 함께 개발하고 유지보수할 수 있는 시스템을 만드는 것은 다르다. 개발 직군으로 전환하려면 개발 도구뿐 아니라 개발하는 방식도 배워야 한다.

작게 시작해서 직접 만들어봤으면 한다

처음부터 거창한 시스템이 필요한 것은 아니다. 나도 사용하지 않는 장비를 구해 환경을 만드는 것부터 시작했다. 작은 문제를 해결하고, 그 결과를 확인한 뒤, 다음 문제로 확장했다. 그렇게 경험이 쌓이면 처음에는 막연해 보였던 일도 조금씩 구체화된다. 책이나 강의로만 이해한 기술은 실제 구현 과정에서 예상하지 못한 문제를 만나기 쉽다. 직접 설치하고, 실패하고, 수정하고, 다시 동작시키는 과정에서 얻는 경험이 중요하다.

버티는 것만이 정답은 아니다

나는 어려운 개발팀 환경에서 오랜 시간 버텼다. 함께 개발팀으로 이동했던 동료는 비교적 이른 시기에 다른 길을 선택했다. 나는 종종 단군신화의 곰처럼 버텼다는 생각을 하곤 했다. 하지만 지금은 오래 버틴 사람이 반드시 더 나은 선택을 했다고 생각하지 않는다. 어떤 사람에게는 환경을 바꾸는 것이 더 합리적인 선택일 수도 있다. 성장을 위해 노력하는 것과 자신의 한계를 무시하며 버티는 것은 다르다. 중요한 것은 어떤 환경에서 자신의 역량을 가장 잘 발휘하고 지속적으로 성장할 수 있는지 아는 것이라고 생각한다.

11. 다시 떠올리는 두 문장

예전에 후배들에게 했던 말을 다시 생각해본다. "개발자가 아닌 나도 하는데 너희는 더 잘해야지?" 그 말에는 개발 직군으로 입사한 후배들에 대한 기대가 있었다. 하지만 지금이라면 조금 다른 표현을 쓰고 싶기도 하다. 사람마다 출발점도 다르고, 배움의 속도도 다르기 때문이다.

반면 두 번째 말은 지금도 그대로 전하고 싶다.

"개발자가 아닌 나도 하는데 누구라도 해낼 수 있어."

물론 아무런 노력 없이 누구나 해낼 수 있다는 말은 아니다. 기초를 배우고, 실패를 경험하고, 실제로 문제를 해결하면서 역량을 쌓아야 한다. 하지만 처음부터 잘하지 못한다는 이유로 포기할 필요는 없다. 

나 역시 처음에는 설계 문서 하나 제대로 작성하기 어려웠다. 그런데 시간이 흐른 뒤에는 직접 개발 환경을 구축하고, 새로운 시스템을 설계하고, 다른 사람에게 개발 방법을 공유하는 일을 할 수 있게 됐다. 그 과정에는 성공한 프로젝트도 있었고 실패한 프로젝트도 있었다. 그리고 두 가지 모두 지금의 나를 만드는 데 영향을 주었다.

12. 결국 내가 원했던 것은 개발자라는 직함만은 아니었다

보안 대응 업무를 시작으로 인공지능팀에서 개발을 경험했고, 다시 대응팀으로 돌아와 직접 개발 환경과 데이터 처리 시스템을 만들었다. 이후 새로운 회사에서 데이터 엔지니어로 일하게 됐다.

지금도 기술은 계속 변하고 있다. 과거에는 새로운 기술을 익히기 위해 책을 읽고, 직접 설치하고, 문제가 생기면 문서를 찾아가며 오랜 시간을 들여야 했다. 이제는 AI의 도움으로 새로운 기술을 학습하고 실험하는 데 드는 부담이 많이 줄었다. 하지만 어떤 문제를 해결해야 하는지, 무엇을 자동화해야 하는지, 만들어진 시스템을 어떻게 운영할 것인지 판단하는 일은 여전히 중요하다.

돌아보면 안랩 개발팀에서 배운 것은 높은 엔지니어링 기준이었다. 대응팀으로 돌아와 얻은 것은 그 기준을 바탕으로 스스로 문제를 해결하는 즐거움이었다. 둘 다 내게 소중한 경험이다. 그리고 그 과정에서 가르침을 주었던 사람들, 새로운 시도를 할 수 있도록 도와주었던 사람들에게 지금도 감사한 마음을 가지고 있다.

나는 개발자가 되고 싶었다. 하지만 시간이 지나고 보니, 정말 원했던 것은 조금 더 근본적인 것이었던 것 같다. 내가 생각한 문제를 내 손으로 해결할 수 있는 사람이 되는 것. 그 마음은 지금도 크게 달라지지 않았다.

---

이 글은 안랩에서 근무했던 시절을 개인적인 관점에서 회고한 기록이다. 당시의 기억과 경험을 바탕으로 작성했으며, 그 과정에서 배우고 느낀 점을 남기기 위한 글이다.