Notice
Recent Posts
Recent Comments
«   2025/05   »
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Tags
more
Archives
Today
Total
관리 메뉴

infra-whale 님의 블로그

카이스트 정글 2.5 주차 회고록 본문

카테고리 없음

카이스트 정글 2.5 주차 회고록

infra-whale 2024. 8. 26. 23:26
정글에 온걸 환영한다.
-매번 강의실에 들어올 때마다 드는 생각-

 

정글이 시작한지 3주가 지났다.

 

어떻게 흘러갔는지조차 신기했던 0주차가 끝나고, 조금 여유를 찾으면서 나를 포함한 모두는 각자 이곳에서 각자 자신의 자리를 찾아갔고, 꽤나 잘 적응해갔다. 

 

이곳에 입소하기 전, 정글이란 워딩이 내게 준 이미지는 "약육강식" 이었다. 우리중에서 가장 뛰어난 몇 명 만이 살아남고 아니라면 도태되는 피도 눈물도 없는 세계. 아마 사회생활이라는게 그런거다 보니 여기에도 비슷하게 축소된 사회를 구현해놓지 않았을까 하는 생각과, 간혹 이전기수에 블로그에서 보이는 잔혹한(?) 과제 같은 말을 보면서 멋 모르게 이곳이 어떤 곳일지를 지레짐작 했던 것 같다.

 

요즘도 이곳이 정글이란 것을 실감하지만, 이곳 생활이 익숙해진 내 입장에선 좀 다른 의미로 받아들이게 된 것 같다. 정글이 추구하는 가치는 "약육강식" 보다는 완전한 "자유"이다. 운영진분들은 매주 목요일 과제를 주고, 우리에게 가끔 도움이 될 만한 조언을 해주시지만 그 이상은 아무것도 제공하지 않는다. 과제를 수행하고 더 나아가 무언가 새로운것을 배우거나, 아니면 복잡한 머리를 식힐 겸 잠시 쉬거나 정도가 지나쳐서 하루종일 놀아버려도, 그 누구도 제지하거나 도와주지 않는다. 모든 행동은 내가 판단해서 하며, 모든 결과는 내가 책임진다. 그것이 3주동안 내가 느낀 정글의 이미지였다.

 

물론 정글인 만큼 자유가 존재함과 동시에 나름의 생태계도 꾸려지게 되었다. 과제를 잘 따라가는 사람과 못따라가는 사람이 나뉘게 되었고 이에 따른 대처방안도 모두가 천차만별이었다. 모르는 문제가 나오면 하루를 꼬박 써서라도 자기가 풀려고 노력하는 사람, 블로그에서 해답을 검색해보는 사람, 그리고 나처럼 이미 푼 사람을 찾아서 힌트라도 좀 얻어보려고 하는 사람, 도저히 이해가 안되겠으니 잘하는 다른 사람을 찾아 가르쳐달라고 요청하는 사람도. 그나마 다행인건 아예 포기하는 사람은 아직 보지 못한 점이다. 모두가 나름의 해법으로 나름의 답을 찾기 위해 고군분투 하였고, 그렇게 우리끼리의 관계 또한 점점 자리를 잡아 갔다는 느낌이었다. 

 

노는것은 개인의 자유지만, 주어진 할일을 쳐내가는것도 개인의 역량과 노력에 달렸다. 안된다 싶으면 죽어라 달릴 수밖에.

 

1주차부터 3주차까지는 컴퓨터에게 일을 시키는 법이라는 개념을 알고리즘과 코딩테스트라는 형태로 습득하였다. 각 주의 주제와 풀어야 할 문제가 주어지면, 2명에서 3명으로 이루어진 팀이 서로 끌어주고 도움받으며 어떻게든 주어진 과제를 수행하는 형태였다. 각 주의 개념들은 다음과 같은 것을 다뤘다.

  • 1주차
    • 재귀함수, 정렬, 완전탐색, 분할정복, 이분탐색
  • 2주차
    • 스택, 큐, 우선순위 큐, 그래프탐색, dfs, bfs, 위상정렬
  • 3주차
    • 동적 계획법, 그리디 알고리즘

1주차

