0810 상호평가

일단 이 모든 것을 다같이 리뷰하고 평가하기에는 시간도 시간이지만 중요도를 해서 그 설문 자체로는 그거였잖아요. 전체 내가 관찰하는 것 중에 반복되는 문제 중에 가장 대선했으면 하는 것만 쓰는 거였잖아요. 일단 그걸 중점적으로 할 거고 이 비교 대조프를 만든 이유는 가장 그거였고 내가 나를 평가하는 것과 동료들이 나를 평가하는 것 그리고 나머지 동료들이 평가하는 것들이 어떤 차이가 있는지 그것들을 이해해서 내가 어떤 걸 개선해야 되는지를 남들이 피드백을 줬을 때

그 사이의 감극을 대화를 통해서 잘 풀기 위해서 만들게 된 거고 그래서 보면 나중에 한 명, 한 명씩 볼 때마다 달라지겠지만 누군가는 과대평가죠. 나에 대한 평가를 더 후하게 하고 어떤 사람은 남들이 나를 평가하는 것보다 더 스트릭트하게 나를 평가하는 사람들이 있어요. 그리고 그 강급이 안 나는 사람도 있고 아니면 공통평가랑 자기 역할평가의 점수 차이가 큰 사람들도 있고 다 달라요. 그래서 이걸 통해서 뭔가 남들이 인식하는 나의 역할

내가 인식하는 나의 역할 그리고 수행 정도를 좀 잘 돌아보고 개선사항을 정할 때도 정말 구체적인 액션플랜 사실 아까 팀 정체 문제를 볼 때에도 개선 사항을 뭔가 개선을 해야 돼. 사실 느끼지만 실행을 안 한다고 사실 공통의 문제긴 했잖아요. 그래서 그것들을 여기서 해소할 수 있었으면 좋겠습니다. 이.. 이.. 누구 뒤에 베개? 응. 핀 없어요? 네. 사실 당국적으로 나상가 결과를

순서대로 공유할거에요. 전체적으로 지금 전체 데시구도 있는 내용으로 전체적으로 어떤 격차들이 있는지 먼저 공유를 하고 그 다음에는 저 연희 태니 무수노우 순서는 일단 제거를 먼저 할게요. 왜냐면 제가 이걸 진행하려고 제 것도 안 읽었기 때문에 제거를 좀 하면서 어떤 식으로 진행해야 될지 다 같이 감을 잡고 그 다음에는 가위가위 보러 가겠습니다. 운명에 맡겨서 순서대로 진행을 할게요. 그래서 저 평가를 개인으로 넘어갔을 때는 평가결과를 제가 공유를 해주면

그리고 그래서 저 평가 전체에 대한 요약도 AR을 시켰거든요 그러니까 평가 지표를 학습시킨 다음에 그걸로 결과를 냈기 때문에 제 개인적인 견해나 정제 요약이 전혀 없다는 거 그거는 정말 남들이 쓴 그 자연어에 종합이라고만 보시면 됩니다. 전혀 그 어떤 것도 개입되지 않았어요. 그리고 그거를 제가 공유해드리고 나면 그걸로 인해서 어떻게 실제 업무에 영향을 미쳤는지 파악을 하고 그거에 대해서 이 평가대상자 첫번째가 저면 제가 그거에 대해서 설명을 하는 거를 먼저 하겠습니다. 왜냐하면

어쨌든 자기평가, 동료평가가 같이 종합되어 있을 거기 때문에 내가 왜 자기평가를 그렇게 했는지 들어보니까 내가 왜 이런 평가를 받게 됐는지에 대해서 동의하는 부분, 이견이 있는 부분 그리고 뭔가 아니면 내가 서술을 미처 못했거나 아니면 이게 요약됐기 때문에 뭔가 맥락이 빠진 것 같은 것들을 짚어주시면 됩니다 그리고 그걸 통해서 나의 기준, 내가 나를 평가했던 기준이라든지 개선하고 싶다는 문제를 나도 썼잖아요 나에게도 그런 것들이 기준이 뭐였는지를 다 같이 공유되는 자리에서 그 기준을 먼저 듣고

그 다음에 동료들의 의견을 듣겠습니다 그 문은 근데 전체 공유되길 원했잖아요 그래서 본인들에게 다 말해도 되고 근데 아마 앞에서 이미 요약이 됐거나 당사자가 발언을 할 수도 있어요 그런 경우는 그냥 동의한다고 넘어가서 자세히 계속 진행을 하면 되겠습니다 그래서 다른 사람들이 말할 때는 뭐랄까 1회짜라든지 제가 적어놓은 거 있어요 같은 것보다는 이게 어쨌든 어떤 단일 사건에 대한 지적이 아니라 지금 피드백 시간이 아니라 반복되는 문제를 찾아서 개선하고자 발전하고자 하는 거니까

계속해서 이게 반복되더라 나의 증언이라고 봐야겠죠 그거를 서로의 동료들에게 해주는게 도움이 된다고 생각하시면 됩니다 거기서 이제 나온 얘기들에서 이게 실제 사실사건인 것과 그 사실사건 안에서 각자 어떻게 해석하고 받아들이고 있는지 같은 것도 얘기가 됐을 거니까 그거를 바탕으로 그러면 정말 이 사람이 개선해야 될 점은 무엇인가? 그리고 그거를 개선할 수 있는 액션 플랜이 뭔가를 정리를 명확하게 해놓고

그게 곧 다음에 KPT 때의 기준으로 삼겠습니다. 그래서 아까 거기서 그냥 개선을 뛰어넘었어요. 어차피 똑같아서 개개인을 개선할 수 있는 기회가 여기 있습니까? 그렇다면 전체 내용부터 개괄적으로 얘기를 드리겠습니다. 여기 보면 이 큰 숫자 있잖아요. 이거는 동료들이 이 사람을 결과, 기업인 업무 완결성에 대해서 어떻게 평가했느냐의 숫자입니다. 그리고 나도 이걸 예시로 들면 연휴에 대해서 다들 4점을 줬어요.

근데 나도 4점이래. 그래서 크게 간극이 없는 나에 대한 나의 파악과 다른 사람들의 이해도가 같은 그리고 여기 밑에 보면 팀원들은 중앙가 근데 이게 평균이 아니라 중앙값으로 했거든요 2와 뭐 2함... 아휴 어떻게 했나? 1, 2와 5가 있었으면 그 중앙값으로 계산되는 뭐죠? 바할지 척도에 있는 그런 거래요. 그걸로 됐기 때문에 그래서 이렇게 그 간격의 차이가 1점인 거 그래서 이게

나 빼기 동료 평가... 아! 내 평가 빼기 동료 평가여서 플러스인 거는 내가 좀 더 나를 높게 평가하고 있는 거 마이너스는 내가 나를 낮게 말 그대로 낮게 평가하고 있는 거 라고 인식하시면 되겠습니다 그리고 이 색깔에 따라서 파란색으로 갈수록 그거를 잘 수행하고 있다의 판단으로 빨간색이 가까울수록 뭔가 개선해야 될 문제가 이 영역 안에 있다 라고 이해하시면 되겠습니다

그리고 이렇게 큰 색깔이 없는 중앙각 근데 이게 아까 사실 팀 얘기해서 노우라는 적점이 없어서 그리고 디자인 업무는 1인이 수행할 때 너무 분명해서 크게 이견이 생길 게 없다고 했는데 그게 여기서도 사실 이미 드러나 있긴 했어요. 다 그냥 완전 중압값에 머물러 있어서 이건 좀 구체적인 사례들을 얘기하면서 노차례는 좀 더 찾아봐야 될 것 같습니다. 그래서 저 상황에서 요약을 하면 일단 저는 피드백 반년과 성장하는 부분에서 유일하게 오차가 있었어요

그래서 제거를 볼 때는 이 부분에 좀 집중해서 얘기를 하게 될 거고 태니는 전반적인 여기 색깔에서 나타나지만 전반적인 분야에서 인식 차이가 보이는 것들이 항목에 딱 명확하게 있었거든요 그래서 여기서도 그거에 대해서 왜 인식 차이가 생기는지를 먼저 찾고 그 중에서 정말 인식만 개선하면 되는 거 있을 거고 실제로 문제를 개선해야 되는 게 있을 거고 그걸 찾는 게 될 거고 '무'는 굉장히 특이해요 그냥 자기에게 개 박한 사람이에요 그래서 이걸 나중에 또

왜 이렇게 다들 박하게 해주세요? 저만 다 풀렸어요 근데 저는 그게 늦춰졌어요 10이랑 노우는 이게 정말 그냥 그냥 우리가 평소에 약간 MBTI라는 거 할 때 5점 척도처럼 생각해서 그러니까 매우 그렇지 않다 매우 그렇다 정도로 생각하고 평가를 했다는 게 느껴지는 게 5점까지도 범위로 뒀더라고요 근데 제가 볼 때 느껴지는 건 저랑 문은 이 5점을 정말 완전 무결의 그냥 득점으로 생각하고 아예 5점 없이 한 느낌? 왜냐하면 제 입장에서는 제가 이걸 자체를 평가와 이런 자리를 만든 것 자체가

그 누구도 100점이 없기 때문에 서로 100점을 끌어올리기 위한 자리라고 생각해서 사실 저도 그 점수를 없이 하긴 했거든요 거기서 생기는 약간의 오차는 고려해 주시면 되겠습니다 그래서'문'은 그냥 너무 밝게, 근데 그 밝한 게 오히려 우리가 이 사람을 평가하는 거에 대해서 이 사람이 원하는 만큼 밝하게 해서 성장할 수 있게 도와줄 거냐 근데 그걸 원하는 것 같긴 해요, 아까도 말했지만 그렇게 가기 위해서 어떻게 해야 되는지를 보고 또 반면에 아까 그것도 있었잖아요 내가 자신감이 없어서 어? 나 그냥 이 발표 흐름 내 마음대로 해볼게요

내용도 이렇게 하고 디자인도 그냥 내가 해서 낼게요 부분을 그러면 그때 사례를 보면 저희들은 그냥 내버려 둬야 되는 거잖아요 그런 부분들을 좀 찾으면 될 것 같고 스노모도 아까 말했던 거 비슷하게 일단 우정을 하는 것도 나중에 사례들을 보면 알겠지만 이게 여기 보면 4개 안에 있잖아요 나머지 1개에서는 어쨌든 요구하는 것들이 나타나 있으니까 오히려 노후는 여기 언급 안 된 거에서 조금 개선점을 찾아보는 식으로 진행을 하겠습니다.

- 좋습니다 - 저에게로 갈게요 네 저에게로 갈게요 근데 저는 신기하게 다 일치했어요 진짜 신기하다 저는 근데 제가 느끼기에는 제가 피드백을 줄 때도 그렇고 그 업무 결과를 공유 받거나 뭔가 논의할 때도 사실 근데 뭔가 기능적인 거나 피그마에 올려진 것들 아니면 이미 개발된 것들을 나눌 때는 약간 시식시 느낌이 나거든요 어 정말 지금 수평으로 시작 모니 잘하고 있다 재밌다

이 느낌인데 다른 상황에서는 아 뭔가 이 롤과 해야 되는 역할의 인식 차이가 다 크다 라는 걸 솔직히 느꼈는데 평가에서는 똑같이 나와서 좀 사례들을 구체적으로 계속 얘기를 해봐야 될 것 같습니다 그리고 동력평가가 더 높은 부분이 두 개가 있었고 정말 근데 놀라운 거는 이 세 분에 대한 평가가 저에 대한 평가가 서로 서로 다른 네 가지가 있어요 그러니까 모두가 그... 근데 그게 그건 거 같아요 아까도 말했듯이 저는 모두와 계속 접점이 있고 계속 뭔가를 하잖아요?

그렇죠 그러다 보니까 그 안에서 생기는 팀 공통을 벗어나서도 개인적인 관계와 그 의존 관계들이 엄청 촘촘하다 보니까 유대가 밀집한 촘촘한보다는 너무 거미줄이 많다 그러다 보니까 각자 저에 대한 차이가 생기는 것 같아요 근데 그 안에서도 어쨌든 그런 업무 프로세스를 정리할 때 저는 두 관계가 일치게끔 하는 게 저의 그거이기도 할 테니까 그런 것들을 좀 찾을 수 있었으면 좋겠고 그리고 이런 시력 단복 의견은 과반이잖아요. 사실 4명 밖에 안되기 때문에 두 명이 언급하면 과반으로 했거든요.

그래서 어쨌든 그렇다는 거는 그게 결국에는 이 팀의 여론이라고 볼 수 있는 거니까 그런 의견이 하나가 있어서 그것도 짚어보겠습니다. 이 페이지는 사실 제가 웹배포를 안 해놨거든요. 그 한 방법을 AR 때려서 만들던지 이 파일 자체를 공개하겠습니다 그래서 이 비교표는 나중에 다 각자도 소유하고 남의 것도 계속 오가면서 볼 수 있게 할게요 여기는 생략하고 객관성을 위해서 그냥 준거 같습니다

보면 근데... 안개... 근데 저는 일단 강점이 되는 점은 3명 중에 3명이 다 같은 의견을 주긴 했어요 그래서 외부 이해관계자랑 논의하는 거 정리하고 후속 업무가 연결하는 행동 근데 이게 굳이 비교하면 PM이나 계획부자보다는 대표의 롤의 범위라고 생각되긴 하거든요

아 근데 이것도 근데 이거 어떻게 아까 팀 회의를 할 때는 분배해야 된다는 의견이 있긴 했었잖아요 일단 보류하겠습니다. 감점이라고 해줬으니까 그리고 이거 반복되는 내용이 그거였어요 위임했을 때 완료 조건이랑 이거 됐다 안 됐다 어떻게 할 거냐 그런 것들에 대해서 이 각이 그래서 이게 그게 문제라는 얘기가 나왔어요. 이게 대표로서 확인하는 지점이 언제야 되는가.

사실 아까도 말했지만 제가 지금 중간중간에 계속 확인을 하는 것들이 있잖아요. 근데 그거를 사실 일이 잘 흘러가든 안되든 완전 빠져있는게 맞다라는 생각을 최근에 좀 많이 확인했거든요. 이제 그만해야 된다 정말. 각자의 독립을 시켜야 된다. 그게 일정이 더 걸리든, 아니면 뭐 그렇게 되든. 그래서 일단 제 의견을, 근데 이건 제 얘기를 제가 진행해야 되니까 동시에 바로 할게요. 읽으면서 제 의견을. 제 의견은 약간 뭐라 해야 되지. 그거를 좀 신경을 많이 썼어 사실. 예전에 뭔가

업무에 수행이 잘 안 되거나 이래서 제가 뭔가 '아 이거 다시 해주세요' 할 때 이'다시'를 마치 업무를 새로 준다라고 느끼거나 그거에 대해서 컴플레인을 받은 경우가 있거든요 지시를 제대로 안 해줘서 설명을 안 해줘서 였는데 제 입장에서는 그거를 공부하고 설명하고 업무의 범위를 정하는 것조차도 안 하는 게 맞는 건데 내가 말한 DRI는 그게 안 되니까 나는 가이드하고 도와주기 위해서 그런 것들을 제시하고 이런 것도 조사하면 좋다 아니면 이런 것도 하면 좋다 결과물이 이런 식으로 나오면 좋겠다

를 했는데 상대방이 느끼기에는 진작만 해주지 뭔데 이렇게 되는 경우가 있었어요 그래서 그걸 안 만들려면 이제 미리미리 계속 확인을 해야 되는 거죠 이 방향 가고 있나? 근데 그 방향이 더 좋으면 당연히 내버려 주겠지만 안 되고 있거나 아예 일이 미뤄져 있으면 아 근데 이거 해야 돼서 이러이렇게 해달라 이러이런 부분 챙겨달라가 되다 보니까 너무 약간 마이크로 매니징 아닌 마이크로 매니징 이 됐는데 그 부분을 좀 합의를 통해서 아예 손을 안 댄다 로 가버리는 게 좋지 않나 라는 생각이 아까 그 팀에서 마지막에 얘기할 때도

어쨌든 뭐라 그러지 그런거 의정관계도 정리를 하고 그 테스트 쓸 때도 자세히 썼으면 좋겠다 라고 텐이가 구체적으로 그 액션 플랜을 제시해 줬잖아요 근데 저는 그거를 그 정기회의 안에 넣는다던지 제가 자 쓰세요 이렇게 하는게 아니라 뭐 예를 들면 새롭게 생길래 아 내 세미나가 그러면 아 세미나 시작해야 돼요 그러면 사실 그 세미나에 발표한 내용은 PC 아니면 위치 시각화일 거잖아요 그럼 그 시각화를 맡은 면이 뭔가

발표 자료 준비와 김정 교수와 협의의 DRR을 맡았다. 그러면 그 자료에 들어가는 기술적인 근거는 무가하겠지만 발표 흐름과 발표자는 제가 되겠죠? 아니면 김정 교수님이 도메인에 강조를 했지만 만약에 이게 완전 기술적인 얘기가 소개된다. 그러면 개발자 둘 중에 선택이 될 것, 발표자가 흥어가 될 것. 근데 발표자료를 최종적으로 디자인하고 거기에 우리의 BI를 씌워주는 건 NO가 될 거잖아요 이런 것들을'아 이건 누가 해야겠네' 누가 해야겠네

그 순서를 내가 기술적인 자료를 기획자에게 넘겨서 기획자가 발표 흐름을 짜주면 뭐 그 다음에 NO가 디자인 이런 것까지 다 하는 게 좀 DRI라고 생각해요 그래서 만약에 정기회에서 그런 업무 얘기가 나왔다 그러면 그 테스트 투두에는 그냥 세미나 준비 세미나 준비를 위해서 정말 뭘 준비해야 되는지 누구를 여기 참여시키고 내가 누구의 일정 누구의 업무를 주고 결과물 확인하고 해야 되는지까지 다 관리했으면 좋겠다 그렇게 되지 않으면 기존 문제가 또 발생한다 왜냐면 계속 제가 정기회의원에서 관리를 할 거고 거기서 또 리캡하고 거기서 또 테스트가 주어지면 또 의사결정자가

헷갈려질 것 같아요. 그리고 또 그렇게 하다보면 또 그래서 이렇게 제가 어? 근데 이거 발표 이렇게 되지 않아 해버리면 만약에 그걸 누가 들었다. 아까 누가 말하고 어? 그럼 이거 빠르지 뭐. 또 이렇게 되는 어 그런 문제가 계속 꼬여갈 것 같아요. 그래서 기존에 있었던 그런 배경을 DRRI 그냥 완전 분리하는 식으로 해서 정말 책임지고 A to Z를 해봐야 거기서 내가 A, Z를 못하는 파트를 찾아서 그걸 대표한테 요청을 하던

아니면 뭐 같은 직무를 하는 사람이 요청을 하던 아예 다른 노예 요청을 하던 그런 게 생길 것 같고 아무튼 그렇습니다 아 그리고 그게 완전 분리돼야 저는 저게 그것도 같이 썼거든요. 제가 쓴 내용은 이거였어요. 이게 뭐라 해야 되지? 어떤 업무를 얘기할 때는 저는 대표고 팀원이라는 생각으로 의사결정 된 거를 얘기한 건데 그 업무 안 한대.

결론적으로 업무 안 한다가 되는 경우가 있어. 그럼 어? 네? 어? 이거 대표로서 의사결정 권을 가져야 되고 이 업무를 완료를 해야 되는데 애초에 DRI를 안 맞겠다 같은 식으로 정리되면 약간 이렇게 돼 근데 또 기획자로서 이렇게 논의를 하려고 하면 저에게 모든 의사결정을 맡기는 녀석지가 많다고 느껴지거든요 기능도 회의 때 논의하자 회의 때 근거자를 준비해서 A, B안 중에 고릅시다 하는 게 아니라 제가 기능명서에 쓰면 그게 결론이 약간 되는 아니면 그거를 노후랑 저랑 일대일로 얘기해서 하다가도

만약에 제가 노후 의견을 납득하고 이렇게 하면 그게 결정인거고 아니라서 계속 또 이렇게 막 논의하다가 새로운 게 찾아지면 그게 의견이 되고 결국에는 의사결정권이 저한테 안 있어도 되는 게 저한테 의사결정이 와 있으니까 거기서도 또 약간 병목이 생긴다고 느껴지거든요 거기서 뭔가 저의 대답을 기다리는 느낌? 근데 그거를 이제 거기서 오히려 발을 빼고 확실하게 대표이사결정이 필요한 부분에서 그거를 잘 수행해야 되지 않나? 근데 그러려면 진짜 그냥 아예 업무를 분리해야 된다

그래서 제가 만약 기능랑서를 쓰는 게 필요하다 면 그 단계에 저를 그 업무에 저에게 요청해서 개입시키는 그 의존관계를 DRI인 사랑이 끌어오는 구조를 하는 게 좋지 않나? 라는 생각을 해서 평가에 그런 내용들을 좀 썼었어요. 그럼 다음으로 넘어갈게요. 아 그러니까 한 게 또 같은 것 같아요. 결국엔 자율 실행을 만드는 지원과 피드백 방식에서 저 스스로 저게 문제라고도 썼거든요. 근데 인식 차이가 개 크네.

그래요. 회의에서 맥락을 확인하겠습니다. 세 분 뭐라고 쓰셨어요? 저 뭐라고 썼죠? 이게 어느 분이냐. 저는 뭐라고 썼는지 기억나요. 아 그래요? 네. 전 모르겠는데. 저거는 7번이라고 생각합니다. 여기. 음~ 그럼. 왜일까요? 음~ 왜일까?

아니, 이 부분에 대해서 그냥 얘기하면 될 것 같아요. 구성원이 자율적으로 업무를 다 수행하거나 완료하거나 스스로 완성도를 높일 수 있게 하는 그런 것들에 대해서 지원이나 피드백이 안 되는 거죠. 근데 제가 스스로 판단하기에 저의 문제는 다 안 됐을 때 날카로운 패배를 한 적이 잘 없는 거라고 생각해요 왜냐면 이 회사의 발전 아니면 다음 사업 방향을 위해서 안 나왔어 그럼 더 짜야 되는데 솔직히 제가 좀 못하는 것 같아요 못했던 것 같아요

왜냐면 그 기준 중에 하나는 이거였어요 나도 이 안 끝낸 거 많은데 왜냐하면 나도 이거 하느라고 뭔가 명세 안성해서 양해 공하는 거 많고 나도 뭐 이거 안 돼서 그 노우에게 서비스 소개 같은 경우 어쨌든 우리 다 똑같은 팩트 알고 시나리오 있으니까 노우가 만들어 만들면 그 다음에 제가 라이팅 수정을 할게요 이런 식으로 그런 것들 순서를 바꾸거나 그때그때 그냥 융통성 따라서 한 것들이 있기 때문에 그래서 상대방이 뭔가 융통성을 발휘하거나 완성도를 안 하고 그래도 완료다 라고 스스로를 평가했을 때 그거에 대해서 지적을 하지 못했던 것 같아요

근데 그렇기 때문에 내가 어차피 끝에 가서 지적을 못하니까 계속 단계별로 개입하는 느낌? 스스로는 그걸 악순환 좀 시킨 것 같아요 제가 판단할 때 그래서 그렇게 한 번 했습니다 다들 뭐라고 했길래 세 명이 다른지 저에게 좀 들려주시겠어요? 기억이 안 나 작성한 거 작성한 거 좀 보겠습니다 별도 진행할 때도 봐야 될 때부터 볼게요 아 근데 이게 요약이 되니까 뭔가

뭔지 뭘 하고 저러는지 진짜 저도 봐도 돼요 캡쳐도 좀 본인 쓴 거 봐도 됩니다 리딩을 막 하고 그거에 참여도를 이끄는 노력을 계속 주기적으로 한다고 생각이 들고 본인의 노력을 한다고 생각하는데 실제로 그게 팀원의 자발적인 것까지 연결되지 않는 것 같아서 그런 의견을 썼던 것 같아요.

노력은 하나? 팀의 영향력을 받아가지 못한 느낌인가? 안 좋게 얘기하면 그렇죠. 안 좋게 해석하면 그렇죠. 저 혹시 뭐라도 없나요? 루틴이 6, 8번에 대한 의견 남긴 거를 보면 될 거예요. 자꾸 6번과 8번을 내가 몇 점을 줬나. 저는 8번은 안 줬고요. 6번씩만 했는데 여기 다 까요, 그냥. 이렇게 하면 돼. 아니 말할 거 같아. 근데 제가 어제 보고 있으니까 노은은 아니 노은은

강점만 남겨놨어요. 패스하겠습니다. 저 앞에 적힌 이... 이의경과... 아, 어디야? 이런 부분에 대한 얘기만 언급을 해놨고 저는 6번 한 거 거기에 적성되어 있어요. 태닌이 그냥 얘기해주시면 됩니다. 저 글에 대한 거를 설명해주시면 됩니다. 저는 제 거의 사례를 들면서 얘기를 했던 것 같은데 뭔가 요청을 할 때 뭐뭐를 조사하고 어떤 제시를 해달라는 추상적 요청보다는

어떤 흐름을 업무를 했고 이를 앱으로 전환해서 할 방안이 있는지 아니면 법적 제약이 있는지 같은 구체적인 요청 업무로 저만 했으면 좋겠다 이렇게 적어봤어요. '무'는요? 잠시만요. '무'는 제가 읽어줄게요. 몇 번이요? 아 왜요? 아 제가 안 해봤는데 제가? 6번과 8번을.. 아 근데 제가 같은 칸인데'무'는 6, 7, 8, 10, 2처럼 나눠서 써놓긴 했어요. 몇 번이요? 6에서 8번에 쓴 답변을 보시면 됩니다. 아~ 저는 사업 678 다 얘기하면 돼요?

네 사업가면 일단은 로드맵이나 이런 거 적극적으로 하는데 저는 최근 MDM, DRI 관련해서 조금 소통에서의 문제가 있었다고 생각해가지고 이게 저한테는 조금 혼동이 이 부분을 적었던 것 같습니다 그리고 뭐 8번은 외부 미팅마다 아젠다 설정을 해줬고 이제 최근에는 오히려 DRI를 조금 아예 할당을 해가지고 하는 편인데

이거에 대해서 괜찮다 생각해서 그냥 이 의견도 남겼던 것 같아요 저 MDM 얘기를 두 분은 모르는 얘기라 공유를 하자면 그 MDM 회의를 이렇게 3명 참여했잖아요 근데 제가 그걸 하기 전에 무에게 그 어쨌든 무에게 할당할 거기 때문에 그 SNL 이쪽이랑 연락을 해야 된다. 먼저 공유를 해놓고 단톡방에도 얘기를 했어요. 그리고 그때 제가 얘기를 할 때는 이거 무가 맡아야 된다. 각자 이제 테스트를 나누기 때문에 무는 이 파트를 했으면 좋겠다 라고 해서 저는 그 시점부터 이건 무가 가져간다 라는 생각을 한거에요.

근데 무의 입장은 그.. 그래서 저는 그거를 더 확실하게 전달하려고 사전 미팅이 가능한지를 3명에게 체크했고 근데 그 전날 못했기 때문에 당일날 12시 반에 하게 됐죠 그래서 제 입장은 12시 반에 확실하게 리마인드하고 이 DRI가 스스로 수행이 되는 게 잘 알고 있는지만 체크하고 됐으면 그냥 시작 미팅부터 완전 무다라는 생각을 가지고 있었고 근데 미팅을 시작해보니까 이거 이제 철저히 저의 시점 "왜 무카 진행을 안 하지?"가 되는 거예요 그래서 그때마다 제가 하다 보니까 그 회의 자체에 DRI를 제가 하고 마무리하게 되었어요.

근데 끝나고 나서 제가 무한테'무가 진행을 알수록 됐다. 다음에는 회의를 좀 더 주저적으로 해도 좋겠다.' 했더니 무의 입장은'어? 근데 지금부터 이미 DRI인지 몰랐다.' 다 된 거예요. 그래서 그때 얘기한 거는 DRI 할 때 시작되는 날짜를 고지를 하겠다. 확실하게 그걸 받아가는 날짜를 이라고 얘기하고 그때 끝냈는데 근데 그 뒤로는 사실 뭐 그분이랑 Q&A 하고 하는 거를 바로 가져가서 하고 있어서 저거의 배경 스토리는 그렇습니다.

근데 어쨌든 그렇게 나누는 거에 대한 건 업무상 괜찮다고 생각하시는 거네요. - 어, 맨날은? - 오케이. 예. 그러면 그 인식책은 여기서 커서 그런가 봐요. 여기는 DRI 가져가는 게 맞다고 태인이는 DRI 주는 게 아니라 구체적으로 업무를 지시했으면 좋겠다. 구성인데. DRI를 지시한다고 하면 어떤 기준으로 지금 현재 상황처럼 연희가 판단해서 이 부분은 무가 가져갔으면 좋겠다 하면

