Feedback

feedback circuit

http://cad.kyungpook.ac.kr/micro/feedback/feedback-detail.html

Review

report, monitoring, response, communication

5F

• fact, feeling, finding, future, feedback

선순환

• 좋은 인재 - 좋은 글 - 많은 독자 - 수익 증가 - 좋은 인재

선순환

응원하는 사람과 응원받는 사람이 서로 힘을 받는다 마라톤 대회에서 음료를 나눠주는 사람들과 음료를 받으며 회복하는 사람들 서로 고마워하며 서로 행복해한다

시너지

투명성, 공유, 인터렉션

프로페셔널과 선순환

영화현장에서 배두나가 빼어난 프로페셔널한 모습을 보여주니 다른 관계자들도 프로페셔널한 부분을 끌어내려고 하는 선순환이 일어났다고 한다

2025-Archive#review of 6 months of german life

선순환

잘 되는 서비스 -> 사용자 증가 -> 데이터 증가 -> 사용성 개선 -> 잘 되는 서비스

Software Feedback

알림이 너무 많이 오면 노이즈가 되어 무시하게 된다 변경 사항에 대해 알림을 준다

한 번에 너무 많은 메시지는 피곤하다 같은 에러가 여러 번 오면 따로 표시해준다 시각적으로 한 눈에 알 수 있으면 좋겠다 에러가 발생한 곳이 어딘지 알려주면 좋겠다

배포 후 배포 상황 확인

변경 작업 후 모니터링 페이지로 가서 한 눈에 확인할 수 있으면 1차 확인은 되겠다

행동별 보는 페이지가 있으면 되겠다

grafana는 다양한 메트릭을 보여줄 수 있어서 사용하되, 한눈에 보는 페이지는 따로 관리해야겠다

• grafana에서 셋팅하는게 무난해보인다... alert 설정도 좋고, export도 잘되고

running server with auto attachment auto feedback

• running well?
• how speed?
• any problem?
• need more?

program -> feedback -> program -> feedback

• program send data to feedback
• feedback send data to program

running well: health check

how speed: test script

any problem: log

need more: receive client voice

Feedback

• 하루를 돌아보는 작업도 피드백
• 프로젝트를 회고하는 것도 피드백
• 슈팅 후 원하는 위치에 갔는지 확인하는 것도 피드백
  • 슈팅을 어떻게 했는지 모르고 감으로만 차면 감만 늘고, 기술적 성장은 안된다

피드백은 잘 진행되고 있는지 평가할 지표가 있으면 명확해진다

계획이 성공되려면 중간 중간 평가할 요소가 있어야겠다 추적할 수 있는 지표

빠른 실패

빠르게 진행해서 빨리 피드백을 받는 것 실패는 항상 찾아오니까 빨리 개선점을 찾으려고 하는 것

근데 무턱대고 하면 안되고, 그렇다고 너무 준비를 오래해도 안된다

어렵다

진행됐다고 치고, 진행이 되면 반드시 실패가 찾아온다. 피드백을 빨리 받고 고쳐서 다음 단계로 나간다. 처음 시작하는 것을 어떻게 할지가 어렵다 말을 적게 하면 좋다는 생각에서 많이 해서 고치는게 좋다는 생각으로 바꼈었는데 무작정 많이하면 안된다는 것도 새삼 깨달았다

많이 하되, 정제된 상태로 많이하는 것이 능력이겠다 +정 반 합 으로 생각을 한번 정리한 후에 말하면 되려나+ +피드백을 받을 수 있는 형태로 정제해서 진행+ 하면 무작정 뱉는 것보다 나아질 수 있겠다

feedback

피드백을 어떻게 줘야 하나...

1. 콘솔에서 아웃풋
2. 메신저로 보내기
3. 슬랙 같은 팀 채널에서 모아서 관리하기