1주차에는 아무래도 파이썬에 익숙해지는 기간이 아니었나 싶다. 약 2주간 플라스크를 공부하긴 하였으나, 중괄호와 세미콜론이 없는 문법이 너무나도 어색하였고, 코치님도 그것을 감안하셨는지 앞 19문제는 문법을 익히기 좋은 쉬운 문제들을 제시해주셨다. 덕분에 쉬운 문법에 익숙해져, 코드 구현에 좀 더 신경 쓸 수 있게 되어 그동안 더 재밌게 PS공부를 할 수 있지 않았나 하는 생각이 든다.

 

과제를 받은 첫 날, 19문제를 풀면서 문법에 익숙해 진 다음 바로 한 일은 일주일간의 목표를 정하는 것이었다. 쉬운 기본문제를 푼 이후에도 우리에겐 약 30문제가 남아있었고, 그중에는 분명 만만찮은 문제들도 섞여있었다. 또한 정렬이나 이분탐색 등은 개념조차 잡혀있지 않은 부분도 커서, 1주일간 헛짓을 하지 않기 위해선 계획의 필요성이 절실했다. 팀원들이 머리를 맡대고 계획을 세운 결과, 큰 개념별로 나누어 각각 하루를 잡고, 필요 시 이론공부를 병행하면서 문제를 풀고, 주어진 시간까지 풀지 못한 경우 문제를 푼 사람의 답을 공유받는 것으로 정하였다. 5일동안 코딩테스트 30문제와 개념공부를 병행하려면, 완벽하게 하진 못해도 일단 넘기고 새로운 것을 접하는 것이 필요하다 판단해서였다.

 

그렇게 계획을 세우고 실전으로 들어갔을 땐 ... 확실히 어려움이 많았다. 정글에 입소하기 전 코딩테스트 약 50문제를 풀고 간 상태여서 약간 자신감이 붙은 나였지만, 퀵정렬이나 병합 정렬 등 여러 정렬 알고리즘의 자세한 원리나 이분탐색의 원리 부분으로 넘어가니 그것을 이해하는데 생각보다 오랜 시간이 걸렸고, 아는 개념이었어도 꽤나 어려운 문제들도 많이 섞여있어 힘들었다. 내 경우에는 개념 공부의 경우 팀원들이 서로 머리를 싸매면서 이해하는 시간을 가지고, 어려운 문제의 경우 화이트보드에 도식화 해가면서 풀었을 때, 조금 쉽게 풀렸던 것 같다.

 

어떻게든 이해해보려 고민했던 흔적들

 

다행히 좋은 팀원들 덕에 무사히 넘어가지 않았나 싶다. 특히 내 옆자리에 앉은 친구의 영향을 많이 받았다. 단순히 주어진 문제를 해결하는데에만 초점을 맞춘 것이 아니라, 내가 짠 코드의 효율적이지 못한 부분이 어느 곳이고, 어떻게 개선하면 더 나은 시간복잡도를 가진 코드가 될지를 고민하는 자세는 이후 주차에서 문제를 해결할때도 정말 큰 도움이 되었다.

 

또한 다른 사람에게 내가 풀었던 문제를 설명할 때, 생각보다 내가 짠 코드를 쉽게 이해시키기가 힘들었다. 아마 내가 짠 코드임에도 불구하고 완전히 이해하지 못한 탓이었던 것 같단 생각이 들었다. 이러한 생각이 든 이후로, 같은 팀원이나 지나가다가 무언가 막힌 것 같은 사람이 보이면 발걸음을 잠시 멈추고 고민하는 문제에 대해 같이 고민하기도 하고, 내가 이해하고 있는 것이라면 알려주려 노력하기도 하는 등의 시도를 좀 늘렸다. 그러면서 오히려 역으로 내가 배우기도 하는 경우도 많았고, 점점 남에게 설명하는 것도 쉬워지는 느낌도 받을 수 있었다. 

2주차