무가 DRI로 지정이 되는 형식으로 들고 가는 건가요? 어쨌든 여기 평가에도 대표 기준으로 썼지만 그런 입장에서 정말 이 팀의 성과를 위해서 제가 분배하는 게 맞는 것 같고 근데 그게 만약에 이렇게 개발자처럼 이인이 있어 그리고 이미 진행된 업무가 있으면 상호 확인을 해서 누구에게 배정할지 맞는지 정하는 게 나을 것 같아 근데 MDM과 PCM이 완전 분리되어 있고 뉴! 였어서 평평성 있게 하나하나라고 생각했는데 그런 거는 좀 누구에게 할지는 얘기해보면서 앞으로 정해가면 될 것 같고

좋습니다 구체적으로 준다와 그냥 이 영역을 맡아라고 한다면 저는 이 영역을 맡아라고 DRL 주는 걸로 결정하고 싶겠네요. 앞으로 업무 방식을. 왜냐면 사실 제가 지금 태희가 말한 것처럼 계속 그렇게 구체적으로 주잖아요. 그러면 이 구체성이 있는 걸 주기 위해서 저는 항상 그 모든 공부하고 있어요. 사실 PCI 주인하여 공부를 다 했거든요. MDM을 주기 전에 저는 MDM 하는 거랑 ABM 설정하는 것과 사실 다 알고 있어요. 그래서 이미 그분에게도 전화 미팅하면서 전화 주세요 그 한 줄에 대해서 제가 맥락을 파악하기 위해서

저는 이미 많은 것을 공부해야 해요. 근데 그 공부가 안 나오지면 제 업무 딜레이를 해결할 수가 없거든요. 그래서 계속 저한테 뭔가 자세히 주세요 라고 하는데 그거는 내일 네가 해라고 사실 느껴지긴 해요. 제가 말한 DRI는 그 공부를 당신이 해서 당신 수준을 높여서 우리 팀의 수준을 높여주세요 라는 말이죠. 그래서 그게 사실 됐으면 좋겠고 그런 의미에서 이 상춘되는 의견에서는 지금 노우가 말한대로 DRI를 누구에게 왜 주느냐의 기준을 어떻게 할지만 분명히 하고 근데 그거는 첫째로는 그냥 일단 대표의 판단.

왜냐하면 어쨌든 전문 배경이 각자 있긴 하니까 두 번째는 모호하거나 이 사람이 담당을 해야 되는데 이게 맞는 게 그 시기라든지 이제는 우리가 프로젝트성으로 일을 할 수 있기 때문에 상대방에 따라서 세미나 준비든 R&D든 경찰이든 그렇기 때문에 그때 누군가에 업무가 몰려있다 그러면 이 사람이 진행하는 걸 넘기고 새로운 DRI를 줄 거냐 남에게 주고 아니면 일정을 조율해도 이 사람에게 줄 거냐 아니면 업무가 과밀이니까 이 DRI를 내가 안거나 남에게 줄 거냐

뭐 이런 것들을 그때그때 상황에 따라서 좀 협의하면서 하는 걸로. 유순이는 무조건 협의가 필요한 걸로. 그리고 제가 DRR 줬을 때도 방금 말한 같은 상황에 본인이 처해있으면 잘 공유해줬으면 좋겠어요. 대표가 주니까 "옙옙옙" 하고"삼일지 뒤지겠다. 저 못해요." 이렇게 되지 않게. 스스로 본인의 룸을 잘 파악하고 하면 좋겠다. 그리고 그때 그 DRR 맡았을 때 제가 근데 MDM은 정말 저에게 또'엥?'의 상황이긴 했잖아요. 그래서 제가 확인한 최대한의 확인한 거를 그냥 싹 다 공유했고

PCI는 사실 그 참석을 못했기 때문에 그래서 회의 그 리켓하는 회의부터 다 같이 한 번 했고 그 다음에 PCI를 줬는데 그... 근데 그렇게 받았을 때 내가 진짜 감을 못 잡겠다. 나도 이... 어떻게 보면 어떤 부문장을 맡기는 거죠 큰 회사의 기준이라 치면 근데 내가 이 TF팀에 나보고 하래 ETF실에 실장을 하래 나도 이게 뭔지 모르겠어 하면 그거에 대한 사실 팀 전체 의견을 구할 수도 있는 거고

저는 이 부분이고 새로운 예를 쳐볼게요 만약에 시공단 3D맵을 우리 앱에 넣어야 돼. 보니까 이미 경찰이 그 정도 가 있기 때문에 우리 수순이 그런 것까지 다 구현한다는 걸 보여주려면 3D맵 프로토타입까지 나와야 될 것 같아. 근데 그게 어쨌든 시각적인 게 크다 보니까 노우에게 던져진 거예요. 근데 우리는 아직 한 번도 회의에서 개발적으로 어떻게 되는 건지, 아이오에서 어떻게 되는지 말한 적이 없어. 근데 그거를 다 혼자 공부해서 할 수는 없잖아요. 그럼 노우가 다 소집해. 기술적인 제약을 개발팀에서 좀 확인해 주셨으면 좋겠어요.

아니면 그거에 대해 뭔가 모델링된 이미 어딘가 소스가 있으면 그거 받아서 캡쳐라도 해주시면 제가 그거 토대로 UI만 바꿔서 프로토카드 가져올게요. 이런 식의 새로운 의정관계를 만들고 이 프로젝트에 누군가를 개입시키는 거 조차 DRI가 있으면 좋겠다. 그런 생각입니다. 예. 어떻게 하는 색? 혹시 저 얘기하는거? 그러니까 우~처럼 제가 하고 싶은 말은 이거를 그냥 A to Z부터 이렇게 이렇게 해가지고 이렇게 해주세요 라기보다는

사실 그때 리켓 했을 때 제가 그 회의에 참여하지 못했기도 했고 리켓 했을 때 그리고 클로징 노트에는 PCI값 사전 조사 이렇게 되어 있어서 전 진짜 사전 조사나 그 PCI값이나 이런 부분에 대해서 좀 더 공부를 한 다음에 저는 공유를 하고 그 다음에 목데이터를 만든다고 생각을 했고 근데 목데이터 부분을 하려다 보니까 그냥 값만 받아와서 그걸 시컥하는게 불가능했다 그래서 이런 부분에 그냥 목데이터를 필드로 넣을 수는 있다 라고 설명을 하고 싶었고 그걸 이제 연희한테 그 회의 준비하기 전에 이런 이런 상황이다 이렇게 얘기했을 때

그때 요청이 온 게 시컥화를 얘기해 주셨거든요. 그런 부분에 대해서 그냥 조금 더 시작할 때, 완전히 가르쳐달라는 게 아니라 조금 더 얘기해서 '아 그러면 제가 여기서부터 여기까지 해가지고 이걸 가져올게요'가 됐으면 좋겠는데 아마 저 때 회의 때 저는 사전 조사까지 하고 공유를 하라는 뜻이구나, 그 다음 업데이터를 만들라는 뜻이구나까지 밖에 생각을 못했다가 마지막쯤에 그 딱 전날이었거든요. 그때 이게 ppt 자료 오면서 급하게 또 저도 준비를 했다 보니까

그래서 저는 뭔가 사전에 그런 설명이 안 됐다라고 저는 인지를 했던 것 같아요. 그래서 그런 부분에 있어서만 조금 해달라는 거지 막 다 알려달라는 거지 그건 인지하는 것 같아요. 근데 그 맨날, PCR에 구체적으로 얘기를 할게요. 우리가 그 자리에서 들었던 PCI도 태희가 들은 수준이랑 똑같아요. 경찰의 PCI 관장, 사실 우리 알고 있잖아요. 국수공 가서 들었긴 했잖아요. 그 자료를 우리가 볼 수 없는 외부인일 뿐. 근데 이 교수님도 그거까지 앱에 들어가 있어야 세미나도 하고

이걸 어디 경찰에 보여줄 수준이다 까지가 다였어요 사실. 그래서 자료가 오면 준다고 했는데 그 자료도 너무 허술했고. 근데 그럴 때 제가 그 다음에 카톡에서 얘기한 건 이거였을 거에요. 이게 된다 안 된다 판단할 때 이 자료가 있으면 어디까지 고도화할 수 있는지 같은 기능적인 그 다음 단계도 생각해서 그러면 이게 만약에 우리한테 지금 단순히 시각화가 안 되긴 하잖아요. 우리가 통신사 정도의 대규모 기업의 빅데이터도 가지고 기술을 가지고 있는 게 아니면 그러면 이렇기 때문에 안 되는 거고 그래서 이걸 만들어내려면 경찰에 어떤 정보를 받아야 된다. 를 정리해주길 바랐던 거예요.

근데 공부해보니까'우리는 시각할 수 없어요.'에서 끝나기 때문에 이걸 그 사전 조사에서 끝내는 게 아니라 이 사전 조사를 이 목적으로 하는 걸 이해하고 이 부분을 고려해서 회의를 준비해줬으면 좋겠어요. 였거든요. 그래서 근데 아 이거를... 근데 DRI가 딱 주어졌을 때 내가 이 목적성을 모르겠다 라는 거는 지금 태니가 말한대로 그렇게 얘기해서 계속 확인해서 맞춰가는 게 더 좋긴 하거든요 근데 그걸 회의 당일에 하지 않았으면 좋겠다 그 테스트가 주어진 날이던지 그리고 그게 만약에

사실 일주일 시간에 끝이었잖아요 사실 그랬어서 그것만 아니면 괜찮을 것 같다 같이 잡아갈 수 있다면 그리고 또 하나는 그래서 제가 그거에 나중에 업무 프로세스를 잡을 때 얘기할 생각인데 그래서 그냥 DRI를 줄 때 우리 팀에게 맞는 PRD 구조를 생각해 오긴 했거든요 제가 계속 업무 프로세스 생각해보겠다 한 거, 무조건가 있다고 했던 거 근데 그때 했을 때 그 PRD 개념의 최종 목적 왜냐면 제가 계속 이 단기에 눈에 보이는 확실하게 이해하고 수행할 수 있는 것들을 계속 주다 보니까

그 태니가 말한 그런 상황이 생기는 것 같은 거예요 그 다음을 계속 생각한다 근데 저는 그게 답답하고 그러면 계속 개입하고 이게 있다 보니까 그게 무의 입장에서는 그래서 우리 이거 수사해서 하면 어디 가는데 까팀에 공유가 안 되는 것 같고 그걸 하려면 그냥 여기에 구체성보다 더 넓은 최종의 목적성만 제가 제시를 하고 그걸로 기본적인 PRD를 쓰고 그 안에서 그 목적을 달성하는 단계별을 어떻게 할 거며 누구누구가 개입될 거며 첫 번째 과제가 뭔지 내가 그 첫 번째 과제 몇 월 며칠까지 할 건지 같은 거를 디자인과 개발이 각각 영역을 해서 PRD를 완성해놓고

끝까지 나온 다음에 그 뒤에 자세한 스타일은 뒤에 가서 얘기할게요. 근데 어쨌든 첫 PRD를 제가 그 지금 태니가 말하면 완전 최종의 하는 그걸로 시작을 하되 근데 기존까지는 제가 이것까지 다 고민하고 학습한 다음에 요만큼을 줘서 다음 다음 스텝을 갈 수 있게 했던 그거였다면 이제 이것만 주고 어떻게 되든 내버려 두기를 사실 생각하고 있어요. 근데 그렇게 하면 둘 다가 원하는 걸 좀 충족할 수 있나? 있지 않나? 라는 생각이 들어요.

팬이 원하는 것도 어쨌든 최종의 산출물이나 목적성을 명확히 해달라는 거고 그렇다 보니까 그 판단은 정기회의 때 언급하거나 열어두고 하지 않고 제가 그냥 판단해서 그냥 이 업무가 있습니다가 되고 그 업무의 세부는 자율적으로 주도적이게 되는 그거 하면 조금 할 수 있잖아요 근데 해보고 또 아는 게 발견될 수 있으니까 그때 또 조정하고 해보면 좋을 것 같아요

- 그렇습니다 - 좋습니다 근데 그거를 개선 상황에서는 다른 게 더 개선해달라고 했을 수 있기 때문에 아 근데 이 상태면 금방 제가 말하는 방식을 적용해봐도 될 것 같아요 태인이면 무의 의견이 그게 맞다면 그리고 사실 DRI를 지정할 때 연희가 이미 지금 현재 상황에서도 물을 거기에 지정할 때도 이걸 해줬으면 좋겠다 하는 게 있어서 지정을 해주는 거니까

그거를 그냥 문서 한 번 해놓으면 되지 않을까 싶다. 나도 미리 플랜을 짜고 세부 실행안을 내가 정해서 역으로 공유하는 그래서 공유한 것부터가 DRI 회의가 시작되면 될 것 같아 모두 소집해서 연관된 사람만 소집해서 그냥 최종적으로 받고 싶은 결과물과 시간만 정해주고 하면 그 이유는 그 사람이 알아서 해야 된다고 생각

하는 느낌이긴 해요. 그래서 저 완료 조건도 제가 아마 언급했던 것 같은데 뭔가 이게 나와야 된다. 어느 시점까지. 약간 딱 이것만 정해지면 사실 수습 일정 발견해서 해내고 그게 DRI의 몫이라고 생각을 해서 그 정도만 하는 걸로 한번 해보고 안 되면 이제 어디가 문제인지 한번 다시 파악해보는 것도 좋을 것 같아요. 그럼 처음에 보통은 제가 배경 설명하고

이렇게 해야 된다 목적성을 그냥 이렇게 설명하고 정계위 때 설명하고 거기서 그러면 그걸 하기 위한 테스크 첫 번째 테스크만 쓰는 식이었던 거를 다 없애고 그 아젠다 자체를 넘겨주는 그러니까 PRD를 넘기는 식으로 가져가고 그거에 대해서 제가 기대하는 일정을 먼저 박아놓을게요 근데 거기서 협의가 필요하면 이제 그 DRI가 세부사항들 체크해보고 조정이 필요하면 조정해달라고 하면 그냥 저 열린자세로 받아들이는 걸로 근데 그게 정말 부득이한 일정들이 있잖아요

아 그리고 저것도 있었거든요 업무 일정이 촉박하게 준비되어서 우선순위 조정이 어려웠다 근데 사실상 지금까지 모든 사업적 일정은 우리 팀이 결정할 수 있는 게 없었어요 그래서 저거는 어쩔 수 없지만 근데 우선순위 조정을 직접적으로 논의하는 과정들이 필요하다. 왜냐면 태니한테는 제가 그때 그 OCR 회의하면서 그래서 뭐부터 우선순위 할 거냐 해서 다 조정을 같이 했잖아요. 무도 그게 안 될 것 같으면 근데 사실 태니가 요청하지 않았는데 제가 그냥 바로 정리를 해버린 거였어요. 왜냐면 계속 태니가 가고 싶어하는 기능의 방향이 있는데

당장 해결해야 되는 기능이 또 있어. 근데 저는 태니가 어떤 우선순위를 하고 있는지 모르니까 우리 팀은 그 공유가 안 되는 게 문제였기 때문에 그 자리에서 정리를 해버렸는데 저거는 일단은 일단은 지금 노호가 말한대로 스스로 일정관리하고 우선순위하는게 DRI다 나는 마음으로 해보고 근데 안돼 아니면 연희가 둘다 중요하대 둘다 P형이래 근데 그게 하필 나한테 다 있어 그러면 그때는 SOS를 쳐서 일정을 조율하거나 뭐 그런 식으로 하는게 어떤가 어떠세요?

제가 사실 제가 적었거든요. 네, 그래서 누구고 얘기하는 거예요? 어떠세요? 아니, 근데 이게... 아니, 의명이 없잖아요. 아니, 이거는 얘기할 수... 아니, 정확한 표현은 제가 얘기하잖아요. 네. 근데 갑작스럽게 생기는 거는 어쩔 수 없다는 거죠. 사례, 사례 얘기해 주세요. 사례는 이제 어무게 안 나죠. 아~ 밥 먹으러 가야 돼 저한테는 좀 꼼꼼한 고민할 시간이 필요한 거고

사실 이거를 제출하고 나서도 제가 놓친 부분이 굉장히 많다고 생각이 들었어요 그래서 시간이 저는 제 특성상 시간을 더 길게 줬을 때 계속 고민하는 부분이 있으니까 거기서 좀 더 고민해볼 여지가 있어요 이게 굉장히 중요한 거거든요 근데 저에게 10시간에 저는 사실 1시간 걸린다 했잖아요 90분이? 저는 저도 더 걸리긴 했어요 저도 더 걸리긴 했어요

저는 저렇게 생각은 안 하긴 했는데 저 자기 평가하면 3시간 넘게 쓸 수 없거든요 진짜요? 그러니 저렇게 스트릿하게 나오는 거예요 자유 평가 10분에 나는데 근데 이 의도는 사전 안내 공개랑 똑같아요 이걸 기간을 길게 줄수록 저렇게 파고든단 말이에요 그렇기 때문에 오히려 객관성이 떨어지고 플러스로 증거를 준비하는 시간이나 이거에 대한 평가가 우려돼서, 남이나 어떻게 평가할까? 내가 나한테 이 점수를 줘도 될까 때문에 내 기존 업무를 열어서 수정하고 그거를 캡처해놓고 이런 쓸데없는 일을 안 하길 바랐어요.

그래서 일부러 1, 2일에 타이트하게 준 거고. 그리고 두 번째 이유는 이 형편성이라는 게 그때 무의 질문에 답했지만 우리 팀에는 HRD나 HRD 담당자가 없어요 그리고 제가 퍼실리티, 이걸 만들어서 이런 제도를 도입도 해야 되는데 진행도 해야 되고 근데 결국엔 사실 의사결정권도 저에게 달려있긴 하잖아요 그래서 형평성을 있게 이 척도를 만들고 질문에 형평성을 가져가려면 저는 그냥 이 질문 자체를 수정하는데 계속 오래 걸렸기 때문에 이 질문을 보고 고민하는 시간을 많이 주느니

근데 우리가 이미 이거를 하겠다는 공지는 더 전에 됐었잖아요 그리고 사실 비슷한 문제 제기가 됐기 때문에 저의 2편까지 의견이 이거예요 여기에 다 써라 너 여기 말 안 하면 다신 경청 안 해줘가 아니라 오늘 우리는 회의를 그냥 해야 되는데 그냥 앉아서 불만 얘기해봐 라고 하면 KPT 때처럼 유야무야 되는 거를 방지하기 위해서 그냥 기준점을 만들기 위해서 한 것 뿐이고 그리고 어쨌든 이렇게 공공 공론화 할 자리가 이미 준비되어 있기 때문에 그거여야지 그냥 사전 준비

이걸 읽어보면 가서 아 이런 얘기 하겠구나 아니면 어? 난 이건 생각해본 적 없는데 어? 팀에 그러니까 이거죠 1점과 5점을 보면 이 팀에서 기대하는 최고치가 뭔지를 어쨌든 인지하게 되잖아요 그 회의로 오기 전에 그냥 아 이 창업팀에 최상의 컨디션은 이런 거구나 만 인지하고 오면 되는 거. 저 그냥 기준점이 없어 그래서 저는 일별만 좋습니다 근데 이 항목은 계속 유지될 거니까 다음에 쓸 때는 무 한 일주일 동안 쓰세요

일주일 동안 쓰세요 저는 하루하루정 공개가 됐어요 근데 저는 이거에.. 근데 이걸 일주일 동안 공개했잖아요 그럼 무 또 쓰러... 아 나 일할 것도 많은데 이것도 써야 돼. 이걸로 스트레스 받았을걸요? 아 뭐 미리 더 쓰면 조절... 근데 또 어떻게 생각하면 저는 하루 줘야 되고 노우실을 일주일... 왜요? - 고민 좀 하세요. - 저 진짜 고민 많이 했어요. - 그래요? - 응. - 그렇게 남 평가하지 마세요. - 그니까. - 지금 제재 들어갑니다. - 지금 평가 끝났는데. - 그러니까.

상대방 의도 평가지만 제가 사전 안내했는데 중지하겠습니다 그럼 그 말고 사례가 없나요? 그러면 넘어가도록 하려고요 그리고 이제 일정은 각자에게 달려있기 때문에 반복되지 않지 않을까 싶습니다 그래도 전 자신 있는 건 제가 외부에 뭔가 정보를 얻거나 습득했다 딜레이 없이 팀에 공유합니다. 그렇기 때문에 일정의 열기간을 제가 축소시키는 일은 없었다고 생각해요.

오케이. 하지만 명세서의 이슈는 죄송하게 생각하고 있습니다. 왜냐면 그것도 제가 늦게 확인했기 때문에 노우에게 누락된 부분을 요청하는 것도 노우가 그걸 만들었다는 걸 거의 이질 시점쯤에 리바이뉴드를 했어요. 왜냐면 뭔가 그걸 만든 지가 정말 오래 됐잖아요 근데 그걸 이제 선택이 시작한 거예요 그런 이슈는 해결해 가겠습니다 스트립뷰요? 네

만든지가 언제네 이제 아 맞다 그거를 개발 우선순위에 애처 잊지도 않았지 아이콘 수정해야 되는데 근데 개발하자라고 말하고 나서도 한 2주 뒤에 노우에게 제가 말했던 것 같아서 디자인 이 부분 덧붙여다라고 그럼 저는 저도 작업하겠습니다 여기서 또 확인해야 될 게 있는데 아 맞아 저 이거 있어 그 태인이 안 돼 물어봐야 되는 게 있어 그 NO로 그냥 표시한 것들이 있거든요 근데 그게 뭐랄까 이게 나만 피드백하는 게 아니라

팀 자체에서 피드백 주고받는 것도 목격을 하거나 한 게 없어서인지 아니면 특별한 의견이 없어서 그냥 없음 처리한 건지 피드백 관련이 없었고요 맞아요 그걸 왜 그렇게 했는지 그게 의견 없음인 건지 아니면 피드백 주고받는 경우가 없어서인지 잠시만요

하나 말씀드리자면 43분 지났습니다. 연희만 하는 게? Yes. 조금만 스피글과 - 지금 40분이 되어봤습니다. - 물에 하나는 좋죠. - 이게 아마 애매했던 게 - 눈이 뿌해지거든요. 그러니까 막 그 전후를 비교하기가 되게 애매했다고 해야 되나? 이게 어쨌든 내가 과거에 KPT 하기 전이랑 지금이랑 뭔가 바뀌었느냐? 라고 했을 때

제가 연희를 관찰하지 못했던 것 같아요. 정말 관찰한 적 없음. 그래서 이거를 의견을 주기에 아까 전에는 뭐 어떤 게 부족했는데 그게 발전됐다더라 이런 부분을 뭔가 저희가 그래서 스스로 아 너무 내가 다른 사람들에 대해서 집중하지 못하고 신경 없었구나 생각하고 진짜 답을 어떻게 해야 될지 몰라서 1번부터 5번 안에 그래서 제가 이거 해놓으를 했었어요. 네. 그렇습니다. 근데 우리가 산호 업무 수행을 관찰 안 하긴 해.

근데 이거 비대면으로 하는 이상 어쩔 수 없다고 생각해요. 그러니까 피그마펜스 다 보지 않는 이상. 태희가 일 끝내고 스트리프 되고 있나 점검하고 안 되는 내가 푸쉬해야지 하고 들어가서 보고 하지 않는 이상 사실 서로 약간은 그런 걸 독려하는 중에 좀 힘든 구종인 것 같긴 어쩔 수 없고 굳이 안 된 게 이제는 그냥 스스로 잘하죠 그럼 태희는 그냥 뭐랄까 이렇게 의존 관계가 있는 업무들이 있잖아요

그거에서라도 그런 내가 정말 잘 피드백하고 있는지만 하면 될 것 같아요 NO가 NO를 NO인 항목을 없애기 팀원과 교류하기가 네 좋습니다 오케이 알겠습니다 그러면 제가 계산할 사항 각자가 지금까지 언급했던 걸로 계산하면 충분한지 아니면 다른 개선 문제를 본인이 쓴 게 있어서 그것도 같이 논의했으면 하는 게 있는지

얘기해주시면 될 것 같습니다 여기 노션 스쿨을 막 올리는데요? 저는 일단 없습니다 와 진짜 많이 썼다 많이 썼다고? 그렇게 일을 안 했었는데 저가 좀 제일 많이 쓴 편 아닌가? 아니요? 제가 더 긴 데서 쓴 게? 진짜요? 저 시간만 해서 쓴 진짜 많이 쓴 게 제가 제일 짧아요? 아니요? 아 그래요? 아 다행이다 안 짧은데?

이 항목은? 개선은? 아 근데 이 부분, 노후가 구체적으로 언급한 건 이거요. 그 언급반받아서 완료기준이랑 확인 방법을 같이 정리해야 된다 거든요. 근데 완료기준은 제가 어차피 목적을 말하면서 이 목적을 달성하기 위해서 어떤 산출물을 내놔라 라든지 아니면 이 산출물이 나올 수 있는지

뭐 PWD 체크해라 같은 거는 되어 있을 거니까 그리고 그게 안 되면 그 DRI가 안 됐다고 판단하더라도 최고 판단을 제가 하는 식으로 하면 좀 될 것 같아요 근데 확인 방법이 애매한 것들이 생길 수 있거든요 그쵸 그리고 제가 약간 생각했던 거는 뭔가 물론 수연이랑 해서도 잘 안 지켜지긴 했는데 그때 처음 시작할 때 이런 문제들이 막 데드라인 안 지키고 이런 문제들이 너무 많았어서

뭐 세 번 안 지키면 아웃 시킬까 약간 이런 거를 뭐 상호 합의하고 시작하긴 했거든요 물론 안 지켜진 부분이 있는 것 같긴 하지만 근데 어쨌든 그런 기준 같은 게 필요할 것 같긴 해요 왜냐면 뭐 디아래를 바뀐다고 해서 안 됐어요. 뭐 근데 죄송? 이렇게 하고 끝날 수 있는 게 아니다 보니까 뭐 만약에 진짜 듀얼을 맡았는데 업무 수행이 뭐 이 정도가 안 됐다.

근데 그러면 추후 조치를 뭐 어떻게 할지. 뭐 그 상황은 그냥 안 된 거대로 끝인 건지. 그럼 그 안 된 업무는 누구한테 넘어가는 거고. 이런 게 조금 미리 대충이라도 정해두면 좀 허들이 될 수 있지 않을까 싶습니다. 그래서 아까 안에 들어있긴 하겠지만 그 DRI 제가 처음에 PR들 만들어서 넘어가고 나면 그 안에 각자의 일정을 어쨌든 쓸 수밖에 없게

해놓고 할 거라서. 근데 그거를 이제 누가 감시하느냐가 이슈인데 그것도 좀 DRI가 하느냐. 극킬하죠. 그게 반복적으로 되면 어떤 제재가 필요한지는 업무 방식 때 할까요? 네. - 좋습니다. - 합시다. 그리고 일단 어쨌든 지금 개선하고자 하는 거를 기준으로 스스로 점검하고 감시해서 4주 뒤에 그런 강력한 제재를 할 거기 때문에 첫 번째는 일단 이 부분만 다른 개인 작은 테스크들에 대해서 어떤 걸 하기보다는

그렇게만 일단 하는 걸로 하겠습니다. - 좋습니다. - 그럼 저희의 사항 문제점. 음.. 일단 바꿀 행동은.. DRI.. 배분이라고 해야 되나? 분담.. 배정.. PURE D적성? 또는 데스크.. 요청이 아니라 짓이라고 할게요 이제 데스크를 요청이 아닌 지식으로 - 쇼핑할 때 - 쇼핑할 때

- 근데 웬만하면 다 그 데드라인은 안 지키면 - 그렇죠 - 나갈인 경우가 많기 때문에 - 죄송합니다 꼬르륵 소리가 없어. 등을 모두 고정하고. 저 아니세요? 배고프세요? 저 아니니까. 도장이 필요할 경우.

아흥. 남자가 공고를 두고. 차비하기로. 그리고. 드라이의. 업무 과정에 대입하지 않게 마일스톤 마당 배드라인 마일스톤이랑 최종 배드라인 수행이

아 돈이 너무 많은 거 아니야? 어? 알죠. 이번에 그거를 어떻게 할 거냐에 대한 흐름을 그냥 이렇게 써서 놓을게 한계는 그냥 어 뭐다. DRI 배정식 복잡성과 일정만 부여하고 공격적으로 업무할 수 있.. 아 업무하고 책임을 지도록 한다. 그래서

