Skip to main content
← 블로그

기대와 실제 사이

VauDium ·

회고 섹션에 Result 필드를 더했습니다. 단순한 입력칸 하나가 아니라, Intention의 Expectation과 짝을 이루는 구조적 보완이었어요.

기대와 실제 사이

어긋난 대칭

Fecit의 태스크 상세 화면은 섹션 단위로 구성돼 있습니다. 그중 “의도(Intention)“와 “회고(Retrospect)“는 태스크의 앞뒤를 담는 쌍이에요.

의도 섹션에는 세 칸이 있습니다.

  • Target — 지금 어떤 상황에서 시작하는가
  • Expectation — 어떤 결과를 기대하는가
  • Obstacle — 극복해야 할 난관은 무엇인가

회고 섹션에는 두 칸만 있었습니다.

  • Satisfaction — 얼마나 만족했는가
  • Retrospect — 돌아보며 무엇을 느꼈는가

뭔가 허전한 게 느껴졌습니다. Expectation에 대한 짝이 없었던 겁니다. “어떤 결과를 기대했는가”는 기록해 두는데, 막상 “실제로 어떤 결과가 나왔는가”는 적을 곳이 없었어요. Satisfaction은 결과에 대한 감정이고, Retrospect는 전반적인 성찰이라서, 사실 그 자체를 적기엔 자리가 맞지 않았습니다.

Result 필드 추가

그래서 회고 섹션의 맨 앞에 Result를 더했습니다. 배치는 자연스럽게 이렇게 정리됐어요.

  1. Result — 실제로 무엇이 일어났나 (사실 기록)
  2. Satisfaction — 그 결과에 얼마나 만족하나 (감정 반응)
  3. Retrospect — 경험에서 무엇을 배웠나 (넓은 성찰)

사실 → 반응 → 성찰이라는 순서로 회고 흐름이 만들어집니다. 각 칸은 자기만의 질문을 가지고, 유저에게 다른 렌즈로 돌아보라고 요청해요.

짝을 맞추면 비교가 생긴다

Expectation과 Result가 나란히 있으면 자연스럽게 비교가 일어납니다.

기대: 이번 발표에서 질문 세 개 이상 받기를 기대했다 결과: 실제로는 질문이 거의 없었고, 쉬는 시간에 한 명이 따로 물어봤다

이렇게 적어두면, Retrospect에 뭘 쓸지가 거의 저절로 나와요. “왜 예상보다 적었을까? 발표 포맷의 문제인가, 아니면 청중 특성인가?” 같은 질문이 자연스럽게 따라옵니다.

비교는 학습을 낳습니다. 기대가 맞았을 때도, 어긋났을 때도, 그 괴리를 관찰하는 것만으로 다음번에 더 나은 추정을 할 수 있게 됩니다. 기대만 적거나 결과만 적어서는 이 학습 루프가 완성되지 않아요.

구조화된 쓰기 공간의 힘

Fecit의 차별화 축 중 하나는 태스크당 쓸 수 있는 구조화된 공간이 유난히 많다는 것입니다. Todoist나 Things 같은 일반 태스크 앱은 제목과 설명, 기껏해야 댓글 정도가 있어요. Fecit은 거기에 Target, Expectation, Obstacle, Preparation, Retrospect, 그리고 이제 Result까지 붙습니다.

“왜 이렇게 많이 쓰게 하냐”는 질문을 받을 수 있는데, 답은 단순합니다. 쓰기 칸 자체가 질문이기 때문입니다. 빈 칸에 “뭐 쓰지” 하다가 그 필드의 이름(Target, Expectation, …)이 던지는 질문을 받아들이게 되고, 그걸 적는 과정에서 생각이 정리됩니다.

좋은 칸은 빈 종이보다 낫습니다. 빈 종이는 자유롭지만, 방향이 없어요. 구조화된 칸은 “이 관점으로 생각해보라”고 부드럽게 요청합니다. Expectation 칸이 “기대를 적어봐”라고 묻고, Result 칸이 “실제로 뭐가 일어났어?”라고 묻는 것이죠.

물론 억지로 다 채우게 하진 않습니다. Fecit의 “Minimal to Maximal” 원칙은 여기서도 작동해요. 기본은 심플한 할 일 하나, 필요해지면 구조를 펼칩니다. 짧은 산책 같은 건 Target도 Result도 안 쓰는 게 자연스럽고, 중요한 발표나 프로젝트 마일스톤은 모든 칸을 꼼꼼히 채워두면 복기할 때 큰 자산이 됩니다.

빈칸이 보이는 순간

설계를 하다 보면 “뭔가 허전한데 뭐가 빠졌는지 모르겠다”는 느낌이 자주 들어요. Result 같은 짝이 빠진 걸 눈치 채면, 허전함의 정체가 구체적인 형태로 드러납니다.

짝이 있는 구조는 스스로 설계 질문을 던집니다.

  • Expectation이 있으면 “Result는 어디 있지?”
  • Target이 있으면 “Target을 얼마나 달성했는지는 어디에?”

후자는 아직 답을 못 정했습니다. 별도 필드가 되어야 할까요, 아니면 Result와 합쳐도 될까요. 이번 작업의 Result 추가가 다음 고민을 낳은 셈입니다.

마무리

Result는 하나의 필드이지만, 추가 이유는 단순히 “쓸 수 있는 칸이 하나 더 생긴다”가 아니었어요. Expectation의 짝이 되어 비교 루프를 완성하는 것, 그리고 회고의 흐름을 “사실 → 감정 → 성찰”로 깔끔하게 정리하는 것, 이 두 가지가 본 의미였습니다.

필드 하나가 가진 무게는 그 칸이 어떤 질문을 던지는지, 그리고 어떤 다른 칸과 짝을 이루는지로 결정됩니다. 회고가 조금 더 생산적인 대화가 되기를 바라며, 오늘은 여기까지.