2주차 역시 비슷하게 흘러갔다. 후반부 개념인 DFS BFS의 경우 전에 우연히 공부할 기회가 있었어서 생각보다 수월하게 넘어갔고, 위상정렬 또한 무시무시한 네이밍에 비해 생각보다 이해하기 쉬운 개념이어서 무난하게 배울수 있지 않았나 싶다. 오히려 문제는 자료구조인 스택, 큐, 우선순위 큐 였다. 쉬운 개념인 만큼 응용할 곳이 무궁무진한 것인지 주어진 과제 중에 어려운 문제가 많았고, 풀려고 노력했지만 실패한 문제도 많았다. 대신 다양한 문제 유형을 접하다보니, 문제 해결 시 스택을 어떤 경우에 써야하고 큐와 우선순위 큐는 어떤 상황에 쓸지 감은 더 잘 잡을 수 있었다.

 

2주차 역시 팀원끼리 으쌰으쌰하는 느낌으로 진행하였다. 2명으로 구성된 팀이었고, 내 경우는 1.5년의 현업 경험과 잡다하게 쌓은 지식이, 다른 팀원은 대학교에서  2년간 전산학을 배운 경험을 토대로 서로가 모를 때 서로에게 배우기도 하고, 가르쳐도 주면서 긍정적인 상호작용을 하지 않았나 싶다.

아직 진행중인 3주차

그리고 지금은 ... 처음 만난 DP라는 개념 속에서 모두가 고통받는 중이다.

 

tmi이긴 한데 DP의 Dynamic 이란 워딩은 사실 개념과 별 관계가 없다고 한다. 해당 개념의 창시자인 벨만 포드가 연구비를 탈 목적으로 좀 있어보이게 지은게 시초라고... 나무위키에 나와있긴 하다. 유래야 어쨌든 우리에겐 꽤나 다이나믹 한 경험인건 확실했다. 메모이제이션을 하라는데 이 문제에선 이 방식으로 하고, 저 문제에선 완전 다른 방식으로 하고, 문제를 어떻게 풀지까진 접근하였는데 이것을 그대로 쓰려면 for 문을 3중으로 중첩해야 하고 ... 그렇게 구현하다가 내가 여태껏 짜온 코드도 이해가 힘들어지고 ... 이렇게 고통받고 있다가 고개를 돌려 뒤를 보면 다들 속이 쓰려오는 표정을 짓고 있어, 나만 그런게 아니구나 하는 소소한 위안도 얻기도 하면서 4일 정도를 보냈다. 