회장이 안될 경우 책임을 묻는다 이렇게 할게요 그렇습니다 그럼 피드백하고 책임을 묻는다 아 저 경우가 아니면 피드백도 하지 않는걸로 하겠습니다 반복되는 개입 어... 구체화 또 의견 뭐 있었죠? 이게 그럼 되나치네요?

오케이 그럼 저걸 해결하기 위해서 이렇게 할게요 세분은 이 순서로 진행하겠습니다 확인 기준 이제 아 근데 PRD가 아직 확정은 아니니까 어쨌든 정기회의에서 개별 테스크 테스크 두두가 아닌 진짜 방어 만든다 그리고 DRI 지정 지정과 및 목표 살짝 목표 데드라인

고지를 정기회의회 이렇게 점검 이렇게 할게요 좋습니다 52분 진짜 쉽지 않다 와우 - 좋은데요. - 명확하잖아요. - 그러니까. - 4주 뒤에 저 내용 확인하고 안 된 사람은 피바람이... 자, 태일이랑 무랑 스무 가입하고 왔어요.

안 내면 진다. 사이가이 보. - 뭐 먼저? - 아, 저부터? 좋아요. 그래요. 진 사람부터. 어떻게 마침 와 있네. 아, 그리고 이렇게 놀라 보는 것도 있거든요. - 이거. -부터 시작하겠습니다. 모두가 동의한 게 일단 기한 준수 잘하는 거 빠르게 시각화하고 피드백하는 거 강점이라고 했어요 근데 이 화면 제작의 범위를 넘어서 아까도 있었지만 언급되지 않은 한계 항목이 있었잖아요

그 부분에서 문제 제기가 좀 되는 게 화면 제작하는 거 넘어서 우리가 이 기능 만들기로 했기 때문에 UX/UI가 정립이 돼야 되는 거 외에 뭔가 그 안에서 생긴 예외상태나 그리고 내가 디자인한 거에 대한 근거를 설명하고 공유하는 거 아니면 그 디자인된 결과물을 실제로 쓰기에 괜찮은지라든지 더 나은 새로운 레퍼런스가 있는지 같은 것들을 검증하는 거 그리고 이 모든 맥락 등의 이런 게 문서가 돼서 핸드오프 되는 거 생각해보면 사실 디자인의 문서가 가장 적긴 하거든요 그런 부분들에 대해서 자세히 얘기를 해보면 좋을 것 같고

그리고 기존의 디자이너라는 것보다 UX/UI 디자이너보다 프로덕트 디자인으로 성장이 필요하다의 맥락이 있습니다 보면 일치하는 거는 두 개밖에 안 되었어요 아 근데 이게 뭐 문제는 아니니까 그럼요 그럼요 무려 네 명이 서로 다른 얘기 당연히 하는 거고 그리고 자기 인식 점검이 필요는 없습니다 근데 이거는 아까 말했듯이 5점의 유무가

저는 모두에게 다 넘겨졌어요 이 5점의 존재의 의미 자체를 좀 다르게 해석한 것들이 있어서 그 오차를 조금 조정해서 생각해주시면 여기서 1점을 빼고 생각해도 된다고 생각해요 그러면 그 중에서 오차가 생기는 거는 이거 문제점이야 제품 사업 판단, 협업과 정보 공유 그래서 아까 그 유학문에 있던 것과 비슷한 맥락이라고 볼 수 있겠네요 그리고 동료가 선호품은 없어요 근데 여기서 일식 빼고 나면 사실 일치하거나 뭐 그런 것들이 있어서

괜찮습니다 그리고 인식 차이가 컸던 거 지금 음 이거는 동료가 인식 차이가 노 빼고 우리 세 명이 노 를 볼 때 서로 다르게 노 를 생각하고 있는 거 서로 다르게 평가한 거 그래서 피드백 반영을 하는 것과 성장하고 있는지 같은 거 그리고 사용자 문제를 인식하고 제품 구조하는 거 앞에 언급된 것 중에 하나 이거 두 개 언급된 거고 이 지점에서는 또 셋이 다른 의견을 가지고 있는 거니까 이것도 점검을 해보면 좋겠습니다

어떻게 저렇게 다 다르겠지 그리고 반복되는 의견 중에 하나는 그 상태 완결하는 점 근데 이거에 대해서 아까 노우도 스스로 판단했지만 내가 디자인 주고 나서 개발이 정말 그렇게 끝까지 구현이 됐는지 파악하는 것들은 잘하고 있는 부분들 디자인 의도대로 구현이 되는지 같은 것들은 잘 되고 있다는 의견이 있고 그리고 아까 말했던 이 부분 프로토 디자인 역량에 대해서 좀 더 구체적인 게 이건 것 같은데

선제적으로 내가 뭔가 테스트 발굴하는 거. UX, UI적으로 계산할 점을 찾는다든지 계산하려면 개발적으로 구조적으로도 뭔가 바꿔주기를 요구한다든지 그런 것들. 근데 그걸 스스로도 인지하고 있다고 그들 끄덕이는군요. 썩군요. 그런 것들. 근데 그게 본인뿐만 아니라 다른 동료 중에서도 언급이 있었다는 거니까. 그리고 핸드워프 부분. 이것도 혹시 본인도 그렇게 판단했나요? 적었던 것 같아요. 두 명의 노후가 포함인가?

누군가는 체크리스트 중심의 개선안을 제시했다고 하니까 나중에 들어보죠. 제가 적은 건데, 체크리스트? 아 그래요? 그러면 본인이 포함되어 있네요. 그럼 누군가 한 명이 저걸 더 해주길 원하고 있다. 저 정도로만 해석하면 될 것 같습니다. 아 이거 독립품 거 밖에 안 보이는구나. 양치. 10? 아니 10이.

노후 거 보면 이 피드백하고 성장하는지에 대해서 좀 흩어져 있고 그 제품 구조화 부분에서 좀 흩어져 있거든요 이걸 각자에겐을 좀 다 그냥 들어보면 될 것 같습니다 근데 또 이렇게 흩어져 있는데 본인이 평가하는 거랑은 또 그냥 나름 평균치는 없는 것 같아요 그래서 강점은 아까 언급한 대로 비행진술 잘하는 거 사실 타이트한 일정에서도 뭐라 해야 되지? 이거 말하면 그 제한된 기한적이든 물리적인 리소스든

관해서 해결을 잘하고 결과물을 바로 쓸 수 있는 결과물로 가져오는 것의 강점이고 자기 평가에서도 잘 인지하고 있는 것으로 근데 그렇다는 건 사실 그거죠 내가 이렇게 수행해야겠다는 목표를 세우고 항상 잘 그렇게 진짜 하고 있는 사람이라는 거니까 좋은가서? 되게 자존감 높은 사람인 것 같아요 그리고 반복적으로 나왔던 거 아까 했던 엔드투엔드 UX상태환결에 대해서

기본적인 UX점검이 누락되는 거를 본인이 맞아요 하고 그리고 나머지 3명이 전부 동생을 공개 그러면 나중에 동료 얘기 들을 때 해봅시다 요 얘기 끝나면 저거에 대한 노후 생각을 먼저 듣고 저희 3명의 얘기로 반응권에 공개할게요 오케이 오케이 네 그래서 보면 되게 자기 얘기 따라 잘한다 계획 플로우가 충분히 정해되지 않아서 개발자가 출원하거나 추가 질문이나 보안이 필요했다는 의견이 계속 계속 나왔다고 합니다

그리고 '나주 반박 타임으로 넘어갈게요' 그리고 이것도 반복, 그러니까 노후는 다 스스로 인식하고 스스로도 인식을 하고 나머지 팀원들도 공통적인 걸 원하고 있어요 생각해보면 근데 개선점과 성장 지점이 너무 분명하다는 좀 좋은 지표일 수도 있다고 생각해요 그리고 여기서도 사실 앞에 거와 비슷한데 그 UI 제작하는 거 말고 사용자 문제를 새로 발굴한다든지 그게 기존의 이 사이트에서도 되고 나와있는 UI에서도 더 바꿔보면 좋겠다 같은 것들이 계속 나오길 바라는 의견들이 많고

그리고 UX 개선 아젠다도 개발 QA 같은 단계에서 말고 그냥 자발적으로 일어났으면 한다는 그게 좀 근데 이게 사실 그런게 생겼을 때 DRR를 먼저 파서 사람들 모으고 하면 잘 해소되고 그리고 개발이랑 직접적인 연관성도 생기는 것 같아요 근데 그걸 다들 직접적으로 요구하고 있어서 아까 팀 문제에서 제기된 거랑 묶어서 빠르게 개선이 될 수 있을 것 같습니다 그리고

아 그럼 그게 좀 특징인 것 같아요 기존의 거를 개선하기보다는 이렇게 하면 더 성장이 된다라는 의견이 좀 많이 모여있는 것 같아요 노후의 평가에 이 핸드 오프 부분에서는 아 자기인식 체크리스트 중심의 개선안을 제시한 게 있다고 하니까 들어볼게요 곧 그리고 두 명 이상은 근거나 문서 개발 전달 문제를 언급했다고 하는데 아~ 음~ 근데 이것도 뭐

아까 언급됐으니까 미리 말하자면 노후 말대로 애니메이션이나 이런 디자인적인 부분에 대한 명세는 본인이 미리 작성을 UI된 거 위에 미리 얹어놓는 식으로 하면 회수가 되지 않을까 싶네요 이어서 계속 그냥 바로 노후의 의견을 드려보면 될 것 같아요 이 부분은 사실상의 만장일치기 때문에 두고 여기서 부활했어야 했다에 대한 나의 생각 다 이어지는 흐름이긴 한데 제가 사실 UI를 이번에 잘 안 건드렸거든요

C6보다 오히려 안 했던 것 같은데 일단 변명 아닌 변명 첫 번째는 PPT나 외부적인 디자인을 더 많이 했던 것 같고 그리고 두 번째는 이게 조금 더 메인인데 약간 저는 회의 때도 계속 여러 번 언급했던 것 같긴 한데 지금 단에서 UI와 프로덕트를 고도화하는 거에 대한 약간 회의감이 아직도 있는 것 같긴 해요. 왜냐하면 사용자 사실 한 4월달쯤부터는 형사님들이 써보고

그 피드백을 바탕으로 그 데이터를 바탕으로 조금 고도화를 하거나 수정을 하거나 이런 방향을 기대를 했었는데 뭔가 그게 이루어지지 않고 있고 지금도 사실상 저희 뇌피셜로 하는 부분이 많다 보니까 뭔가 확정이 돼도 뭔가 찝찝한 느낌? 이거를 굳이 지금 하는 게 의미가 있나? 라는 생각이 계속 들다 보니까 뭔가 거기서 오는

이어지는 느낌으로 약간 예배케이스 이런 것도 사실 이미 물론 할 수 있었지만 하기 싫어서 이제 그랬던 것 같다 아니 하기 싫어서 소위 하기 싫어서 그만 그렇게 말했지 않아? 아 이게 글쎈한데 그러니까 이게 뭔가 데이터를 기반으로 하고 싶은데 그냥 데이터가 없는 느낌? 그러니까 아무런.. 그게 없는 느낌이었긴 했어요 사실

동기부여가 거의 없었던 느낌입니다 그래서 돌이켜보면서 오 생각보다 내가 좀 UI UX를 진짜 많이 안 했구나 이 생각을 느꼈던 것 같아요 특히 그 핀 추가 할 때 엄청 기본적인 인터랙션들이 많이 빠진 게 그때 막 연희가 추가해 준 것도 보고 이래가지고 와 진짜 미쳤네 약간 이 생일이 없더라고

주가 공포들 갔다 좀 썼어 그래서 이제 어 어 이때 좀 딱 자각해서 그때 제가 체크리스트 이런 걸 적었던 것 같아요 그래서 체크리스트가 스스로 어쨌든, 하긴 1인팀에서 스스로 점검해야 되니까 그렇죠 그런 의미에서 그렇습니다 이 정도로 이렇게 써놓을게요 일단 감사합니다 이제 팀 의견 넘어가도 되나요?

네 근데 저도 이걸 쓰면서 이미 인지하고 있었어요 이 UI를 지금 개선했을 때 어쨌든 최선의 결과는 찾지 못한다. 그리고 우리는 사용자 데이터라는 게 없기 때문에 맞나? 라는 그걸 회의 때마다 어쨌든 항상 설명을 해서 근데 최근에 와서 어쨌든 확인된 거는 그렇다 하더라도 이미 만들어진 우리 아이디어와 일시각화된 우리가 만들어 놓은 사용 플로우와 보여지는 이 UI에 대해서 만족도가 높은 거를 반복해서 확인하고 있고

그걸 해놨기 때문에 김정일 수는 만났을 때도 와 우리는 연고밖에 안 되는데 이 정도 실행이 있네요를 또 확인했잖아요. 그걸 사실 국수부원에서 이미 확인해줬지만 이건 그럼 이미 모바일이 되는 거죠 에서 우리에게 수요를 확인한 게 있었지만 그게 그 한 사람이 아니라 또 다른 웹에서도 인지가 된 걸 보고 제가 그때 돌아와서 회의 리캡 때도 말했지만 느낀 거는 아 선제적인 활동 무조건 필요하다 그래서 스트레이트뷰 바로 진행하게 됐고 PCI도 바로 남겼고 그게 필요하다고 느꼈어요 왜냐하면 어쨌든 우리는 판매를 해야 되는 입장이면

아무것도 되어 있지 않은데 할 수 있어요 보다는 이렇게 구현되어 있어요. 근데 너네가 내부 데이터를 주거나 우리와 협업을 시작하면 우리는 이 수준까지 정말 빨리 끌어올릴 수 있어요의 증거물들이 있어야 된다는 생각이 들어서 이 배경은 알지만 저거를 사실 쓴 거거든요. 제 의도는. 그리고 또 하나는 저 핸드워프 부분 이거는 체크리스트가 필요하기도 하겠지만 핸드워프가 필요하면 느낀 부분은 그게 있는 것 같아요 근데 이것도 사실 VRR하고 나면 해결될 것 같긴 한데

노을 어쨌든 의도로 설명을 할 거니까 지금까지 진행방식은 정기회의에서 이 기능 만들어야 된다 아니면 뭐 어떻게 수정해야 된다 하면 솔직히 다 같이 논의하잖아요 루테니가 뭐 아 근데 이렇게 만들었는데 나중에 데이트 꼬이니까 뭐 안 된다 복잡해준다 하면 누가 대체하냐 하면 말해줘 그리고 시뮬렛을 계속 보여줘 어 마음에 들어 어 괜찮은데요? 확정해 그러면 거기서 UI를 만들어 오거나 이렇게 되는데 근데 그 맥락에서 문제하고 놓은 중 한 개는 그거예요

아직 논의가 완전히 세제하게 디테일을 못 챙겼는데 근데 그것도 체크리스트가 좋다는 것 같아요 모든 항목이 논의되지 않았는데 그 UX적인 관점에서 누가'일단 만들어 와 볼게요' 했을 때 그러면 그 일단 만들어진 거를 페일에 한 번 더 해야 되는데 그게 피그마 단계로 끝나버리고 제가 명세를 빨리 완성해서 문화 태닝이 시작해야 되니까요 제가 거기서 비어있는 거를 무슨 노후가 발견한 것보다 근데 사실 스타일 가위도 그렇고 다 컴퓨터가 잘 되어 있으니까 가능한 거기도 한데 제가 뷰 북뷰 타고 그런 거 해서 만들어낸다든지 아니면 개인 명사로서 보완을 한다든지

또 대버리는 것들, 갈무리 해버리고 근데 그때 우리가'어떻게 하세요' 하는 이유도 신뢰하기 때문에 시작된다고 생각하거든요 근데 그거의 완결성을 사실 아무도 신경을 못 쓰는 것 같고 또 한 개는 모든 뷰가 다 있어요 아니면 사실 생략해도 되기 때문에 생략된 뷰들이 있는데 근데 그게 예를 들면 가장 최근에 어쨌든 스트릿 뷰니까 그걸 생각하면 제가 그걸 보고 그 사이에 인터랙션이 다 비어있으니까

결국 판단이 제가 이제 해야 되잖아요. 그래서 고민돼서 너한테 지금 이거 만드는 거 어떤 식으로 만들어지는 거냐. 왜냐하면 저는 예전에 스트랩뷰가 네이버에서 될 것 같다 라는 얘기를 한 적이 있으니까. 아 그럼 네이버 데이터 끌고 오면서 되는 방식으로 다 끌어가시는 거라고 처음에 일단 이해를 하고 있었어요. 근데 물어보니까 아니고 만들어야 되는 부분들이 많더라고요. 커스텀이라고 생각해야 되나? 그렇게 바꿀 수 있는 부분들이 너무 많고. 그래서 디테일을 사실은 다 논의했어야 되는 배경이더라고요? 근데 저.. 아 맞다 말 끝이야.

아 근데 일단 얘기해볼까? 아니 근데 스트릿 뷰가 제가 C6 때 만들어놓은 뷰예요. - C6 끝나고 아니에요? - 아니에요. 그때 C6 때 이미 만들어놨었고 네. 다음에. 맞죠. - 한 번 더 못 들었어. - 정확한 시점은 모르겠는데 그 상태에 그냥 스터빙 상태예요. 그래서 그 이후로 뭔가 제가 스트립 비쪽을 건드리거나 이런 게 없어가지고 제가 마지막으로 만든 건 그 핀추가 오시얼 부분 그 사이에.. 아 근데 그냥 애초에 제스처 얘기를 할 겨를 조차 없긴 했거든요

근데 그 사이가 비어있을 때 이거를 어디서부터 누가 놓을지 애매하더라고요 근데 어쨌든 누가 바로 만들거든요 그러니까 그리고 그전까지 저의 이해도는 뭔가 통으로 기능 하나를 API 붙여지는 것처럼 이해를 했기 때문에 물어봤는데 다 할 수 있길래 네이버는 카카오에 있고 애플 이런 데 뭐가 좋은 거냐 하니까 어 사용성 매냐 이러면서 애플맨 맞다 이런 얘기를 해주더라고 그래서 그거에서 이제 확인된 걸로 그래 그래 왜 이렇게 가야겠다 하고 근데 하려고 보니까 명세를 쓰려고 보니까 명세를 붙일 뭔가 아이콘 부분이라든지 이런 게 이제 없는 걸 그제 알게 된 거예요

그래서 뒤늦게 다시 노력한 거고 이런 것들이 있는데 그 최근 걸 들면 그 틴에서도 그룹 추가, 일괄 추가로 제가 바꾸고 싶은 거 그 맥락이 애초에 뭐라 그럴까 왜 그렇게 하고 싶은지나 그렇게 바뀐 부분이 어딘가 정리가 되어 있으면 제가 그거를 테니에게 전달하기도 쉽고 테니도 이야기 쉬웠을 텐데 그게 없다 보니까 제가 테니한테 디코에서 할 때 구절절 그 배경을 설명했거든요

노예 의도가 노후가 이렇게 하고 싶다고 했다. 근데 저는 원래 방식이 나은 것 같은데 어쨌든 노후가 주고 싶은 이 기능의 핵심 요소는 어쨌든 개별 추가로서 커스터마이징을 줄 거면 근데 우리 앱의 목적이 근데 그것도 사실 제가 추측성까지 붙였어요. 우리 앱에 왜 노후의 성향을 아니까 이 앱의 베스트 사용성을 만들기 위해서 어떤 기준을 갖고 있는지 아니까 근데 이 앱에서 형사님들이 기존에 수기로 하는 반복적으로 하는 업무들이라든지 하나하나 내가 다 관리해야 되는 거, 어려움을 해소하는 게 우리 애기 줄 수 있는 베네피치면

어쨌든 일괄 추가 기능은 정말 버튼 몇 번으로 착착착 끝나는 쉬운 UX를 주고 싶어서 이렇게 되는 것 같다 그래서 이걸 구분하고 싶어한다. 근데 이거 때문에 나중에 발생하는 문제가 있다. 그래서 그거에 대한 논의를 태니랑 엄청 자세히 했고 이거를 다음에 다 같이 논의하자고 이렇게 논의했거든요. 근데 그게 핸드오프 하나가 있었다면 태니도 먼저 그걸 보고 더 프로탈 리뷰를 만들어 본다던지 아니면 미리 텐이가 의사를 결정을 해서 팀밋에게 발언을 했으면 이런 게 있었을 텐데 없다보니까 아마 제가 하면서 방금 경우에는 노회의도를 제가 잘 파악해서 전달했지만

안 되는 게 또 문제가 생길 수 있지 않나? 라는 걱정들이 들어서 좀 저렇게 있었어요 저는 네 사례가 무전 잘했네 다른 분들도 사례를 보태주시겠어요? 가보시죠. 뭐 뭔지 아시겠어요? 뭔지 아세요. 아니면 그 사례까지 안 하더라도 어차피 근데 이게 지금 되게 연결돼 있고 사실상 만장일치, 어, 노후권 사실상 만장일치 그래서 그러면 내가 구체적으로 확인했던 사실 그러니까 반복된 문제가 뭐였는지 쓰고

계산 문제점 쓴 거 있잖아요. 그 부분만 말해주셔도 될 것 같아요. 저는 금방 말한 그거를 써놨었거든요. 그러니까 저는 근데 다 의견이 통일된 부분을 쓴 게 많아가지고 뭐 예를 들면은 비만은 뭐 이런 것 같은 게 없다보니까 임시로 만들어서 이렇게 하면 괜찮을까요? 이렇게 되는 경우가 있어가지고 그런 부분을 강조해서 딱 마지막으로 요청시 피드백을 할 수 없죠? 아.. 답은 잘 받다

아 근데 지금 들으니까 그 점 좀 어려웠어요 제가 그때 태연이가 alert 더 추가되는 부분 데이터를 환경해서 제가 정리하긴 했잖아요 그러면 네이버는 이렇게 하는데 우리는 그냥 그거 다 통일해서 하나의 alert을 쓰자 했는데 그 alert 지점을 찾기 위해서 너무 막 약간 녹아들어가야 되나? 그것들이 필요하더라고요 근데 그게 사실 UI 이미 정리되어 있거나 그 예외 부분이 이미 있었으면 거기서 텍스트만 수정하면 됐던 거니까 그런 부분 진짜 예외 처리 부분 이미 UX 단계에서 좀 파악이 돼 있으면 좋겠다 싶긴 했어요

됐습니다 아 그리고 토스트 나오는 시점 같은 거 왜냐면 지금 유아이는 사실 또 디자인 하나 꽉꽉하게 붙어있는 경우 실제 그 시점마다 좀 뭔가 되어 있으면 다 하고 있고 무엇이야? 통일이라고 했는데 생각보다 좀 좋은 것 같아요. 생각보다? 이랬는데 안 좋은데.

문은 일단 시작이 양식과 다름. 아 너무 쉬운. 양식이랑 하기 애매한 게 있어서. 아, 애매겠네. 그래서 좀 다른 거는 제가 양식과 다르게 쓴이라고 썼던 것 같은데? 아닌가? 아니면 이거 그냥 제가 문은 상관없어요. 제가 읽을게요. - 여기도 그럴 수 있어. - 안 되는 거 아니야? 그러니까 그 요소를 그냥 공개할게요. - 어때요? - 일단 앞에는 피드백 칸인데 공개해줘야 되는 세트리와 감점을 할 수 있는 게 좋겠는데

예를 일단 제외할게요. 근데 아까 요약된 거랑 똑같아요. 감점을 제외하고요. 바라는 점이 저 부분이 좀... 기존 업무의 개선을 바라는 것보다 누가 요청하는 개선 방향은 하지 않았던 영역의 UX 디자이너로서 좀 더 개입을 하는 것 좀 더 적극적으로 새로운 위에 있던 새로운 걸 발굴해서 만들어내는 것 해주면 좋겠다 그리고 그 앞에서 언급된 그... 그건 무만 언급한 게 아닌 것 같긴 한데

디자인이 완료되고 나서 이 프로토 디자인의 업무 끝! 이라고 주는 게 아니라 다시 그 플로우를 돌아보고 그리고 새로운 기능이 추가되거나 다른 기능이 개선이 있으면 그것과도 플로우를 봤을 때 좋은지 이런 것들 고민이 좋지 않나 싶네요 제가 그대로 읽은 거 아닙니다? 네 그대로 읽은 거 아니에요? 아니에요! 좀 바빴잖아요 근데 조금 더 안 좋게 얘기하신 거 같은데 아니요 아니요 근데 왜냐면 다른 부분도 같이 읽은 거 아니에요 다른 분들까지 종합해서 얘기하고 있거든요 그리고 구체적으로 사례를 든 게 있어요. 이거는 공개할게요

네 저 뭐죠? 탐문탭 CCTV 왜냐하면 사실 CCTV 부분 그거 도형을 그럴지 어떻게 할지 한번 해보기로 했는데 아무것도 되지 않고 있긴 하거든요 업무 정체가 있는 부분이라서 그거 저도 아차했었는데 그거 진짜 계속해서 그 부분 어떻게 개선하면 좋을지 그 안에 있어야 개발에서도 테스트를 해보고 보내고 하니까 그걸 아젠다로 진행해달라는 요청이 있습니다. 저는 약간 의견인데 그런 것도 약간 인터뷰를 통해서 뭔가를 하고 싶어요.

그런 거, 학생님들 어떤 걸 주로 보는지가 뭔가 통계가 아니더라도 말로라도 설명이 있고 그래서 우리가 이런 걸 보여주면 말로 하시는 걸 바로 눈으로 볼 수 있겠다고 생각하시면 그리고 있으면 그리기도 편할 것 같고 그런 쪽으로 통계를 어떻게 내릴지를 알 수 있을 것 같아서 좋습니다 근데 지금 노후가 근데 우리가 새로 어쨌든 확보할 네트워크가 없으니까 여러분들은 다음에 DRR가 열리면 하겠지만

네트워크가 없으니까 이런 경우에는 그 윤희동 경관 쪽에 뭔가 가서 이거 또 물어봐 주세요 요청을 한다든지 그런 걸 진행해 주면 되겠네요 좋습니다 오케이 그럼 개선할 문제점은 살게 및 아

좋습니다. 바꿀 행동 한두 개 유익 점검 부분은 노후가 말한 체크리스트를 하면 될 것 같아요 그렇습니다 체크리스트로 누락된 플로우나 노아이 디자인을 선제적으로 체크하기. 그거 하면 될 것 같은데? 저희 C6 때 저 디자인 끝내고 오면

다 불러가지고 생활일자를 한 번 쭉. 그거 그냥 비대면으로. 어. 그 디자인. DRI. 베이크에 완료된 디자인. 완료된. UI 설명회 및 피드백 타임을 필수 반영한다 좋습니다

중 하나로 이렇게 좋습니다 확인기준 디자인 DRI 음... A가... 진행됨... 그러면 40동원이니까 월 2회 오케이 근데 사실 매주 발생해도 이상하지 않거든 충분할 것 같긴 한데 근데 어쨌든 이거는 개선되고 있는 날 보는 거니까 A가 월 2회 진행됐는지와

월 2회? 2주마다 정도 생각합니다. 근데 그게 매번 새로운 아젠가일 필요는 없으니까 사실. 같은 걸 수도 있고 다른 걸 수도 있고. 그리고 그 안에 완료된 UI 설명회 및 설명회. Where are we? 피드백 반영. 과정이. 선생님 저는 UI/UX만 하는 게 아니에요. 디자인 하세요 그럼. PPT 디자인 하시고. 아 근데 저 디아가 유에 그 유엑소에가 아닌 것도 포함해서 유에니까 아 오케이 오케이 그래서 아마 한 개 아젠다가 아니고 두 개 정도에 봐야 될 것 같긴 해요

뭔가 지금 남아있는 거 생각하면 과정이 잘 기록되었는지 확인한다 하면 될 것 같습니다 좋습니다 디아를 정말 열었는지와 그 안에 일단 열고 봐 그 안에.. 아 그거 뭐야. 아 맞아요. 설명해서 근거와.. 아 근거까지 포함해서. 그거 설명하고 근데 거기 피드백 오면 그 피드백을 어떻게 조율하고 반영했는지까지 기록이 되어 있는지까지가 중요해요. 핸드오프까지 가야 되기 때문에 그 회의로가 안에만 들어있어도 근데 충분하지 않나 싶습니다.

오케이. 됐습니다. 용량이.. 팩스 정도는 받아주겠지. 자 가위 가봐주세요. 저 먼저 했어요. 아니요. 아! 잘한다. 긍이 기도 사람이 아직 가위바위보! 아 근데 저 물 좀 어디.. 너무 불안한 것 같아요. 감사합니다. 이거는 뭐해줘요? 이거 뭐해줘요? 아 이거 뭐해줘요? 에이 아이고야

