기획서가 사라진 개발팀은 어떻게 일해야 할까?

큰 틀로 나뉘던 개발 직군의 경계가 흐려지고 있다. 기획자가 코드를 짜고, 개발자가 UI 및 디자인 시안을 만들고, 아트가 직접 프론트엔드 개발을 한다. 직군을 나누던 경계가 너무나 빠르게 없어지고 있다. 이 글은 너무나 빠르게 기존에 개발하던 개발 파이프라인이 바뀌었고, 그 속에서 각자의 전문성으로 단단히 경계벽을 세웠던 직군이 무너지는 과정 속에서 조직이 겪었던 경험, 그리고 지금 본인은 어떤 솔루션을 시도해보았는지에 대해서 간단히 이야기해보고자 한다.

AI가 뉴노멀이 된 세상에서, 직군과 하는 일의 경계가 흐려지거나 사라지는 건 당연하게 받아들여지고 있다. 그러나 이런 현상이 닥쳤다고 해서, 갑자기 하루아침에 “자 이제 우리 회사의 모든 사람은 다 같이 기획하고 개발하고 그림 그리세요” 같은 의사결정을 조직은 할 수 없다. AI로 인력을 줄이거나 조정하고 효율을 끌어올려도 아직까지는 조직이 필요하고, 그럼 조직은 어쩔 수 없이 어느 정도의 경계를 필요로 한다. 

AI 에이전트를 아무리 잘 세팅해도 대규모 서비스를 감당하는 데는 한계가 있기 때문이다. 대규모 게임 서비스, 이커머스 플랫폼, 웹툰 같은 콘텐츠 서비스, 배달과 O2O 플랫폼을 소수 인원이 만들고 운영하는 그림은 아직 그려지지 않는다. 이런 서비스는 여전히 파트를 나눠서 일한다.

파트가 나뉘어 있으면 그 사이를 연결하는 도구가 필요하다. 아주 오랜 시간 동안, 개발이란 건 통상적으로 기획서와 개발 명세서가 그 일을 해왔다. 서비스와 조직에 따라 다르겠지만, 통상적으로 기획자가 무엇을 만들지 정리해 문서로 넘기면 개발과 아트가 그걸 읽고 각자의 결과물을 만든다. 문서에 적힌 것이 기준이었고, 적힌 대로 나왔는지가 기본적인 완료의 정의였다. 각 파트가 자기 결과물을 다시 퇴고할 때도 판단의 기준은 명세였다.

그러나 내가 이 일을 시작하고 나서, 이 방식으로 일하는 내내 각 파트에서 불협화음이 나오지 않은 적이 없다. 기획서를 받은 쪽에서는 뜬구름 잡는 것 아니냐거나 이게 뭔지 모르겠다고 했다. 개발에서는 예외 처리나 복잡한 기능은 리스크가 크고 비용이 안 맞는다고 했다. 아트에서는 문서에 적힌 레퍼런스가 설명과 안 맞는다고 했다. 혹은 “앞쪽에서 일정이 딜레이 되서 우리는 지금 할 게 없어요”. 매번 동일한 패턴이다. 

누가 잘못해서 생기는 일이 아니었다. 같은 주제를 놓고 각 파트가 서로 다른 것을 떠올리는 게 당연한 프로세스였고, 병렬로 작업할 수 없으니 일정 관리 하나하나가 너무나 중요했다. 그래서 다들 말하곤 했다. “동작하는 목업이 하나 있으면 서로 이해하기 좋을 텐데, 병렬로 작업할 수 있는 방법은 없나? 언제까지 기다려야 돼.” 불과 이삼 년 전까지 그랬다.

기획서가 사라진 개발팀

20명 남짓 게임 개발팀의 어느 날, 갑자기 상부에서 기획서를 예전 방식으로 쓰지 말라는 지침이 내려왔다. 기획자가 파워포인트와 엑셀과 워드를 열어 문서를 만들고, 그 문서를 기획 파트 안에서 리뷰하고 컨펌한 다음, 다른 파트에 개발 리뷰를 도는 일반적인 개발 과정 중 가장 첫 단부터 물리적으로 이전 방식을 쓰지 마라, AI 써라 라는 지침이 내려온 거다. MS 오피스와 VSCode, 포토샵이 기본으로 모니터에 떠 있는 업무 환경. 그러나 이제 이런 모습과 레거시한 파이프라인은 찾아보기 어렵다. 대부분의 회사가 직접 금지하는 단계까지 왔다.