그런데 아마 코치님도 우리가 고통받는 모습을 보고 계셨나보다. 오늘 슬랙으로 이런 글이 올라왔다.

 
컴퓨팅 사고로의 전환 마지막 주가 지나고 있습니다. 어떠신가요? 이미 소프트웨어 개발자가 된 것 같나요? 아직 뭐가 뭔지 모르겠나요?
1. 혹시 아직도 뭐가 뭔지 모르겠다면내가 생각한 것을 프로그램으로 만들 수 있는지 자기 자신에게 질문해 보십시오. 이 과정의 가장 근본적인 목표는 내가 원하는 작업을 컴퓨터에게 시키는 능력을 키우는 것입니다. 일단, 내가 원하는 것을 컴퓨터에게 쉽게 시킬 수 있다면 잘 따라가고 있다고 생각합니다. 미래에 내가 원하는 것, 해내야 할 작업이 뭐가 될지 모르기 때문에 정형화된 문제들로 연습하는 것이고이왕이면 효율적으로 빠르게 컴퓨터에게 일을 시키기 위해 계산 복잡도를 고려하고, 문제 유형을 나누어 익히고,정해진 시간 안에 프로그램을 짜는 연습을 하는 것입니다.
2. 이번 주 keyword들에 대해서 이야기 하자면
DP (dynamic programming)도 분할 정복을 구현하는 방법들 중 한 가지 방법이며, 따라서 재귀 함수로 구현하기 좋습니다. (솔직히 점화식이 보이는데 이걸 깨닫지 못한다면...) DP 문제를 단순 재귀 함수로 구현하면 같은 함수가 여러번 불리는 경우가 있으므로 한번 계산한 함수는 그 결과값을 저장하는 기법을 사용하는데 그 기법을 memoization이라고 부릅니다. k-차원 array를 만들고 array를 채워 나가는 DP의 풀이 방식, 소위 bottom-up 방식의 풀이는 가끔 이해하기 어려운 경우가 있습니다. 사실 bottom-up 방식은 재귀를 이용한 top-down 방식을 (stack 없이) 반복문으로 만든 겁니다. 이렇게 만들어 놓고 보면 상당량의 최적화, 특히 공간 최적화를 더 할 수 있는 경우가 많기 때문에 이 방식의 풀이를 좋아하시는 분들이 계신데... 일단은 이해가 중요합니다. 이해 할 수 있는 풀이를 먼저 찾는 것을 권장합니다. Python은 cache decorator를 제공하여 top-down DP 구현을 쉽게 만듭니다. (function argument == array index)" 점화식을 알면 DP를 쉽게 짤 수 있는데 점화식을 어떻게 만들지 모르겠다"라고 하시는 분들 계실텐데, 맞습니다. 점화식을 만드는 것 자체가 문제를 푸는 것이고, 좀 더 정확하게는 문제를 어떻게 잘 자를 수 있는가를 찾는 과정입니다. 사실 1주차 재귀, 분할정복에서부터 필요했던 능력입니다. 가끔 보면 문제를 딱 보고 어떻게 자르면 되는지 알아차리기를 원하시는 분이 계시는데, 그 정도의 능력은 저는 재능의 영역으로 봅니다. 솔직히 이게 되면 못 풀 문제 없죠. 특정 사람들만 알아듣는 말로 "직사의 마안"을 가졌다고 표현합니다. 그렇다고, 노력해도 기를 수 없는 능력이냐 하면... 뭐, 하다 보면 늘기는 합니다. DP나 다른 방식이 아닌 Greedy로 풀 수 있으려면, "매 결정 단계에서 최선을 다 하면 global optimum에 도달할 수 있다"라는 증명이 되어야 쓸 수 있습니다. 이 증명 없이 "대충 이러면 최적해가 나오겠지?"라고 생각해서 프로그램을 짜면 엉뚱한 답이 나옵니다.가끔 문제를  풀다 보면, 이게 DP인지 DFS인지 recursion인지 분할정복인지 헛갈릴 때가 있습니다. 네, 사실 4가지 다라고 할 수도 있습니다. 그러니까 문제 유형을 딱딱 나눠서 생각한다는 것 자체가 대단히 어리석은 것일 수 있습니다. 어쨌던, 문제는 풀면 됩니다. 쓸데없는 형식과 용어에 집착하지 마셨으면 합니다.
3.  지금까지 풀었던 문제들을 생각해 보면
일단 어떻게 풀어야 할지 잘 모르겠으면 답이 될 수 있는 모든 것을 다 해 봅니다. - brute force문제를 자를 수 있으면 잘라 봅니다. - divide & conquer
문제를 자른 모양이 원 문제와 같은 모양이 되면 lucky 입니다. - recursion똑같은 argument를 가진 recursive call이 많으면 caching 합니다 - memoization, top-down DP문제 크기를 반으로 자를 수 있으면 very lucky 입니다. 탐색 시간이 O(log n) 이 됩니다.
recursive call 로 문제를 풀었는데 iteration으로 바꿔보니 쓸데없는 부분들이 보여서 optimize 합니다.문제의 모양이 순서대로 처리하거나, 동굴 탐험처럼 들어갔다가 나왔다는 반복하는 모양이 보이면 queue나 stack을 사용할 수 있습니다.관계(relation)가 있다면 graph로 표현할 수 있습니다.
관계들이 크게 한 덩어리로 뭉쳐지는지 조각조각을 되어 있는지는 connected component 수를 세어보면 압니다.그래프는... 사실, 수도 없이 많은 응용방법이 있습니다.
다음 주 부터는 다른 과정이 시작됩니다.컴퓨팅 사고로의 전환 마무리 잘 하시길 바랍니다.

컴퓨팅 사고로의 전환 과정에서 다음 능력은 꼭 익히셨으면 합니다.