무의약 바로 할게요 제 걸 마지막으로 했어야 되는데 제일 짧게 끝날 거 같은데 다른 분들이 이제 의견일치가 없기 때문에 같은 케이스라서 가보겠습니다 그러니까 이 무의 우리의 의견차를 가장 체크해야 될 부분은 기술판단이랑 제품 기여부분은 동료들이 누가 생각하는 거다 훨씬 인정하고 있어요 박치는 거예요 지금? 박수예요 이거?

그렇습니다 근데 진행상태를 공유하는 거랑 그 제한한 아젠다의 후속적인 정말 잘 진행이 되고 있고 아니면 완결을 했느냐 부분은 못한다고 하지 않았어요 근데 그 부분을 잘하면 팀 내의 역량력이 커질 수 있다고 판단합니다. 근데 저렇게 나온 이유는 무수수로를 저걸 못하고 있다고 판단했기 때문에 저렇게 지금 요약된 것 같아요. 네 그렇습니다. 그래서 자기평가와 동료평가가 비교적 일치하는 부분은 이거예요.

근데 갑자기 개발 부분에 있어서는 이거 말대로 책임감 가지고 그리고 주저성 있게 하고 있다고 하고 구현품질이랑 릴리즈 연결성 근데 테스크를 뭔가 놓치거나 일정을 못 찍힌 게 없다는 공통평가입니다 뭐 나중에 들어보죠 그렇게 갸우더라도 그리고 기술 오너십과 설명 가능성 이 부분은 사실 이게 일치하는 부분에 공통점이 있어요.

그냥 중앙값이 딱 3. 이게 뭔가 더 평가 의견이 상세하게 딸리는 1, 2점이나 5점 쪽이 아니라 그냥 사실 3이라서 그냥 무난하게 수행되고 있네 의 의견일치라는 점이 그렇고, 그리고 자기 인식에서 가장 저 이거를 제일 신경 쓰는 부분이긴 해요. 아 그래서 뭔가? 제출하고 나서 좀 더 생각했으면 이걸 따르게 적었어요. 아 그래요? 근데 이거는 유일하게

우리가 느끼는 것보다 누가 더 잘하고 있다고 생각하는 지점이 딱 저 부분이거든요. 하나밖에 없어요? 좀 막 여수 있잖아. 근데 그게 끄덕인 점에 좀 독특하게 해. 다시 보다는 피드백은 안 돕다. 그리고 그 성장 부분에서도 지금 내가 성장을 잘 못하고 있다 했는데 정작 평가 점수로는 본인이 스스로 이렇게 말하고 그때 할 때 기분이 좋았나. 그러니까 딴 건 엄청 박하게 점수 져놓고 성장은 하고 있다. 라고 하는 이 괴리감을 스스로 좀 이제 들으면서 판단해 보세요. 정확히 어떤 쪽인지

저기 좀 괴리가 있어요. 그리고 숨은 강점. 그거죠. 내가 나에게 너무 박한 부분들. 지금 차이가 큰 것만 보면 큰 것만 보면 일단 이거 1번과 4번이거든요. 근데 사실 딴 것보다 이게 가장 큰 것 같긴 해요. 나는 최저점을 줬는데 동료들은 어? 안돼. 그냥 하고 있는데? 이런 의견이거든요. 그래서 협업과 전보거든요. 에서는 누가 부족하다고 느낀 점이 뭔지 우리가 들어봐야 될 것 같고. 근데 1점을 줬구나. - 저는 1점을 안 줬어요. - 그래요? 저 1점 정도 있는 것 같아요.

벌써 다물치기는 해. 근데 있는 거 같은데? 다들 박하게 해주는 거. 다음을 참고하겠습니다. 그리고 나는 부정 쪽에 있는데 팀원들은 도둑게 사전 쪽에 완전 긍정에 있는 게 결과에 기여하는 거나 업무를 잘 마무리했다는 점. 그러니까 이게 아직 기준적이 다른데 있어버릴 수 있으니까 그거는 무의 기준을 설명해주고 본인이 이 부분을 성장하고 싶으면 나중에 설명해주세요 개인의 별 시간에 인식 차이 개 많아

근데 이 정도 참 신기해요 무 한 명을 바라보는 시선이 팀 내에서 근데 바라보는 시선이 다르거든요 우리 세 명 다 무에 대한 기준점이 다르다는 거거든요 이 사람이 요구하는 거 좋아 그래서 이것도 동료 의견에서 많이 자세히 들어야 될 거 같아 시간이 꽤 걸릴 거였을 예상이 됩니다 지금 범위가 큰 게 이거거든요. 근데 이거부터 보면 다른 거는 사실 뭐 이런 거 있잖아. 제품 배절분 붙여야 할 거 같으면. 저 오점들 다 나은 거 같은데. 어쨌든 다 긍정 쪽에 있잖아. 상의. 상의 준비 필요긴 하지만. 그리고 이런 것들도 어쨌든. 오오오오. 이런 것들은 사실. 저 무시하세요. 그렇게 유의미하게 안 봐도 된다고 생각해요. 근데 이렇게 긍정과 부정이 나눠져 있는 애들. 아니면. 디어라이 같은.

5점을 4점이라 쳐도 어쨌든 2점과 4점 이렇게 어떤 파트에서는 무와의 협업에 만족하는 거고 누구는 부만족하고 있고 아니면 누구는 그 무의 주도성을 있다고 판단하는데 누구는 그게 소통이 안 된다고 느낄 수 있을 것 같거든요 저 2사를 합쳐보면 그거를 나중에 좀 풀어보면 좋겠습니다 그리고 반복된 내용 3명이나? 지진 상태가 완료예요. 본인도 포함됐을 것으로 보고요. 계속 오늘 언급하셨으니까

나중에 뒤에서 보시면 되겠습니다. 그리고 아, 이건 스스로 말한 거니까 팀원 중에 누구 한 명은 비슷하게 느끼고 있나봐요. 제한한 아젠가를 과거 문제 때문에 해결을 못하고 있는 거예요. 이거 익명 맞죠? 이게 몰려만 있는 춘장은 합심이 안 돼. 나중에 통해 밝힐 것 같지만 누군지. 일단 단점은 아까 말했던 대로 기술적인 문제 부분에서는 스스로 탐색도 하고

그리고 뭔가 구체적으로 언급한 내용들의 취합이거든요. 여기 활용되는 단어들은 누군가 한번 언급한 단어예요. 정제되거나 AI가 추가한 단어 없이 그 평가시에 있는 단어로 구성됩니다 실제 동작이나 시뮬레이트를 통해서 설명했기 때문에 제품 개선으로 연결하는 양이 강점 있는 것 같다 라는 평가하고 너무 제발 두려워요 아오 아오 근데 본인은 아니래. 그래서 이 지점을 나중에 왜 이렇게 했는지 알려주세요.

그리고 진행상태 완료 여부에 대해서 공유가 된다 안 된다에 대해서 본인은 안 된다 라고 했는데 티원들도 그렇고. 근데 그거를 어떤 방식으로 어느 시점에 공유하기를 원하는지를 체크하면 될 것 같습니다. 네~ 네, 다 그런 거 맞다고 했나? 그리고 그 제안한 아젠다에 대해서 후속 과정과 완결에 대해서 세명 중에 2명이나 얘기를 했고요

본인은 과도한 문제라고 했는데 어쨌든 나머지 2명은 후속 실현이 안 되고 있다고 판단하기 때문에 본인이 왜 그런 문제들이 있었는지 설명을 해주고 그리고 그런 문제가 될 때 누가 불편함을 겪는지를 체크해 가시면 될 것 같아요 그러면 앞으로 그 사람에게 우선적으로 본인이 공유를 해야겠죠 그런 것들을 이따가 얻어 가시면 되겠습니다 그리고 협업 주도성에 대한 인식 차이 이게 근데 왜 이와 사인지는 나중에 스스로 좀 밝혀야 될 것 같아요

아니면 제가 이걸 보고 그 차이가 나는 이 사람에 대해서만 공개하겠습니다 - 협추도 수 있는 거. - 네. 앞에 이거 한 것처럼 시뮬레이터 보여주고 실제 동작하는 거 보여주고 이런 식으로 실무 설명이랑 그렇게 본인이 기술 개발 쪽을 했기 때문에 도움이 되는 거에 대해서 다 높게 평가해. 근데 누군가 갈등 상황을 설명해 주는 사람도 있나 봐요. 갈등 상황에서 결론을 이끌어내는 거라든지 아니면 팀 전체적으로 뭔가를 공유해주고

그런 것들을 주도하는 것들은 누군가는 하고 있는데 누군가는 개선하길 바라는 이건 정말 구체적인 사례를 봐야 될 것 같아요 둘이 다른 사례에 대한 얘기를 하고 있을 것 같아서 무우가 먼저 얘기하시죠 왜 이 부분을 낮게 평가하는지 왜 일리전 같은 걸 주셨는지 제풍 기업 라고 생각했을 때 그냥 크게 봤을 때 지금 기간이 얼마나

지났는데 뭐가 이 앱이 개선됐고 뭐가 기술이 추가되어 야를 스스로 돌아왔을 때 저는 한달만 해도 할 수 한달도 한달만 해도 할 수 있는 수준이라는 생각을 스스로 한 것 같아요 그래서 이 기간 내에 내가 이 정도밖에 못한 것에 대한 저는 스스로의 평가죠 그럼 거기에 추가 질문 드릴게요 지금 내가 지금까지 개발해 놓은 거 사실은 한달만에 할 수 있다 기준에서

근데 그 한 달에는 다른 사업적인 부분을 안하고 개발만 몰두할 때인거죠. 그 기준이 9to6 개념이 아니라 밤새고 열심히인가요? 그렇지 않을까요? 모르겠어요. 그런 입장적인 생각은 안해봤는데 근데 어쨌든 한달만 해도 할 수 있을 것 같다. 결과물은 아니다가 제일 그런 거죠 스스로에 대한 만족도에 대한 질이나 양이나 어쨌든 만족도가 떨어져서 저렇게 평가한 거다

내 기여도가 실제 낮다기보다는 내 기대치나 내 만족도에 그래서 그렇다 병목이 뭐였어요? 병목이요? 자기 기준은 이만큼인데 실제로 이만큼까지 못한 이유 일단은 저는 그냥 제 종특이라고 기대치를 높게 잡는 특징 기대치보다는 저는 손이 느려요 누우시는 손이 느려 하나의 테스트를 하는데

뭐를 하나를 보면은 옆으로 가고 '어 이거 다른 문제도 있네' 하고 다른 문제를 들여다보다가 그게 저는 너무 많아요. 그래서 뭔가 리서치에 대한 그걸 주면 저는 오히려 그걸 잘 할 수 있는 사람인 것 같고 지금 말하자마자 그 생각 나왔어. 우리 C6 시작할 때 조사효라고 했을 때 완전 브리테니커 백과사전처럼 해왔잖아요. 깊고 넓게. 근데 그게 저는 모든 게스트였으니까 여러분들이 생각하시면

이거는 빠르게 결론을 해서 줬으면 되는데 저는 이게 왜 이렇게 되지? 왜 이렇게 되지? 계속 그거를 생각하고 찾아보게 되니까 딜레이가 되고 사실 남들이 봤을 때 제 엄마가 그렇게 과다한 양 자체는 아니에요 근데 그 하나하나에 제가 엄청나게 이만큼을 많이 많이 써서 저 하나만 더는 3~4시간 썼는데 이게 너무 부르니까 그게 저의 기존에서는 그게 과중인거에요

남이 봤을 때는 그건 안 많은데 지금 정말 저와 다른 사람 같아. 신기하다. 아닌 거 같네. 저는 그래서 밥을 새게 돼요.

그리고 기회를 파고 파고. 얘기할 것 같긴 한데, 귀에겐 설명해, 다음 날 오전에 내가 이걸 넘겨야 다음 후에 넘어가. 그리고 내가 이걸 더 자꾸 고민하면 그 클라이언트 줘야 되는 마감했다고 했었는데, 그거부터 하루라도 시간을 덧사버리세요. 다음 날에 정말 걸려있는, 이거 영상이었다. 그 영상 촬영부터 스타일리스트 준비하는 거 저기 미술팀 부터 한 집 같은 집에 나중에 녹음실까지 가야 되고

근데 광고주랑 막 이거 해야 돼. 피드백 받고 해야 돼. 그럼 내가 일정 잡아먹으면 그 모든 사람에게 어쨌든 손해를 주는 거니까 근데 저는 그걸 뭔가 못 놓는 그런 것도 있어. 자꾸 저렇게 해. 그러면 그냥 밤새서 하고 아침에 끝나는 약간 있긴 하거든요. 근데 저 그것 때문에 발표자로는 진짜 끝 안 내놓으면 끝장이잖아요. 안 내면 기회가 박탈이잖아요 사실. 그래서 그럴 때는 그냥 저의 해결책은 그냥 이 조사를 하고 싶지만

이 가진 범위 내에서 최상의 결과목을 만드는 게 나의 테스크다라는 마음을 사실 하긴 하거든요. 그런 경우에 사실 개발에 적용하기 쉽지 않긴 하겠는데 근데 그거를 본인의 교선목득을 주고 싶어요? 아니면 일단 다른 것을 우선순위를 정할 수 있나요? 그거에 대해서 어떤 개선점을 찾고 싶나요? 음... 근데 본인이 단점이라고 생각 안 하면 굳이 안 고쳐도 될 것 같아요. 그러니까 평가만 낮게 줬는지 개선하고 싶은지가 궁금해요.

일단 더 들어보고... 아, 근데 일단 저희가 요구하는 개선점은 없으니까. - 본인의 수술을 위한 거. - 왜냐하면 그렇게 해서 팀에 비여하는 결과물에 대해서 어쨌든 팀을 만족하고 있다는 결론이니까. 근데 그게 나중에 내 업무의 과부하나 방목의 원인이다. 그런 개선을 해서. 그럼 들어보고 합시다. - 다음은.

그러면 그 진행상태 완료 공유 여부 근데 이건 아까 누가 한번 설명해서 사실 근데 그 사례 말고 다른 것도 혹시 사례를 들 게 있나요? 아까 그 사람은 MDM DRI 맡은 거의 사례였어서 뭐 개발적인 부분에서 뭐 디자인이랑 저에게 뭔가 기획이라고 말해 대표라고 말해서 그런 것들 아니면 그 개발팀 안에서 월요일마다 뭐 회의하는 거나 그런 거에서 제가 찾아볼까요?

제가 쓴 거를 볼 수 있으면 좋긴 한데 근데 굉장히 많았어요 제가 생각하기에 -저기 또 생각을 못 했어요 -어떤 게 나오겠습니다 어떤 거 진행 상태 완료요? 네 그러니까 -진행 상태에 대한 공유 부족이죠? -신방을 갖고 있어요. 근데 리팩토링 할 때 늦어지면 늦어진다고 계속 공유를 해줬던 것 같은데?

제 기억에. 그래서 저는 여기 딱히 뭘 안 적었긴 하셨는데. -근데. -근데 제가 생각했을 때 제가 고지를 하는 순간도 저는 늦었다 생각해요. - 그건 맞긴 한 것 같아요. - 제가 고지를 했다면 할까 말까 할까 말까? 더 좀 더 완성해서 공유해야지? 를 거치고 하는 거예요. 늘 그래요, 저는. 근데 그거는 솔직히 개선이 쉽기 때문에 써놓는 게 좋을 것 같아요. 뭐, 되지?

아~ 대상세 완료되네. 대상세. 이거는... 여러분은 뭐라고요? 할까 말까? 하거나 좀 더 작업해서 공유하고 싶다는 생각에 미루고 미루다가 하면 해 마인드가 별로 없네. 그러니까 타이밍을 놓지. 저는 그냥 인생이 하면 해인데. 아 저는 배워 오실 거예요. 근데 이건 무조건 개선해야 돼요. 사실.

맞아요. 본인 때문에 그걸 생각해야 돼. 내가 이거 한 번 더 하는 것 때문에 남들은 그 불확실한 미스트가 가득 찬 세상에서 저기 밖에 예수가 오는, 제 물이 오는 상태로 있다고 생각하면 돼요. 예수가 오는 집에. 영한 미스트를 생각하시고. 내가 예수가 소서스가 될 거냐? 저 곤충벌레가 될 거냐? 생각해보시면 쉽게 나오거든요. 내 때가 전에 하나예요. 지금 내 실시간에 통화를 그냥 알려줄게. 뭘 정리해서 내 정보를 주고 다 필요 없어요.

저 지금 이 부분 하고 있는데 근데 일정을 미뤄야 될지는 조금만 더 해보고 알려드릴게요. 그 사람은 예상하겠죠. 아 일정을 미뤄줄 수도 있겠다. 근데 무가 이때까지 끝날 수도 있으니까 어쩌다 나도 그거를 작업할 무무를 안 나겠다 이런 생각을 하겠죠 판단을 남에게 주고 그냥 말 그대로 그냥 내 상황 스크립상에서 준다는 느낌으로 주세요 이거는 그냥 계산을 해야 된다라는 생각이 들죠 화이팅! 약간 머릿속으로 외쳐요. 쫄쫄? 이런. 근데 그거를 공부하지 못하는 거는 남에게 있지 않죠. 내가 그 생각하는 거지. 아 이렇게 하고 주면 나중에 나에 대해서 일 안 했다고 생각하는 거 아니야? 그런 거는 절대 없어요. 그러면 정말 나의 문제는. 그러니까 그냥 내 실시간. 나 지금 이거 하고 있어. 그러니까 취대 없는 개인적인 거 아니야?

여사친한테 하지 말고 단톡방에 하세요 나 지금 이거 개발하는데 이 궁임을 지금 사서 못 태어나고 있어 하면 상대가 말하겠죠 아 근데 중단하고 일단 이거 해놓고 가던지 아 근데 그거 해보면은 더 고도가 잘 될 수 있으니까 그러세요 그 시간 하루 더 늘려도 될 거 같지 마시죠 장대방이 그거를 이제 그 견토 산다 생각하고 해주시면 감사하겠습니다 드림먼즈 그거 그걸로 바꿔요 파마만

파마만 그래서 바꿀게요 그러면 그 다음 제안하는 데서 완결 루는 근데 TRI 얘기를 한 번 보면 MDM 얘기랑 같은 건가요? 과바 문제를 언급한 게 있고 근데.. 연결이에요. 근데 다른 팀원들은 그 후속 실행 과정에 대한 언급을 했다고 하거든요. 근데 저 무 금방 하는 부분에 대해서 어차피 연결이라고 하니까 후속 실행.. 그러니까 이 무가 언급한 게 그게 있어요.

뭘까? 근데 구체적으로 전혀서 제가 이해를 하고 읽을 수 없는데 그냥 그대로 읽을게요. 제가 먼저 턴트 해야 되는.. -배포 자동화에 대한 얘기에요. 이 맥락을 내가 이해할 수 없어. 여기서 무슨 불만을 느끼는지. 배포 자동화? -그거는 안되는데. 제가 먼저 해보면 안되네. -그게 구형 풍자의 완결성에 대한 답이거든요. -어? -응. -그냥 읽어주세요. -네. 지금 대포 자동화는 시행되고 있지 않지만

슬프트 포맷, 코드 품질 개선 도구나 기드 액션을 직접 규칙을 만들어서 프로젝트에 적용을 한 상태이 또한 현재 독시와 같은 인계를 대비한 문서가 완벽하게 작성되어 있지 않으나 제한을 하고 일부 작성된 상태이 -어머, 네. -그러니까 이게 되게.. -그거 맞는데? -그러니까 이까지만 돼 있고 일단 적용은 했는데 -마무리까지 하고 활발히 활용이 안 돼서 -아, 맞아요. - 저 어라케 된건지. - 할머니 국가정분도. 그거는 불만과 개선 의지가 있다는 건가요? 아니면 그냥 현 상황을. - 아 그냥 현 상황을. - 점수를 두게 된 근거로 그냥 한 건가요? - 현 상황이고 그냥 뭔가 제안을 많이 하는 것 같은데.

그러니까 수탈이 완벽하게 수행이 떨어진다. - 아 그 의미에서. - 아 제안하고 내가 아이디어를 막 해보자. - 그렇죠. 예시로 팔란티어, 팔란티어. 하지만 예측 모델이 나온 거 없다. - 그렇죠. 예측 모델이 필요한 데이터셋을 말한 적이 없다. - 그러면 저 다른 사람이 말한 것보다도 비슷하긴 한가 봐요. - 그렇죠. 다른 분은 새로운 단계가 있나요? 저 부분에 대해서? - 제 하나는 아젠다가 후속 교재가 되지 않는 것.

근데 없는 것 같아요. 근데 여기 답변을 안 하신 분도 있거든요. 그래서 없는 것 같아요. 얼마가 관심이 있나요? 크게. 응. 감사합니다. 맞습니다. 내가 뭘 쓸지? 저게 몇 번인 거예요? 4, 5번인 건가? 저게 6, 8번 안에 있는 거예요. 제가 그럼 한번 배워볼게요.

6번? 아~ 근데 이게 정확하게 매칭되는 건 아닌데 제가 그거를 쓰긴 했어요. 미팅 전에 이해관계자의 예상 질문이라든지 기술 리스크를 고려해서 선제적으로 준비하지는 않았다. 라고 썼거든요. 근데 이렇게 쓴 이유가 그거예요. 그러니까 지금 무도 그렇고 태님도 그렇고 그 얘기 하잖아요. 그러니까 지금 태닌은 우리가 사용자 대체를 못 얻으니까

인터뷰라도 해서 뭘 들어보자 라고 하고 무면 아 저 이것도 물어보고 싶어 저것도 물어보고 싶어 하고 회의 끝나면 가서 개인적으로 물어보는 경우가 많잖아요. 근데 그걸 사실 회의 안에서 우리도 어필 될 수 있게 하고 실제로 그렇게 궁금하게 얘기가 돼서 기회를 만들 수 있는 걸 해야 되는데 하고 싶은 기대치는 많아 근데 그걸 회의에서 보여주는 게 없어서 그렇게 제가 쓴 거 같거든요 예를 들면 저희 그때 김종교수 만나면 옆에 연구원이 앉아 있었고

근데 궁금한 게 있으니까 끝에 가서 그렇게 인사하고 있을 거 아니에요? 그리고 김종교수 할 때도 제가 그 전체를 요구했잖아요. 김종 교수님의 배경에 대해서 하고 주요 연구 분야라든지 지금 회의 때 얘기 나오면 학습해서 왔으면 좋겠다. 근데 사실 회의 진행 중에 딱히 그런 것들 구체적으로 언급되거나 그 사람의 흥미도를 끌어낼 만한 것들 하지 않았잖아요. 그게 아쉬운 거죠. 늘 이런 자리를 원하는데 가서 액션이 없는 정도 근데 뭐

근데 그거는 제가 문제로 썼다기보다는 그냥 저 점수를 준 근거 정도로 전했어요 저도 저게 완전 매칭된 얘기는 아닙니다 근데 있어서 해봐라 답변하면 되나요? 어? 해야 돼요? 일단은 저도 그런 자리를 가잖아요. - 쫄아요? - 아니, 쫄는 게 아니고 머릿속으로. 저도 그 생각했거든요. 뭔가 의미한 질문을 해야 된다는 그걸 계속 하는데.

근데 이게 왜 그런지 모르겠는데 늘 거의 끝날 때 딱 떠올라요. 그래서 추가로. 그래서 늘 그때 가는 거고 뭔가 일부러 그런 건 아니긴 해요. 그러니까 회의 때 말하는 게 사전 준비해서 그런 질문 리스트가 생기지 않는지. 사실 김지훈 교수님 미팅은 너무 큰 자리라고 생각을 했었고 근데 그게 정확히 뭔 자리인지

인지를 못했어가지고 그래서 계속 이제 그런 R&D 하시는 분이 우리한테 뭔가 도움을 받을 부분이 있나? 왜냐하면 링고는 우리가 도움을 줄 수 있는 부분에 대해서 논의가 이루어질 거라 해가지고 그래서 그것만 생각하고 링고한테 그래서 그때 스타벅스에서 울었는데 링고도 사실 저도 잘 몰라요 이래가지고 저는 거의 질문 리스트 없이 가져왔고

제 머릿속에는 근데 그거는 항상 팔란티아는 머릿속에 항상 있거든요 그래서 늘 그거를 생각해요 온톨루지 온톨루지라는 기술이 있거든요 근데 그게 뭐냐면은 그러니까 맥락에 따라 다르게 해석된다는 거예요 연희, 남도연이라는 사람이 저랑 엮였을 때 남도연은 이상한 사람으로 보여질 수 있는데 다른 사람한테는 괜찮은 사람인 거예요 그러니까 데이터가 묶였을 때 그 데이터가 다르게 해석될 수 있는 그 관계를

알아야지 우리가 추론을 할 수 있게 되는데 - 언토로드 생각에 목이 메이는 거잖아요? - 울지 마세요 그거를 왜 끝나고 거기 가서 언급한 거 근데 그건 회의 때 나온 것도 아니라서 개인적인 궁금증 아 그쵸 개인적인 궁금증이고요 왜냐면 연구원이니까 그리고 저는 계속 이제 고도화를 얘기를 하면서 좀 얘기하셔서 한으로 가긴 한데 아 근데 그거를 회의 때 아 근데 요즘 언토로드 얘기가 많은데 그런 부분은 연구되고 있냐 한마디만 하면 되잖아 근데 그것조차도 마지막에 생각이 나아서 그랬다. 인공간.

근데 약간 또 그 흐름을 깨는 느낌도 있으니까 안 하신 거고. 근데 조금 또 궁금한 게 있어. 이걸 만약에 내가 혼자 간 자리였어. 아니면 혼자가 아니어도 우리 팀원들이 다 같이 가. 근데 DRI가 무였어. 개발이니까 DRI는. 그래서 무였가 했어야 됐어요. 그러면 제 역할을 원해. 무였가 했어야 됐어. 그럼 질문을 했을 거예요. 근데 이렇게 얘기하니까 좀 다르긴 해요. 왜냐하면 제가 거기 책임자였잖아요.

상 대봐야 될 것 같은데 질문을 조금 난사했을 수도 있을 것 같은데. 정확히는 모르겠는데 제가 책임자고 제가 거기서 얻고 싶은 거를 제가 편하게 다 물어봐도 된다라는 기자가 있으면 좀 더 편하게 할 것 같긴 해요. 근데 그게 기존에 질문하고 싶은 내용이 있다고 리스트업 하지 않은 거에는

DRI가 아니었기 때문이 되는 건가? 그렇게 하기에는 좀.. 근데 진작 그.. 그걸 찾고 싶은데.. 이 팀의 목적 자체를 몰랐다는 거에요. 제가 항상.. 사실 노후는 이런 분에 대해서 뭔가 컴플레인이나 요구를 한 적이 없어서 빼고 얘기를 하면 태인이가 누가 항상 요구하는 게 이거거든요 뭘 하라는 건지 모르겠다 이게 뭔지 모르겠다가 항상 있어요 근데 문제는 뭔지 해야 되는지 찾는 게 DRI 역할이라는 거죠 근데 지금 상황이 만약에 이렇게 돼?

그러면 사실 저도 똑같잖아요? 그러니까 PCI에 대한 정보도 우리 모두가 똑같다 근데 태인이는 답을 요구해 사실 나도 없어 그러면 태인에게 주기 위해서 아까 말했듯이 다섯하고 내가 결론을 내서 줘야 된단 말이죠 그러면 그게 또 제한을 주는 거잖아요. 텐이가 판단할 수 있는 거에 대해서. 근데 이것도 그 미팅이고, 이거 사실 판단도 안 되죠. 아무것도 모르잖아요. 제이가 무슨 꿈꿍이를 가지고 오는지도 모르고, 왜 하필 저 사람이 참석했을까도 모르고, 이 윙고는 이것도 얻고 싶고 저것도 얻고 싶고 하는데, 사실 와서 한 역할이라고는 애플 아카데미의 학위였잖아요.

근데 그런 거 예상할 수, 있는지 없는지도 애매한 상황이 하지마. 근데 그렇게 그냥 불티만한데 어쨌든 중요한 사람 만나게 되는 상황이야. 근데 그 상황을 정말 컨트롤하고 가서 뭔가 유의미한 답을 얻는다던지 베네핏을 만들어낼 수 있을까에 대한 걱정이 항상 있긴 하거든요. 왜냐면 그런 분이 있을 때 스스로 문화 판단해서 어? 그럼 이런 거 좀 물어봐서 이런 방향으로 가볼까요 보다는 그래서 이게 뭐예요? 저한테 좀 알려줘 봐 보세요. 약간 제가 뭔가 안 한 게 있는 것처럼. 그러니까 설명을 다 안 해 준 것처럼 될 때가 많거든요.