수년에서 십 년 넘게 같은 방식으로 일해 온 사람들이 하루아침에 바뀐 환경에 적응하기는 쉽지 않다. 내가 속한 20명 내외의 게임 개발팀에서 처음 택한 방법은 기획서를 AI로 쓰는 것이었다.

기획서를 AI로 썼다

코드베이스를 직접 읽히고, 기획안을 AI와 크로스체킹한 뒤, 노션 같은 공유 도구로 아웃풋을 뽑았다. 후보정에 걸리는 시간이 획기적으로 줄었다. 기획서를 다 쓴 다음 읽기 좋게 시인성을 잡고 오탈자를 고치는 작업이다. 처음에는 신기하고 편하다는 생각이 들었다. 그런데 퇴고하려고 다시 읽어 보고 파트에 공유하자 반응이 좋지 않았다. 나도 뭔가 이상하다는 느낌이 들었다.

기획서의 기본은 다른 사람에게 설명하는 것이다. 남이 빠르게 파악할 수 있도록 가시성과 시인성을 잡고, 읽기 쉽게 내용을 배치하고, 이미지와 플로우를 넣는다. AI로 기획서를 쓰면 그냥 길어진다. 필요하지 않은 텍스트가 덕지덕지 붙고, 작은 글씨가 여기저기 빼곡하게 박히고, 표는 읽히지 않고, 왜 있는지 모를 코드 설명이 들어간다. AI가 쓴 AI 스타일의 워딩이 문서의 대부분을 차지해 읽기가 짜증나고, 중요한 내용이 그 사이에 끼워져 있으니 객관성이 떨어져 보여서 그냥 지나치게 된다.

어느 팀원은 AI가 만드는 문서를 두고 회사 기획 문서가 아니라 “대충 AI한테 알아서 쓰라고 시킨 것 같다”라는 노골적인 불만도 표시했다. 이유는 간단하다. AI로 문서를 만들어본, 혹은 AI로 발표 자료 등을 만들어 본 사람이라면 자신이 처음에 만든 결과물이, 사람이 읽으라고 쓰던 기획서 대신 프로그램이 읽기 편한 구조의 무언가가 만들어졌다는 걸 기억할 거다. 사람들은 거부감을 느끼고 짜증을 냈다. AI를 못 믿겠다고 하거나, AI로 기획서를 쓴 기획자를 비판하는 반응이 나왔다. 당연한 일이다.

이걸 고치려고 하네스를 만들고 지침을 세우고 프롬프트를 다듬었다. 그러다 보니 작업량이 예전에 문서를 쓰던 것과 비슷해졌다. 정작 읽는 사람 입장에서는 달라진 게 없었다.

게다가 손으로 쓸 때는 각 파트 안에서 검수하는 과정이 있었다. 그 과정에서 예외 케이스를 정리하고 경험 설계의 미스를 잡아냈다. AI로 넘어가면서 이게 사라졌고, AI는 그런 것을 잡아내지 못했다.

예를 들어 장비를 강화하는 시스템을 추가한다고 하자. 강화할 장비를 슬롯에 넣고, 재화를 투입하고, 결과와 연출이 나온다. 실제로는 재화를 차감하고, 서버가 결과를 판단하고, 클라이언트로 패킷을 보내고, UI가 단계별로 처리하면서 이펙트를 출력하고, 결과 팝업이 뜨는 순서를 밟아야 한다. 이런 내용을 모든 팀원이 보고 이해할 수 있도록, 오해가 최소화되도록 쓰는 것이 기획서였다.

동일한 내용을 LLM에 주입하고, 기본 세팅과 하네스를 잡고, 코드베이스를 파악하게 한 뒤 기획서를 작성하라고 했다. AI가 쓴 기획서는 서버가 결과를 준 뒤 클라이언트가 내용을 파싱하기 전까지의 UI 처리를 뭉뚱그려 적어 놓았다. 재화를 차감한 시점에 앱이 종료됐을 때 재화를 어떻게 처리하고, 결과를 어떻게 확정하고, 재접속했을 때 무엇을 알려줄지도 빠져 있었다. 2~3년차 기획자라면 당연히 짚고 넘어갈 내용이다.