1. 어디가 잘못되었는지 찾아내는 능력 (소위 디버깅 능력)
내가 생각하기로 이렇게 컴퓨터에게 일을 시키면 이 문제를 풀 수 있을 거라고 생각했는데 그렇게 되지 않는 경우가 많을 겁니다.
생각대로 되지 않거나 오류가 발생한 경우
내가 어디를 잘못 생각했는지, 어떻게 수정하면 원하는 대로 되는지, 아니면 전체적으로 문제를 잘못 이해했는지를
알아낼 수 있는 능력을 말하는 거고요
그 과정에서 print 문을 끼워 넣던, python -m pdb를 사용하던, vscode의 python 디버거를 사용하던, 내 나름대로의 input을 만들어서 시험을 해 보던
현재 일어나는 현상을 파악하기 위한 행동이 익숙해 지셨으면 합니다.

'이 문제는 이렇게 푸는 거야' 식으로 답을 외우려 하지 마시고
내 생각대로 코드를 짰는데 제대로 되지 않는다면
무엇이 문제인지 파악할 수 있는 게 좋습니다.

2. 눈 앞의 프로그램의 성능을 개선할 수 있는 능력 (소위 optimization (최적화) 능력)
일단 짠 프로그램을 살펴보고 좀 더 빠르게 하거나 차지하는 메모리를 줄일 방법이 없는지 생각하고
그 방법을 찾고 고쳐서 제대로 수행되고, 성능이 나아지도록 할 수 있으면 좋겠습니다.
계속 성능이 좋아지게 고치다 보면, 소위 프로그램 잘 짜는 사람들이 왜 이 문제를 이렇게 풀었는지 이해할 수 있게 되는 경우가 많습니다.

DP에서도 bottom-up 방식이 좋다고 처음부터 bottom-up으로 짜려고 bottom-up solution만 쳐다보면 이해하기 힘든 경우가 많습니다.
문제를 어떻게 나누고, 그걸 recursion으로 어떻게 구현하고, 어떻게 memoization을 추가할 수 있으며, recursion을 loop로 바꾸고, 그 과정에서 어떻게 stack을 제거하고, loop의 진행 방향을 어떻게 잡으면 전체적인 계산 횟수가 줄어드는지 파악하다 보면
왜 이렇게 코드가 만들어지는지 이해할 수 있습니다.

매주 목요일 문제풀이 시간에 보셔서 아시겠지만, 코드의 개선 방법은 꽤 많습니다.
단순히 코딩 테스트를 위해서 이 과정을 하는 것이 아닙니다.

기계를 이해하지 못하고 기계에게 명령을 제대로 내리지 못하는 사람에게는
아무리 좋은 framework와 computing resource가 주어져도
주어진 문제를 풀 가능성은 대단히 낮아진다고 생각합니다.

 

DP 문제가 주어지면, 예전에 사용했던 DP 배열을 어떤식으로 써먹었지 ... 하면서 짱구 굴리기 급급했던 내게 꽤나 찔리는 글이었다. 수요일에 내 힘으로 풀지 못했던 문제들을 복습하면서 위에서 말씀하신 내용들을 상기하면서 다시 풀어볼 예정이다.

 

방법은 제쳐두고라도 DP에서 고통받았던 탓인걸까. 그 이후로 손댄 그리디 알고리즘 문제는 훨씬 쉽게 접근이 가능하였다. 정공법보다 편법을 찾는 느낌이어서 쉬운길 찾는 걸 좋아하는 내 성격과 잘맞았던 탓인지, 시도한 모든 문제가 정말 재미있었다.

 

3주차의 팀원은 2명이다. 한분은 현업 경험이 많으신 형님과, 살짝 정신없지만 배우기 좋아하고 꽤나 빨리 이해하는 동생 한명. 후자의 팀원이 모르는 게 있어서 내게 질문을 하면, 모르는 부분을 가르쳐주면서 나도 많이 배우고, 가끔 보여주는 통찰력에 놀라기도 하면서 재밌게 지내는 중이다.

주어진 과제를 풀다 보면 가끔 밤을 새우기도 하고 그러다 보면 항상 컨디션이 마냥 좋을수는 없다. 그런 순간마다 휴게실에 있는 빈백과 담요가 정말 큰 도움이 되었다.

 

시험

매주 주어진 과제가 끝나고 목요일 10시가 되면, 강의실에서 1시간 반 동안 시험을 쳤다. 시험 결과가 퇴소 여부를 결정하거나 협력사에게 전달되는 것은 아니라고 하지만 그래도 매번 긴장되는 것은 어쩔 수 없었다.