피드백의 핵심은 즉시 알아차리게 하는 것인데 메신저는 약간의 지연이 있을 것 같다 (비동기 통신 방법이긴 하네) 동기 통신으로 보내자면 또 저장을 못하고, 그러면 개발 중에 메신저를 항상 켜놓는다는 전제로 생각해야하나 채널을 하나로만 하면 너무 많은 데이터가 쌓여서 또 곤란하겠네

개인 개발 시에는 메신저로 오게 할까 근데 메신저로 오면 업무의 연속성이 안좋을 것 같다 노트북으로 작업할 때는 노트북에서 바로 볼 수 있어야겠는데

빠른 피드백 vs 인터럽트

feedback이 인터럽션이 될 수 있다.

어느 정도가 적당한 빠른 피드백일까

약속된 시간에 주는 신호는 노이즈가 되어 무시가 될 수 있다.

search 하는 경험을 피드백을 녹여보기

1. 시작점을 찾는다 (내부에 들어가기 전에 내 생각을 먼저 확인한다)
   • 피드백을 빨리 받아서 고치는 방법을 알고 싶다
   • 피드백을 효율적으로 받는 방법을 알고 싶다
   • 과학적으로 행동에 대한 인지를 하는 방법을 알고 싶다
   • 다른 영역이 응답을 빨리하는 것에 대해 모은 지식을 알고 싶다
   • 어떤 방식으로, 어떤 주기로, 어떤 내용을 주면 좋을지 알고 싶다
2. 단어를 모은다 (측정 가능한 기준을 세워서 범위를 잡는다)
   • 피드백
     • 빠른 피드백 주는 법
     • 피드백 실험
   • 모니터링 서비스의 피드백
   • 운동에서의 피드백
   • 기계 시스템에서의 피드백
   • 빠른 피드백
   • 개발에서 빠른 실패, 애자일
   • 온라인스토어에서 고객의 불만 접수 및 응대
   • 연예인이나 컨텐츠 제작 후의 시청자 반응에 대한 응대
   • 공인이 불미스런 사건을 일으켰을 때의 조치
   • 커뮤니케이션에서의 피드백
   • 회사 메뉴얼의 축적
   • 회고
   • fail fast
   • 피드백의 종류가 다양하다. 정량적 피드백, 정성적 피드백 기계에게 하느냐, 사람에게 하느냐의 차이도 있다
     • 디자인 뉴스레터 디독
   • 제품 제작, 디자인 등 클라이언트가 있는 작업
3. 정보를 쌓는다 (인용이 많이 된 것들은 좋은 글일 확률이 높은 것 같다)
   • 커뮤니케이션에서의 피드백
     • 감정의 관리가 필요하다
     • 해결해야 할 문제나 솔루션의 불확실성이 높을 때, 리뷰의 빈도를 올린다
     • https://ridicorp.com/story/giving-honest-feedback/
   • 회사 메뉴얼의 축적
     • 개인의 노하우가 회사의 노하우가 될 수 있도록 해야한다
     • 문서가 너무 많아지면 오히려 읽지 않는다
     • 회사에서 누군가 경험한 것이라면 다시 실수가 반복되지 않도록 알려주면 좋은데, 찾지 못하면 소용이 없다
   • 피드백을 주는 것은 시스템, 사람이지만 받는 것은 사람이다
     • 시스템끼리 피드백을 처리할 수도 있지만 최종 피드백은 사람이다
   • 변경 된 사항을 적절한 시점에 알게 되는 것이 필요하다
   • 피드백 유형과 과제지속의 관계에 대한 연구
   • microsoft, google에서 피드백을 받는 도구를 만든게 있다
     • https://docs.microsoft.com/ko-kr/windows-insider/developers/tools
   • 운동에서의 피드백
     • http://kocw.xcache.kinxcdn.com/KOCW/document/2018/seowon/yoonwanyoung201/9.pdf
     • 운동학습
4. 정리한다
5. 검증한다

