**AI 시대에 알고리즘을 왜 배워야할까?** 나는 이전 세대의 사람들이 알고리즘을 공부해왔다는 이유만으로 관성처럼 똑같이 하는 분위기가 싫었다. AI 시대에는 새로운 공부 방법이 등장해야 한다는 사실에 동의한다. 그래서 무언가에 익숙해지기 위한 '최소한의 절대 시간'을 넘기면 학습 곡선이 급격하게 올라가는 구조를 만들고 싶었다. 이전까지는 불가능했던 학습 방식으로 더 빠르게, 더 많은 것을 배워야 살아남을 수 있지 않을까? 그래서 내가 이 최소한의 절대 시간 내에 대체 뭘 배워야 하는지 계속 고민했고, 다음과 같이 세 가지로 추려졌다. 1. 컴퓨터 하드웨어 2. 알고리즘 3. 실무 코드 분석 내가 생각한 최소한의 절대 시간은 6개월에서 길게는 1년이다. 이 기간이 지나면, 여기서 쌓은 배경지식을 바탕으로 그래픽스를 공부하거나 언리얼 엔진처럼 공개되어 있는 대형 프로젝트의 소스 코드를 본격적으로 '공부할 수 있는' 출발선이 만들어진다고 생각한다. 지금 당장 만들고 싶은 걸 만들고 코드를 짜는 것도 충분히 의미가 있지만, 더 많은 걸 받아들이기 위한 배경지식으로 알고리즘을 꼽았다. 알고리즘을 공부한다는 건, 개발자들끼리 '생각의 결'을 맞추는 첫걸음이라고 생각한다. 뒤에서 자세히 적겠지만, 하나의 기획을 두고 여러 사람이 같은 방향으로 생각을 맞추는 건 정말 어려운 일이다. 그렇다면 알고리즘이란 무엇인가? 나는 일종의 템플릿이라고 생각한다. 컴퓨터 공학이 수많은 문제를 해결하며 만들어낸 정형화된 생각의 틀이다. 이 틀을 공유함으로써 개발자들 간의 문제 해결 방향이 한곳으로 모이고, 이전에 증명된 효율적인 방식을 가져다 쓸 수 있는 베이스가 된다. 당장 실무에 그걸 쓰지 않더라도, 배경지식으로 알아두면 반드시 유용하게 쓰일 것이라 확신한다. 그래서 나는 알고리즘을 배운다. 이번 주의 키워드는 다음과 같았다: **배열, 문자열, 완전 탐색, 재귀, 백트래킹, 복잡도(BigO, 시간, 공간), 정렬(버블, 삽입), 정수론** 문제는 베이직, 하 난이도까지는 수월하게 풀었는데 중 난이도부터는 풀 수 있는 것과 없는 것이 갈렸다는 점이다. 키워드마다 응용되는 난이도가 달라서 힘들었고, 특히 '하노이의 탑'처럼 도저히 이걸 왜 풀어야 하는지 직관적으로 와닿지 않는 문제들은 하기 싫어서 몰입이 잘 안됐다. 새로운 개념을 익히고 그걸 이해했는지 테스트하는 수준의 활용 문제까지는 즐겁게 풀었지만, 난이도가 너무 높아지면 '이렇게까지 해야 하나' 하는 생각에 방황했던 것 같다. 하지만 중 난이도 문제까지는 나에게 주어진 필수 과제라고 생각하고 받아들이려는 노력을 해야겠다. 알고리즘은 기본 틀을 잡고 유연하게 사고해야 한다는 조언을 들은 만큼, 앞으로 이 틀을 어떻게 이용할지 그 응용 방법을 몸에 익혀야겠다. ** AI 팀프로젝트-수요코딩회-** 난 기획을 중요하게 생각해서 기획 단계에 시간을 많이 쏟았다. 기획을 하면서 가장 어려웠던 점은 팀원들과 **'생각의 결(방향)'을 같은 곳으로 향하게 만드는 것**이었다. 최종 결과물에 대해 몇 번씩 설명해야 했고, 아이디어에 대한 동의를 얻기 위해 내 생각의 흐름을 여과 없이 말해야 했으며, 여러 레퍼런스를 찾아 보여줘야만 비로소 내 생각을 온전히 전달할 수 있었다. 여기서 든 의문은, 지금은 나를 포함해 4명인 팀이지만 앞으로 30명, 40명, 혹은 수백 명의 사람들과 팀 프로젝트를 할 때 과연 한 기획에 대해 모두가 같은 지향점을 가질 수 있을까 하는 점이다. 이걸 가능하게 하는 회사의 시스템은 대체 뭘까? 4차원, 3차원으로 실현되는 내 머릿속 아이디어를 어떻게 2차원, 1차원의 언어로 깎아서 전달할 수 있을까. 가만 보면 이건 AI를 다룰 때와 비슷한 느낌이다. 같은 프롬프트를 넣어도 각자의 뇌가 알아서 계산하고 상상하게 만드는 과정이랄까. AI를 다룰 때의 정교함과 동료를 대할 때의 태도는 의외로 같아야 할지도 모르겠다. '협업'이란 단어의 재정의가 필요한 시점이지 않을까. 우리는 기획서 프롬프트를 작성할 때 다 같이 모여서 적고, AI가 출력한 기획서를 함께 보면서 검토하는 과정을 거쳤다. 이때 서로가 무슨 생각을 하고 있는지 최종적으로 점검할 수 있어서 아주 잘한 선택이라고 생각한다. 원래 계획은 각자 상상하는 것을 실제로 만들어서 가져온 뒤 가장 좋은 것을 고르는 방식이었는데, 그건 전체적인 생산성을 떨어뜨렸을 것이다. 다 같이 프롬프트를 깎는 과정 덕분에 팀원들의 생각이 더 견고해지는 결과가 나왔다. 이후에는 AI가 짜준 과제를 4분할 해서 각자의 로컬 컴퓨터에서 기능 구현을 하고, 최종적으로 깃허브에 merge 하는 방식으로 진행했다. 여기서 느낀 점은, 쓰레드 기능을 사용하면 사실상 하나의 컴퓨터에서 4대를 돌리는 것과 같은 결과가 나올 텐데 굳이 각자의 환경에서 파편화해서 작업해야 했을까 하는 의문이다. 그와 별개로, 가장 기본이 되는 전체 데이터베이스를 먼저 세팅해 두고 그 이후에 4개로 기능들을 쪼개서 구현했다면 훨씬 원활한 팀 프로젝트가 되었을 것 같다. 이번 프로젝트에서 뼈저리게 느낀 건 'AI 프로젝트에서는 책임질 수 있는 사람이 없다'는 사실이었다. 코치님들은 "AI의 신뢰성을 믿고 배포할 수 있을 만한 수준의 프로젝트가 만들어질 수 있는가?"에 대해 질문하셨는데, 그게 가능하려면 적어도 자기가 모르는 기술 스택을 쓰면 안 될 것 같았다. (모른다면 나중에라도 꼭 공부를 하든지.) 개발자는 자신이 만든 것에 대한 책임을 져야 하고, 책임을 지려면 그 코드를 자신이 직접 보고 검증할 수 있어야 한다. 그리고 AI를 사용하는 좋은 개발자는 자신의 시행착오 프로세스를 팀과 공유하며 코드를 견고하게 만들어야 한다. AI를 쓰면 웹페이지 하나를 하루 만에 뚝딱 만들 수는 있지만, 그렇다고 프로젝트 마감 기한을 하루로 잡으면 안 된다. 코드를 검증하고, R&D를 할 수 있는 절대적인 시간이 필수적이라고 느꼈다. 시간 단축에 대한 시각을 완전히 달리해서 '남는 시간 안에 완성도를 높이는' 쪽으로 생각해야지, '적은 시간에 똑같은 퀄리티의 결과물을 낼 수 있으니 끝이다'라고 생각하면 안 된다는 느낌이 강하게 들었다. 결국 기본기가 제일 중요하긴 하지만, 요즘 같은 AI 시대에 매주 AI로 코딩을 해보는 시간이 있는 건 정말 좋다고 생각한다. 앞으로 더 적극적으로 활용해 보고 싶다! ps. 팀원들과 회고시 AI에 관한 내 생각을 전달할 때 쓴 영상 자료이다. 참고로 보면 좋다 [링크 텍스트](https://youtu.be/92WHN-pAFCs?si=CzxPlLPRXGPakJTv)

프로세스 메모리의 전체 흐름