2번의 시험을 치르면서 느낀 건 다음과 같았다.

  • 처음 보는 문제를 풀기 위해선 결국 많이 풀어봐야 한다.
    • 문제를 보자마자 이게 완전탐색인지, dp 문제인지 그리디 문제인지 판단하는 기준은 결국 이전에 풀어본 문제들에서 올 것이다. 많이 풀어보고 그 방식을 익히기도 하고, 내가 짠 코드의 문제점을 빨리 파악하는 능력을 기르는 것이 가장 중요하다.
  • 문제를 푸는 건 물론 중요하다. 하지만 주어진 시간 안에 푸는 것 또한 중요하다.
    • 알았던 문제도 짧은 시간안에 푸는 것은 힘들 수 있다. 또한 면접에서 라이브 코딩을 할 시 대개 30분 이상 시간을 할애받는 것은 대개는 힘들다. 평소에 주어진 시간동안에 문제를 푸는 연습을 하여야 한다.
  • 문제를 풀기 위한 전제조건은 지문을 잘 읽는 것이다.
    • 테스트케이스를 통과 못하는 것은 코딩을 잘못한 탓도 있지만, 전제조건을 잘못 이해했을 수도 있다. 1분 지문읽는 시간이 아까워서 대충 넘겼다가, 테스트케이스 검증에서 더 많은 시간을 날릴 수도 있다. 지문은 꼼꼼하게 잘 읽자.

2번째 3번째 항목의 경우 두 번째 시험에서 정말 뼈저리게 느꼈다. 시간은 부족하였고, 주어진 문제의 전제조건을 잘못 파악하여 생각보다 많은 시간을 소모하였고, 이 때문에 뒤에 있는 문제들에 악영향을 끼쳤다. 이번에 반성한 점들을 반영하여 3번째 시험에서는 같은 실수를 반복하지 않고자 한다.

회식

1번째 주 시험 이후에는 정글 운영진들과 함께하는 티타임과, 회식이 있었다. 크래프톤의 장병규 의장님을 처음 뵈었고, 마치 연예인을 보는 것 마냥 즐거웠었다. 많은 질문들이 오갔고, 이는 회식때까지 이어졌다.

회식 때 장병규 의장님이 우리 테이블에 와서 처음 하신 말씀은 각자 한 사람을 집어서 칭찬해보란 것이었다. 각자 1명을 집어 칭찬하였고, 그 이후에는 왜 이걸 시켰는지 아냐고 질문하셨다. 각자 많은 추측을 말한 이후, 의장님은 정확히 기억나진 않지만 이런 말씀을 하셨다.

우리들에게 가장 중요한 것은 상관들의 평가가 아니라 바로 옆, 동료의 평가다.

 

그땐 가볍게 들었지만, 정글에서의 생활이 3주에 접어든 지금으로선 꽤나 뼈가 있는 말이라는 생각이 든다. 매주 팀원들이 바뀌면서 하는 다면 평가를 포함해서, 우리는 알게 모르게 우리의 옆 동료들, 또 다른 팀의 동료들을 평가한다. 그리고 이는 분명 어느 순간부터 우리에게 큰 영향을 끼쳐나갈 것이다. 그것이 정글에서의 마지막, 나만의 무기 만들기 조 편성이 될 수도 있을 것이고 정글을 수료하고 나서 수료생들끼리 만드는 네트워크에도 영향을 미칠 것이다. 또 그 영향에 따라 향후 취업에 대한 정보라던가 준비 정도도 크게 달라질것이다.

모두가 서로를 평가하고 있는 마당에, 내가 할 수 있는 것은 내 주위 사람에게 더 친절하고, 주어진 것에 최선을 다하면서, 동시에 누가 나에게 앞으로도 도움이 될지 눈여겨 봐두는 것 아닐까.

최근 동생과 전화통화를 하면서 느낀 것인데, 동생이 수료한 부트캠프 학생들 사이에서의 네트워크와 스터디가 취업에 매우 큰 도움을 주었다는 것을 들었다. 내가 이곳에 들어온 목적 또한 함께 열심히 할 사람을 찾는 것도 있었으니, 나 자신도 최선을 다하면서 동시에 같이 최선을 다할 사람을 찾는 노력도 게을리 하지 말아야 겠단 생각도 하는 중이다. 당연하게도 찾기만 해선 안된다. 내가 그들을 평가함과 동시에, 그들도 나를 평가하는중일 테니깐. 

 