근데 그러면 이게 진짜 투명한 상황에서 내가 빠진 상황에서 본인이 맡았을 때는 어떻게 되는 거지? 를 모르겠는 거죠. 그래서 그 방법을 확인한 거예요. 이게 DRR가 아니니까 한 발을 빠졌기 때문에 사실은 질문 리스트를 준비했는데 노후가 말한 것처럼 언급 타이밍이 애매해서 끝나고 하게 되는 거냐? 아니면 애초에 이렇게 뭔지 모를 회의를 준비할 스킬이 부족하고 그런 가상 신경을 그려보고 다 준비하는 게 벅찬 거냐? 근데 그 벅찬 게 경험에서 벅참 수도 있고 다른 업무 테스트가 많아서 벅참 수도 있긴 한 거잖아요?

그런 거를 확인하고 싶습니다. 그렇죠? 뭔가 기대치가 다를 수 없는 일이라고 생각하거든요. 근데 저는 김지현 교수님의 그거를 한다고 했을 때 저는 책임감을 많이 느꼈다고 생각은 해요. 아닌가? 오늘 책임감 다 느꼈겠죠. 기회다. 어떻게 해야 된다고. 기회. 그니까 그 흐름이 김지훈 교수님에 관해서 계속 알아보니까

그 사람이 그 사이버캅, 그게 보안, 그리고 보안에서 그 약간 다크웹이랑 흩어진 자료들을 취합해서 하는 건데 근데 가면 갈수록 너무 고도화, 너무 진짜 온톨러지 플러스 그냥 일반인들이 접할 수 없는 기술의 레벨을 다루시는 분이어서 -뭘 넘사하다. -그 조사를 하면서 하면서 다다른 결론이

-이 사람이 우리한테 뭘 넣고 싶어서 하는거지였고 -왜? 그래서 바로 링고한테 그 첫 질문이 아마 그거였던 거였지. 근데 링고도 모르겠다. 근데 그러면 되게 느끼기에 아 이거 이거인데 뭐 개선하고도 문제는 아닌 것 같은데 그렇게 이사함에 가진 의중을 파악하지 못할 때 그걸 단계적으로 파헤칠 나의 그런 프레임이 없어서인 것 같아요 그냥 왜냐하면 지금 모르겠다 했을 때

어 그럼 여기부터 파봐서 알아봐야지 아니면 이라는 질문하자고 해야지가 아니라 링크한테 물어봐야지 그러니까 답을 바로 얻으려고 되잖아요 그걸 파헤쳐갈 단계를 만들지 못하는 게 사실 그런 거 같아서 근데 이거는 뭔가 DRI가 좋아질 때 이 부분을 그냥 같이 할 수 있는 구조로만 만들게 근데 이거 때문에 DRI가 꺼져가고 까지는 아닌 거 같아 근데 혼자 있을 때랑 팀이랑 있을 때랑 조금 다른 거 같긴 해요 또 문젠데?

팀이 없어서 또 소극적인 거 같아요 같이 있을 때 근데 그래서 지금 물어보는 거에요. 사전실문을 준비 안 하게 되는 과정이 진짜 안 궁금하고 현장에서 질문 생겼네 못하게 되는 건지 사전 준비 사실 해놓으면 그 순서처럼 진행하면 되잖아요. 아니면 그렇게 질문 준비해놓고 다 같이 취합할 때 섹션이라도 나눠놓고 그럼 이 타이밍이 오면 우리가 말을 안 하고 무에 말을 기다리면 되는 거잖아요. 그런 식의 게 궁금한 것이죠. 의중을 모를 때는 애초에 지금도 준비를 안 못하겠어. 그래서 가서 들어봐요. 아 그럼 이거 물어볼까? 분위기 끝나고 물어보던지 다음에 전화해야지 이렇게 되는 건지 같은 게

근데 뭐 이걸 당장 개선할 필요는 없으니까 근데 맥락은 파악한 것 같아요. 그럼 무의 생각을 저랑 너무 극명하게 차이가 나가지고. 아 무의 대한 생각이? 어 그럼 빨리. 무가 지금 생각하는 거랑 제가 생각할 때 연희가 저한테 물어봤으니까 이렇게 무의 얘기를 들어보는데 무의 생각이랑 저의 생각 너무 달라서. 근데 지금 무의 금액에서 텐이 얘기를 하고 싶다는 거죠. 근데 무에 대한 텐이의 평가가 무가 본인이 느끼는 거랑 다르다면 얘기해 줄거예요. 어 아니요.

생각 얘기해야 돼요. 저 생각 얘기해야 돼요? 무슨.. 아니 너무 어려워. 모르겠어. 굳이 개선할 점을 지금 찾을 필요가 없을 것 같아. 그리고 어쨌든 유성경관님처럼 개인적인 라포를 쌓거나 정말 Q&A가 기반이 되는 거 아니면 이미 우리가 어떤 목적을 갖고 접근한 사람한테는 어려움이 없잖아요 그래도. 네. 아 이게 그 기준이 저한테 있는 것 같아요. 아 이거 좀 다른 얘긴가?

얘기해 주세요. 그러니까 제가 생각하기에 이 수사이사회에 도움이 될 것 같은 미팅이나 그런 거는 얘기 안 해도 저는 조사를 좀 많이 해서 가는 것 같거든요. 뭐 이제 경찰 분들 만나거나 아 근데 김지원 교수님은 뭐가 도움될지 몰라서 아 그쵸 그쵸 그런거 같은데 근데 사실상 겁나 결정적인 분이셨잖아요

근데 사실 개선점으로 잡을 정도는 아닌거 같아요 잘하니까 어떻게.. 고려하겠습니다 앞으로 네 그래서 왜 나갈까? 예 이 팬이도 근거에 대해서 더 얘기할 거 없는 거죠? 근데 여기 내용상으로도 뭐 없긴 해요 적힌 답변에서 그리고 협업 주도성에 대한 인식 차이? 본인은 1점이거든요.

근데 팀원들은 1점이 준 사람은 없긴 한데 2, 3, 4를 줬어요. 다 다르게. 그리고 참 이게 문은 본인에게 왜 1점을 줬는지? 저도 왜 1점을 줬는지 궁금하게 하네. 네? 아니 저게 하나 그 얘기 때문인가? -저는 밥을 잘 줄게요. 확인할게요. -아 제가 하고만 해요. 진짜 눈이 너무 감겨요. 입을 벗어요. -아 진짜 나 손을 잡아봐요. -참을 잡아봐요.

-사식도 안식. -진짜 연희가 존경스럽다. -저분 되게 좀 쌩쌩한데? -그런데 연희 밤새고 하는 거구나. 자긴 잤죠. 저한테는 잤 거 아니긴 해요. 그래요? 12시 4시 보다는 6시 10시가 깨고 난데? 그건 인정. 그렇죠. 4시에 일어나는 게 말이 안 돼. 아 진짜. 자면 잤지. 그러니까. 제가 자셨는데?

저는 목욕을 1점으로 낮게 평가. 정보 공유? - 공유하면 안 돼. - 그러니까, 결국 아까 했던 거라. - 그렇죠. - 똑같은 거 맞죠? 근데 종로 점수가 2에서 4거든요. 누군가는 공유를 받지 못하고 있는 거야, 누한테. 그렇다고 생각하는 사람이 얘기해 주세요. 보통 생각하는 사람이 있으면 얘기해 주세요. 저는 4점 준 것 같은데. - 네. - 동로가 맞는데. - 전가요? - 0인가요? 네. 아, 제가 2점 줬어요. 네. 근데 이게 그냥 그랬다가 아니라 그래서 개선됐다라고 정답긴 했거든요

아 그럼 이는 과거의 점수인거에요? 그렇게 했다고 네 아 그럼 원래 1점 주고 싶었는데 개선됐으니까 이 점 정도? 아니요 아니요 이 점인데 이 점이긴 하지만 그래도 개선을 하고 있다라고 아 계속 되어가고 있으니까? 근거는 낙히 없다? 근데 그 이점을 주게 된 근거는 뭐예요? 이점을 주게 된 근거? 음 이거는 팀 내부 논의만으로 합의점을 찾지 못한 점이기 때문에

그래서 이점을 줘도 없긴 하거든요 내부 논의만으로 합의점을 찾지 못한 거 그래서 정기회의 같은 얘기고 아니요. 개발회의? 개발회의 하면서 내부가 아닌 외부까지 갔다 보니까 그 외부가 전체회의인 거죠? 구체적으로 얘기를 해줘야 돼요. 조율해서? 그리고 그게 개선이 되고 있다고 느끼는 게 누가 알아서 개선이 된 건지 태니가 명확하게 그 문제를 언급하고 개선해줬으면 좋겠다 하고

그거에 대한 누가 개선 의지를 보인 건지 이런 맥락이 필요한 거 같아요. 일단 거기 이 점에 다른 구성원이나 반복 공제가 필요했다라고 그래서 이 점을 주긴 했는데 그 후 작업에서는 계속 서로 반복하면서 확인하는 과정 까지만 제가 적혀있어서 지금 확인을 못하거든요. - 캡처를 했더니. - 아~ - 근데 그 정도 평가한 거는 되게 이내로 다 했어요. - 저거 하나는 다 볼 수 있어요. - 제가 이렇게 그걸로 보고 있어요. - 그래서 이거 들어가면 수정할 수 있다고 한 게 그.. - 예~ - 와 저 못해는 다 본가봐. - 캡처 해놓은 것도 정성이다. - 진짜.

- 그리고 나 손 놓고 까먹을까봐. - 다 캡처를 하나하나 입고 음.. 제가 보겠습니다. 아~ 아, 그러네. 이번 항목에 어쨌든 차이를 조정하려면 다른 구성관련 대표의 방법 준비가 필요했다. 그 부분에서 어쨌든 그 개발의 어떤 원인데 둘이서 결정 못 내고 결론 못 내고 팀으로 가져왔으니까 그것 때문에 네. 그럼 그거에 대해서 어쨌든 문제가 무에게도 크게 있다. 라고 느껴져요.

무에게 있어서 중요한 거죠. 근데 그걸 하면서 저도 저에게 먼저 그렇다고 생각을 근데 거기에 작성한 방법이 아예 없어가지고 아~ 하나 했어있어 근데 여기 못 찍어도 돼 있어서 아까 어디까지 있었다고? 잠시만요 아 근데 그 후에 사실 개선 방안으로 찾은 게

서로 반복해서 확인하는 과정을 추가해서 그 뒤로는 서로 맡은 역할을 신뢰하면서 하고 있다 라고 하거든요 근데 저 서로 확인하는 게 그러면은 누군가 PR을 올리면 뭐 제휘존에 검토하는 거 말고 또 다른 뭔가 검토 과정 같은 게 있는 건가요? 그거 하면서도 계속 개발 회의 일어나면은 회의록 같은 거 무조건 녹음하고 정규회의가 생긴 점이 대선 노력으로 아~ 예~ 그럼요~

저랑 누군가 다른 부분에 대한 없어서.. 괜찮았습니다. 개선 좀만.. 개선.. 바꿀 행동만 분명히 하면 될 것 같습니다. 아 저거.. 근데 저는 본인의 만족더라.. 무는 본인의 계산점을 뭐라고 하셨냐면요. 왜냐하면 저희가 요구하는 그게 분명하게 있지 않아요. 그래서 그냥 무의 자기 평가를 가겠습니다. 왜요? 뭐지? 저 뭐라 선지. 근데 무는 그냥 상황 공유 안 되는 걸 제일 큰 문제로 삼았어요.

근데 그거는 계산 문제에서 그냥 실왕 공유해주기 파마마로 바꾸기 파마마라 갠폭한다는 마음으로 편안하게 그냥 오타쿠 아 근데 약간 찐 오타쿠는 아니고 약간 호소이? 이제 입문할게요. 오타쿠 있죠? 어. 근데 이게 다른 분들이 제안하는 개선 부문들이 있거든요.

근데 저 부분이 워낙 본인이 크게 느끼니까 하나는 저걸로 하고 다른 개선 하나는 저나 펜이나 노후가 제안한 것 중에 하나를 하면 될 것 같습니다. 근데 일단 그 뭔가 요구한 것도 미디 팀에 공유하기에요. 아 근데 저도 이걸 보고 나니까 저 공유 자체가 무의 개인 작업의 속도나 진행과정의 그것보다는 개발 회의에서 뭔가 아 이거 결정 어떡하지 물어볼까 말까 하는 것도

또 팀 회의에 빨리 가져오던지 근데 그 팀의 정기회의에 아 근데 이거 언니 안 말할까 말까 하면서 붙이는 거 말고 정말 개발 대화 회의를 열어서 개발 회의에서 이런 게 언급돼서 고민하고 있다는 게 공유가 되는 게 중요할 것 같아요. 저 공유가 실환의 부분에 두 분이 뭘 논의하고 뭘 결정했는지가 공유가 돼야 될 것 같아요. 아무래도 트윈한테 중복되는 게 나오지 않을까 싶네요. 이 내용상에는. 왜냐하면 그렇게 안 됐을 때 이미 개발해서 뭔가를 진행해버려서 되돌리기 힘들다든지

아니냐? 뭔가 그런 것들이 생기게 하니까. 제가 쓴 것은 다 공개하네요, 근데? 오해하죠. 사례는 명확하게 인지시켜야죠. 근데 저도 약간 비슷한 맥락이에요. 근데 저 그냥 이거 대놓고 말할게요. 그걸 했어요. 그 상대방의 태도라든지, 그러니까 돌아오는 태도라든지 내 감정상태에 따라서 협업역량이 자주 유지되는 경우가 있는 것 같다.

그래서 충돌 회피 경향이 가끔 보이는 것 같다. 그러니까 내가 이런 진지한 얘기를 꺼내거나 어떤 개선하자는 걸 꺼내는 것 때문에 불편한 상황이 올 것 같으면 참고 안 하다가 그 문제를 혼자 해 보려고 하는 그런 것들이 생기는 것 같거든요. 근데 그게 뭔가.. 아.. 그 예시도 그냥 말할게요. 그 개발 업무 분담회의를 제안했는데 종결짓지 못한 거. 그래서 그 종결 안 됐다 까지만 공유를 들어서 제가 뭐한테 물어봤고 태희한테 물어봤잖아요. 왜 그 종결 안 된 맥락이 뭔지가.

근데 그거를 근데 그게 어떻게 보면 아생각이 던져놓고 종결 안 하는 것도 되긴 하겠네요. 근데 그 부분에 왜 상대방이 어 이거를 업무분담에 대해서 거절을 하는지에 대한 맥락도 좀 더 끈기 있게 사실 확인을 해서 팀에 공유하거나 그게 아니면 그냥 애초에 뭔가 SOS 요청을 하던지 가 있으면 하는데 그것도 뭔가 어 시도했다가 중단된 느낌이 있기는 해서 그리고 플러스로 그 스트릿뷰 그 하이파이 같은 것도 이거 UX에 나와 있으니까 기념 명세 써주면 좋겠다. 그럼 작업 시작하겠다.

이것보다 뭔가 그 플로우에서 누락된 게 있으면 그 디자인이 정말 다 끝난 게 맞는지를 한번 점검하고 줬으면 좋겠는데 그게 안 된 거를 제가 언급해 놓게 됐거든요. 근데 그게 이건 어떻게 뭔가 그건지 약간 궁금해지는 거죠. 저한테 말하는 게 가장 속도가 빨리. 왜냐면 그냥 저를 결정자라고 생각해서 저한테 말하면 결정해서 그 부분을 다 정리해 줄 것 같아서 그렇게 되는 건지 아니면 노우한테 갔다 오면 시간이 걸리고 거기서 뭔가 병목이 생기고 막 해야 되니까

그거를 회피하고 싶은 건지 사실 모르겠는 거죠. 이게 그런 게 뭔가의 협업이 생략되는 부분들이 그래서 그거를 그래서 그거를 뭔가 그때그때 필요할 때마다 회의를 열어서 공개적으로 상황 공유를 하고 요청을 하면 좋겠다라고 해놓긴 했거든요. 사실상 그 디자인이 있을 때 당연하게 그냥 뭔가 완성되어 있다. 누가 완성됐어요 하면 그럼 이제 연일 명세서 차례 라고 생각해서 그랬을 것 같긴 하거든요.

근데 그것을 로가 직접 뭔가 확인해보고 검토해보는 게 있으면 좋겠다 그리고 류탄이와 뭔가 중단된 일이 있을 때도 한 번 더 체크하는 그런 구석조치가 있으면 좋겠다 같은 게 좀 저에게 여기 써져 있는 내용이 그러니까 그런 것들 실제로 누가 완성해야 되는 아니면 목표에 도달하고 싶은 어떤 거를 할 때 아 개별적으로 파악해서 단순 취합이라도 해서 회의 같은 자리에 가져오거나

아니면 그 취합한 거를 내 선에서 종합적으로 판단해보는 거를 하면 좋겠다의 의견이에요 네? 그건 관련해서 그거는 팀프로세스에서 얘기하려고 했어요 이거 균말이에요? 아니면 지금 들어야 되는 거예요? 뭐예요? 아 그 연희가 의문점 했던 거를 이제 제가 이제 같이 얘기를 하면서 아 한 번 더 얘기했나요? 한 번 더 그거를 언급해 주겠다고 해서 그거를 지금 할 건지 나중에 할 건지 모르겠어요

근데 사실 그거는 의견을 듣기 위함이긴 했거든요 사실 그래서 뭐 저는 그게 종결이긴 했어요. 아 이걸 들어봤다 해서? 아 그 목적이? 뭔가 업무 맡은 그거를 바꿔보는 게 목적이 아니었고? 바꿔보려는 저는 제안을 했는데 거기서 이제 그 갑자기 제가 생각했을 때는 본인이 잘하는 역량에 맞는 그거를 생각했을 때 바꾸자고 얘기를 한거였는데

근데 이제 상대가 생각했을 때는 뭐 어떤 일련의 이유로 이거는 뭐 그대로 가도 될 것 같아 라고 해서 아 그런가요? 아 그러면은 그대로 일단 갑시다 라고 한게 저한테는 사실 종결이 있거든요. 근데 이제 한 번 더 그 약간 맥락을 왜 이렇게 생각했는지를 물어보셔서 그거에 대해서 한 번 더 고민한다고 하고 이제 근데 그걸 고민하다 보니까 결국에는 업무 프로세서적으로 이어져가지고

업무 프로세스 얘기 나중에 좀 이따 할 것 같은데 그때는 같이 할게 알겠습니다 어 네 업무 프로세스도 남았고 한참 남았어요 저희 그럼 어쨌든 저 공유라는 게 내 작업의 공유만이 아니라 내가 개발해서 협의하고 있는 것들 개발팀에서 일어나는 것들까지 포함해서 잘 공유를 그냥 해주면 될 것 같아요 그리고 그 구속 조치를 할 건지 종결인지 같은 거 그냥 그것만 공유되면 될 것 같습니다 네. 그러면 치료 공약이 많이 아니라. 한 번만 더 결렬된 거.

음 음 음 들어가겠습니다 공유하는 게 낫다 이게 사실 고민되는 상황이긴 했거든요 근데 막 공유하라고 해서 막 진짜 3분의 1번씩 막 이렇게 하라는 게 아니라 공기적인 업데이트가 필요하다 뭐 미뤄질 거 같으면 미뤄질 거 같다 근데 뭐 하루 전에 말하는 게 아니라. 이런 제가 뭔가 업무적인 거를 조금 이제 스위칭해서 하자 했는데 그게 이제 어? 우리 그냥 그대로 가자 했는데 사실 그러면은 팀 전체적인 거기서는 그냥 그대로 하는 거잖아요. 그러니까 이런 거를 굳이.

그러니까 이제 거기서 알짤딱이 필요한 상황이라고 생각합니다. - 옆으로 할게요. - 좋습니다. 확인 기준. 제가 비록이 되어 있는가. 그리고 이거 비교하기 힘들게 할 때 개발 회의록에서 주요하게 정리된

그러니까 항상 그런 게 있었던 것 같아요. 개발 회의할 때 뭔가 이런 거 이런 거 이런 거 다 고민해보고 결국 이렇게 했다. 그래서 지연이 됐다 이렇게 말하는데 이거 이거 이거 있었을 때 전체로 꺼내줬으면 바로 확정됐을 법한 사안들이 몇몇 있었던 게 기억이 나서 저도 피드백에 그걸 적었었거든요. 그래서 뭔가 그런 게 고민이 너무 길어진다 싶을 때 뭔가 그냥 전체로 올려주시면

생각보다 빨리 해결될 수 있지 않을까 하는 느낌이었습니다. 뭔 말 알? 그죠. 저도 그게 큰 병목 프로세스의 병목이라고 생각을 했었어가지고. 근데 막 모든 고민을 공유할 필요는 없을 것 같긴 한데요. 한 명 한 명이잖아요. 근데 뭔가 각자 근거가 있어. 근데 하기가 안 돼. 아 그치 그치. 그치 그치 딱 그 얘기해야 될 게. 아니면 사실 기존에도 그 개발에서 어떤 판단한 걸 보고 있기 때문에 UI가 틀어지는 것들이 자꾸 생겼잖아요.

근데 그런 것들을 틀어지기 전에 고지했으면 일단 틀어주대로 해보세요. 그 다음 제가 보정할 경우가 생길 수도 있는 거고. 아니면. 안 되니까 하지 마세요가 빨리 컷 될 수도 있는 거니까. 그런데 UI는 못 받고, 어쨌든 뭔가를 개선해야 돼요. 그걸 이제 다시 개발 큰일을 열어서 그 문제를 개선하기 위한 방안을 찾는 거죠. 근데 그 전제 조건이 뭔지 이제 설명해 줘야겠죠. 그게 담당자가 알아서 이렇게 해서 바꾸고 싶은데 디자이너한테 물어보니까 UI는 이런 의노로 유지해야 된다고 하더라.

이 상황에서 어떻게 개선할 수 없이 회의하자. 를 해야겠죠. 이제 그 DRI가 되시겠죠. 교사색도 해주시면 좋을 것 같습니다 좋습니다 두 시간 지났습니다 고마워 아 네 오케이 못 잡겠는데? 아유 아유 아유 저 혹시 화장실 한 번 가도 되는 부분? 그럼요 아 근데 대신 것도 잘 만들었다 저 잘했죠? AI 잘하죠? 너무 저 심지어 그것도 있어요

개발자 하세요 저희 진행하는 것도 좀 다 만들어져 있어요 시간 다 재고 있고 나로도 다 쓰고 있어요 진짜 잘 만드는 거 같아 미쳤다 GPT가 순식간에 똑같아 GPT에요? 클로드 아니라? 응 GPT에요 어 역시 GPT 클로드인 줄 알았어 이거 너무 클로드 지연이라고 생각했는데 근데 뭔가 코덱스 통합되고 그거 알아서 한 뒤로 뭔가 그림체가 바뀌었을 때 제가 신기해 다녀오세요. 네. 잠시 멈춰두겠습니다 그러면.

네 멈춰요. 멈춰요.

구구 네 태인이는 강점으로 뽑힌게 빠르게 구현하는거랑 기술 리스크를 발견해주는거 가 있었고 근데 자기평가와 복류평가에 간격이 커요 아까도 대시부도 있었지만 여섯 개념이 다 그리고 기술 오너십을 확인해야 된다 어떤 부분을 확인해야 되는지는 밑에 문항이랑 답변을 들어놓은 것들을 보면서 같이 얘기를 해봐야겠네요.

일치하는 부분이 두 개 있긴 한데, 그게 DRI 책임이랑 협업정보 공유하는 점. 둘 다 3점이라서 그냥 수행하고 있다. 하면 될 것 같고, 자기인식점검에서 자기평가가 더 높은 점. 점수 차례 좀 봐야 될 것 같은데. 아 근데 전부 다 공유해야 될 것 같아요. 왜냐하면 자기평가로는 평균이 낮, 중립이라고 표현하면 되겠지.

3이 사실 주어진 일만큼을 수행하고 있다. 3점이거든요. 주어진 일을. 수행한다. 근데 그 본인의 판단으로는 주어진 일을 잘 수행하고 있다. 근데 동료 평가에서는 그거보다 낮게 2점이 나오거나 1점이 나오거나 한 것들이 있고 그리고 오히려 내가 잘하고 있다. 그러니까 그 주어진 테스트 이상의 것을 하고 있다. 라고 4점이라고 준 거에서 동료가 그 부정조개 하고 있는 것들이 있어서

이건 구체적으로 확인을 해야 될 것 같아요 네 고용 품절이나 릴리즈 완경성에서는 사실 어쨌든 중립 이상의 품절치라서 옛날 유자 푸신이로 두고 나머지 부분들을 살펴보면 될 것 같아요 아 내가 진짜 대시보게 사면 아니네? 실수하지 않았네? 어쨌든 자기 평가 중립인데 팀원 평가 1,2점에 가인다던지 아니면 자기 평가 3인데 팀원들 판단이 극과 극으로 있다던지

좀 그런 케이스가 많은 것 같아요 4점이었는데 본인은 4점이라고 했는데 팀원들은 2, 3, 4에 분산돼 있거나 이런 것들은 이 항목마다 구체적으로 논의를 다 들어가야 될 것 같아요 태니 거랑 그 공격한 거를 다 들어가야 될 것 같으니까 인식 차이 많진 않은데 세 개 항목이 오~ 태니도 앞에 거랑 좀 비슷한 것 같아요 아예 점수가 1, 3, 4로 완전 분산되어 있는 게 DRI 책임성과 주도성 부분

그리고 이건 근데 자유 공통의원이라고 보면 될 것 같은데 중간값인 걸 빼면 피드백 관점과 성장하는 게 낮게 평가된 게 있고 그리고 구현품질 및 완결성도 동요들이 싹 다 다르게 평가해서 아마 본인과 협업한 거에 대한 걸, 동료 평가다 보니까 태희가 같은 업무 중에서 나와 협업한 거 기준으로 아니면 내가 보기에 이 팀에 어떤 영향을 미친 업무를 각자 생각한 게 달라서 차이가 나는 거 같은데 그거는 구체적으로 확인을 해보면 될 것 같습니다

그리고 반복적으로 평가된 게 3명이 만장일치로 말한 게 뒤에서 나오겠지만 결과물 검증과 완결성 아까 부분에서 완결성 그래서 사계를 들어봐야 될 것 같아요. 그리고 기술 판단한 것에 대해서 설명을 할 수 있는지랑 책임을 지고 있는지에 대한 것 같습니다.

그런데 이 부분은 언급한 키워드들의 조합이나 이 서술을 단 답변에 키워드가 조합된 거거든요. 그것도 사례를 한번 확인해보면 되겠습니다. 일단 강점으로 아까 소개했던 빠르게 구현하고 비슬리스크를 발견하는 것. 자기 평가에서도 이거를 강점으로 인식하고 있다고 했고 그리고 사례를 두는 두 명이 서술형에 쓴 게 동료 두 명이 각각 다른 사례를 들긴 했는데

어쨌든 어떤 사례를 근거로 기술 리스크를 발견하거나 구현이 빨랐다 라고 적게 평가한 게 있었습니다. 그래서 각자 다른 업무를 한 사람이 어쨌든 그 부분에 대해서 강점으로 꼽았다 라고 이해하면 될 것 같고요. 반복된 의견 중에 하나로 결과물 검증과 업무 완결성. 예린경리, 제출한 결과물이 있는데 팀이 바로 활용하기 어렵거나 요구사항, 설명, 검토가 부족해서 다른 구성원이 다시 확인하고 보완하는 일이 방법됐다 이게 문화에 있는 항목이 적용된 것 같긴 한데

어째서 그런 평가가 있었고 자기인식에서는 공동 항목 전체를 다 3점으로 줬거든요 근데 그거를 다 중... 약간 사실 이게 중립이 아니라 그 3분의 문항 각각마다 내가 그렇다 라고 평가한 거니까 그거에 대한 근거를 나중에 쭉 설명을 해주면 좋을 것 같고 그리고 세 명이 다른 팀원들 전부 다 재확인을 해야 되거나 재작업을 해야 되거나 그대로 활용하기가 어렵다 라고 언급을 했어서 그 사례들을 확인해서 그 사례들의 뭔가 동의하고 개선점을 바로 찾을 수 있으면 하고

거기에 뭔가 사유나 아니면 나 스스로도 문제진단이 되지 않아서 더 구체적으로 왜 문제라고 느끼는지 확인하고 싶으면 좀 더 얘기를 자세히 하면 좋을 것 같네요. 그리고 또 반복 의견으로 3인 다 공통으로 나온 게 AI 결과라든지 아니면 기술이 변경된 것들을 충분히 이해하고 검증하고 설명하지 못해서 다른 구성원이 코드라든지 판단 근거 같은 거를 추적해서 찾아봐야 되거나 아니면 대신 설명해야 됐다. 반복됐다라고 하거든요.

