2010년에 처음 개발자로 일을 시작했을 때는 Java와 Spring을 사용했다.
그때만 해도 내가 나중에 BI를 하고, Hadoop을 하고, 클라우드 환경에서 일하고, 결국 AI에게 SQL과 코드를 물어보면서 일하게 될 거라고는 생각하지 못했다.
돌이켜보면 개발자로 일하는 동안 정말 많은 기술을 사용했다.
당시에는 앞으로도 계속 쓰일 것 같았던 기술이 어느 순간 거의 보이지 않게 되기도 했고, 반대로 오래전에 사용하던 기술이 지금까지 살아남은 경우도 있다.
나 역시 처음부터 데이터 엔지니어였던 것은 아니다.
웹개발자로 시작했고, 이후 BI 엔지니어로 일하면서 OLAP과 MicroStrategy를 사용했다. 그다음 Hadoop, Hive, Oozie를 접했고 Cloudera와 Hortonworks 같은 Hadoop 생태계도 경험했다.
이후에는 HDInsight와 AWS 같은 클라우드 환경을 사용하게 됐고, 지금은 AI가 개발자의 일하는 방식 자체를 바꾸고 있다.
한 사람의 커리어 안에서도 이렇게 기술이 많이 바뀐 걸 보면 조금 신기하다.
그래서 이번에는 기술 하나하나를 설명하기보다는, 그때 내가 사용했던 기술들은 어디로 갔고, 그 많은 변화를 거치고 나서 무엇이 남았는지
한번 기록해보려고 한다.
1. 시작은 Java와 Spring이었다
처음 개발자로 일을 시작했을 때 가장 많이 사용했던 것은 Java였다.
웹서비스를 만들고, 화면에서 요청이 들어오면 서버에서 처리하고, 데이터베이스에서 필요한 정보를 가져와 다시 화면에 보여주는 일을 했다.
Spring도 자연스럽게 사용했다.
지금 생각하면 당시와 지금의 개발환경은 많이 다르지만 Java와 Spring은 여전히 살아남아 있다.
수많은 기술이 뜨고 사라지는 동안 아직도 현업에서 사용된다는 점이 오히려 대단하게 느껴진다.
그 당시에는 새로운 프레임워크 하나를 더 알고 있는 것이 꽤 중요한 경쟁력처럼 느껴졌다.
그런데 다른 분야로 이동하고 시간이 지나면서 오히려 오래 남은 것은 특정 프레임워크의 사용법이 아니었다.
서버와 애플리케이션이 어떻게 움직이는지, 데이터베이스와 프로그램이 어떻게 연결되는지, 하나의 시스템이 어떤 흐름으로 동작하는지.
당시에는 너무 당연해서 중요하다고 생각하지 않았던 이런 기본적인 것들이 이후에도 계속 도움이 됐다.
2. 그리고 Flex도 있었다
지금 개발을 시작한 사람들에게 Flex라고 하면 모르는 경우도 꽤 있을 것 같다.
하지만 당시에는 실제 업무에서 사용했던 기술이었다.
웹에서 조금 더 풍부한 화면을 만들 수 있었고, 나름대로 꽤 진지하게 사용됐다.
당연히 그때는 “몇 년 지나면 이 기술이 거의 사라질 수도 있겠다.” 라는 생각을 하지 않았다.
회사에서도 사용하고 있었고, 관련 자료도 많았고, 실제 프로젝트도 계속 있었다.
그런데 시간이 지나면서 거의 볼 일이 없는 기술이 됐다.
아마 이때 처음 느꼈던 것 같다.
지금 많이 사용하는 기술과 오래 살아남는 기술은 꼭 같은 것은 아니다.
개발자는 기술 하나를 배우기 위해 꽤 많은 시간을 쓴다.
그런데 그 기술의 수명은 개발자가 결정할 수 없다.
그렇다고 Flex를 배운 시간이 모두 사라진 것은 아니었다.
화면과 서버가 어떻게 데이터를 주고받는지, 사용자가 원하는 정보를 어떻게 표현하는지 고민했던 경험은 다른 일을 할 때도 남았다.
기술은 사라져도 그 기술을 사용하면서 배운 경험까지 사라지는 것은 아니었다.
3. 웹개발 다음에는 BI 엔지니어가 됐다
웹개발을 하다가 바로 Hadoop으로 넘어간 것은 아니었다.
그 사이에 BI(Business Intelligence) 엔지니어로 일했다.
OLAP을 이용해서 여러 관점으로 데이터를 분석하고, 현업에서 필요한 지표나 리포트를 만드는 일을 했다.
이때 주로 사용했던 솔루션 중 하나가 MicroStrategy였다.
요즘에는 이 이름을 이야기하면 재미있는 일이 있다.
젊은 개발자나 주식에 관심 있는 사람에게 MSTR을 말하면
“아, 그 비트코인 회사요?”
라고 반응하는 경우가 있다. ㅋㅋ
그런데 내가 MicroStrategy를 사용하던 시절에는 적어도 나한테는 비트코인과 아무 관계가 없는 회사였다.
BI와 OLAP 솔루션을 만드는 회사였다.
기업의 데이터를 가지고 지표를 만들고, 여러 관점으로 분석하고, 리포트와 대시보드로 보여주는 것이 중요한 제품이었다.
시간이 이렇게 흘렀구나 싶은 부분이기도 하다.
생각해보면 BI를 했던 이 시기가 이후 데이터 엔지니어로 넘어가는 데 꽤 중요한 과정이었다.
웹개발을 할 때는 “사용자에게 어떤 기능을 제공할까?”를 많이 생각했다면,
BI를 하면서부터는 “이 숫자는 어디에서 왔고, 어떤 기준으로 만들어졌으며, 현업에서는 왜 이 숫자를 보고 싶어 할까?”
를 생각하기 시작했다.
SQL도 훨씬 많이 사용했다.
단순히 데이터를 저장하고 가져오는 것을 넘어 데이터에 업무적인 의미를 붙이는 과정을 경험한 것도 이때였다.
돌아보면 내가 본격적으로 데이터 쪽으로 방향을 틀기 시작한 시점이 BI였던 것 같다.
4. 그러다 Hadoop을 만났다
BI를 하다 보면 자연스럽게 데이터의 앞단이 궁금해진다.
리포트에는 결과가 보이는데, “그럼 이 데이터는 앞에서 누가, 어떻게 만들고 있는 거지?”
라는 생각이 든다.
그러면서 점점 업무의 범위가 데이터가 만들어지는 쪽으로 이동했고 Hadoop을 접하게 됐다.
처음 Hadoop 생태계를 봤을 때는 웹개발과 느낌이 완전히 달랐다.
웹개발에서는 하나의 서비스가 어떻게 움직이는지를 많이 생각했다면, Hadoop에서는
많은 데이터를 어떻게 저장하고 처리할 것인가
가 중요했다.
HDFS에 데이터를 저장하고, Hive로 대량 데이터를 조회하고, Oozie를 이용해 작업 흐름을 관리하기도 했다.
지금 보면 조금 오래된 느낌이 나는 기술들이지만 당시에는 Hadoop 생태계가 정말 컸다.
데이터가 빠르게 증가하고 있었고, “앞으로 대용량 데이터는 이런 방식으로 처리하는구나.”라는 생각을 자연스럽게 했다.
아마 당시의 나에게
“10여 년 뒤에는 자연어로 설명하면 AI가 SQL을 만들어줄 거야.”
라고 했다면 쉽게 믿지는 않았을 것 같다.
5. Cloudera와 Hortonworks, Hadoop이 정말 컸던 시절
Hadoop을 사용하면서 Cloudera와 Hortonworks 환경도 경험했다.
요즘 데이터 분야에 들어온 사람에게는 조금 낯선 이름일 수도 있지만 당시에는 Hadoop 생태계에서 굉장히 익숙한 이름들이었다.
Hadoop 하나만 사용하는 것이 아니었다.
HDFS, Hive, 여러 처리 및 관리 도구들이 하나의 거대한 생태계를 이루고 있었다.
그만큼 운영도 쉽지 않았다.
컴포넌트가 많다 보니 버전 하나를 변경할 때도 신경 쓸 것이 많았고, 문제가 발생하면 어디서부터 봐야 할지 찾아가는 것 자체가 일이었다.
당시에는 각 기술의 명령어나 설정을 익히느라 바빴지만 지금 돌아보면 그 시기에 더 중요하게 배운 것이 있었다.
시스템 전체를 보는 법이었다.
문제가 발생했을 때 한 프로그램만 보는 것이 아니라 데이터가 어디에서 들어오고, 어느 단계를 지나고, 어디에서 막혔는지 전체 흐름을 보는 습관이 생겼다.
특정 제품의 사용법은 시간이 지나면서 잊어버려도 이 감각은 아직 남아 있다.
6. 그리고 클라우드가 들어왔다
그다음 큰 변화는 클라우드였다.
예전에는 서버와 클러스터를 직접 구축하고 운영하는 것이 자연스러웠다.
그런데 점점 필요한 기능을 서비스 형태로 사용하는 방식이 늘어나기 시작했다.
HDInsight 같은 환경도 사용했고 AWS를 비롯한 클라우드 환경도 접하게 됐다.
이때부터 기술을 바라보는 방식이 또 달라졌다.
예전에는 “이 서버에 무엇을 설치할까?”를 고민했다면,
클라우드에서는 “이 기능을 우리가 직접 운영해야 할까, 아니면 이미 만들어진 서비스를 이용할까?”
라는 선택지가 생겼다.
직접 구축하면 세밀하게 제어할 수 있지만 그만큼 운영해야 할 것도 많다.
반대로 관리형 서비스를 사용하면 편해지는 대신 비용이나 종속성 같은 다른 문제가 생긴다.
결국 기술이 발전했다고 문제가 없어지는 것은 아니었다.
문제의 종류가 바뀌었다.
그리고 이때 또 하나 느꼈다.
기술이 발전할수록 개발자가 직접 해야 하는 작업은 줄어들 수 있지만,
수많은 선택지 가운데 무엇을 사용할지 판단하는 능력은 오히려 더 중요해진다.
7. 어떤 기술은 사라지고 어떤 기술은 끝까지 남았다
2010년부터 사용했던 기술을 하나씩 떠올려보면 꽤 재미있다.
당시에는 꼭 알아야 할 것처럼 보였던 기술 가운데 지금은 거의 사용하지 않는 것도 있다.
Flex는 사실상 내 경력의 추억에 가까워졌다.
Hadoop 생태계도 여전히 존재하지만 예전처럼 모든 데이터 플랫폼의 중심이라는 느낌은 많이 달라졌다.
Cloudera와 Hortonworks가 경쟁하던 시절도 지나갔다.
그런데 그 와중에 계속 남아 있는 것들도 있다.
Java도 그렇지만, 개인적으로 가장 재미있는 것은 SQL이다.
개발자로 처음 일을 시작했을 때도 SQL을 사용했고, BI 엔지니어가 되면서 더 많이 사용했고, 데이터 엔지니어가 된 이후에도 계속 사용했다.
AI가 등장한 지금도 여전히 SQL을 사용한다.
그렇게 많은 기술이 나타났다 사라졌는데 정작 아주 오래된 SQL은 여전히 현역이다.
왜 그런지 생각해보면 결국 해결하려는 문제가 없어지지 않았기 때문인 것 같다.
데이터를 찾고, 연결하고, 집계하고, 필요한 정보를 만드는 일은
플랫폼이 바뀌어도 계속 필요하다.
그래서 지금은 새로운 기술을 볼 때 예전처럼
“이걸 꼭 배워야 하나?”
만 먼저 생각하지 않는다.
대신 “이 기술은 무슨 문제를 해결하려고 나온 것일까?”를 먼저 생각해보는 편이다.
문제를 이해하면 도구가 바뀌어도 다시 배울 수 있기 때문이다.
8. 그리고 이제는 AI가 코드를 짜준다
최근 몇 년 사이 체감되는 가장 큰 변화는 역시 AI다.
예전에는 문법이 기억나지 않으면 검색했다.
공식 문서를 보고, Stack Overflow를 찾아보고, 다른 사람이 작성한 코드를 참고하면서 직접 만들었다.
지금은 AI에게 먼저 물어보는 경우가 많아졌다.
SQL도 만들어주고 Python 코드도 만들어준다.
처음 접하는 기술도 어느 정도 설명해준다.
예전에는 한두 시간 헤매야 했던 일을 몇 분 만에 시작하는 경우도 생겼다.
개발자로 처음 일을 시작했을 때는 상상하기 어려웠던 환경이다.
그런데 AI를 실제로 사용하면 사용할수록 묘하게 경험이 필요 없어졌다는 생각은 들지 않는다.
오히려 반대인 경우도 있다.
AI가 만들어준 SQL이 정상적으로 실행된다고 해서 결과가 맞는 것은 아니다.
조인 하나가 잘못돼 숫자가 두 배가 될 수도 있고, 업무 기준을 잘못 이해하면 문법적으로 완벽한 쿼리로 완전히 틀린 결과를 만들 수도 있다.
특히 데이터 업무에서는 에러가 나는 코드보다
정상적으로 실행되는데 결과가 틀린 코드가 훨씬 무서울 때가 있다.
AI는 코드를 만들어줄 수 있다.
하지만 그 코드가 왜 필요한지, 결과가 맞는지, 실제 운영환경에서 사용해도 되는지는 결국 누군가 판단해야 한다.
그래서 AI 시대에는 코드를 직접 타이핑하는 능력의 가치는 조금씩 줄어들더라도,
문제를 정의하고 결과를 검증하는 능력은 오히려 더 중요해질 수도 있겠다
는 생각을 한다.
9. 2010년의 내가 지금을 봤다면
2010년에 처음 일을 시작했을 때는 어쩌면 평생 Java 개발자를 하게 될지도 모른다고 생각했을 것이다.
그런데 웹개발을 하다가 BI로 이동했고, 빅데이터를 했고, Hadoop 생태계를 거쳐 클라우드를 사용하게 됐다.
그리고 지금은 AI와 같이 일하고 있다.
앞으로 10년 뒤에 내가 무엇을 사용하고 있을지는 모르겠다.
지금 중요해 보이는 기술 중 일부는 사라질 수도 있고, 아직 이름조차 모르는 새로운 기술을 매일 사용하게 될 수도 있다.
예전에는 새로운 기술이 등장하면 “이걸 또 언제 공부하지?”라는 생각을 먼저 했다.
지금은 조금 다르다.
어차피 기술은 계속 바뀐다.
그리고 2010년부터 여러 번 그런 변화를 겪고도 아직 이 일을 하고 있다.
결국 중요한 것은 모든 기술을 미리 알고 있는 것이 아니라
필요할 때 다시 배우고 적응할 수 있는가 아닐까 싶다.
그런데 일을 오래 하면서 생각해보니, 단순히 새로운 기술을 빨리 배우는 것만으로도 부족한 것 같다.
내가 지금 중요하다고 생각하는 능력은 오히려 조금 다른 곳에 있다.
10. 기술이 바뀌어도 내가 계속 가지고 가고 싶은 세 가지
첫 번째, 일단 한 번 의심해보는 습관
데이터를 오래 다루면서 가장 중요하게 생각하게 된 것 중 하나가 비판적으로 보는 시각이다.
쉽게 말하면 “이거 정말 맞나?”를 한 번 생각해보는 것이다.
쿼리가 정상적으로 실행됐다고 결과가 맞는 것은 아니다.
숫자가 그럴듯하다고 그 숫자가 맞는 것도 아니다.
오래 운영된 로직이라고 해서 항상 옳은 것도 아니다.
조인 때문에 데이터가 중복됐을 수도 있고,
집계 기준이 잘못됐을 수도 있고,
애초에 원천 데이터가 틀렸을 수도 있다.
그래서 데이터를 볼 때는 어느 정도 “내가 틀릴 수도 있고, 이 데이터도 틀릴 수 있다.”라는 전제를 가지고 보는 편이다.
어쩌면 그냥 꼼꼼한 성격이라고 할 수도 있겠다.
하지만 특히 데이터 분야에서는 꽤 중요한 능력이라고 생각한다.
AI 시대에는 더 그렇다.
AI는 아주 자연스럽게 틀린 답을 만들 수도 있기 때문이다.
그럴듯한 답을 빠르게 만드는 능력이 커질수록 그 결과를 의심하고 검증하는 능력도 같이 중요해진다.
두 번째, 이가 없으면 잇몸으로
나는 일을 하면서 정말 많은 도구를 사용했다.
그리고 그중 상당수는 지금 거의 사용하지 않는다.
그래서 특정 도구를 잘 쓰는 것 자체가 목적이 되어서는 안 된다고 생각하게 됐다.
원래 사용하던 도구를 쓸 수 없으면 다른 방법을 찾으면 된다.
SQL로 해결하기 어려우면 Python을 쓸 수도 있고,
원하는 솔루션이 없으면 가진 도구를 조합할 수도 있고,
환경이 제한돼 있다면 그 안에서 가능한 방법을 찾으면 된다.
회사마다 환경도 다르고 예산도 다르고 사용할 수 있는 기술도 다르다.
현실에서는 항상 내가 원하는 도구가 준비되어 있지 않다.
그래서 결국 중요한 것은 “나는 이 제품을 사용할 줄 안다.” 보다는
“주어진 환경에서 이 문제를 어떻게든 해결할 수 있다.” 에 더 가까운 것 같다.
조금 옛날 표현이지만 나는 이걸 그냥 “이가 없으면 잇몸으로.” 라고 생각한다. ㅋㅋ
기술은 계속 바뀌지만 문제는 기다려주지 않는다.
결국 가지고 있는 도구를 이용해서 답을 만들어내야 한다.
이런 적응력은 특정 제품의 사용법보다 훨씬 오래 남는다.
세 번째, 정답이 없을 때 다른 방법을 생각하는 능력
그리고 하나 더 중요하다고 생각하는 것이 창의적인 발상이다.
데이터 업무에는 정답이 정해져 있지 않은 문제가 많다.
원하는 데이터가 없을 수도 있다.
데이터는 있는데 품질이 좋지 않을 수도 있다.
요청받은 결과를 그대로 만들 방법이 없을 수도 있다.
그럴 때 “그 데이터가 없어서 안 됩니다.”라고 끝낼 수도 있다.
하지만 조금 다르게 생각하면 다른 데이터를 이용해 비슷한 답을 얻을 수도 있고, 여러 데이터를 결합해서 새로운 방법을 만들어낼 수도 있다.
때로는 정식 도구보다 단순한 방법이 더 빨리 문제를 해결하기도 한다.
결국 기술을 많이 아는 것도 중요하지만 가지고 있는 데이터와 도구를 어떻게 조합해서 새로운 답을 만들어내느냐도 중요하다.
AI 시대에는 오히려 이런 능력이 더 중요해질 수도 있다고 생각한다.
정형화된 코드를 만드는 일은 AI가 점점 더 잘하게 될 것이다.
하지만 어떤 질문을 해야 하는지, 어떤 데이터끼리 연결해볼 수 있는지, 기존에 없던 방식으로 문제를 풀 수 있는지
를 생각하는 능력은 또 다른 영역이다.
11. 결국 기술보다 오래 남은 것들
2010년부터 정말 많은 기술을 사용했다.
Java와 Spring을 사용했고, Flex도 했다.
BI 엔지니어로 일하면서 OLAP과 MicroStrategy를 사용했고, Hadoop, Hive, Oozie도 사용했다.
Cloudera와 Hortonworks 환경을 경험했고, HDInsight와 AWS 같은 클라우드 환경도 지나왔다.
그리고 지금은 AI에게 코드를 물어보면서 일하고 있다.
기술 이름만 놓고 보면 전혀 다른 일을 해온 것처럼 보인다.
그런데 돌아보면 내가 하는 일은 크게 달라지지 않았던 것 같다.
문제를 이해하고, 데이터를 보고, 적절한 도구를 이용해 해결하는 것.
도구만 계속 바뀌었다.
그리고 그 과정에서 오래 남은 능력은 특정 기술의 사용법보다 오히려 이런 것들이었다.
결과가 정말 맞는지 한 번 더 의심해보는 것.
익숙한 도구가 없어도 다른 방법을 찾아보는 것.
정답이 없을 때 새로운 방법을 생각해보는 것.
여기에 데이터를 이해하는 능력과 시스템 전체의 흐름을 보는 시각, 그리고 결국 사용자가 무엇을 원하는지 이해하는 능력이 더해진다면 앞으로 기술이 몇 번 더 바뀌더라도 어떻게든 적응할 수 있지 않을까 싶다.
예전에는 특정 기술을 잘하는 사람이 되는 것이 중요하다고 생각했다.
지금은 조금 다르다.
특정 기술이 없어져도 일을 계속할 수 있는 사람이 되는 것이 더 중요하지 않을까.
2010년의 나는 지금 내가 이런 도구를 사용하며 일하고 있을 줄 몰랐다.
아마 지금의 나도 10년 뒤 무엇을 사용하고 있을지 모른다.
그래도 그때도 새로운 도구를 배우고, 결과를 한 번 의심해보고, 안 되면 다른 방법을 찾아가면서 어떻게든 일하고 있지 않을까 싶다.
그리고 10년 뒤 다시 이 글을 읽으면 또 웃길 것 같다.
“2026년에는 AI가 대단하다고 이런 글을 썼었네.”
하면서 말이다. ㅋㅋ
'IT > 빅데이터' 카테고리의 다른 글
| AI가 코드를 짜주는 시대, 데이터 엔지니어의 일은 어떻게 바뀌었나 (0) | 2026.08.30 |
|---|---|
| [현장 후기] Microsoft AI Tour 2025 – 하루 종일 AI에 푹 잠기다 (1) | 2025.03.26 |
| H3를 활용한 주행 데이터 분석 – 운전 습관을 데이터로 읽다 (0) | 2025.03.15 |
| 데이터 플랫폼은 한 번 만들고 끝나지 않는다 (3) | 2025.03.04 |
| SM 프로젝트의 현실과 개발자의 경험 (2) | 2025.03.03 |