왜 이렇게 만들었는지 AI에게 따져 물었다. 이런저런 변명을 하는 LLM에게 짜증을 내고, 다시 지시를 내려 부분부분 수정을 하지만, 비슷한 문제가 계속 사라지지 않았다. 결국 내가 직접 그 문서를 다시 고친 다음, 마무리 보정만 AI에게 시켰다. 그리고 의문이 든다. 이게 정말 맞나. AI를 이렇게 쓰거나, AI로 기획서를 쓰는 게 맞나.

직접 돌아가는 목업을 만들었다

그래서 몇 번의 시행착오 끝에, 기획서 대신 차라리 목업과 움직이는 실제 결과물을 쓰자는 간단한 결론에 도달한다. 모두들 합리적이라고 판단했다. 구조와 기본 리소스가 갖춰진 상태로 목업을 만들면, 앞서 나왔던 예외 상황만 간단히 기획서로 정리하거나, 목업만 보고도 다른 파트에서 한눈에 알 수 있을 거란 기대가 있었다.

실제로 바이브코딩을 통해 만들어지는 목업은 그럴듯했고, 이전처럼 기획서를 쓰지 않고 실제 움직이는 것을 기반으로 기획을 하다 보니 만드는 재미도 올라가는 듯했다.

그러나 이건 기존 기획서 기반 파이프라인과 크게 다르지 않았다. 기획 파트에서는 기획 의도나 왜라는 질문 대신, 바이브코딩 잘하는 방법에 대해 연구하기 시작했다. 기획을 잘하기 위한 방법이 아니라 목업을 만드는 것에 집중되기 시작했고, 이는 프로그램 파트나 아트 파트도 다르지 않았다. 코드를 효과적으로 짜고 아트 퀄리티를 올리는 대신, 목업 기반 개발을 하기 위한 AI를 공부했다. 각자의 파트에서 하던일이 선을 넘어 버렸는데, 그 당시엔 그 누구도 그게 잘못됐다고 생각하지 못했었다. 지금생각하면 아찔한 일이다.

처음엔 이것도 도입 과정에서 벌어지는 시행착오겠거니 했다. 그런데 깊이가 깊어질수록, 기획은 더 그럴듯한 목업을 위한 바이브코딩을 하고, 프로그램 파트는 바이브코딩을 통한 효율보다 목업을 받아봤을 때 그것을 해석하고 AI가 만든 엉성한 스파게티 코드를 다시 고치는 일을 하고, 아트는 목업을 다시 디자인 언어로 변환하고 레퍼런스를 직접 그리고 있었다. 무언가 AI를 도입하긴 했는데 이전과 뭐가 다른 건가 하는 생각이 들기 시작했다.

개발 속도가 효과적으로 향상되거나 AI를 통한 개발 경험이 좋아지는 게 아니었다. 그저 AI를 쓰기 위해 AI 솔루션을 공부하고, 그 솔루션이 모델 업데이트에 따라 무용지물이 되고, 반복되는 상황 속에서 미래를 위한 각자의 지식 자원으로 남지 않는 현상이 발생했다.

두 번째 팀에서 만든 것

앞서 두 번의 경험을 통해 얻은 결론은, 결국 넘기는 걸 AI로 만드는 정도로는 파이프라인이 변경되는 게 아니라 그저 껍데기만 AI 활용에 지나지 않는다는 것이었다. AI로 기획을 하든 목업을 만들든, 레거시한 기획과 개발과 아트의 역할군을 고정하고 제작 파이프라인이 동일한 한 결과물이 바뀔 리가 없었다.

하지만 우리는 열심히 AI를 썼다고 생각했었고, 그로 인해 AI를 부정적으로 바라보는 시선도 생겼다. 포스트모템을 해보면 아주 단순한 이유다. 똑같은 순서로 일을 하는데 그 안의 도구만 몇 개 바꾼다고 해서 나아질 거라고 생각했던 거다. 기획서를 MS 워드에서 파워포인트로, 파워포인트에서 노션으로 쓰는 방법을 바꾼다고 한들 결과물이 바뀔 리가 없잖은가. 근데 다들 AI가 신기하니까, 그걸 AI를 통한 제작 파이프라인 개선이라고 생각한 거다.