비슷한 사례가 언급된 걸 수도 있어서 들어보면 좋을 것 같습니다. 그리고 이게 또 자기평가는 4점이라서 그 간격이 좀 큰 것 같긴 하거든요. 그래서 한번 구체적인 사례를 보면 좋을 것 같고 그리고 피드백 이후의 행동 변화에서도 같은 피드백을 계속 반복해서 줘야 되는 그 말이 곧 같은 문제가 계속 반복되고 있다 없어서 추가 설명이나 추가 수정이 필요한 이 앞의 문제가 사실 반복된다 인 것 같거든요 추가 설명과 수정이 필요했다는 게

그래서 앞에 이 두 문제를 확인하면 이거는 좀 확인이 될 것 같네요. 그리고 두 명 이상이 반복했는데 동료 중간 값이 1점이면 거의 1,2점만 나온 것 같긴 해서 이번 기회에 이것들은 무조건 사실 개선을 해야 된다 라고 생각해야 될 것 같아요. 그리고 논의의 핵심일지. 단일 의견으로 있었는데, 세 중에 한 명. 표현이나 단어 해석에 논의가 오래 머물러서 핵심 결정과 실행이 늦어진 경우가 있었다.

라는 사례가 있어서, 이것에 대해서도 본인은 배경 설명이 길다 라는 문제로 인식했고, . 네. 수업은 이거나 큰 거라서 휴양에서도 강조 확인을 해놓으면 좋겠어요. 강점은 관계가 또 아까 너무 계획처럼 있다가. 만장일치. 네. 만장일치 가깝다고 보면 될 것 같아서 강점은 계속 있게 해주면 될 것 같고요. 그래서 결과물 검증과 업무 안결성에 대해서 이 종합위원에 대해서 태인의 의견을 순서로, 뒤에 거까지 하나하나씩 순서를 들어보면 될 것 같아요.

일단 공통한 거 다 3점을 줬기 때문에 전체적으로 사실 이렇게 3점을 보통 평가해서 계속 3점을 인정하면 이거에 신뢰성이 떨어진다고 판단해서 보통 재검사를 하거나 아니면 면담 같은 거로 이어지긴 하잖아요. 그래서 저거를 다 3점 준 거에 대해서 어떤 근거로 그렇게 됐는지와 이 항목이 3점인 이유는 구체적인 사례를 설명해주면 좋을 것 같아요. 음.. 네. 일단 제가.. 저도 근데 사실 인식 못했는데 다 3점을 줬..

3점 준 거, 4점 준 것도 있고 한데 거의 대부분 3점을 줬던 이유가 어.. 엄청 막 더 잘하려고 하고 막 이렇게 주도하거나 그러지는 못해도 정량적으로 어떤 작업이 있으면 테스크가 기간 안에 끝냈다고 생각했을 때 정량적인 부분은 제가 했다고 생각했던 것 같아요. 특히 제가 개발자라서 인 것도 있지만 개발적인 부분에서 일정을 느리게 한다거나 그런 부분이 없어서 조금

3번을 멈췄던 것 같고 그리고 이제 저는 이렇게 개발하면서 되게 언급 많이 했던 게 안전성이나 아니면은 좀 보안감안 이런 거를 조금 집중하고 싶었고 초반에 그런 리펙토링에서 그런 작업을 했다라고 생각이 들어서 아마 거기에 대해서 사정을 줬던 것 같은데 그래서.. 음.. 아.. 어? 근데 그.. 뭐지?

그쪽은 역할성장 부문이어가지고 그냥 그.. 개발자로서 한 업무 말고 그냥 팀에서 맡은 모든 업무의 전반적인 답변이 공통질문의 내용이라서 거기는 다 3점을 주긴 했거든요. 근데 여기서 공부해주는 건 그 기준은 3점을 주신 이유가 나에게 주어진 테스크를 내 기준에서는 다 했으니까 일단 3분정도 3점에서 1,2점을 안 준 이유는 설명이 되는데 4점을 주지 못한 이유도 필요할 것 같거든요

주도적이지 못했기 때문에 응 더 막 얘기해봐요 더 잘해봐요 고도화 더 잘해요 이런 것보다는 당장 내가 맡은 거에만 집중하는 게 조금 컸던 것 같아요 스스로 생각했을 때 그럼 태희는 3번 중에 어쨌든 그러면 업무를 완결했다 기준은 3번이었잖아요 태희가 판단하는데 업무 완결의 기준은 뭐예요? 일단 기간 내에 작업을 다 하는 것이라고 생각을 해서 그러니까 그 작업을 다 했다 이 기준 거기서 간격이 생기는 것 같아서

일단 제가 생각했을 때 그 완결 기준은 제가 하겠다고 했던 테스크들을 자꾸 이거를 근데 저도 쓰다 보니까 개별적인 것만 제가 이번주 안에 이렇게 작업을 하겠다고 말스톤을 찍으면 거기까지는 무조건 작업을 다 하고 회의할 때도 여기까지 다 했다고 생각을 했고 회의를 찾아갔을 때도 더 늦어졌거나 하는 게 없어서 그냥 기분치는 했다고 생각을 했던 것 같아요

만수의 기준은 정확히 뭐라고 생각해보는거지? 일단 코드가 그 기간 내에 검토를 받고 그냥 PR이 올라갔고 거기에서 작업이 됐다? -머리는 게 머지 됐을 때. -네.

-그 PR 올리는 기준은 어떤 거예요? -정상적으로 작동하고. -아, 그 정도 되는 거. -네. -정상적으로 작동하고. -네. -그 기능에 대한 한 사이클이 제대로 돌아가는지. -네. 피아로링게 모제됐을 때인 거고 나머지 업무에 대해서는 완성의 기준은 일단 1장 1장 안에

그 완수가 1장에 공개하는 것도 다른 의미긴 해서 지금 앞에 내용을 보면 그 어쨌든 완결성에 대한 이유가 있으니까 그 완결성의 기준이 달라서 생기는 문제라서 이걸 확인해야 개선을 찾을 수 있을 것 같거든요 제가 썼을 때 지원사업에서 뭘 했는지를 막 적힌 사람인데 이것도 약간 기준이 그만 회의에 뭔가 늦어진 게 없었다를 조금 그러니까 그 기간 내에 작업했다의 여부로 좀 많이 따졌던 것 같아요

확실한 건가요? 그냥 그분과 같은 하거든요. 태니의 만결 기준이 팀의 기준을 미치지 못하는 것. 다른 지점이 있음이거든요. 근데 지금 태니가 말하는 것도 이 업무의 완성도의 기준이 없고 일단 일정한의 끝냈다만 있는데 그 끝에 대한 기준이 사실 없어서 그거를 구체적으로 오늘 확실하게 정하고 해야 될 것 같아요

끝나는 그거의 결과물의 기준 저거 저거의 기준에 다른 팀원들에게는 팀원 의견 얘기할 때 한번 확인해보면 찾을 수 있지 않을까 싶습니다 좋아요 그러면 뒤에 이 얘기 이것에 대해서는 기술판단 운영을 사정으로 평가했거든요 이게 아까 태니가 말했던 사정 중에 있다라고 역할 그쪽 부분인데 저게 사정이 이거거든요 대안이라든지 트레이드 오프 해야 되는 거

내가 만약에 A 0을 하고 있어 A B를 하고 있어 근데 CD 업무가 생겼을 때 어? 그러면은 AB를 일단 일시 중단하고 CD를 해야겠다 판단을 한다든지 아니면 어? 그러면 A는 다른 개발자에게 주거나 개발 언급 끝났으니까 어? 그리고 Q&A는 그냥 너네한테 할 수 있는지 물어볼까? 이런 식으로 뭔가 디테일 업 시켜서 업무를 해야 하는 거 그리고 리스크를 비교해서 제품 운영 환경을 고려한 현실적인 공고안을 제시한 거 이렇게 하고 싶어가 아니라 권고안을 제시했다가 4점이거든요.

그거에 대한 근거를 한번 설명해주면 좋을 것 같아요. 왜 또 호황을 찾지? 내 스스로? 근데 이건 있는 것 같아. 5점을 바라보는 것. 그리고 이 사전 설명에 대해서 어떤 사례를 떠올리는지. 저도 그랬어요. 사례를 생각했기에 사정을 줄 수 있었는지 그 사례를 얘기해 주는 거 왜냐면 작성 근거가 전혀 없거든요. 사전인데도 사전인데도 없었어요 그래서 방금 얘기해 주는 기준으로 또 얘기하면 될 거 같습니다

뭔가 이렇게 얘기하면 변명일 수도 있는데 저희가 뭔가 기술이나 이런 걸 고도화하자고 했을 때 저는 좀 제약상 아니면은 저희가 이거를 작업한다고 확장을 했는데 문제가 생길 사항 같은 거에 대해서 되게 많이 저는 안 된다는 입장을 많이 거수했던 것 같더라고요. 그런데 기술을 만들기 쉽고 이런 것보다 이런 제약이 있어서 문제가 될 수도 있으니까

이런 부분은 조금 더 검토를 해본다거나 아니면 다른 방식으로 접근해야 되지 않을까 라는 것을 저는 주장을 했다고 생각을 하는데 사실 다른 팀원분들의 얘기를 더 들어봐야 될 것 같아요 그래서 저는 점수를 그냥 다 포하게 준 것 같아요 근데 저기 뭐 뭐랬디 그 문제를 진단했다 까지는 사실 감점이 이미 있는 내용이잖아요 그런 리스트를 계속 이마인드 이런 것들을 근데 이 항목은 사실 그런 문제들을 구체화하고

판단을 정확하게 했느냐. 사실 그렇기 때문에 4번이 그거에 권고안을 만들어 왔느냐. 지적만 한 게 아니라 대체한이 있었거나 또 고도화를 주는 방향에 제시하거나 내 의견을 설득하기 위해서 근거들을 조사해서 충분히 설명이 되었느냐,긴 하거든요. 그래서 그 부분에 사례가 생각나는 게 있으면 뭐 나중이라도 얘기해도 될 것 같고 팀원들의 얘기를 들어보고 테니 말대로 그때 또 논의를 하고, - 알겠습니다. - 네, 괜찮습니다.

- 감사합니다. 리마인드하고 일단 표현할게요. 태니가 계속 반복했다고 하는 부분은. 일단 하는 경향이 있어요.

일단 이런 거. 네. 이렇게 하고 피드백 이후의 행동 변화의 부분은 어쨌든 과반 이상 의견이 있긴 한데 음.. 근데 태니가 스스로 인식할 때도 회의 전달 방식을 계산적으로 인지는 했는데 결과물 검증 문제인식은 제한적이었다 라고 되어 있거든요 그래서 회의는 약간'지금 이거 평가하다 보니까 문제 있었던 거 같아' 까지만 된 거 같고 여기 써져 있는 걸로

결과물 검증 문제는'내가 어느 정도 알고 있다' 이런 식의 내용을 써서 제한적이라고 표현이 된 거 같은데 혹시 저 평가할 때 어떤 근거로 저렇게 썼는지 혹시 기억나나요? 아니면 제가 요즘에 안으로써요. 작성은 해놓은 게 뭔지 조금 한번 봐주실 수 있어요 저 매일이 남아있어가지고 확인 못해요 자기 평가는 공개 안 되겠죠? 자기 평가와 정의 평가를 비교하면서 보정할까봐 자기 평가를 공개하지 않았습니다 아하 이것을 그럼 태니의 개인 핵심 피드백을 공유를 할게요

공개 회의에 대한 게 있어서 음~ 저렇게 정된 거 그거 때문에 막 또 이 핵심 피드백에 이게 사실 그거잖아요 그 쓰는 순서를 이런 상황이 있고 그 상황 때문에 내가 이런 팀에 이런 영향을 미치고 그래서 개선점을 이렇게 해야 될 것 같다 라고 써야 되는데 앞에 문제만 있고 뒤에 개선점이 없어서 제한적으로 인식하고 있다 라고 얘가 평가를 한 것 같고 팬이 언급한 내용을 얘기하자면

내가 판단하는 계산하고 싶은 부분 아니면 계산해야겠다 라고 느낀 부분은 회의 시에 결과만 정리하기보다 해당 방향을 선택한 근거, 검토, 배경과정을 모두 설명하라는 경향이 있었음 있는 팀원들에게 내용을 설명해야만 결과가 충분히 납득될 것이라는 판단이었음 하지만 행위에서는 핵심안건과 결정사항이 빠르게 드러나야 하며 서로의 의도를 직접 확인하는 과정이 번복되고 있었음. 이렇게 되어 있거든요. 뒤에 한 개의 상황이 더 있나요? 행위 얘기?

아 이거 앞에 행위가 됐어요. 이까지만 하고 이거에 대해서 부여 설명을 해주면 좋을 것 같아요. 테니의 입장은 결과만 정리하는 게 아니라 회의 시간에 해당 성향을 선택한 근거와 검토, 배경 같은 모든 걸 설명하려는 경향이 있다. 그거를 다 설명해야만 팀원들이 납득할 것 같아서 그렇게 했는데 그렇게 하다 보니까 회의 때 결정사항이나 안건이 빨리 드러나는 게 안 되고 있다의 얘기인 것 같거든요. 네, 있는 것 같아요.

근데 뭔가 평가만 좋게 있어가지고 그거에 대해서 정확히 이 사례를 좀 설명해주고 왜 개선하고 싶은지랑 어떻게 개선할 수 있을지를 한번 얘기해 주면 좋을 것 같아요. 일단 제가 회의록을 써놓은 걸 되게 많이 이것저것 찾아봤는데 저한테 되게 주로 개발 아닌 업무로 받아진 게 IP 알고리즘이랑 그 다음에 PCI 이렇게 두 갠데 제가 두 가지 아 그리고 ESG도 있긴 했었어요. 일단은 그 세 개를 다 봤을 때 제가 자료 조사는 하는데 그거를 모두에게 아 저 이렇게 자료 조사했고요 이렇게 이렇게 했고요 이런 내용 있고 이걸 하나하나 다 설명을 해요.

그렇게 하고 결론적으로'아 근데 이렇게 하니까 이게 좀 안 될 것 같아요'로 항상 계속 끝나더라고요. 그래서 그런 부분이 좀 문제가 있었다라고 생각이 들었고 그러니까 어쨌든'이게 안 될 것 같아요'라는 거를 조금 더 짧게 아니 해야 되는데 저는'안 될 것 같아요'라고 보면 '근데 능력이 안 된다'라고 이제 표현이 될 것 같으니까 '근데 능력이 안 되는 거야'라고 말을 하고 싶으니까 그게 좀 말이 길어진 것 같다.

이런 게 좀 있었던 것 같고 그리고는 개선하고 싶은 문제로 그냥 일단 쓸게요 네 정리하자면 회의 때 왜 살짝 표현해야 돼? 회의 때 개발 외적인 부분에 대해 말하는 걸까? 개발적 관련해서는 오히려 그냥 답이나 이런 걸 조금

그래도 뚜렷하게 냈던 것 같은데 그러니까 그런 것 같아요 그 IP 알고리즘이랑 PCI 같은 건 잘 모르는 부분이니까 제가 조사한 것까지는 만약에 나름 저는 100% 다 찾아봤다고 생각했는데 이 티만이나 아니면 바깥에서 봤을 때'어 그거 아닌데'라고 될 수도 있으니까 이제 구구절절 내가 이렇게 이렇게 찾아봤는데 이렇게 찾아보니까 이게 안 되더라 약간 이런 식으로 계속 흘러갔던 부분이 있었던 것 같아서 알고리즘 같은 경우에도 지금 생각해보면 제가 그때 연희한테 이거 너무 천문학자나 통계학자나 데이터 사이언스 보는 것 같아서

저는 거기서 만들어진 거를 가져와서 쓰거나 하는 건 할 수 있을 것 같은데 제가 이걸 만들려고 하니까 막 벅차다 이런 얘기를 연희한테 막 했던 것 같아요 막 눈물난다 막 이러면서 근데 그런 거를 안 된다? 아니면 이걸 지금 우리가 못한다를 말하기가 스스로 이제 좀 그걸 못하니까 계속 막 회의에서도 계속 그냥 계속 변명 이게 막 이렇게 했는데 안 됐다 이렇게 됐던 것 같아서 그 부분에 대해서 정말 고민이 많고 이걸 제가 어떻게 해결해야 될지도 조금 막막하기도 하고

그래서 좋은 주시면 좋겠습니다 진짜 궁금한 게 저.. 그러니까 저 안 된다는 판단을 할 때 다른 근거를 사실 가져올 수도 있긴 하잖아요 응 근데 뭔가 어떻게 말한 것처럼 변명처럼 아 이거 진짜 어려운 거다 이렇게만 되는 혹시 이유가 있을 거 같아요 일단은 데이터가 다 가지고 있었어야 했다고 해야 되나요?

그때 그걸 찾아볼 때도 그냥 처음에는 모르니까 AI나 이런 걸로 이제 조금 찾아가면서 프롬프트를 완성시키잖아요 그래서 한창 만들고 하면은 어? 이렇게 하면 될 것 같다 라고 했는데 막상 다시 돌이켜보니까 어? 그 GPS 정보가 필요하네? 우리 앱이랑 이게 맞는 건가? GPS 정보를 받는 게 차량이나 이런 걸 빌렸을 때 말고 핸드폰으로 받은 기지국 정보로 가능한가? 그때 그걸로 또 어 이거 안 될 것 같다 라고 얘기를 했던 것 같고

제가 기억했을 때는 그 부분은 그것 때문에 안 된다고 했던 것 같아요 PCR 같은 경우에도 제가 리캡할 때 PCI 들은 게 한 줄이랑 다 했잖아요 그래서 제가 무한테도 카톡으로'혹시 PCI에 대해서 더 들은 거 있냐' 내가 그냥 PCI로 검색을 해보니까 그냥 식별 번호라고 되어 있는데 이게 그냥 핸드폰으로 오는 거냐 그때 제가 아마 그게 문자에서 오는 번호라고 생각을 못했던 거 같아요

어? 그거 그냥 연희한테 물어봐라 그래서 근데 저는 좀 더 제가 찾아보고 싶은 거예요 그래서 찾아보고 찾아보다가 이제 결론적으로 보니까 기지국 번호였어요 아 나 잘못 또 헛짓했네 약간 이렇게 생각하고 찾아보는데 거기에 있는 검색 결과나 이런 거에서는 붙잇볼 모양으로 뭔가 결과가 나온대요 그래서 아 그러면 이거 수치상으로 되겠다 이러면서 그런 자료조사를 하고 시각할 수 있도록 뭐 그래서 이렇게 찾아보고 했는데 나중에 김지영 교수님 ppt를 보니까 이게 부채꼴 형태로 나타나는게 아니고

방향도 알 수 없고 그냥 그 번호만 주는거더라 그리고 그게 받은 ppt를 보니까 그 기지국에 정보를 주는게 아니라 형사님들이 돌아다니면서 수집하고 있는 앱인거 같더라구요 어? 그러면 이거를 우리 앱에서 어떻게 도입을 하지? 그러면 이거를 시각화하는 게 너무 어렵다? 그러면서 또 이제 연희랑 얘기를 했던 것 같고 그게 또 회의에서 구구절절이 됐던 것 같아요. 결론적으로 태니는 그렇게 구구절절 다 설명하게 되는 거를 개선하고 싶은 것 중에 하나라고 생각을 하는 건가요?

그 이유는 뭐예요? 그렇게 저희 팀에서 이 기능을 넣을 수 있으니까요 만약에 쓴다고 하면 그거를 그냥 자료 조사만 해놔라고 하면 PCI라는 게 뭔지를 그냥 4명이서 알면 되는 거잖아요 자료 조사라는 거는 근데 그게 아니라 PCI를 우리가 활용을 해야 돼요 아니면 이걸 우리가 업데이터로 활용을 해야 돼요 그럼 업데이터로 어떻게 들어오는지를 확인을 해야 되고 근데 그게 그냥 숫자였고 그래서 이거를 식어 한다고 하면은 식어 할 수가 없는 상태다

근데 문자에서 오는 거더라 문자에 오는 것만이라도 저장할 수 있다 까지만 결론을 도출했던 거죠 아 그 제가 물어본 거는 지금 구구절절한 거를 개선하고 싶다 라고 말했잖아요 근데 금방은 구구절형 설명이 있어야 기능에 도입할 수 있으니까 그랬다 그러니까 개선하고 싶은 것과 이유가 지금 안 맞아서 이걸 정말 개선하고 싶은 게 아닌 건지 그리고 이걸 진짜 계산하고 싶은 거면 왜 구구절절 안 하고 싶은 건지가 필요한 것 같아요 구구절절 안 하고 싶은 거는 회의에 되게 굉장히 속도감을 늦춘다는 거

그리고 그래서 더 앞에 있는 프로세스가 조금 일단 그거인 것 같아요. 개선하고 싶은 것 같고. 이렇게 길어져서. 개선하고 싶은 것 같고. 음.. 그리고 음.. 이게 제일 큰 것 같은데..

근데 이게 계속 도돌이표인 것 같아요 그렇게 하지만 받은 테스크에 대해서 뭔가 결과를 내려면 또 설명을 하고 있는 거 도돌이표는.. 어떻게 해결할지를 좀 모르겠는 상황.. 이렇게 써놓을게요. 그리고 다음에 또 하나 더 있거든요. 그대로 읽을게요. 정제하지 않고.

업무 공유 시 결론을 중점으로 나머지 배경안은 빠르게 설명하거나 팀원들이 보기 쉽게 정리하고 추가 질문을 받는 형식으로 변경하다가 아, 이거는 그 방안을 지지한 건가? 제가 거기에 아마 그렇게 적으라고. 그리고 DRI 시 내가 전달하고 싶은 것과 결정받고 싶은 것을 정리하고 추가 설명 사항은 별도로 기록해서 회의나 흐름이 다르게 가는 일이 없도록 할 것이거든요 그럼 이거는 그냥 저.. 박불행동에 일단 붙여놓고 나중에 팀원의견 다 들은 다음에

저게 가장 개선할 우선 문제라고 생각되면 그대로 활용을 할게요. 조확장이 되는구나. 그리고 DRI에 대한 산출물이 제대로 안 나오는 것도 저거랑 같은 맥락인 것 같아서.

일단 비교해봐야 하니까 일단 이렇게 해서 먹으면 네 그러면 그 다음 항목이 피드백에 대해서 아 근데 그렇게 잘 볼 것 같아 아 근데 이거 했습니까? 근데 태니는 회의 전달 방식만 개선적으로 얘기를 하긴 했는데 이게 팀원들이 언급한 내용에서는

피드백이 반복돼도 언급이 계속 반복되거나 추가 설명이나 수정이 필요했다는 의견이 있거든요 태니가 이 회고를 돌아볼 때도 '아 뭔가 내가 피드백 받았는데 똑같은 거 또 한 적 있다' 라던지 나는 끝났다고 생각했는데 누가 설명을 더 요구하거나 태인이 근데 지금 설명을 항상 길게 자세히 다 해줬다 그랬잖아요 근데 설명이 더 필요했거나 수정을 했어야 되는 경우 혹시 기억나는 자리가 있나요? 없으면 팀한테 들어보겠습니다 일단 팀원한테 들어보겠습니다 지금은 없으면?

들어보고 지금 약간 뇌가 멈췄어요 다음이 단일 의견이긴 한데 아까 말했던 거 보면 이게 이렇게 지적한 거에 대해서 이 평가 AI는 어쨌든 배경 설명이 길다는 문제 인지하고 있다 인 것 같아요. 근데 이거는 설명이 길다기보다는 그.. 논제를 벗어나서 약간 3000% 빠진다의 맥락이 큰 것 같아서

그거에 대해서 혹시 팬이가 뭔가 기억하는 사례나 아니면 이 문제를 느낀 적이 있는지 스스로 인식한 적이 있는지 있나요? 3000% 빠진다는데 용지 안 쓴 것 같은데 아니 그러니까 스스로가 아니라 그런.. 자기 인식을 한 적이 있느냐 팀원이 언급하는 문제에 대해서 표현이나 뭔가 단어 같은 거에 논의를 계속 하느라고 실제로 핵심 결정해야 되는 거나 실행이 딜레이 되는 거에 영향을 끼친 적이 있다

이것도 예시를 좀 먼저 들어도 될까요? 지금은 없다네요? 없다 보기보다는 들었어. 들어보고. 네, 들어보고. 어쨌든 파악하지 못했다라고 일단은 생각하고 진행을 할게요. 나는 그걸 문제로 인식하지 않거나 아니면 애초에 저 사례를 문제로 느끼지 못했거나 인 상황인 거 같아요. 여기서 좀 감극이 오는 거 같아서 그거는 팀 얘기를 듣고 열심히 얘기를 들어보는 걸로 하겠습니다. 조심히다.

이것만 보고 일단 얘기를 해볼게요. 네. 어차피 세 명 전부 다 재확인하거나 재작업하거나 바로 활용하기 어렵다. 언급이 있었어서 각자의 사례를 얘기하면 될 것 같아요. 저 때 점수를 내긴 근거 아니면 그때 설명의 사례를 들었던 거를 공유해주면 될 것 같아요. 왜냐하면 이게 사례를 다 들어야 되는 이유가 지금 일단 태인이 그냥 말했듯이

그 문제지만 그 원인이 나에게 있다고 인지를 못하고 있거나 애초에 그 문제 상황 자체를 문제로 안 바라보고 있는 거거든요. 평가에서는 다 긍정평가를 했다는 거는 그래서 구체적인 사례를 말해서 인지를 시켜야 될 것 같고 인지를 하고 나서도 문제라고 본인이 판단을 안 하면 왜 문제라고 판단 안 하는지에 대해서 계속 얘기해야 될 것 같아요 음... 음...

1번에 대한 답이거든요 1번 1번 이거 저 먼저 얘기할게요. 그리고 각자도 이메일 온 걸 그대로 읽어두고

그냥 기억이 나면 그거를 얘기해 주시면 되겠습니다. 제가 쓴 거는 이거 공성분이라고 그냥 그대로 읽어둘 것 같아요. 사업계획서에 반영할 예산 측정이랑 그 예산 측정한 거를 문서에 작성하는 거 그리고 신규 BM 아이디어 하는 거 기술 특허를 위한 업무가 제대로 수행되지 않아서 활용할 수 있는 결과가 없었으며 이를 보완하거나 더 나은 대안을 제시하거나 하는 후속 조치가 없었음 그리고 노션의 자료 업데이트 또는 AI 요약하는 것 외에 팀에 제공할 최종 문서가 정리되거나

로 개설하는 게 미흡해서 반복적으로 계속 확인하거나 추가 질문을 해야 했고 그때마다 노선에 있다. 이거 확인해라. 라는 답변만 주로 받아서 문제가 해결되지 않았다. 라고 썼습니다. 이거를 좀 구체적으로 얘기를 설명할까요? 일단 첫 번째 사업계획서 예산은 사실 이거는 일부러 공공의 자리에서만 언급을 받고 태인이 개인적으로 어차피 끝난 업무라서 제가 마무리 했어야 됐어서 패드웨그를 더 하지 않았는데 그때는 사실 포기의 진정이었어요.

왜냐면 그때 계속 개인이 작업할 때도 그 애초에 AI에게 잘못된 정보를 적기 때문에 잘못된 결과가 나온다는 게 태인이의 노션 페이지에 보였어요. 그 답변 내용 자체가 우리 드림홈즈가 가지고 있는 환경이 아니었어서 그래서 그걸 개선해달라고 계속 요청했는데 그게 어떤 원인인지 모르겠어요 태인이 판단하기엔 그게 최선이어서였는지 아니면 프롬프트를 고치지 않아서 라든지 아니면 그 프롬프트를 해서 받은 내용을 실제로 내가 뭔가 검색하거나

그거의 주체성을 갖는 어떤 공식 출처의 자료와 비교를 안 해서인지 모르겠는데 그중에 가장 제가 제일 힘들었던 거는 최저임금이 아닌 걸 계속 쓰는 거 그게 안 된다고 4, 5번 말했는데 최종도 그거였거든요 그래서 제가 수정을 했는데 제가 수정한 페이지도 보지 않고 태희꺼의 기준으로 또 수정하는 바람에 왜냐면 제가 수정했는 거 혹시 봤냐 일부러 프롬프트까지 다 올려놨다 라고 해서 봤다고 했는데도 제가 수정한 안에 기준에서 태니가 다시 태니 판단을 보완한 게 아니라 태니 문서에서만 또 보완을 해서 또 뭔가 잘못되어 있는 거예요.