더불어 팀스파르타 이범규 대표님과 손윤주님과도 많은 대화를 나누었다. 팀스파르타의 경우 정글 입소 전까진 코딩 교육을 하는 회사라는 정보만을 알고 있었는데, 정글 운영에 열정을 불태우시는 대표님의 모습을 보고 협력사 채용이 있다면 꼭 지원을 해야지라고 의지를 불태우는 중이어서, 대표님께 어떤 사람을 채용하고 싶으시냐는 질문을 드렸다. 대표님께선 "같이 밥먹고 싶은 사람"이라 하셨고 어떤 사람이랑 같이 밥먹고 싶은지 설명해주셨다.

  1. 말을 예쁘게 하는 사람
  2. 성장을 갈망하는 사람
  3. 실패에서 배우는 사람
  4. 유쾌한 사람
  5. 만들고 싶은 세상이 있는 사람

모두 한번씩 생각해 봄 직한 키워드였다. 정글에 온건 성장에 목말라서 온 것이긴 하지만, 그동안 난 내 과거를 잘 돌아보려 하지 않으려 했던 것 같다. 좋았던 기억도 많았지만 괴로웠던 기억도 많아서 그냥 덮어 버리면 편했으니까. 하지만 어떻게 보면 그런 괴로운 상황에 닥치기까지의 과정에선 내 의사결정의 영향도 포함되어 있었고, 이를 잘 상기시키면 내 이후의 의사결정에서 좀더 나은 선택을 할 수 있지 않을까.

또 만들고 싶은 세상이 있는 사람은 좀더 생각해봄직 했다. 나 또한 하나의 서비스를 무작정 만들어보려다가 실패한 경험이 있었으니깐. 정글에 있는 동안엔 꼭 성공해보자고 의지를 다지는 순간이었던 것 같다.

 

손윤주님은 정글에 자주 모습을 보이셔서 혹시 우리 선배인가 했었는데 직접 질문드리니 항해99 출신이라 하셨다. 같이 이야기를 나누면서 자신이 어떻게 팀스파르타에서 일하게 되었는지, 팀스파르타에선 어떤 일을 하시는지 들었는데 매우 도움이 많이 되었다. 

 

일상

아무리 우리가 있는 곳이 정글이라고 하더라도 여기도 사람사는데다. 아침에 의지를 불태우며 강의실에 가도 오후 즈음에는 다들 과제에 고통받는 좀비 비스무리한 것들이 되고, 그때 유일한 희망이 되는 건 휴게실이었다. 무언가 잘 풀리지 않아 휴게실에 가게 되면 대부분은 나와 비슷한 고민을 하면서 잠시 머리를 식히러 온 상태였고, 그런 동기들과 이야기를 하거나 간단한 게임을 하면서 좀 회복이 되었던 것 같다.

온갖 재밌는 일은 전부 휴게실에서 일어난다.

 

덤으로 다들 사온 간식을 풀 땐 휴게실에서 풀어서 머리가 잘 안돌 땐 휴게실에서 공부하고 있다가, 의도치않게 좀 얻어먹는 경우도 종종 있었다. 항상 미안하면서도 고마워서 큰 힘이 되었던 것 같다.

 

가장 어려운 맺는 말

 

정말 많은 일이 있었던 것 같지만 정글은 이제 시작일 뿐이다. 모두가 많이 이 상황에 적응되고 편해지면서 나 자신도 예전의 불타오르는 모습이 좀 꺾인 것 같아 반성하고 있기도 하다. 앞으로 남은 약 4개월 동안도 지치지 않고 긴장을 유지하면서 꾸준히 달려나가보고 싶다.

 

아 그리고 요새는 여기 오기 정말 잘했다는 생각을 항상 하는 중이다. 살면서 언제 또 이렇게까지 무언가에 순수하게 몰입할 수 있을까. 정말 행복한 기회를 잡았다 생각하면서 모든 순간을 즐기면서 최선을 다해보려 한다.