그래서 이 레거시한 개념부터 없애보기로 했다. 그 이후, 조직 개편 등을 통해 새로운 프로젝트에 착수하게 되었고, 10명이 채 안 되는 작은 조직이 되었다. 이후 우리는 킥오프에서 이런 이야기를 나누었다. “왜 AI 시대에 이전과 같은 제작 파이프라인이 필요한가”. 그래서 우리는 이 흐름부터 없앴다. 프로그램과 아트는 기획을 기다리지 않는다. 대신, 요즘 LLM에 지시할 때처럼 우리가 뭘 만드는지, 뭐가 목표인지만 빠르게 정했다.

기획은 기획서가 아니라 직접 제품을 만든다. 여러 세션을 띄우고, 필요한 부분은 빠르게 md 등의 형태로 피처만 정리한 걸 워킹트리에 공유한다. 각자의 파트가 원래 가장 잘하는 일을 개별적으로 처리한다. 직렬이 아니라 병렬로 작업했다. 같은 작업을 프로그램과 기획에서 동시에 진행하기도 했다. 충돌이 나면 각자의 의도를 공유하고 충돌 지점을 어떻게 병합할지만 논의했다. 아트도 마찬가지다. 디자인과 레이아웃을 잡고 레퍼런스 이미지를 서칭해 적용한다.

그리고 팀에는 두 가지 원칙을 적용했다. 우리가 만드는 것의 목적을 항시 명심할 것. 어떻게 해요가 아니라 뭐가 더 나아요라고 말할 것. 이 두 가지 원칙만 지킨다면, 기존에 각자의 파트에서 편의나 귀찮음 때문에 남 탓을 하거나 무시했던 부분이 상당 부분 없어지며, 심지어 이제는 AI가 그걸 알아서 수정해줬다. 조직에서 개발을 해본 사람이라면 내가 하는 말이 무슨 말인지 이해할 것이다. 원래 조직에서의 개발은 제품을 나은 방향으로 만드는 것도 목적이지만, 책임과 귀찮음을 떠맡지 않으려고 하는 경향도 상당 부분 있기 때문이다.

이제는 그 귀찮음을 AI가 대신 해줄 수 있기 때문에, 우리는 AI가 못하는 것만 하면 됐다. 이건, 엄청나게 긴 호흡으로 진행되는 대규모 개발에서 원칙과 목표를 잊지 않는 것이다. 그리고 이런 과정을 통해 각 파트는 경계가 아니라 교집합, 즉 같이 공유하는 것과 차집합, 즉 각자가 가장 잘 마무리할 수 있는 것으로 역할을 재분배했다.

위의 개념과 도구를 기반으로, 우리 서비스에서 마일리지와 멤버십 서비스를 개발하고 구축했던 경험을 이야기해 본다.

만약 게임에서 마일리지와 멤버십 서비스를 개발한다고 치면 통상적으로 이렇다. 기획안 발제 후 기획안 작성에 이삼 일, 기획안 컨펌에 반나절, 개발 리뷰 후 착수 시작까지 반나절, UI 구성에 이틀, 서버 하루 반, 클라이언트 하루. 서로 겹치는 시간을 감안하면 대략 워킹데이 기준 닷새 정도 소모되는 일정이다. 이는 기획 단계에서 밀리지 않을 경우 최적의 코스 기준이고, 게다가 하나만 개발하는 게 아니라 여러 작업이 병렬로 돌아가기 때문에 앞단 부하가 크면 클수록 뒤가 계속 밀리는 구조다. 게다가 지금은 내 팀의 전공인 게임 개발이 아닌 앱 개발이었다.

심지어 마일리지와 멤버십 시스템은 여느 게임 혹은 여느 앱에나 있는 레퍼런스가 명확한 것임에도 이 정도가 소모된다는 것이다. 기본적으로 레거시한 명세 기반 개발에서는, 그냥 레퍼런스가 있다고 해서, 그걸 “알아서 만들어 주세요”라고 할 수 없다. 그렇게 말하는 누군가가 있다면 ...(...) 상상에 맡기겠다.

따라서 우리 게임 혹은 앱에 맞는 변형 과정이 필요하고 그만큼 일정을 정확히 계산해야 한다. 마일리지의 캡은 어느 정도인지, 회당 쌓이는 마일리지의 양, 최대 수량, 마일리지가 현금으로 어느 정도의 가치인지, 이 수치로 해야 하는 이유(통상적으로 게임에서 천장이라고 부르는 시스템을 이해하면 된다). 회당 쌓을 건지, 마일리지를 개별로 지급 가능하게 할 건지, 타입은 재화인지 일반 아이템인지. 간단해 보이는 시스템도 우리 사정에 맞게 개발하려면 이런 복잡한 결정 과정과 구현 스펙이 필요한 게 기본적인 개발 방법이다.