• 검색 범위가 넓으니까 지친다. 작게 작게 찾아지도록 해야겠다
• 피드백이라는게 넓은 의미를 가져서 다양한 영역에서 추상적으로 설명하고, 자기계발서 같은 곳에 뻔한 글들이 많아서 걸러내면서 찾기가 힘들다
• 피드백이 좋다는 것이나, 방법론 적인 추상적인 이야기가 많다
• 피드백이 중요하다는 것은 사람들이 알고 있으나, 정보 공유는 많이 하지 않는 영역이라 피드백이라는 단어보다 우회적인 단어를 찾아야한다.
• 이렇게 한 영역에 대해서 찾는 것을 하다보니 학술 공부하는 것과 비슷한 느낌이다. Roam Research에서 봤던 노트 구조로 작성하면 효과적일까
• 정보의 출처에서 연결된 정보가 또 나온다

feedback

• 머신러닝에서의 피드백
• 학기마다 보는 시험도 피드백
• 하루를 되돌아보는것도 좋은 피드백이다

상용서비스라면 유저들이 활동하는 영역에서 사용 경험이 산발적으로 나올 수 있다 이런 피드백도 잘 수집하면 좋긴 하겠다

it 기기 관련 리뷰는 그런 제품들을 사용하는 사람들이 많이 모인 커뮤니티에 주로 올라온다 물론 예상치 못한 곳에서도 올라온다

원하는 자료가 한 곳에만 올라오는 일은 거의 없다 그랬다면 자료 찾기도 훨씬 수월했겠지

그러면 흩어진 자료를 찾는 방법이 피드백을 찾는법과 비슷하겠다

기계의 고장률이 제로가 되지 않는다 기술이 많이 발전했지만 예상치 못한 문제가 생긴다

모니터링도 카오스 테스트도 예상 못한 지점을 찾으려고 한다 근데 경험을 통해 개선하는 것이 최선인 것 같다

로켓펀치 같은 채용사이트에 새로 등록되는 채용안내문은 많은 양이 아니라서 적당히 모아서 구직자에게 알림을 보내도 방해가 되지 않는다 이 알림의 적당량은 어느정도일까

채널을 맞추고 통신하면 소통이 확실해질 수 있다

사람과 사람 사이에서 피드백은 강한 피드백 등 안좋은 영향을 조심해야한다

복잡성과 피드백

각 서비스에서 피드백이 복잡성을 푸는 키다

복잡성은 복잡하지 않은 것들이 많이 동시에 일어날 때 생기는데

각 서비스에서 피드백을 어떻게 주느냐를 잘 설정하면 로그, 데이터 결합, 복잡성 해소가 해결되는 실마리가 될 수 있다

feedback 회로

인풋 아웃풋 아웃풋을 통해 인풋을 조절해서 원하는 아웃풋으로 유지하도록 한다. 인풋을 뭘로하고 아웃풋을 뭘로 해야 하나. 아웃풋이 기대값이 있다면 함수형으로 만들면 피드백 루프가 필요없을 수 있겠다.

google에서 grpc request와 response를 따로 하는 이유

구글 api는 왜 각 속성마다 request와 response를 따로 만드나?

• 입력값과 출력값이 각 함수마다 다르기 때문...

매일 매일 조금씩 하는 것

작은 것들이 모여서 큰게 되는게 맞지만, 상호작용이 중요하다. 함께 자라기에서 상호작용은 피드백이라고 했지만, 피드백이 없더라도 어떤 상호작용이 있다면 거기서 창발적 현상과 함께 큰 성과가 따라올 것이다. 신경 써야 하는 것은 상호작용이 있냐 이다. 그리고 피드백은 좋은 상호작용이긴 하다.

행동과 가이드를 매칭할 방법

트리거를 등록할 방법

뭔가 자료조사를 할 때 저절로 가이드를 옆에 띄울 방법 어느 장소에 가서 뭔가 해야할 때 다시 기억나게 할 방법 집에 가면 뭔가를 해야할 때 그것을 떠올릴 방법