그래서 그리고 그때 중간에 그냥 총액이 안 맞거나 이러면 어떻게 총액이 안 맞는데 어느 부분 금액을 빼면 되냐 이런 얘기가 있었을 때도 뭔가 스스로 수정하고 있는 게 없었어가지고 뭔가 계산이 안 맞는 거 그리고 이미 각 항목을 배분이 제대로 안 된 거에 대해서 맞는 게 자기 확신이 있으면 그거를 저를 더 설득해서 설명을 줬으면 좋겠는데 그게 아니라 그냥 AI 답변 붙여놓은 페이지를 계속 읽으라고만 하니까 저는 텐에 설명이 필요한데 왜냐면 제가 판단할 때 이미 아닌데 이거를

서류에 넣을 수 없는데 그래서 그 부분에 합의가 안 되는 거 그리고 결국에는 임금 부분 이런 거를 제가 수정해서 올렸잖아요 근데 그렇게 하고 나서 양식을 맞춰서 문서에 넣어달라 라는 작업을 했을 때도 몇 명이랑 월수 인원 곱해서 하는 거 그런 것들이 양식대로 통일이 안 되는 것도 통일이 안 됐다고 했을 때 어 맞췄는데요? 막 이렇게 계속 돌아왔었거든요 사실 그래서 거기에 이제 시간을 계속 허비할 수 없으니까 그냥 제가 다시 수정해서 올리는 거 근데 그때 맨 마지막에

사스를 제가 또 근데 이 사스 어떤 기준으로 한 건지 또 확인을 했었거든요 근데 그때도 태니가 또 노션을 보라고 했어요 다 리스톱 해놨다고 했죠 근데 저는 전체 리스트는 사실 상관없죠. 그거는 태니가 조사한 내용인 거고 그중에 어떤 태니가 뭘 선별해서 뭘 누가 쓰길래 남은 개월 수, 근데 8개월 쓴다고 했는데 태니가 알지 졌거든요. 8개월이 지나갔다고 근데 그거를 어떤 어떤 항목을 그리고 만약에 기터비 여러 개야. 근데 그중에 왜 기터비 항목을 쓰고 클로드가 사실 플랜이 많은데 클로드 무슨 플랜을 썼길래? 한 달 총합이 이거지? 그 총합을 4명 나눠보면 돈이 엄청 작은 거에요.

그걸 계속 확인하는데 이미 다 정리된 거라고 계속 났거든요. 내고 막상 돌아왔을 때 정리회의 때 언급이 됐잖아요. '어? 왜 한 달에 80밖에 못 쓰지? 그럼 우리 다 클러도 못쓰는데?' 내가 됐잖아요. 그래서 제가 그때 태니한테 다시 요구했잖아요. 이걸 짠 근거가 보였냐. 근데 그때도 태니가 전체 풀리스트를 보라고 그랬거든요. 제가 그때 태니가 그 밑에 괄호의 예시를 태니가 써놨잖아요. 일부러 그대로 낸 거거든요. 왜냐하면 태니가 계속 확신이 있다고 하니까 근데도 그때 그게 그.. 보완이 안 됐잖아요. 문제가 생긴 거 알았어.

그래서 제가 테니한테 계속 보내고 근데 테니가 자꾸 있대. 그러면 돈을 보내달라고 했는데 회의 끝난 것도 안 보내주고 이후에도 안 보내줘서 그래서 그냥 제가 조정해서 최대한의 부모님한테 요청해서 금액을 변경을 했던 그런 히스토리였잖아요. 그래서 그런 부분에 있어서 사실 저는 근데 앞에 다른 분이 AI 언급을 해서 저 키워드가 들어간 거 같은데 저의 더 큰 문제는 AI는 누구나 쓰는 거니까 AI 활용도나 그런 게 하는 거는 물론 문제라고 할 수 있겠지만 어쨌든 이 평가의 기준은 가장 개선하고 싶은 거 하나를 언급하는 거였으니까

저는 그런 것들 합의가 되지 않는 거나 점검이 다시 안 되는 거 그리고 피드백을 받아들이지 않는 게 사실 너무 계속 반복됐었거든요 근데 그게 똑같이 반복됐던 게 또 그 IP 할 때, 테니도 GPS 그 얘기를 아까 설명을 했었는데 그 GPS에 문제가 뭐였잖아요 애초에 우리는 GPS 데이터가 있지도 않은데 AI가 갑자기 남겨진 GPS를 뽑아줬으면 그 문서를 저한테 다 했다고 주기 전에 테니 선에서 끝내고 잘라내고 셀값만 있는 상황에서 가능한 거를 만들어냈어야 되는데

그걸 그냥 저한테 줬을 때가 꼭 그거 보고 그래서 사실 1, 2, 3번에 테니가 한 번에 해서 줬잖아요 그래서 그거를 하려고 1번을 딱 열었는데 이미 우리의 조건을 벗어나 있어서 그래서 제가 그때 피드백 엄청 자세하고 친절하게 페이지를 만들어서 작성을 해놨잖아요 이게 태니의 의도가 뭔지 모르겠다는 점부터 시작을 해서 왜냐면 GPS를 넣은 게 태니의 판단이었으면 이거는 당장 하는 게 아니라 GPS까지 받게 되는 케이스를 고려하는 건데 그걸로 고려해서 만든 거죠 근데 그랬으면

GPS가 없으면 안 된다는 결론이 아니었을 거고 근데 GPS가 잘못 들어간 거였으면 그걸 빼서 수정한 결과를 줘야 되니까 이 1, 2년 중에 컨택해서 수정을 해달라고 이러고 이번에 돌아온 국회는 '아 근데 GPS가 없으면 안 되는 거예요'가 끝이었거든요 그래서 제가 다시 '그러니까 이러이런 방식으로 보정이 어떻게 될지' 이런 의견을 주면 좋겠다 였는데 그 상황에서 이제 그때는 '아 근데 이제 이 교통수단 판별이 그렇게는 안 될 것 같다' 하고 또 끝이었거든요 그래서 뭔가 이전과 똑같은 방향

어떤 과제가 주어졌고 그 과제 근데 목적이 그거였잖아요 사실 맨 처음에 목적은 이 IP 기술을 기반으로 한 특허를 하나 낼 수 있으면 좋겠다였잖아요 그래서 그거를 이 법률 자문과 관계가 있을 때 빨리 무료로 자문을 받고 싶다였는데 텐이가 아 근데 뭘 해야 될지 모르겠다 그런 아이고서 만들어서 너무 어려운 일이다 라고 해서 제가 그럼 제가 이미 그때 법률사문 그분이랑 그날 얘기한 논의된 것도 있으니까 그 세 개를 먼저 그럼 한번 해봐달라 이 중에 되는 게 있어요 해봐달라였어

근데 그러면 이 세 개를 해봐달라가 사실 핵심 문제가 아니라 이미 목적성이 전달되어 있잖아요 우리는 법률사문을 받아서 어떤 기술을 특허를 낼 기회를 만든다면 이 세 개가 다 안 됐으면 태니에 대한 GPS가 있어야 되네요 없네요 끝이 아니라 진짜 아 그럼 알고리즘 다른 걸 뭘 만들어 볼 수 있지? 아니면 이 만든다는 게 그때도 그 표현의 해석 차이 때문 테니가 그건 천문학자라는 거여서 제가 그 뜻이 아니라 3 더하기 1이 4인 걸 아니까 쓰자는 것처럼 어쨌든 그런 거였잖아요 사실은 그런 식으로 기존에 있는 어떤 연구 논문이라든지

알고리즘을 도입해서 우리에게 무슨 기능이 될 수 있는지를 찾아달라였는데 사실 그게 그냥 쭉 사라져서 근데 그 이후에 사실 또 우선 과제가 되는 리팩터링들이 생겨서 굳이 푸시는 안 했던 거거든요. 근데 그때도 똑같은 마음이었어요. 아 그냥 포기! 그게 사실 크긴 했어요. 그래서 아직도 그 법률 자문에 예산이 남아있는 상황이고 근데 그거는 뭐 나중에 언제라도 막바지에 다급하게라도 다른 종류의 자문을 쓸 수 있으니까. 어쨌든 그런 식으로 하고 그게 또 반복된 거라고

반복의 시 하나가 신규 유행 아이디어 저 때 ESG를 가져왔는데 사실 그때 가져온 게 ESG 사업 아이디어가 아니라 그냥 ESG 약간 뭐랄까? ESG 인증이라는 시스템이 있다의 수준이었거든요 그래서 제가 막 후속 질문으로 '어? 그러면 ESG를 어떤 산업에 적용하는 거 생각하는 거냐' ESG를 뭐라고 소문을 했을 때 사실 그 전체 문서를 이해하고 우리에게 제안하고 있다는 느낌이 아니었어요 그냥 이게 조사된 게 이런 거고 조사된 거 이런 거 봐 볼게요.

의 느낌이었어요. 왜냐하면 그 후속 질문에 대해서 또 답을 하지 못했고 그 자료에 대한 요약이 없는 것 테니 말대로 다 설명을 해줘야 내가 어느 정도 조사인지 알 수 있기 때문에 그렇다고 할 수 있는데 그럼 내가 이 조사는 어떻게 해서 어떤 걸로 알고 싶어? 왜냐하면 여기 다 들어왔다는 거. 이 조사는 내용을 통해서 어떤 BM을 생각하고 있으니까 가져왔다 했는데 사실 BM은 없고, 근데 결론이'규모에서는 뭔가 안 될 것 같아요' 약간 그런 거였거든요. 그래서 제가 항상 말하는 게'어, 안 될 것 같아요' 해서 끝내지 말고

그 근거를 확실하게 하거나, 왜냐면 그 근거가 있으면 그 근거만 해결하면 할 수 있는 일이 되는 거잖아요. 되거나 아니면 제 다른 대안을 가져다 달라고 했는데 모든 업무에서 계속 반복해서 안되고 있어서 그거를 저는 썼어요. 구체적인 사례는 크게 이렇게 세 개입니다. 그리고 그거를 또 자주 반복해서 그래서 얘기했던 게 노션 봐달라고 하면서 그냥 내가 학습한 거 올려놓은 그런 자료 말고 팀에게 전달되는 요약본 같은 것들. 제가 사업 개설 쓰기 전에 요약해서 만들어 놓은 거 전페이지 같은 식이던.

아니면 정말 그냥 DRI 회의록 안에 이 아젠다가 우리 오늘 이거 논의할 거고 그래서 그중에 고민해야 될 건 이거. 해야 될 건 이거. 이런 게 정리되기를 바란다. 라고 했던 거. 근데 그게 사실 계속 안 됐거든요. 이건 다 공통의 그거긴 한데 그거를 써놨습니다. 저는 이것만 써먹게

바로 답변이나 아니면 다 듣고 가나요? 아니요. 다른 답변이나 다 듣고 저는 연희꺼 안에 포함된 것 같긴 한데 저는 사실 개발 쪽은 적점이 없어서 잘 모르고 저도 데스크 리서치나 이런 부분에 대해서 중점으로 적었는데 저는 사실 노션에 적을 때 최대한

핵심 위주로 적고 간략하게 적으려고 하거든요 왜냐면 저도 글 읽는 걸 별로 안 좋아해서 이제 딱 봤을 때 그냥 아 이런 내용이구나 이렇게 넘어갈 수 있을 수 있을 수 있게 하려고 저도 노력하는 편인데 이제 뭔가 태니의 데스크 리서치 서류 같은 노션 페이지를 보면 이제 되게 양이 많아서 일단 약간 처음에 이제 양에 어? 조금 놀라고? 이제 슬슬 이렇게 보면

아 그렇구나 이제 이해는 되지만 약간 AI 말투가 있어서 조금 읽기가 어려웠다 그래서 조금 전달력이 떨어져서 이걸 바로 뭔가 어디 문서대로 활용을 한다거나 발표 장표에 들어간다거나 바로바로 이렇게 쓰기에는 좀 활용도가 떨어지지 않았나 이렇게 적어였습니다 1번 망인가요?

네? 저 이상한 명확하게 안 좋은 거 같은데 그 1, 3번 평가 근거 밑사래 이거 말하면 될 것 같은데 음.. 저는 좀.. 상황을 그렇게 구체적으로는 안 쓰는.. 아니면 이 결반물의 검증과 업무 완결성에 대해서? 그냥 뭐의 생각을 말해보니까 아 네 일단은.. 얘기 들으면서 생각했는데 뭐 ESG 그때도 저도 비슷한 생각을 했던 것 같고

그냥 종합적으로 좀 더 DEPTH를 들어갈 수 있음에도 뭔가 결론을 빨리 짓는 것 같다는 생각을 한 것 같아요 뭔가 음... 네 뭐 PCI라고 하면은 PCI가 어려운 거는 맞는데

PCI가 사실 PCI 값이 어떤 것부터 시작해서 뭔가 김지영 교수님이 PCI를 한번 알아보라 한 의도는 PCI가 뭔지 그것만으로 뭔가 위치를 알기보다는 그 값이랑 또 어떤 데이터랑 연관을 지어서 유의미한 값을 만들어 낼 수 있어서 그거를 제시했지 않았을까 라는 생각이 저는 초에 검색해봤거든요.

PCI를. 그러면 이제 그 막 주파수나 여러 값을 통해서 뭔가 쓸 범위인가? 뭐 알 수 있는 뭐 그런 방법이 있긴 있더라고요. 저도 깊게는 안 들어가 봤는데 그래서 뭔가 조금 더 리서치에 데프스를 들어갔으면 좀 더 좋은 자료까지 확인할 수 있었지 않았을까 라는 생각을 조금 결과물을 해서 생각을 한 것 같아요.

일단 각자 한 줄씩만 이렇게 써먹을게요 감사합니다 일본에 대해서 된 얘기죠 일단은 AI를 활용할 때 AI 활용할 때

깊게 판단한다거나 하는 부분에서는 좀 문제가 있구나를 깨달았고 사업계획서 같은 경우에도 제가 예산안을 짜면서 연희랑 되게 많이 계속 피드백이 빨리 안 왔다는 것도 지금에서야 조금 늦게 지는 것 같아서 그때는 그냥 시간이 지나니까 까먹었던 것 같아요.

그때도 저는 예산을 짜면서 너무 파악이 안 되고 제가 처음에는 제 상황을 설명을 하자면 예산을 짰을 때 인건비를 너무 많이 쓰면 사람들이 봤을 때 그냥 이거 돈 주려고 하는 거다라고 인식하기 때문에 그걸 100%씩 주는 게 아니라 일정 부분만 줘야 되고 나머지는 사무실을 대회한다거나 홍고비로 쓴다거나 이런 거를 제가 공부를 했어요. 그렇게 해서 그러면 100%씩 주는 게 아니라

그냥 일정 부분만 받는다고 생각하고 해야 되겠구나라는 게 생각이 바뀌어서 아마 처음에 그렇게 예상을 들었던 것 같고 그때 언니가 일단 인건비를 다 가득 채워서 메꿔라고 했을 때도 '그런데 이렇게 가득 메꿔면 안 될 것 같은데' 해서 제가 지금 기억하는 바람은 프론트테크에서 몇 퍼센트씩 더 떨어뜨려줘, 더 떨어뜨려줘 하면서 음... 거기에서 계속 뭔가 숫자도 계산이 안 맞거나 아니면은 하면서 그런 오차가 있었던 게 아닐까 지금 생각해보니까 좀 그런 것 같고

그러니까 제가 공부했을 때는 예산안 이렇게 인건비를 많이 쓰면 안 되겠구나 라고 생각을 했던 게 너무 컸나봐요. 그렇게 하고 나서 그런 생각. 그러면 애초에 직업만 한 명 두고 두 명 매주로 해서 빼라. 인건비를 줄이는 걸 할 거면 이렇게 해라. 맞아요. 그거를 안 한 이유는? 그렇게 했지 않아요? 제가? 그렇게 안하고 최저임금이 안 되는 돈으로 받았어요. 그래서 그때 제가 생각한 거는 이 100%의 기준은 사업비가 만약에 2억이면 2억에 100%를 채우지 마라 아니면 80%를 채우지 마라인데

이 프롬버트를 이 아이가 잘못을 이해해서 저에게 인금 500을 맨 처음에 책정이 되어 있었어요. 100%를 채우지 마라를 500에서 500을 100%로 돈을 줄이나? 그래서 자꾸 최저임금에 안 맞는 돈이 제시되나 싶었거든요. 왜냐면 저는 명확하게 최저임금이 안 적힌 거는 문서에 낼 수가 없으니까 범죄를 서술했다는 거를 제안할 수는 없잖아요. 정부 사업에. 그래서 빼달라고 했는데도 계속 들어오길래 이거는 태니가 점검을 안 하거나 애초에 A하게 요청을 안 바꿨거나

근데 어쨌든 둘 다 문제긴 하잖아요? 점검을 안 하고 준다 한 가지 그래서 그게 문제였거든요 근데 어쨌든 그때 태니가 그렇게 했던 거는 어떤 특정 하나의 기준에 너무 꽂혀 있어서 그거를 가장 큰 닷으로 가서 그런 거였다 인거네요? 네 ESG 같은 경우는 약간 계속 그냥 변명은 아니고 그때 상황이 이랬다라고 지금 제가 기억을 못 하고 있었으니까

너무 BM 모델을 급하게 만들다 보니까 제가 비슷한 솔루션이나 이런 걸 안 찾아보고 '아 ESG가 아직도 그냥 캑스트로 현장조사를 하고 있네?' '그럼 이거를 그냥 DX로 전환하면 되겠다'라고 너무 가볍게 접근해서 '아 그냥 이런 거 있을 것 같다' 그래서 이런 현장조사도 있고 삼성이나 LG 대기업에서 이렇게 밑에 있는 기업들한테 ESG 경영 때문에 체크리스트를 많이 하는데 그게 다 텍스트더라

까지만 하고 저도 아마 그냥 어? 그럼 이거 괜찮다 라고 했을 때 조금 더 빌드업 되기를 제가 미룬 거겠죠 이런 아이디어가 있더라 이런 아이템이 있더라 까지만 가져갔던 거 같고 그러고 나서 이제 연희가 더 가져와봐 라고 했을 때 찾아보니까 이미 너무 잘 되어 있는 솔루션이 있었고 거기서 저도 그냥 제가 그냥 맘도로 판단한 것도 있는 것 같아요 이렇게 이미 다 잘 되어 있는데 우리가 이걸 문제인식을 제대로 하지 못했던 것 같다

이런 게 크다 보니까 그때 뭐 막 또 BM을 막 새로 안 할 수도 있었던 시기인가? 아무튼 그때 그래서 그냥'이것도 안 될 것 같아요' 이렇게 하면서 제가 다 잤던 기억이 있으니까 그런 부분에 있어서는 저도 개선을 해야 될 것 같고 그리고 누가 말했던 그 주파손은 저도 학습을 한 부분인데 그게 사용자 핸드폰에서 주파수가 나오는 거고 문자에서 나올 수가 없어서 제가 안 될 거라고 생각해서

노락시킨 부분이여가지고 음.. 그 부분은 그래도 그런 부분에 대해서 설명을 못한 건 제가 좀 더 많이 해야 되지 않을까 네. 또 저 안 한 말인가요? 근데 거기 개선 방안을 스스로 찾을 수 있나요? 들어보니까 문제인 것 같다, 이잖아요 사실. 스스로 개선 방안을 찾을 수 있는. 일단 AI를 활용하고도 그거를 그냥 그대로 붙이고 했던 부분을 확실하게 그냥 안 해야 되겠다는 걸 인지했고.

그럼 기존의 문제는 일단 프로브즈 주고 나면 결과는 그냥 믿고 가져왔던 게 문제인 건가요? 믿고, 지금 막 그랬느냐 안 했냐고 물어보면 사실 정확히 기억이 나지가 않으니까 왜냐면 이제는 이렇게 한다 라는 행동을 정해야 되기 때문에 구체적으로 내가 어느 시점에서 내가 이 문제를 만들었는지가 판단이 되는지 안 된다면 저희가 원하는 개선사항을 그대로 수행을 해야 되는 거라서 여쭤봅니다 지금 개성방법이 적극돌나요?

아직 안 있어요. 그러니까 저희가 언급한 이 문제들에 대해서 아 문제라고 하네? 근데 이 사람들 문제라고 시작하는 이거에 대해서 왜 생겼는지 원인을 스스로 찾을 수 있는지 왜냐면 그걸 알면 본인이 그냥 개성방법을 제안하면 되는데 앞에서 이렇게 한 것처럼 제가 근데 이 부분은 DRI 할 때 제가 먼저 목적이랑 날짜만 주고 중간중간 개입을 안 하면 지금 컴플레인이 해결될 것 같은 것들을 그렇게 제안을 할 수 있는 상황이 뭔지

아니면 그냥 들어보니까 그 상황이 문제였다고 하는 문제인가 봐의 상황이라서 그 나머지 그 이후의 구체적인 후속 조치도 팀원들의 의견에 더 필요한 건지 아니요 이거는 제가 그냥 저 사람 데스크 리서치를 할 때 너무 무방비한 AI 활용 같은 부분을 좀 자제를 해야 되고 그런 부분에서 정리를 하고 정제해서 공유해야 되는 거는 제가 개선을, 그거 먼저 개선해야 되잖아요.

액션 플랜이 있는 어떤 목적을 위해서 예시의 테스트가 있으면 그 예시의 테스트는 아니라 목적 달성을 위한 대안을 제시해서 문서화해온다 이렇게 액션 플랜이 나와야 돼가지고 그 AI의 의존성을 떨어뜨릴 수 있는 플랜 같은 게 있긴 할 것 같거든요 근데 일단 그러면서 제가 제일 공감했던 거는 태니의 문서를 읽으면 AI가 말한 게 느껴져요. 근데 그거를 우리한테 설명할 때도'어? 잠깐만요' 이게 좀 많거든요 사실.

근데 저희는 사실 준비팀 얼굴 보고도 안 하니까. 근데 이 과제를 태니가 너무 일찌감치 해놔서 기억을 못하는 거니까. 근데 그것도 문제라고 생각할게요. 회의 전에 아신담을 분명하면서 불구하고 확인을 안 하고 오는 거니까. 회의 준비를 안 하고 오는 거니까. 근데 그걸 떠면서 이미 그 정리된 순서가 AI 게임에 의존이 돼 있으니까 우리를 설득하기도 힘들다고 느껴지거든요 왜냐면 그때 사실 BM 하고 나서도 분명히 BM 생각이 없다 그랬는데 갑자기 제가 가져온 아이디는 이것만 괜찮겠다라고 해요 근데 저는 그게 제가 그거를 영업해서 팔기 위해서 그 문서를 다 구조화해놓고 그 근거를 다 붙여놨기 때문에 그냥 혹하는 거라고 생각해요

그래서 명확하게 이 아이디어가 어느 점이 좋은지랑 이 시장이 어디가 매력있다고 느끼는지 설명 못하면 안하겠다 안하고 싶다고 제가 그냥 중단했잖아요 근데 그 회의 준비한다는 거는 그리고 내 의견을 주장한다는 거는 구구절절 다 해서 이 사람들 이해할 때까지 끝없이 말해줘야지 보다는 내가 스스로 내 주장을 약간 구조화하고 근거를 정리해오는 걸 해야 된다고 생각하거든요. 그래서 AI 인도성을 떨어뜨리겠다 라는 말 말고 뭔가 액션 플랜이 나와야 점검을 찾을 수 있을 것 같아요. 그리고 지금 사실 아까 그 태인이 제안한 계산점 그 부분

뭔가... 나중에 액션 플래너로 만들 때 좀 더 부착을 하긴 해야 되겠다 우선순위 정해서 몇 가지만 남기겠지만 정리하긴 해야 되겠다 그럼 어쨌든 우선순위를 모으긴 해야 되니까 다음 거를 하고 싹 다 듣고 개선안을 고를까요? 하나씩만 들어놓고 고르지 말고 좋아요 기술판단? 네 이것도 자주 연결되는 거 외화연금이 있긴 한데 저는 완전 동일한 거예요

아 여기 근거로 드는 거? 기술판단은 다른 게 있으면 다 소개하는 걸로 잠시만. 그러면 이게 '어제도 내가 기술 판단한 거를 설명할 수 있고 책임질 수 있다'에 대한 거에 의견 차의 간격이 지금 큰 거거든요. 이렇게 들어가요. 탈퇴판이니까.

2시 돌봐 6번 4시에 잘 거니까 잘 수 있을까 6번에 대한 답으로 하면 되겠습니다 근데 진짜 상황 가서 나머지 아센터를 넘기는지 해야 되겠다 IP는 생각해도 문제없을 거 같고 사실 저희끼리 이미 하게 되는 게 대부분이라고 그러면 1시간 더 붙여서 한번 좋아볼게요 6번 근데 여기에 태니는 작성이 없어요. 그래서 일단 팀원들의 의견만. 저 이거 아까 그 팀 과제에서 예시를 봤던 거에 무랑 태니 하나씩 예지들면서 태니한테 예시를 들었었던 거 같은데 저는 그겁니다.

아 근데 경채로 봐야 되나 이것을? 기술판단 근데 이 부분도 기술판단이라고 생각하고 저는 얘기를 할게요 아까 말했던 OCR에 어느 방향으로 이걸 고동하고 뭘 먼저 개발할 거냐 이것도 어쨌든 기술판단이잖아요 우리가 어떤 기술강점을 먼저 구축을 하느냐에 있어서 이게 사용자랑 사업적인 요구보다 개인판단에 근거하는 일이 반복됨.

이거 사회가 아까 큰 거에요. 왜냐면 사용자의 선에서도 형사님들이 이거 다른 자료받은 것도 넣을 수 있으니까 확인을 했지만 근데 그것보다 어쨌든 우선순위 되는 거는 휴대폰으로 찍어 다녀야 되는 문제를 해결하고 싶다. 서류 다 다른 모양으로 오는 거 폰에 넣고 싶다 해서 그거를 먼저 우선 과제를 하고 있었잖아요. 근데 그게 완성이 안 됐는데 그 다른 부분을 개선하는 그런 것들에 대해서 그 순서로 병행하는 건 상관없지만

어쨌든 기존에 OCR을 완성해야 된다라는 요구를 계속 했는데 그게 완성이 안 된 상태에서 그 다른 거를 계속 아 근데 나는 이거 개발하고 싶다. 나는 이거 개발하고 싶다. 이걸 항상 고려하고 있다가 계속 반복해서 제안이 됐어서 우선 수행해야 될 과제를 일정내에 완수하지 못한 것 QA 결과 대응하는 거나 후속 테스트하기로 한 것들이 사실 지금도 분류된 것들이 있잖아요 그게 근데 지금 아 테스트 안해서 공유가 안 되는 건지 테스트를 다 했는데 그 테스트 결과에 따라서 수정하기 위해서 지금

그런 단계인데 공유가 안 되는 것이조차 어디까지 와인에서 조차 공유가 안 되어 있는 것들 그거를 저는 문제를 썼어요. 반면에 근데 앱이나 개발 고도화에 앞서서 계획하는 단계에서는 예상되는 문제 같은 것들을 파악해서 그거를 근거로 설득하고자 함. 그래서 태니가 강점이라고 꼽은 거랑 비슷하긴 해요. 리스크를 예상하는 것들에 대해서는 잘 설명해주는데 당장 수행에 대한 테스트의 우선순위를 정하거나 하는 것에 대한 근거는

뭔가 실제 사업요고나 사용자요고보다 내가 우선순위를 두고 싶은 것을 계속 설득하는 그런 것들이 있다고 썼습니다 주니가 하나만 썼어요. 입체판 통틀어서 -뭐 얘기도 들을까요? -저요?

-노을 안 가고 저러 갔나요? -노을 똑같은 거 아니에요? -똑같아요? -집 좀! 오케이. 일단 678이죠. '뇌 상황에 대한 리스트나 제한적인 부분에 의견을 잘 준다고 생각을 함' -정도 맞춰면 되게 취해졌다. -하지만 다소 방어적인 부분이 있다고 생각하면. 근데 뭐 이거는 예시이긴 한데 저희 그냥 이거는 개발에서 카메라 뷰 예전에 지금 많이 바뀌었는데 중간에

그.. 간단한거긴 한데 그 카메라뷰의 상하단이 잘려가지고 근데 그 문제를 제가 생각하기에는 이렇게 하면 될 것 같아서 그 없앨 수 있다고 판단했는데 이제 어 이거는 비전킷이라서 안된다 라고 얘기를 했고 근데 이제 제가 그 코드를 해봤을때는 대가지고 그런 사례를 보고 조금 제가 느끼기에는 시도해볼 수 있는데 조금 방어적으로 얘기를 한다고 느꼈던 것 같습니다