이번엔 다르게 했다. 익숙하지 않은 개발 환경임에도 우리는 다음처럼 시도해보았다. 마일리지에 필요한 수식과 값들은 LLM에 위임했다. 알아서 맞춰달라는 게 아니고, 기존처럼 데이터 테이블에 한땀한땀 넣는 것도 아니다. 1회당 10마일리지가 쌓이고, 지금 우리 앱에 마일리지를 사용하는 부분이 a와 b, 얻는 부분이 b와 c와 d라고 한다면, 궁극적으로 약 100만 원 정도의 값어치가 마일리지 보유 수량의 최대치라고 계산하고 이걸 1회당 쌓이는 마일리지에 근거하여 맞추는 수식을 코드로 넣어달라고 한 것이다. 기존에는 이걸 하려면 기획자가 일일이 식을 계산하고 케이스를 구분하고, 엑셀에 셀들을 수식으로 엮어 산출해야 했다.

이렇게 하기 위해 도구를 만들었다

예전 같았으면 이 아젠다를 개발하기 위해 담당 개발진이 모인 단체 채팅방을 만들어 작업했을 것이다. 이번에는 내부 팀 인원이 접근할 수 있는 소규모 인트라를 만들었다. 항목 단위로 만드는 것이 중요하다. 프로젝트 전체를 담으면 너무 무거워지고 기능이 많아진다. 모듈화만 해놓으면 누구나 복사해서 쓸 수 있기 때문에 유지보수 부담도 없다.

노션 같은 협업 문서 도구를 이용하지 않은 이유는, 실제 코드와 깃 워킹트리를 바로 임포트할 수 없기 때문이었다.

구조는 이렇다. 깃 워킹트리를 연동하고, 프론트엔드를 맡은 기획과 개발이 클로드 코드 세션을 이 페이지에 연동한다. 그리고 세션에서 나오는 아웃풋을 인트라 페이지에 자동으로 렌더하는 하네스를 구축했다. 비록 이런 추가 과정을 통해 추가 토큰 소모와 시간이 걸리지만 오히려 이득이다. 우리는 회사원이니까. AI가 하는 동안 커피라도 한잔 더 하는 게 좋지 않은가(..). 연동만 해놓으면 실제 dev 환경을 귀찮게 열지 않고도, 새로이 개발될 항목이 돌아가는 목업을 바로 볼 수 있다. 항목 단위라 빌드가 가볍기 때문에 가능한 구성이다.

여기에 하나를 더 붙였다. 목업을 관리하는 세션과 실제 코드를 다루는 세션을 연결했다. 엔진이나 데이터, 실제 dev 환경이다. 목업에서 나온 수정 사항이나 이슈를 코드베이스에서 검토하고 그대로 고칠 수 있게 했다. 목업을 기반으로 개발하는 것이 아니라, 실코드와 목업이 같이 연동되도록 해놓은 것이 특징이다. 앞선 시도에서 개발이 AI가 만든 엉성한 코드를 다시 고치고 아트가 목업을 디자인 언어로 다시 변환했던 것은 목업과 실코드가 떨어져 있었기 때문이다. 둘을 붙여놓으니 그 변환 작업이 없어졌다.

레퍼런스와 변형 과정은 기획자가 직접 바이브코딩을 하고, 그게 실시간으로 워킹트리에 올라가 인트라에 그대로 렌더된다. 모두가 같은 화면에서 움직이는 것을 보면서 실시간으로 조정한다. 엔지니어와 디자이너는 이 기획안이 동작했을 때의 의도와 기술적 리스크, 자신이 해야 하는 일을 여기서 정리한다. 기획자는 그걸 다시 문서화하지 않고 그 화면에서 바로 목업을 조립하고 소통한다.

레퍼런스가 일시에 공유되었기에 개발과 아트 파트에서는 각자 현재 해야 하는 것부터 빠르게 착수한다. 개발에서는 마일리지가 재화 타입인 것을 확인하고 서버와 DB에 필요한 세팅을 한다. 아트에서는 레퍼런스 이미지를 기반으로 아이콘을 세팅하고 디자인을 잡는다.

그리고 기획 파트에서 변경 사항은 나중에 두세 번 작업이 안 되도록, 개발 과정에서 기획 파트가 작업 중인 바이브코딩 기반 작업에 연동되도록 파이프라인을 구축한다. 누구도 선행 작업을 기다리지 않고, 누구도 회의를 필요로 하지 않았다. 현재 작업된 수준에 맞춰서 각 파트에서 필요한 작업을 병렬로 할 수 있었다.

워킹데이 기준 닷새는 걸릴 작업이, 첫날 기반 작업, 둘째 날 실제 dev 환경에 올라갈 작업까지 마무리한 후, 셋째 날 각 파트에서 테스트까지 마칠 수 있었다.

실제 앱에 올라가는 것은 아니더라도 동작하는 것을 같이 보고 같이 생각하니, 서로 다르게 이해한 채로 진행했다가 되돌아오는 일이 줄었다. 물론 겹치는 부분이 충돌되거나, 툴을 계속 유지보수해야 하는 일들은 있었고, 이게 정답이라고 생각하지도 않는다. 다만 적어도 우리 조직에는 이런 생각이 생겼다. AI 기반 개발은 기존 문법을 개선하는 게 아니라, 새로운 가치를 만들 수 있는 제로베이스에서 시작해야 한다는 것.

마치며

각 파트에서 AI를 쓴다고 해서 AI를 쓰는 조직이 되지 않는다. 기획이 기획서를 AI로 쓰고, 개발이 코드를 AI로 짜고, 아트가 시안을 AI로 뽑아도, 그 결과물이 오가는 순서가 그대로면 예전과 같은 것이 나온다. 첫 번째 팀에서 겪은 것이 정확히 그랬다.

AI로 바뀐 생각과 업무 구조를 반영하려면 기존의 레거시한 파이프라인 자체를 바꿔야 한다. 이 글에서 내가 말하고자 하는 건, 조직은 파이프라인, 즉 뼈대이므로, 이 구조를 들여다보지 않고선 수박 겉핥기식의 AI 사용은 회사, 조직, 개인 누구에게도 가치가 적다는 것이다. 자동차에 타이어를 바꾸고 날개를 달고 제트엔진을 넣는다고 자동차가 하늘을 날지는 않는다. 하늘을 날게 하려면 하늘을 날 수 있는 뼈대부터 만들어야 한다.

나의 경우 두 번째 팀의 사례를 통해 생산성을 끌어올릴 수 있었다. 그러나 포스트모템을 해보면, 결국 최후 끝단, 사용자와 직접 닿는 부분은 여전히 그 파트의 스페셜리스트들이 해야 한다. 그렇지 않으면 그저 빠르게 만든 것이다. AI를 통해 더 낫고 더 좋은 가치를 만든 게 아니라. 요즘 AI를 아는 모든 사람들이 한목소리로 말하고 있는 게 이런 내용들이지 않은가.

마지막으로, 이런 파이프라인의 변화에 따라 개개인은, 빠르게 변하는 산업과 조직 속에서, 나는 기획자니까, 나는 프로그래머니까 같은 관념과 경계를 아직도 가지고 있는지, 그게 정말 AI를 대하고 있는 우리 시대의 생각이 맞는지 점검할 필요가 있다고 생각한다.

AI 시대의 개발자라면, “나는 이런 스킬을 잘 사용해”는 더 이상 그 가치가 없다고 생각한다. 고작 AI를 활용하는 스킬 몇 개, 테크닉 몇 개는 솔루션이 발달하고, 그리고 바이브코딩을 통해 누구나 너무나 쉽게 따라 할 수 있다. 모두가 그렇게 말한다. 자신만의 무언가가 있어야 한다고. 나는 여기서 한 가지를 더 말해보고 싶다. 

자신만의 무언가를 얻기 위해선, 낡은 방식, 불과 “이 년 전까지도 이렇게 했어”라는 생각 자체를 빠르게 버려야 한다고. 이제는, 우리가 익숙해 질 수록, 뒤쳐지는 시대가 되어버렸기 때문이다. 익숙해 질만 하면 새로운 스킬과 솔루션이 나오는 이 시기, 빠르게 적응하기 위해선, 과감히 내가 알고있던 모든걸 버리는 용기도 필요하지 않을까.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.