그리고 뭐 7번이 릴리즈 그런건데 에러 같은 경우에 인프라 구축하고 코드에 잘 반영할 수 있는 기반을 만들어줬다 생각함 그리고 이거는 빈번하지 않다고 생각하거든요 근데 이제 PR, 코드에 대한 설명을 올렸을 때 가끔 이제 PR에 있는 설명이랑 코드랑 바뀐 경우가 드물게 있었어요

근데 그 부분을 제가 인지한 순간부터 제가 그거를 더 꼼꼼하게 봐야 되는 그런 일들이 저한테는 또 다른 태스크로 이어지는 현상이 있어가지고 네 이 부분을 적었습니다 초반 일 얘기했던 거 아니에요? 초반인가? 네?

네. 네. 아 뭐 그 사례도 있고 그 이후에도 제가 그 이후에는 제가 그냥 소극적인 대응을 했거든요. 이건 뭐 제자로시이긴 하지만. 네. 근데 막 치명적인 건 아니어서 뭐 넘어간 거긴 한데. 코멘트에는 늘 달았었거든요. 만약에 코드랑 코드베이스랑 실제 코멘트 qpr 설명이 다를 경우에. 근데 별다른 피드백이 없이 넘어간 적이 있어가지고

그래서 그 부분을 적었습니다. 카메라 개선 가능한 기능이라고 표현할게요 김용민에게는 좀 서성도 없긴 한데.. 일단 무의 거는 뭔가 이..

근데 결과 완결성이 약간 붙어있는 것 같았는데 그 완결했다고 하는 거에 대한 신뢰성이 살짝 떨어지니까 그게 결국에는 그거를 한 번 확인하는 데서 어쨌든 새로운 그 어쨌든 업무로드가 걸리는 거 까지 연결되는 것 같고 저한테는 제가 말했던 그 사실은 그냥 우선순위를 팀 다 같은 회의가 결정된 우선순위를 그대로 따라서 내가 정확하게 주장하고 같은 기능이 있으면 새로운 근거를 마련해와서 설득력을 갖추고 주장하기를 해주면 될 것 같긴 하거든요

근데 앞서서 얘기했던 것들에 비해서 엄청 우선순위 높게 이거를 먼저 개선하자까지는 아닌 것 같긴 한데 그래서 일단 제 부분은 그런 것 같아요. 굳이 우선 개선 과제로까지. 근데 이 우선 과제로 안 넣는다는 거는 개선 안 해도 된다가 아니라 4주 동안 지켜보는 그 기준에만 안 넣는다는 거지 개선을 해야 되는 걸로. 해야 된다

태현이 의견을 해주시죠 동의인가요? 동행하는 게 있거나, 의견이 있거나, 아까 배경 설명해준 것처럼 뭔가 맨날 빠진 게 있거나 하면 계속 이런 게 반복된다고 하면 제가 설명이나 이런 부분에서 계속 커뮤니케이션이 안 된 걸 수도 있다고 생각하는데

그... 임포트 같은 경우 인터뷰 때 그걸 물어보고 싶었던 거거든요 그냥 그거를 자료를 임포트 할 때 사진을 찍는 게 편할지 아니면 그냥 그 파일을 바로 받은 거를 넣을 수 있게 하는 게 편한지 그런 사용성에 대해서 물어보고 싶어서 아마 그 언니랑 했던 회의에 넣어놓았던 거 같아요 그게 위치적으로 받을 때 인터뷰 하고 싶다는 문제인 게 아니라 그 인포트 엑스포트는 이 시점 이후에 개발하자고 사실 이미 결정을 했잖아요

근데 그거를 제가 지금 이 OCR 리버가 왜 이 단계에 머물러 있는지 라든지 왜 EQA가 안 됐냐 했을 때 어? 나는 그 부분을 하고 싶어서 그 부분 공부하고 개발하느라고 그랬다 라는 답변이었잖아요. 그러면 근데 우성순위를 위해서 그걸 안 하는 게 맞다는 사실 그게 이미 팀 단위에서 결정이 됐는데 왜 그런지가 사실 듣고 싶긴 하거든요. 그때도 말했지만 인터뷰를 한다는 거는 좋죠. 사실 우리 때까지 했던 업무 방식에서 필수적인 과정이고

그래서 사실 인터뷰를 하자는 거에 대해서는 인터뷰할 것 같아요. 자는 아니라 그렇게 말했듯이 이런 질문을 누구에게 하고 싶어요? 구체성 있게 사실 인터뷰해야 될 것 같아요. 그래서 개발 뒤에 못해요는 그냥 사실 이팅구조가 이때까지 태니가 말한 그 원한 업무를 생각하면 연예인터뷰 해와주세요. 그래야 제가 개발이 돼요. 애 맥락으로 느껴지거든요. 그래서 그때도 설명했던 게 그렇지 않게 되려면 인터뷰를 해야 된다 라고 할 때 지금 태니가 설명해준 그때도 설명했던 이런 맥락 때문에 확인하고 싶고

그거를 누구에게 확인하자를 정리해서 제안하는 게 그게 DRI다라고 그래서 계속 DRI를 강조해서 설명을 했던 거고 왜냐하면 어쨌든 그 정보를 수집해야겠다고 판단한 건 태니잖아요. 근데 어쨌든 그걸 다 떠나서 제가 그때 요청했던 거나 질문했던 거는 OCR에서 먼저 하기로 한 테스크 과제들이 있는데 그거에 대해서 테니가 인포트 엑스포트를 얘기했을 때는 그것 때문에 일이 밀리면 안 되는데 병행하는 건 당연히 자유죠 그렇게 해서 개별적으로 더 고도화될 기능들을

계속 고려하고 해주는 거는 너무 고마운 일이죠 팀에 근데 그것 때문에 지금 일에 업무의 로드가 생기고 완결이 안 되면 그건 문제니까 그거에 대해서 얘기하는 부분이에요. 전 실제로 이 임포트한 기능을 구현하고 있지는 않았고요. 이거는 계속 하고 있었던 거는 저희 핀 일발 개별 기능 구현하는 거? 그걸 하고 있었고 아마 행후 계획이라고 적어놔서 했던 거지. 실제 이거를 작업하고 있지는 않았어요. 그러면은 약간 그.. 지금 OCR에 대해서 얘기할 때 어쨌든 이유 중에 하나로 그게 언급이 됐으니까

그럼 어쨌든 그것 때문에 업로드만 실제로 생겼던 건 아닌 거네요? 네 뭐 작업을 하거나 하진 않았어요. 그래서 이거는 안 했다고 설명을 드리고 싶고 계속하고 있었던 것은 주소 추출하는 개선방향을 이렇게 고쳐보고 있고 저렇게 고쳐보고 있다는 걸 조금 얘기하고 테스트 현황 같은 경우에도 임포트나 이런 작업이 아니라 그냥 진짜 좀 잘못된 주소 같은 거를 어떻게 잘 뽑아낼 수 있는지 뭐뭐 동으로만 끝나는 거를 그 앞에 있는 구나

그 앞에 있는 지역 같은 걸 어떻게 뽑을 수 있는지를 계속 작업을 하고 있었거든요. 그럼 지금의 문제는 업무가 밀리는 게 아니라 해야 될 테스크를 제대로 하고 있는데 안 된 것만이 문제인 거네요? 이 부분이 지금 사실 저도 빨리 받아들이고 싶은데 이걸 제가 작업을 하거나 해서 다른 걸 못 해요라고 딴 적이 없죠. 그치. 언급이 정확히 있구나. 우선순위 중요도가 파악되지 않아서 우리가 먼저 해야 되는 과제를 얘기하는 회의에서도

나는 근데 인포트 엑스포트를 생각하고 있다 이런 거를 반복 언급하잖아요. 그래서 그거는 지금 우선순위가 아니다라는 거를 계속하고 근데 금방도 그 얘기를 하는데 근데 실제로 개발한 건 아니니까 근데 제 말은 우선순위가 이미 있게 있고 이 과제에 집중해서 해야 되는데 어 왜 이거 해결이 안 되고 하면 되는 어 근데 나중에 이거 될 거를 고려해서 이렇게 되고 있다 가 되거든요. 근데 그게 태인이는 사실 그것 때문에 러드 전혀 걸리지 않았고 이거 수행 잘하고 있는데 그냥 제가 진행되고 있다는 사실을 파악하지 못한다는 뜻인 건지 지금 태인이안이의 말이

아니면 다른 뭔가 원인이 있는데 그냥 그걸 모르고 제가 저것 때문에 문제라고 하는 것 같다 라는 의견인 건지가 -끝- 사실 기반을 얘기하면 제가 주어진 작업을 계속 하고 있었고 그 계획에 나중에는 이런 걸 하면 좋지 않을까를 적었는데

그게 아마 또 번복이 돼서 제가 해보고 싶다 또는 제가 생각했을 때 형사님들이 이렇게 하면 더 잘 쓸 것 같다를 언급했던 것 같고 그때 그래서 아마 연희가 인터뷰를 해서 원하는 바가 뭐냐고 했을 때 제가 아마 팀원들도 이거를 조금 알아줬으면 좋겠다는 그런 얘기를 했던 것 같거든요. 회의할 때 대화해서. 그러니까 형사님들이 할 때 사진을 찍는 것보다 파일이 더 쉽게 된다. 근데 그게 인터뷰에 약간 근거로 남았으면 좋겠으니까 인터뷰를 할 때 이거 좀 들어왔으면 좋겠다였던 것 같고.

이거를 실제로 작업을 한다고 해서 작업을 한 적은 없기 때문에 이건 작업한 적이 없다고 얘기를 하고 싶어요 그래서 그것 때문에 우선순위가 바뀌거나 하지는 않았어서 작업 순서의 개념은 아니라 중요도를 주는 순위 그래도 중요하게 생각하는 건 아닐까? 지금 테스트를 해서 중요하고 있다? 인터뷰에 여러 가지 질문 중에 하나로 넣고 싶다? 약간 이 정도였던 것 같아가지고 감사합니다.

근데 일단은 뭔가.. 저도 이 지금 상황 어떻게 판단될지 모르겠어서 일단은 넘어갈게요. 어쨌든 제 생각에는 다른 문제에 비해서 이게 그렇게 우선순위 되는 건 아니라서 뭔가 더 사례를 얘기하는 것보다 우회 부분에 대해서 얘기 이어서 해주세요. 리스크를 다소 변화적으로 보는 것 같다랑 실제 개선되어 있는 문제인데 그게 담당자 선에서 안 돼서 계속 상호 확인해야 되는 것들?

일단은 방어적으로 하는 거는 좀 저도 공감하고 전약사항 같은 거 안에서 뭔가를 하고 싶다가 좀 큰 사람인 게 그냥 제 스스로 좀 인지가 돼서 그런 부분은 정말 굉장히 인정하는 바이고 저 카메라 위아래 잘리는 부분은 지금 설명을 조금만 더 해주시겠어요? 아 근데 너무 사소한거에요. PR 찾아야 될 것 같긴 한데 그 세이프 영역 그거 자동으로 먹는거 그거를 이제 그때 비전이 아마 비전킷 바꾸고

첫 PR이었을거에요. 그래서 제가 근데 이거 그 화면이 달라졌는데 위아래는 그 없앨 수 있지 않나요? 카메라뷰는 원래 화면에 꽉 찼으니까 그거라도 유지를 하는게 낫지 않네 뭐 이런치고 코멘트를 달았는데 이제 그거에 달긴 코멘트는 이제 이거 비전킷을 써가지고 여기서 비전킷 안에서 하는 거여가지고 이거는 바꿀 수 없다

라는 코멘트가 달렸었고 근데 이제 거기서 이제 제가 어 이거 될 텐데 하고 이제 해봤는데 돼가지고 이거 코드 몇 번째 라인에 이거 추가하시면 돼요 라고 한 적이 있었거든요 그럼 추가가 되게 해결된 게 지금 버전인가 그래서 딱 비전킷으로 했지만 화면이 꽉 찬 음 혹시 몇 번은 PR?

23번... 샵 23번... 아니 샵 49번 이때 말씀해주셔서 반영한 거는 확인했습니다.

근데 어쨌든 맥락은 반영을 안 해줬다가 아니라 안된다는 판단에서 업무가 종결될 뻔했는데 그걸 찾았고 그런 사례를 경험하고 나니까 이제 어쨌든 근데 그거를 사실 저랑 부호가 감수할 수 있는 게 아니라 둘이서만 공수가 가능한 부분이라서 그게 어쨌든 업무로드에 영향을 미친다 그러니까 근데 제일 지금 느끼기에 이거의 저거는 흥이가 그 근거를 그 저 앞서 말은 내가 저장부 이만큼인데 아니래 같은 게 아니라

그 근거를 일목요연하게 정리해서 문서화를 해놓으면 점검한 거를 순서대로 태니에 그 태스크 일정마다? 말썽마다 하던지 그냥 매일매일.. 매일매일 진짜.. 그게 오늘 보는 게 좀 힘들 것 같긴 한데 그렇게 해놔야 그것만 점검했을 때 이렇게도 공정했는데 아닌가 보네를 알던지가 있을 것 같거든요. 왜냐하면 사실 저 아까 제가 고문했던 것은 지금 태니가 그 인포텍스 토트 얘기를 저희 둘이 회의할 때만 나오는 거라서 사실 노우랑 무한테는 맥락이 필요할 것 같은데

그때 그 얘기가 나온 게 그거였잖아요? 이 지금 태니랑 저랑 OCR 회의를 하게 된 이유가 태니가 태니만의 의도를 가지고 비전킷으로 바꿨는데 태니가 말했던 주소를 더 잘 읽는다 라는 그 목적을 위해서 다시 바꿨다고 했잖아요 팀 회의에서 근데 그게 주소가 제대로 안 읽히는 게 있으니까 그 테스트가 어떻게 진행되냐는 걸 확인하는 과정에서 근데 그런 부분들이 조금 있긴 해도 어쨌든 태니 판단에서는 더 주소 인식 잘 되는 게 맞다였고 플러스로 근데 나는 인포트 엑스포트까지 생각하고 있기 때문에 그걸 하려면 비전 킷으로 바꿔야 했다 있잖아요

PDF로 만들 수가 있어 네 근데 그거를 사실 팀의 그 판단 때문에 됐다는 근거가 사실 남아있지 않고 공유가 안 됐고 근데 사실 더 큰 문제는 그거를 지정해서 강아를 띄우면서 UI가 바뀌고 UX같은 플로어가 바뀌는데 그러면 내가 바꾸고 싶어서 바꾸었으면 그거에 대해서 확실하게 설명을 해놓고 몇 가지 책임을 져야 되는데 그게 안 된 거에서 사실 온 거고 제가 그거의 과정에서 왜 10이 책임을 놓치고 있는지랑 그리고 제가 그래서 저는 이 테스트가 완료가 안 됐다고 생각한다.

라고 했을 때 태니가 나눠 완료라고 생각했는데 왜 아니냐고 했을 때 사실 그거를 상호 체크하면서 그까지 얘기가 나섰던 거잖아요. 그래서 사실 이 문제를 해결하려면 태니가 먼저 본인의 판단에 대한 근거를 충분히 설명을 하는 게 사실 가장 선제되긴 해야 될 것 같거든요. 그리고 그게 결국에는 AI 의존성을 줄어들이게 하는 거가 될 수도 있을 것 같아요 왜냐면 사실 기존에 어떤 검증 과정이 그치는지 모르겠지만

앞에서 AI 의존성이 심하고 태희가 문서화 해놓은 것조차 AI가 쓴 것 같은 기가 많이 나서 우리가 이해하기 어렵거나 쓰기 어렵다 라는 내용들도 있었고 지금도 어쨌든 검증해서 '어? 안 된다'라고 결론을 냈는데 사실은 되는 해결책이 있을 수 있다던지 그런 것들이 있으니까 사실 태인이의 검증과정을 공식화하는 게 그걸 거 같거든요 그리고 뭔가 내가 판단해야 돼서 바꿀 게 있으면 무조건 선제적으로 팀에 공유하는 거

특히 그때도 사실 말하긴 했지만 팀 회의의 그 시간과 노력을 들어서 결정한 거 그리고 노우가 시간과 노력을 들어서 제작한 거를 통째로 엎은 거잖아요 우리 팀의 그 누구도 알지 못하는 과정으로 근데 그렇게 했을 때 사실 태인이 애가 회의 때 '어? 왜 이렇게까지 바뀐?' 했을 때 이유는 하나랬어요 이게 주소 인식을 더 잘해서 근데 어쨌든 우리가 그때 당시에 가장 중요한 건 이 OCR 기능이 주소 인식 잘해서 그 주소를 시작하는 걸 연결하는 것이기 때문에

어? 그럼 개발자가 이렇게 하는 거면 다 확인이 끝날겠지 이게 베스트겠지 하고 이제 그러면 그렇게 바뀌었기 때문에 해결해야 되는 문제들이 사실 엄청 많이 따라왔잖아요 그거를 다 잘 해결해 주겠지였고 그래서 QA때도 엄청 꼼꼼하게 해서 제가 QA 없는 사례들도 넣어놓거나 QA에 대한 것도 OX가 아니라 사실 다른 것도 비교해서 다 넣어놨었잖아요 근데 그것들에 대한 요청된 테스크가 안되고 그래서 OCR이 주도인식한다 라는 테스크가 안 끝났다고 느끼는 거라고 그때 설명을

했던 건데 그거의 해결책은 사실 진짜 그냥 검증의 문서밖에 없는 것 같아요. 물론 또 그 문서를 개발 쪽에서 누가 봐야 되고 다른 부분에서는 또 팀원들이 봐야 되는 어쨌든 문제는 있겠지만 지금 보기에는 최선은 그냥 그 정도의 것 같네 당장 데스크 리서치 이런 게 없을 것 같네

근데 뭔가 개별적인 부분에서 를 할 때 뭔가 개선의 근거든지 아니면 개선할 수 없는 부분에 대한 근거가 정리가 돼야 되겠냐고. 지금 개발에서도 AI 사용이나 이런 게 걸림돌이 되고 있는 상황인가요? -저한테 오시는 분? -네.

님 밖에 없잖아. 사실 뭐 AI 개발 쓰는 거는 저는 괜찮다 생각하는데 제가 문제라고 생각하는 건 그러니까 간혹 설명과 코드가 다른 경우가 있다는 점이 제가 더 확인을 해야 되는 근데 어떻게 보면 논러가 피아를 꼼꼼히 확인해야 되는 건 당연하기도 합니다

잘못 확인해야 하는... 근데 이거로 뭔가... 액션플레이를 작동할 수 있다고... 왜냐면 그거를 AI를... 쓰지 말라고 할 수도 없고... 근데 의존성 없다는 기준이라는 게 A가 쓴 거를 사실 읽어서 검수하고 문제없으면 그 말투 그대로 썼을 때 그거를 검수했냐 안 했냐는 사실 그 누구도 판단할 수 없긴 하지 않나요? 그거를 검수했어요를 확인 기준으로서 상을 뭐가 없으니까 액션플레이를 만들기가 어렵네... 불량제한

근데 그게 무슨 뜻이야 이제 그 요약을 애가 해버리면 또 그래도 양이 적으니까 근데 확실히 저 검증 기준 같은 거를 정리해 놓는 건 필요할 것 같아요 근데 일단은 나머지도 나온 게 있겠다고 그걸로 일단 진행을 해보겠습니다 아 근데 피드백은 저는 아까 이미 설명을 해본 것 같아요 계속 같은 피드백을 했는데 다음 테스트에서 또 반복되는 거

근데 사실 이게 아까도 말했지만 여기 앞에 두 개에서 개선점을 찾으면 해서 수행하면 되는 것 같아서 편의생활 때 아까 이거에 뭔가 액션플랜을 만들만한 게 있나요?

아까 했던 그 AI 의존성이라든지 아니면 그 검증하고 내가 판단한 거에 대해서 만들기 전에 선제적으로 공유한다 같은 것들의 액션플랜 같은 거 - 음. - 아세요.

그 글쎄고 액션 플레이를 찾기 어려운 부분인가요? 아니면 이 문제는 개선해야 된다라는 생각 자체에 대한 글쎄요. 개선 상황을 어떻게 평가를 받을 수 있을까요? 액션 플레이는 내 얘기가 글쎄요. 근데 이건 사실 읽는 사람들의 입장. 인하 판단이 제일 중요한 것 같아서 근데 사실 거기에 근거가 없으면 그 피드백을 했을 때 또 이 문제가 또 반복되니까 안 받아들이면

이게 너무 연관돼 있어서 진짜 어렵네 액션 플랜저 사전이 없지? 아니 사전 중 그 근거를 기준으로 하나 근데 그 태닌의 문제에 사점을 줬었잖아요.

근데 아까 말했던 그 사점의 내용이 대한 트레이드 오프 리스크들을 비교해서 현실적인 공고안을 제시했다거든요 이렇게 제시한다를 액션 플랜으로 잡고 그거에 대한 문서를 하고 그 문서를 노우가 말한대로 팀원에게 공유할 수 있는 수준의 정리를 해서 브리프를 하는 건 어때요? 액션 플랜은? 전혀 말하면 좋지겠어 4번의 문항을 그대로 수행하는 거를 액션 플랜으로 잡는 거 대안이랑 트레이드 오프 해야 될 것, 리스크가 발생할 수 있는 것들을

그걸 내가 판단해서 일단 바꾸고 이게 최고의 선택이었어요. 그것들을 비교해서 그리고 이 프로덕트랑 이 사업의 환경을 고려한 현실적인 공관을 만들어서 이걸 만들 때 내가 어떤 거를 검색했는지를 브리프하기. 그 전체 맥락 소개가 아니라. 근데 그게 사주 안에 뭔가를 내보일 수가 있는 걸까 싶어서 그거 없이 하면 될 거 같아.

지금 척도, 사람은 사정을 준 척도밖에 없는 것 같고 아니면 태인이 사주 생각했을 때 계산할 수 있는? 사실 저게 묶여 있는 거니까 그거를 찾아 이걸 쓸 수 있을 것 같아요 저 UI 설명회 하는 것처럼 한 거 설명회 하기 그 얼굴은 전혀 없는 것 같긴 합니다.

그래요? AI랑 속도가 함께 만들더라도 정리나 전달까지 이어서 하고 후속 조치 됐는지도 확인되고 갈 것 같습니다 좋습니다 근데 태니가 대성점을 제한할 수 없으면 팀원들의 모드로 가야 될 것 같아요 네. 뭐 혹시 더 있나요?

알만 액션 플랜스인가? 좋은 것 같습니다. 두 문제, 저 복합적인 문제를 해결할 수 있을 것 같아요. 저는 근데 진짜 다 그 세 개가 이어지는 느낌이어서. 그래서 저도 결국에 앞에 소개하는 게 없어서 AI랑 사전투성이 끝났는데 그거에 대한 결론이나 구석조치가 없다 이런 거라서 이 부분을 그냥 그대로 활용할게요

이걸 해보면 그 태희가 판단하는 업무 완결성과 팀원들이 기대하는 업무 완결성의 격차를 저 브리프를 통해서 알 수 있을 것 같아요. 왜냐면 그 브리프를 들었는데도'어 근데 이 부분 검토됐나요?' 이런 것들이 많이 나오면 그만큼을 다 체크리스트 채우는 것까지 해야 내가 진짜 업무를 한 거구나 라고 파악하면 되는 거고 브리프를 했는데 정말 문제없이 계속 개발이 잘 이어져

그러면 태니는 태스크를 수행했는데 그거를 팀에 전달하고 공유하는 그 역량이 부족했던 거고 그거를 발견할 수 있을 것 같아요 저걸 해보면 좋습니다 그리고 저 의존성을 줄인다고 하는 거에 이거는 우리가 검토가 불가능하니까 여기에 작성하지 않겠지만 정말 AI가 뭔가를 받고 나면 그거를 태니의 표현으로 바꾸는 연습을 해봐야 될 것 같아요. 아니, 외치에 넣을 때도 그냥 내 말투 유지해달라고 하면 잘해주는 것 같기도 해서.

여기다가 그 4번 항목에 그거를 그대로 가져오겠습니다. 좋습니다 그리고 이렇게 멈춰서 근데 결국엔 팀원들이 보기 쉽게 정리하고 추가 질문 받는 형식 변경하려고 이거 태인이 제안한 계산안을 결국에는 브리프하고 피드백 받는 거랑 같은 거 같긴 하네 응 응

비활하게 되면 전달하고 싶은 거랑 문을 잡고 싶은 것도 정리도 하고 별도로 기록도 하고 저렇게 하면 될 것 같은데 네, 결국에는 두 개 같은 거 그런 것 같은데 내가 또 필요해서 못해도 되고 결국 공통인 것 같아요 그런 설명을 하시면 될 것 같습니다 4점 쪽도

어? 이게 아닌데? 다른걸 4점 쪽도로 아 3점을 가지고 오네 저 앞에 테니가 많은 걸 요약하면 그냥 이거 4점 맞는 거 같아 이렇게 비교해서 운영안경 고려하자 하시면 공간을 아! 응. 이 공안을

제 앞일에 베이브를 브리프한다. 그 다음 확인 기준. 디아라리 오. 디아라리. 오늘 했을 때 어... 으흠. - 기본의 이해를? - 그러면 그거 해야 될 것 같아요. 저.. 제한, 프리미엄프, 리스크, 리스크~

전달할.. 네. 뱅세이 하세요. 결정 받고 싶은 것이라고 했는데 사실 DRI는 결정을 내가 해야 되는 거고 그 논의를 하고 협의하는 과정을 그냥 운영하는 거기 때문에 논의를 결정해야 할 내용이라고 쓸게요 누가 대신해주는 게 아닙니까? 논의 결정해야 할 내용

공부가를 잠가하고, 눈이 붙잡아야 할 내용을 넘어키고 해서 본사 교통을 내렸는지, DRI, 여기 나와있음. 이렇게 할게 태니가 언급했던 항목들이랑 이 항목들이 DRR 계획에 있는지 그걸 통해서 정말 팀원들이 다 이해했고

추가질문이 해소가 됐고 맥락과 결과물들이 다 나와 있는지 그래서 지금 어쨌든 그러면 뚫린 목격은 추가질문이 되길 위해서 아 추가? 보충상은 3개예요 줄일 수 있다 이렇게 할게요 좋습니다 드디어 끝인가

한참 남았지 않나 저 근데 진짜 못할 것 같아 이거의 집중도와 퀄리티를 위해서 저 진짜 와 이게 하이라이트라는데 - 참... - 그래도 여기까지는 왔다. 저 진짜 토이... - 근데 저도 속이 좀 안 좋아질 않거든요. - 그러니까. 지금 3시예요. 지금 컷 앤 투예요. 그러면... 내일 아침에 하시죠. 그러니까. 이거를 조식 드실 거든. 조식으로? 근데 11시에 저도 체크아웃하고 나서도

저 비즈니스실 가도 되긴 하니까 근데 그 버스 시간에 안 늦게 딱 밥을 먹고 그 이후에 일단 이 IP는 사실 일단 질문이 좋은 건 없습니다 여러분에게 그러면 거기에 있는 그 원칙, 우리께 원래 합의했던 원칙은 디폴트하고 그 뒤에 논의해야 될 사항이 있잖아요 그거에서도 따로 뭔가 추가해야 되는 이견이 없으면 그냥 바로 전체 회의에서 이견 없다는 기록만 남기고 제가 그냥 문서하면 끝일 것 같아요 아무 Q&A가 없었습니다

그리고 사실 이걸 해야 되거든요 그러니까 이거를 그러니까요 제가 이거 이거를 내일 아침에 좀 맑은 정신으로 저 근데 진짜 준비해 왔어요 그래서 이거를 하고 이걸 통해서 사실 이 업무 프로세스 조율을 갈 수 있기 때문에 이거 두 개를 내일 세트로 묶어서 2시간을 할당하겠습니다. 45분 40분이요. 정말 안 될 것 같아요. 여기 혼자 45분 썰 것 같은데. 별로 생각보다 안 괜찮고. 사실 업무 토스트에 대해서 꽤 지금까지 정된게 있어서

그거 토대로 확정안을 찾아내면 되는 거라. 근데 여기에 대해서도 다들 얘기를 해야 되니까. 내일. 또. 잠깐만 그거 그거 시간이 녹음 끊어도 되나요? 아 네네 시간이 몇 시죠? 일단 체크아웃은 11시이고 근데 노후 2시 기차? 네 생각하면 1시 안에는 끝낸다는 생각을 해야 되니까 그러면 변경은 가능 변경 못 하지 않아요? 거의 지금 아 맞다 아 저기서 해야 되잖아

그거 사준 거라서 근데 사실 책값을 또 바짝 2시간을 살 수 있다는 전제지만