content.json

{"meta":{"title":"wonderland","subtitle":"wonderland","description":"소프트웨어 개발에 대한 생각과 소개","author":"wonderer","url":"https://wonderer80.github.io","root":"/"},"pages":[{"title":"about","date":"2018-03-29T08:20:32.000Z","updated":"2026-04-13T13:36:46.817Z","comments":true,"path":"about/index.html","permalink":"https://wonderer80.github.io/about/index.html","excerpt":"","text":""}],"posts":[{"title":"사람을 위한 하네스","slug":"사람을-위한-하네스","date":"2026-04-26T03:00:00.000Z","updated":"2026-04-26T11:58:43.495Z","comments":true,"path":"2026/04/26/사람을-위한-하네스/","permalink":"https://wonderer80.github.io/2026/04/26/%EC%82%AC%EB%9E%8C%EC%9D%84-%EC%9C%84%ED%95%9C-%ED%95%98%EB%84%A4%EC%8A%A4/","excerpt":"","text":"AI를 위한 하네스, 사람을 위한 하네스AX 공유회에서 한 동료가 이런 말을 했다. “AI를 위한 하네스는 있는데, 왜 사람을 위한 하네스는 없을까?” 이어진 말도 인상 깊었다. 인간도 에이전트 중 하나이고, Claude Code 같은 도구는 인간의 서브에이전트라고 볼 수 있다는 이야기였다. 들으면서 머릿속에서 “와, 그렇게도 볼 수도 있겠구나!” 하는 생각이 들었다. 그러면서 자연스럽게 다음 생각이 이어졌다. 그렇다면 사람을 위한 하네스란 정말 무엇일까. AI 에이전트는 모델 하나만으로 잘 작동하지 않는다. 아무리 좋은 모델이라도 그냥 던져놓으면 금방 한계가 드러난다. 이전 맥락을 잊고, 도구 호출에 실패하고, 엉뚱한 방향으로 가고, 결과를 검증하지 못한다. 그래서 모델 주변에는 일을 받쳐주는 여러 장치가 붙는다. 이 전체 실행 환경을 하네스라고 부른다. 같은 모델이라도 어떤 하네스를 붙이느냐에 따라 성능이 크게 달라진다는 사실이 알려지면서, 최근에는 모델 자체보다 그 주변의 하네스를 어떻게 설계할지에 대한 관심이 빠르게 커지고 있다. 문제를 단순히 “모델이 멍청하다”로 끝내지 않고, “모델이 잘 작동할 환경을 만들어줬는가”로 다시 묻기 시작한 것이다. 사람(모델) 탓에서 하네스 점검으로그렇다면 사람은 어떨까. 사람도 목표를 받고, 맥락을 해석하고, 도구를 쓰고, 행동하고, 결과를 관찰하며 다음 행동을 고른다. 그런 의미에서 사람도 하나의 에이전트라고 볼 수 있다. 그런데 사람에게는 이상하게도 하네스보다 의지와 태도를 먼저 요구한다. 일을 까먹으면 꼼꼼하지 못하다. 미루면 의지가 약하다. 집중하지 못하면 태도의 문제다. 실수하면 책임감이 부족하다. 물론 개인의 의지와 태도가 중요하지 않다는 말은 아니다. 다만 AI가 원하는 결과를 내지 못할 때 우리는 모델 탓에 머물지 않는다. 어떻게 하면 그 모델이 일을 더 잘하게 만들지를 먼저 고민한다. 사람에게도 같은 태도를 적용할 수 있다. 누군가 잘 해내지 못할 때, 그 사람의 의지나 태도를 탓하기 전에 어떻게 하면 그 사람이 더 잘 해낼 수 있게 도울지를 먼저 묻는 것이다. 모델을 당장 바꾸기 어렵다면 하네스를 바꾼다. 사람도 마찬가지다. 사람의 성격이나 의지를 바꾸는 일은 느리고 어렵다. 하지만 사람을 둘러싼 구조는 비교적 빠르게 바꿀 수 있다. 사람을 위한 하네스의 구성요소사람을 위한 하네스란 무엇일까. 정의를 단정적으로 먼저 내리기보다, 이미 잘 정리된 AI 하네스의 구조를 빌려와 사람에게 하나씩 비추어보고 싶었다. Akshay Pachaar이 AI 에이전트 하네스를 12가지 구성요소로 정리해둔 글이 좋은 출발점이었다. 오케스트레이션 루프, 도구, 메모리, 컨텍스트 관리, 프롬프트 구성, 출력 파싱, 상태 관리, 오류 처리, 가드레일과 안전, 검증 루프, 하위 에이전트 오케스트레이션, 도구 범위 전략이다. 이 12가지를 사람에게 하나씩 옮겨보았다. 그러자 사람을 위한 하네스가 막연한 생산성 이야기가 아니라 꽤 구체적인 모양을 갖추기 시작했다. 원글의 도식은 이 12요소를 LLM을 중심으로 세 겹의 동심원으로 정리한다. 가장 안쪽 런타임(Runtime) 층은 모델이 매 턴마다 굴리는 실행 사이클이고, 그 바깥 기능(Capabilities) 층은 모델이 가진 정보와 외부 자원을 다루는 영역이며, 가장 바깥 안전과 확장(Safety & Scale) 층은 그 둘이 무너지지 않게 받쳐주는 신뢰성 영역이다. 이 세 겹을 사람에게 그대로 옮겨보면 다음과 같다. 층 AI 하네스 구성요소 사람을 위한 하네스 런타임 (Runtime) 오케스트레이션 루프 하루의 사이클 (계획 → 실행 → 기록 → 다음) 프롬프트 구성 작고 분명한 다음 행동, 입력과 기대 결과의 명시 출력 파싱 회의록의 결정/액션 아이템, 보고서의 한 줄 요약 오류 처리 회고, 재발 방지 기록, 되돌릴 수 있는 작업 단위 기능 (Capabilities) 도구 캘린더, 할 일 앱, 메모 앱, AI 어시스턴트 메모리 작업 일지, 결정 기록, 위키/노트 컨텍스트 관리 작업 시작 전 짧은 브리프, 마지막에 남긴 진행 메모 상태 관리 할 일 앱의 오늘/예정 목록, 칸반 보드, 이슈 트래커 안전과 확장 (Safety & Scale) 가드레일과 안전 중요한 결정 전 체크리스트, 더블체크 절차 검증 루프 셀프 리뷰, 동료 리뷰, 페어 작업, 모니터링 알림 하위 에이전트 오케스트레이션 동료·AI·자동화 스크립트에게 일 맡기기 도구 범위 전략 집중 시간엔 알림 차단, 시간대별 도구 분리 표를 펼쳐 놓고 보면 사람을 위한 하네스가 막연한 다짐이 아니라 꽤 구체적인 설계 대상이라는 게 보이기 시작한다. 나는 최근에 오픈클로를 내 삶에서 다양한 형태로 활용하고 있었는데 이 구성요소에 기반해서 AI와 함께 나를 위한 하네스 중에 어떤 부분이 잘 되어 있고 어떤 부분이 부족한지 알 수 있었다. 자연스럽게 내 하네스를 지속적으로 어떻게 평가하고 개선할 것인지에 대한 고민도 함께 하게 되었다. 사람을 바꾸기 전에 조건을 설계하라우린 직접 AI의 모델을 변화시키기는 어렵다는 것을 잘 알고 있다. 그렇기에 하네스라는 환경을 통해서 AI가 일을 더 잘할 수 있도록 노력한다. 사람도 마찬가지다. 나의 능력을 발전시키기 전에, 나의 능력을 잘 발전시킬 수 있는 하네스는 무엇인지를 고민하는 태도가 중요하다고 생각한다. 좋은 하네스는 사람을 통제하지 않는다. 사람이 잘 해낼 수 있는 조건을 만들어줄 뿐이다. 좋은 하네스는 모델을 지나치게 통제하지 않고, 모델이 자율적으로 행동하면서도 목표를 잃지 않도록 해준다. 인간을 위한 하네스도 통제가 아니라, 인간의 장점과 자율성을 보존하면서 목표를 잘 달성할 수 있도록 돕는 형태가 되어야 할 것이다.","categories":[],"tags":[{"name":"AI","slug":"AI","permalink":"https://wonderer80.github.io/tags/AI/"},{"name":"하네스","slug":"하네스","permalink":"https://wonderer80.github.io/tags/%ED%95%98%EB%84%A4%EC%8A%A4/"},{"name":"시스템","slug":"시스템","permalink":"https://wonderer80.github.io/tags/%EC%8B%9C%EC%8A%A4%ED%85%9C/"},{"name":"생각","slug":"생각","permalink":"https://wonderer80.github.io/tags/%EC%83%9D%EA%B0%81/"}]},{"title":"AI 시대, 더 선명해진 소프트웨어 개발의 본질","slug":"AI-시대-더-선명해진-소프트웨어-개발의-본질","date":"2026-04-16T15:20:00.000Z","updated":"2026-04-16T16:52:13.261Z","comments":true,"path":"2026/04/17/AI-시대-더-선명해진-소프트웨어-개발의-본질/","permalink":"https://wonderer80.github.io/2026/04/17/AI-%EC%8B%9C%EB%8C%80-%EB%8D%94-%EC%84%A0%EB%AA%85%ED%95%B4%EC%A7%84-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C%EC%9D%98-%EB%B3%B8%EC%A7%88/","excerpt":"","text":"AI 시대의 불안 앞에서요즘 AI 이야기를 하다 보면 주변에서 뒤처지는 것 같다는 불안을 자주 듣게 된다. 새로운 도구와 새로운 방식이 쏟아지고, 이제 누구나 개발할 수 있는 시대가 오는 것처럼 이야기된다. 특히 기존 엔지니어일수록 이런 변화 앞에서 더 불안해하기 쉬운 것 같다. 나 역시 비슷한 고민을 했다. 이제 누구나 개발할 수 있는 시대라면 소프트웨어 엔지니어는 어떤 역할을 해야 할까. 무엇을 더 잘해야 하고, 무엇을 버려야 하며, 우리는 얼마나 달라져야 할까. 겉으로 보면 정말 많은 것이 바뀌고 있다. 예전에는 구현 자체가 큰 장벽이었다. 특히 현실의 개발은 새 기능만 만드는 일이 아니었다. 이미 돌아가고 있는 레거시 환경을 운영하고, 문제를 수습하고, 조금씩 개선해가면서 동시에 새로운 기능까지 만들어야 했다. 어려움은 단순히 무언가를 구현하는 데 있다기보다, 복잡한 맥락과 제약이 얽힌 상태에서 계속 앞으로 나아가야 한다는 점에 더 가까웠다. 지금도 그 본질은 크게 다르지 않다. 다만 AI는 코드를 빠르게 만들고 문서를 정리해주면서 여러 작업의 속도를 분명히 높여준다. 그래서 처음에는 이제 훨씬 쉬워지거나 빨라질 것 같다는 기대가 생긴다. 그런데 막상 해보면 생각만큼 쉽지도 않고, 기대한 만큼 빨라지지도 않는 경우가 많다. 이런 고민을 하면서 여러 글을 읽고 생각을 정리해보니, 내 생각은 오히려 다른 쪽으로 갔다. 바뀐 건 많지만, 그 변화의 상당수는 작업 방식에 가깝다는 쪽이다. 코드를 입력하는 방식, 초안을 만드는 방식, 지식을 찾는 방식은 달라졌지만 소프트웨어를 만드는 일의 중심에는 여전히 크게 변하지 않은 것들이 남아 있다. 만들기 쉬워질수록 문제에서 멀어진다최근에 읽은 AI Coding is Gambling이라는 글은 AI 코딩이 마치 프롬프트를 넣고 원하는 결과가 나올 때까지 계속 레버를 당기는 일과 비슷하다고 말한다. 문제를 더 잘 이해해서 앞으로 나아간다기보다, 이번에는 좀 괜찮은 결과가 나오기를 기대하면서 계속 시도하게 된다는 것이다. 이 비유가 흥미로웠던 이유는, AI를 쓰다 보면 문제를 깊이 이해하는 일보다 그럴듯한 결과를 빨리 얻는 쪽으로 쉽게 기울 수 있다는 점을 꽤 잘 보여준다고 느꼈기 때문이다. 물론 이런 함정이 AI 때문에 새롭게 생긴 것은 아니다. 원래도 사람들은 고객의 문제를 깊이 이해하기보다, 고객이 말한 솔루션을 빠르게 만들어주는 쪽으로 자주 기울곤 했다. 문제를 제대로 이해하다 보면 고객이 처음 말한 방향과 다른 해석이나 다른 해결책이 나올 수 있고, 그러면 그걸 다시 설명하고 설득하는 과정이 필요해진다. 반면 고객이 말한 솔루션을 바로 만드는 쪽은 더 빠르고, 눈에 보이는 결과도 빨리 나온다. 예전에는 그나마 구현 비용이 커서 함부로 “일단 만들어보자”로 가기 어려웠다. 기능이 정말 필요한지, 어떤 제약이 있는지, 기존 시스템과 어떻게 연결되는지 조금 더 오래 생각할 수밖에 없었다. 하지만 이제는 그 문턱이 훨씬 낮아졌다. 그래서 원래도 하던 실수를 더 쉽게, 더 빠르게 반복하게 된다. 문제의 본질보다 솔루션 생산 자체에 집중하게 되고, 무엇을 왜 만드는가보다 무엇이든 빨리 만들어내는 일이 더 중요해지기 쉽다. 그러면 앞에서 충분히 생각하는 시간은 줄고, 뒤에서는 엉성하게 만들어진 결과물을 수습하는 일만 남는다. AI는 사고를 증폭한다여기서 1991년에 나온 QSM 1의 서문에서 제럴드 와인버그가 한 말이 떠올랐다. The computer, I learned, was a mirror of my intelligence, and I wasn’t too impressed by my reflection.Later, when I wrote larger programs in concert with other people, I learned that the computer was not just a mirror, but a magnifying mirror. 와인버그는 컴퓨터가 인간의 사고를 그대로 비추는 데서 그치지 않고, 더 큰 프로젝트에서는 그것을 더 크게 확대해서 드러낸다고 봤다. 이 말이 1991년에 나온 책의 이야기인데도 지금 AI 시대를 설명하는 데 여전히 잘 들어맞는다는 점이 흥미롭다. 결국 AI도 비슷하다. 인간의 사고를 대체하기보다 오히려 증폭한다. 방향이 맞으면 더 멀리 갈 수 있고, 방향이 틀리면 더 빠르게 잘못된 곳으로 간다. 예전에는 생각이 부족하면 결과물도 대체로 허술해서 문제가 비교적 빨리 드러났다. 이제는 생각이 부족해도 겉보기에는 그럴듯한 결과가 빠르게 나오기 때문에, 더 늦게 이상을 알아차리거나 더 큰 비용을 치른 뒤에 문제를 발견하기 쉬워졌다. 최근에 들은 InfoQ 팟캐스트 AI Amplifies Team Strengths and Weaknesses in Software Development도 비슷한 이야기를 한다. 많은 팀들이 원래도 명확한 스펙, 공동의 책임감, 빠른 피드백, 협업 같은 기본기에서 어려움을 겪고 있었고, AI는 그런 문제를 대신 해결해주지 않는다는 것이다. 오히려 코드 생성만 빨라지면, 기본기가 좋은 팀은 그 속도를 전체 흐름의 개선으로 이어갈 수 있지만 기본기가 약한 팀은 리뷰, 디버깅, 정렬되지 않은 요구사항 같은 다른 지점에서 병목이 더 크게 드러난다. 그래서 그 팟캐스트는 AI를 cure가 아니라 amplifier라고 부른다. 결국 와인버그의 말과 InfoQ 팟캐스트에서 나온 이야기는 비슷한 방향을 가리키고 있다. AI는 소프트웨어 개발의 새로운 본질을 만드는 것이 아니라, 원래 있던 강점과 약점, 그리고 본질을 더 선명하게 드러낸다. 소프트웨어 개발의 본질은 여전히 같다내가 보기에 소프트웨어 개발의 본질은 여전히 현실을 모델링하는 일이다. 예를 들어 주문, 고객, 재고 같은 개념들이 어떤 관계를 맺고 어떤 상태 변화를 거치는지, 그 사이에 어떤 규칙과 제약이 있는지를 코드로 옮기는 일이다. 이건 단순히 코드를 생성하는 능력만으로 해결되지 않는다. 무엇이 중요한 규칙인지, 어떤 예외가 치명적인지, 어디까지를 시스템이 책임져야 하는지를 이해해야 한다. 소프트웨어 개발은 결국 변화를 다루는 일이기도 하다. 처음 만드는 것보다 더 어려운 것은, 계속 바뀌는 요구사항과 맥락 속에서 시스템을 수정해나가는 일이다. AI는 변경을 고려한 것처럼 보이는 구조를 내놓기도 하지만, 실제 맥락과 맞지 않는 추상화나 오버엔지니어링으로 흐르는 경우도 많다. 결국 어떤 변화를 대비해야 하는지 판단하는 일은 여전히 사람의 몫이다. 또 실제 현장에서는 코드 자체보다, 무엇을 만들고 있는지에 대한 이해가 더 자주 어긋난다. 어떤 문제를 풀고 있는지, 누가 어떤 제약을 중요하게 보는지를 서로 다르게 이해한 채 개발이 진행되기 때문이다. 이런 상태에서는 코드가 기술적으로 맞더라도, 정작 사용자가 원하는 문제를 풀지 못하거나 팀이 기대한 방향과 다른 결과물이 나오기 쉽다. 소프트웨어 엔지니어의 역할도 변하지 않는다나는 소프트웨어 개발의 본질이 크게 달라지지 않은 것처럼, 소프트웨어 엔지니어의 역할도 생각보다 크게 달라지지 않는다고 생각한다. 여전히 중요한 사람은 코드를 가장 빨리 찍어내는 사람이 아니라, 현실을 정확히 이해하고, 복잡한 상황에서 중요한 것을 구분하고, 무엇을 포기하고 무엇을 지켜야 할지를 끝까지 판단할 수 있는 사람이다. AI는 답을 더 빨리 만들어주고 개발의 방식과 속도를 많이 바꾸고 있지만, 무엇이 중요한 문제인지 대신 정해주지는 않는다. 어떤 제약이 진짜 제약인지, 그럴듯한 답과 맞는 답을 어떻게 구분할지, 어떤 구조와 선택이 실제 맥락에 맞는지를 판단하는 책임은 여전히 사람에게 남아 있다. 그래서 나는 AI 시대일수록 불안 그 자체에 휩쓸리기보다, 원래 소프트웨어 엔지니어가 해오던 역할의 본질에 더 집중해야 한다고 생각한다. 문제를 정확히 이해하고, 중요한 제약을 구분하고, 끝까지 판단하는 일 말이다. 참고한 글 AI Coding is Gambling AI Amplifies Team Strengths and Weaknesses in Software Development","categories":[],"tags":[{"name":"AI","slug":"AI","permalink":"https://wonderer80.github.io/tags/AI/"},{"name":"생각","slug":"생각","permalink":"https://wonderer80.github.io/tags/%EC%83%9D%EA%B0%81/"},{"name":"소프트웨어","slug":"소프트웨어","permalink":"https://wonderer80.github.io/tags/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4/"},{"name":"개발","slug":"개발","permalink":"https://wonderer80.github.io/tags/%EA%B0%9C%EB%B0%9C/"}]},{"title":"키오스크의 빨간 버튼은 누구를 위한 것인가","slug":"키오스크의-빨간-버튼은-누구를-위한-것인가","date":"2026-04-13T13:35:00.000Z","updated":"2026-04-13T14:24:22.778Z","comments":true,"path":"2026/04/13/키오스크의-빨간-버튼은-누구를-위한-것인가/","permalink":"https://wonderer80.github.io/2026/04/13/%ED%82%A4%EC%98%A4%EC%8A%A4%ED%81%AC%EC%9D%98-%EB%B9%A8%EA%B0%84-%EB%B2%84%ED%8A%BC%EC%9D%80-%EB%88%84%EA%B5%AC%EB%A5%BC-%EC%9C%84%ED%95%9C-%EA%B2%83%EC%9D%B8%EA%B0%80/","excerpt":"","text":"최근 한 커피숍의 키오스크를 사용하면서 묘한 불쾌함을 느꼈다. 처음에는 그냥 UI가 촌스럽고 복잡하다고 생각했다. 그런데 몇 번의 선택 화면을 지나면서 묘한 공통점이 보였다. 눈에 더 잘 띄는 빨간색 버튼이 반복적으로 사용자보다 점주에게 유리한 쪽을 가리키고 있다는 점이었다. 그리고 그 의도가 지나치게 노골적으로 느껴졌다. 이 화면은 내가 이용하고 있지만 나를 돕기 위해 설계된 것이 아니라 의도적으로 점주를 위해 내 선택을 교묘하게 유도하는 것처럼 느껴졌다. 예를 들면 아래 세 장면이 그랬다. 포인트 적립 화면에서는 적립하지 않는 쪽이 더 강하게 보였다. 포인트 사용 화면에서도 마찬가지였다. 포인트를 쓰는 것보다 적립으로 넘어가게 만드는 쪽이 더 강하게 보였다. 영수증 출력 화면에서도 출력보다 미출력 쪽이 더 강조되어 있었다. 각 장면만 따로 보면 사소한 디자인 선택처럼 보일 수도 있다. 하지만 이 선택들이 이어지는 흐름 전체를 놓고 보면 이것은 단순한 우연이라기보다 하나의 방향처럼 느껴진다. 소모품 비용이 들지 않는 선택, 추가 혜택이 발생하지 않는 선택, 점주 입장에서 운영 비용이 덜 드는 선택이 반복해서 더 눈에 띄게 제시되고 있기 때문이다. 물론 여기서 한 가지 흥미로운 질문이 생긴다. 이게 정말 나쁜 일일까? 생각해보면 키오스크 제조사의 직접 고객은 사용자가 아니라 점주다. 그렇다면 점주에게 유리한 UI를 설계하려는 유인은 충분히 자연스럽다. 영수증 미출력을 기본 흐름에 가깝게 만들고, 운영 비용이 덜 드는 선택을 선호하는 것 자체를 무조건 비난하기는 어렵다. 비즈니스적으로 보면 오히려 꽤 합리적인 선택일 수도 있다. 여기서 더 흥미로운 건, 이 매장이 포인트 시스템 자체를 없앤 것은 아니라는 점이다. 만약 정말 포인트 적립이나 사용을 원하지 않는다면 애초에 그런 제도를 넣지 않으면 된다. 그런데 현실은 그렇지 않다. 포인트 시스템은 고객 재방문을 유도하고, 회원을 확보하고, 데이터를 수집하는 데 여전히 유용하다. 즉 제도는 필요하다. 문제는 그 다음이다. 제도는 유지하고 싶지만, 실제 적립이나 사용은 너무 활발하지 않기를 바라는 마음 역시 존재하는 것처럼 보인다. 고객을 끌어오기 위해서는 포인트가 필요하지만, 막상 포인트가 적립되고 사용되는 순간 그것은 비용이 된다. 이 모순은 종종 정책 문서가 아니라 UI에서 먼저 드러난다. 기능은 제공하지만, 그 기능이 충분히 사용되지는 않기를 바라는 태도 말이다. 점주에게 유리한 설계와 사용자를 희생시키는 설계는 같은 말이 아니다. 내가 보기에 사용자를 희생시키는 순간은, 사용자가 자기 이익에 따라 충분히 판단할 수 있도록 돕는 대신 특정 선택을 더 쉽게 누르게 만드는 시점부터다. 특히 키오스크처럼 빨리 결제하고 지나가고 싶은 상황에서는 사람은 문구를 꼼꼼히 읽기보다 가장 눈에 띄는 버튼을 누르기 쉽다. 뒤에 사람이 서 있거나 주문 과정이 길어질수록 더 그렇다. 이때 시각적 강조가 반복적으로 점주에게 유리한 방향을 가리킨다면, 선택권은 남아 있어도 선택의 질은 훼손된다. 여기서 떠오른 대비 사례가 있다. 예전에 한 서비스의 약관 동의 화면을 보고 꽤 인상 깊었던 적이 있다. 보통 많은 서비스들은 전체 동의를 누르면 마케팅 수신 동의까지 자연스럽게 따라오게 설계한다. 기업 입장에서는 당연히 그 편이 이익이기 때문이다. 그런데 그 서비스는 전체 동의의 편의는 제공하면서도, 마케팅 수신 동의는 거기서 제외했다. 필수적인 동의는 빠르게 처리하게 도와주되, 기업에게 이익이 되는 선택까지 관성적으로 따라가게 만들지는 않았던 것이다. 이 차이는 꽤 중요하다. 둘 다 기업의 이해관계 안에서 설계된 UI이지만, 하나는 사용자의 편의를 도우면서도 선택을 오염시키지 않았고, 다른 하나는 편의를 가장해 특정 선택을 더 쉽게 누르게 만든다. 좋은 UX는 기업의 목표와 사용자 경험이 충돌하지 않도록 설계된 UX다. 기업의 목표를 앞세워 사용자의 판단을 비틀기 시작하면, 그건 좋은 UX가 아니라 조작에 가까워진다. 점주에게 유리한 흐름을 만드는 것 자체는 이해할 수 있다. 하지만 그 과정에서 사용자가 받을 수 있는 혜택을 놓치게 하거나, 사용자의 판단이 운영자의 이익 쪽으로 기울도록 유도한다면 그건 친절한 UI가 아니라 편향된 UI다. 키오스크 UI는 종종 기술의 문제가 아니라 태도의 문제를 드러낸다. 이 인터페이스가 누구를 먼저 고객으로 대하는지, 누구의 시간과 비용을 더 소중하게 여기는지는 생각보다 쉽게 감춰지지 않는다. 그런 태도는 결국 버튼의 크기, 문구의 순서, 그리고 색 하나에까지 스며든다. 그래서 내가 이 키오스크에서 불쾌했던 이유는 단순히 복잡해서가 아니다. 이 빨간 버튼이 중요한 선택을 알려주는 표시가 아니라, 사용자의 판단을 아주 조금씩 운영자의 이익 쪽으로 밀어두는 신호처럼 느껴졌기 때문이다. 문제는 버튼이 빨갛다는 데 있지 않다. 그 빨간색이 누구를 위해 쓰이고 있었느냐에 있다.","categories":[],"tags":[{"name":"UX","slug":"UX","permalink":"https://wonderer80.github.io/tags/UX/"},{"name":"UI","slug":"UI","permalink":"https://wonderer80.github.io/tags/UI/"},{"name":"키오스크","slug":"키오스크","permalink":"https://wonderer80.github.io/tags/%ED%82%A4%EC%98%A4%EC%8A%A4%ED%81%AC/"},{"name":"디자인","slug":"디자인","permalink":"https://wonderer80.github.io/tags/%EB%94%94%EC%9E%90%EC%9D%B8/"}]},{"title":"코드 리뷰 개선해나기기","slug":"코드리뷰-개선해나가기","date":"2022-04-13T13:30:00.000Z","updated":"2026-04-13T13:36:46.817Z","comments":true,"path":"2022/04/13/코드리뷰-개선해나가기/","permalink":"https://wonderer80.github.io/2022/04/13/%EC%BD%94%EB%93%9C%EB%A6%AC%EB%B7%B0-%EA%B0%9C%EC%84%A0%ED%95%B4%EB%82%98%EA%B0%80%EA%B8%B0/","excerpt":"","text":"지난 번 글에 이어 이번 글에서는 필자가 속한 조직에서 필자가 입사했을 때 당시의 시점에서부터 현재까지 코드 리뷰 과정에서의 고민과 변화들을 이야기해보도록 하겠다. 코드 리뷰를 처음 도입하는 회사들은 Github의 PR(Pull Request) 리뷰에서 시작하게 되는 경우가 많다. 하지만 처음에는 어떤 식으로 리뷰를 해야하는지 잘 모르기 때문에 로직적으로 결함이 있는지, 컨벤션은 준수되었는지와 같은 코드 스타일을 주로 본다. 필자가 입사 했을 때 당시에도 주로 코드 스타일이나 로직에 대한 부분의 피드백이 중점적이었다. 그리고 테스트 코드를 도입한지 얼마 안된 상황이었다. 백엔드 개발자들끼리 비교적 활발하게 리뷰를 해주는 상황이긴 했지만 각자가 다른 팀에서 바쁘게 일을 하고 있는 상황이다보니 해당 PR의 목적을 이해하기보단 코드 자체에 집중할 수밖에 없는 상황이었다. 그래도 다행이었던 점은 회사에서 오랫동안 근무하며 넓은 범위를 이해하고 있는 개발자들이 많이 있었다는 점이었다. 그들은 별도의 설명이 없어도 코드의 히스토리를 잘 알고 있었기에 자세한 설명이 없어도 비교적 수월하게 리뷰를 진행할 수 있는 장점이 있었다. 하지만 최근에 입사한 분들은 코드만 가지고 피드백 할 수 있는 부분에 한계가 있었으며 필자처럼 Python/Django 개발 경험이 없던 개발자 입장에서는 더더욱 기여를 할 수 있는 부분이 거의 없었다. 또한 과거에 필자가 코드 리뷰를 하면서 느꼈던 큰 한계점 중에 하나가 있었는데 바로 설계에 대한 부분이었다. 데이터 모델링이나 API Spec 설계 같은 경우 코드 전체적으로 중요한 영향을 끼치며 한번 결정되면 추후에 바꾸기가 쉽지 않다. 그럼에도 불구하고 코드 리뷰 단계에서 관련하여 개선 피드백이 나와도 반영하기가 쉽지 않다. 왜냐하면 설계가 바뀌면 이미 작성된 코드의 상당 부분을 재작성해야하는 경우가 생기며 리뷰를 받는 시점에서는 이미 릴리즈를 앞둔 경우가 많기 때문이다. 누군가는 리뷰 과정에서 개선점이 발견되면 당연히 수정되어야 하는 것 아니냐고 생각할 수도 있다. 사실 필자도 그렇게 생각했다. 하지만 릴리즈 시점은 여러 이해가 얽혀있는 경우가 많으며, 개발자 개인이 그런 압박을 견디면서 릴리즈를 미루기는 쉽지가 않다. 실제로 많은 부분이 수정을 해야하기 때문에 비효율이 발생된다. 이런 상황이 반복되다보면 오히려 거대한 레거시가 금방 쌓이게 되고 피드백은 단순하고 큰 가치 없는 내용이 주를 이루게 된다. 테크스펙 도입이런 여러가지 문제를 해소하기 위한 방안으로 코딩을 하기 전에 테크 스펙을 작성하고 리뷰를 하는 과정을 두게 되었다. 테크 스펙의 내용은 극히 일부의 내용을 제외하고는 기술 독립적이며, 목적이나 의도, 기획 내용 등이 같이 기재되어 있기 때문에 개발자라면 누구나 이해하고 리뷰할 수 있다. 또한 개발의 초기 시점에 진행되기 때문에 설계가 변경되더라도 비용이 적게 든다. 오히려 코드가 없기 떄문에 설계나 의도 그 자체에 더 집중할 수 있게 된다. 이것을 통해서 어떤 문제를 해결하고자 했는지 구성원들의 공감대가 있었기 때문에 어찌보면 번거로울수도 있는 과정이 하나 더 생겼음에도 불구하고 모두가 열심히 참여해주었다. 명시적 리뷰어초기에는 백엔드 개발자가 몇명 없었고 동시에 진행되는 업무도 많지 않았기 때문에 별도의 리뷰어를 지정하지 않아도 어느 정도 리뷰가 진행되었지만 인원이 늘어나기 시작하면서 리뷰가 밀리거나 방치되는 상황이 발생되었다. 각자의 업무도 바쁘지만 생성되는 PR도 많아지고 명시적으로 리뷰어를 지정하지 않다보니 하는 사람만 하거나 리뷰가 밀리는 상황이 발생됐다. 리뷰의 중요성에 대해 설명을 하는 것만으로는 부족했다. 명시적으로 리뷰어를 지정하는 것이 좋겠다는 판단이 들었지만 어떻게 지정해야할지 고민이었다. 그 와중에 팀원 분의 아이디어로 리뷰 마니또 라는 제도를 시작하게 되었다. 리뷰 마니또는 본인이 속하지 않은 도메인의 개발자 중에서 랜덤으로 뽑게 되는데 한달동안 본인의 리뷰 요청을 전담해주게 된다. 리뷰는 기본적으로 자신의 속한 도메인 내의 개발자 1명 이상과 리뷰 마니또가 해주게 되는데 리뷰 마니또는 본인이 속한 도메인이 아니기 때문에 이해하기 어려운 코드나 문서를 더 잘 인지하고 피드백할 수 있게 된다. 피드백 중요도 표기코드 리뷰를 진행할 때 남기는 댓글이 모호하게 느껴질 때가 있다고 생각이 드는 경우가 많았다. 그냥 참고하라는 이야기인지, 꼭 반영이 되었으면 하는 내용인지, 리뷰를 하는 사람이 어느 정도의 중요성을 가지고 말했는지 애매할 때가 있다. 리뷰를 하는 과정에서 조심스럽게 전달하다보니 그런 경우가 생기는 것이겠지만 한편으로는 비효율적으로 느껴질 때도 많았다. 이런 부분을 좀 더 명확하게 하고 싶어서 중요도를 달 수 있도록 정의했다. github saved reply 기능을 이용하여 리뷰하는 과정에서 편리하게 중요도를 선택해서 남길 수 있게 하였다. L1에서 L3까지는 반드시 합의를 통해서 resolve가 되어야 하며 L4, L5나 반드시 반영하지 않아도 머지할 수 있도록 구분해두었다. JIRA Workflow와 통합리뷰 요청 방식도 여러번 개선되었다. 요청 시 필요한 정보들이 추가되고 슬랙 워크플로우 기능을 이용해서 템플릿을 제공했다. 근데 요청되는 리뷰가 많아지니 슬랙으로는 내가 요청 받은 리뷰를 확인하는 것이 점점 어려워졌다. 업무에서 JIRA를 활용하고 있으니 자연스럽게 workflow를 연동하자는 의견이 나왔다. 현재는 리뷰 요청하는 과정을 JIRA의 워크플로우와 통합하여 JIRA에 리뷰 관련 정보를 기입하고 상태를 변경하면 자동으로 슬랙으로 발송된다. 또한 리뷰용 지라 대시보드 구성을 통해서 현재 진행되고 있는 전체 리뷰 상황과 나에게 할당된 리뷰도 볼 수 있게 되었다. 지속적인 개선이 중요하다그 외에도 자세하게 기술하지 않은 수많은 개선사항이 있었고 필자는 여전히 개선해야할 부분이 있다고 생각한다. 필자가 이 글에서 결국 전달하고 싶었던 부분은 우리가 현재 어떤 것을 하고 있는가를 얘기하는 것이 아니다. 오히려 맹목적으로 다른 조직이 하는 것을 그대로 따라하는 것을 경계하라고 하고 싶다. 핵심은 우리가 수행하고 있는 프로세스의 목적을 이해하고 지속적으로 개선해나가는 과정이다. 또한 그러한 과정은 특정 한두명이 하는 것이 아니라 구성원들의 참여로 이루어지도록 해야한다. 리더는 구성원들이 이런 의견을 자유롭게 내고 실행할 수 있는 환경을 마련해주는 역할을 해야하고, 혹시나 원래의 목적을 잃고 관습적으로 실행하고 있는 부분은 없는지 살펴야 한다. 다른 조직들의 리뷰 문화나 프로세스를 보면 우리가 하는 것은 보잘것없고 부족해보일 수도 있다. 하지만 정말 부끄러워해야하는 것은 그저 원래 해왔으니까, 남들도 다 하니까 따라 하는 모습일 것이다. 특정 한명의 이상과 역량이 아무리 높을지라도 결국 조직은 구성원들의 평균 수준에 수렴한다. 변화가 한순간에 이루어질 것이라고 기대하는 것은 환상이다. 구성원들과 함께 걸어가며 성장해야 진정한 변화를 이룰 수 있다. 이 글을 통해 코드 리뷰와 관련해서 우리가 지금 관습적으로 하고 있는 것은 없는지 한번 살펴보고, 아이디어를 얻어 가셨으면 하는 바람이다.","categories":[],"tags":[{"name":"개발문화","slug":"개발문화","permalink":"https://wonderer80.github.io/tags/%EA%B0%9C%EB%B0%9C%EB%AC%B8%ED%99%94/"},{"name":"코드리뷰","slug":"코드리뷰","permalink":"https://wonderer80.github.io/tags/%EC%BD%94%EB%93%9C%EB%A6%AC%EB%B7%B0/"}]},{"title":"우린 코드리뷰 잘하고 있을까?","slug":"우린-코드리뷰를-잘하고-있을까","date":"2022-02-09T13:30:00.000Z","updated":"2026-04-13T13:36:46.816Z","comments":true,"path":"2022/02/09/우린-코드리뷰를-잘하고-있을까/","permalink":"https://wonderer80.github.io/2022/02/09/%EC%9A%B0%EB%A6%B0-%EC%BD%94%EB%93%9C%EB%A6%AC%EB%B7%B0%EB%A5%BC-%EC%9E%98%ED%95%98%EA%B3%A0-%EC%9E%88%EC%9D%84%EA%B9%8C/","excerpt":"","text":"코드 리뷰 남들도 다 하더라코드 리뷰 라는 말이 이제는 개발자라면 누구나 익숙한 관용어가 되었지만, 이 용어가 생소했던 시절이 생각보다 그리 오래 전은 아니다. 과거에는 코드는 작성한 개인의 소유물 처럼 여겨졌고 그렇기에 코드에 대한 비판은 나 자신의 비판으로 여겼기에 누군가가 나의 코드를 보는 것 자체만으로 거부감이 있었던 시기도 있었다. 하지만 최근에는 오히려 코드 리뷰를 하지 않는 조직은 시대에서 뒤쳐지는 것처럼 느껴지는 정도의 분위기가 된 것 같다. 반면 최근에 여러 개발자들과 이야기를 나눠보면 본인이 속한 조직에서 코드 리뷰는 진행 하고 있지만 만족스럽게 느끼는 경우는 많지 않다고 느꼈다. 자주 들었던 이야기들은 ‘각자 다른 영역의 업무를 하고 있다보니 코드에 대한 이해도가 떨어져서 의미있는 리뷰를 받지 못한다’, ‘다들 바빠서 리뷰 할 시간이 없다보니 리뷰과정이 너무 오래 걸린다’, ‘공들여 리뷰 피드백을 했지만 바쁘다는 핑계로 반영이 되지 않아 허탈했다’, ‘의견이 다른 경우 합의를 이루는 과정이 너무 피곤하다’ 같은 내용이 많았던 것 같다. 개인적으로 이런 것들은 코드 리뷰를 통해서 얻고자 하는 것에 대한 구성원들의 공감대 없이 다른 곳에서 하는 것을 그대로 형식적으로 받아들였을 때 생기는 문제라고 생각한다. 코드리뷰가 잘 이루어지려면 먼저 코드 리뷰를 통해서 우리가 얻고자 하는 것이 무엇인지 명확하게 구성원들이 인지해야 한다. 형식을 따라하는 것이 아니라 우리가 목표하는 바를 잘 달성하고 있는지를 확인할 때 우리의 리뷰 프로세스가 잘 동작하고 있는지 이해할 수 있다. 그리고 우리의 상황에 따라 지속적으로 변화할 수 있어야 한다. 코드 리뷰를 통해서 얻을 수 있는 이점먼저 구글에서는 코드 리뷰를 통해서 얻는 이점에 대해 다음과 같은 것을 제시하고 있다. 코드의 정확성 검증 다른 엔지니어들이 코드의 변경사항을 이해할 수 있는지 확인 코드 베이스들간의 일관성 강화 팀 오너십 촉진 지식 공유 활성화 코드 리뷰에 대한 이력 제공 일반적으로 첫번째 ‘코드의 정확성 검증’. 즉, 로직에 결함이 없는지를 가장 중요한 리뷰의 목적으로 생각하는 경우가 많다. 그리고 두번째는 ‘코드 베이스들간의 일관성’, 컨벤션 측면에서 보는 경우들이 많다. 하지만 개인적으로 봤을 때 이 두가지는 코드 리뷰에서 상대적으로 가장 덜 중요한 이점이라고 생각한다. 첫번째는 테스트 코드를 통해서 해소하는 것이 더 바람직하며, 두번째는 CI 와 연동하여 자동으로 체크하는 것이 더 효율적이다. 구글에서도 이 부분을 지적하고 있으며 이 중에서 가장 중요하지만 과소평가된 이점으로는 지식 공유 활성화라고 한다. 지식 공유라는 것이 사람수에 비례해서 잘 이루어질 것으로 기대하는 사람도 있지만, 오히려 일하는 방식의 영향을 많이 받는 것 같다. 1000명이 넘는 개발자가 있는 조직에서도 서로가 무슨 일을 하는지, 어떤 방식으로 개발을 하는지 모르는 경우도 있고 반면에 4-5명밖에 없지만 상호간에 활발하게 지식 공유와 학습이 일어나는 경우도 있다. 또한 개인적으로는 리뷰라는 것을 작성된 코드로 한정하면 리뷰를 통해서 얻을 수 있는 이점이 제약된다고 본다. 뛰어난 개발자는 어려운 코드를 만들어내는 사람이 아니라 할 필요가 없는 일을 하지 않는 사람이다. 이런 것을 판단하려면 요구사항 분석 단계에서부터 이 코드가 어떤 문제를 해결하기 위한 작업이며, 그 문제를 해결하는데 가장 적합한 선택인지를 알 수 있어야 한다. 항상 무엇이든 도입보다 유지와 발전이 더 어렵다이러한 이해를 바탕으로 처음에 리뷰를 도입하는 시기에는 먼저 구성원들의 공감대와 개선 의지가 필요하다. 처음에 무언가를 시작할 때는 한 사람의 의지만으로 가능할 수 있을지 몰라도 그것을 유지하고 발전시키기 위해서는 구성원 모두의 힘이 필요하다. 구글에서 제시하는 이점을 참고해도 되고 혹은 다른 것이어도 상관없다. 가장 우리가 필요로 하는 것 하나를 딱 찍어서 목표를 정하고, 그로 인한 효능감을 구성원들 스스로 느끼는 것이 중요하다. 단순히 코드 리뷰를 하면 힙한 느낌이고 그렇지 않으면 뒤처지는 느낌인 것 같은 생각으로 시작되어선 오히려 없는 것만 못한 리뷰가 이루어질 수 있다. 단순히 리뷰를 하고 있는지의 여부가 아니라 우리가 원하는 것을 얻기 위한 리뷰를 잘하고 있는지, 우리의 리뷰를 개선하기 위해 어떤 시도를 해보았는지 스스로 돌아볼 필요성이 있다. 다른 조직에서 하고 있는 것들을 그대로 다 따라할 필요가 없다. 우리가 지속적으로 조금씩 나아지고 있는지, 그냥 형식적으로 따라하는 것을 시도하고 변화가 없는지를 점검해보는 것이 중요하다. 필자가 속한 조직에서도 리뷰와 관련해서 지속적인 개선 시도와 발전을 해왔는데, 단순히 현재 시점에 무엇을 하고있는가가 아닌 어떤 과정과 시행착오를 거쳐 발전시켜왔는지에 대한 이야기를 다음 글을 통해서 공유해보도록 하겠다. 참고 자료 Software Engineering at Google","categories":[],"tags":[{"name":"IT생각","slug":"IT생각","permalink":"https://wonderer80.github.io/tags/IT%EC%83%9D%EA%B0%81/"},{"name":"개발문화","slug":"개발문화","permalink":"https://wonderer80.github.io/tags/%EA%B0%9C%EB%B0%9C%EB%AC%B8%ED%99%94/"},{"name":"코드리뷰","slug":"코드리뷰","permalink":"https://wonderer80.github.io/tags/%EC%BD%94%EB%93%9C%EB%A6%AC%EB%B7%B0/"}]},{"title":"시니어 개발자가 선택할 수 있는 리더 포지션","slug":"시니어-개발자가-선택할-수-있는-리더-포지션","date":"2021-11-10T11:00:00.000Z","updated":"2026-04-13T13:36:46.816Z","comments":true,"path":"2021/11/10/시니어-개발자가-선택할-수-있는-리더-포지션/","permalink":"https://wonderer80.github.io/2021/11/10/%EC%8B%9C%EB%8B%88%EC%96%B4-%EA%B0%9C%EB%B0%9C%EC%9E%90%EA%B0%80-%EC%84%A0%ED%83%9D%ED%95%A0-%EC%88%98-%EC%9E%88%EB%8A%94-%EB%A6%AC%EB%8D%94-%ED%8F%AC%EC%A7%80%EC%85%98/","excerpt":"","text":"왜 리더로 성장해야 하는가?국내에서 개발자로 생활하면서 느꼈던 것은 많은 개발자들이 연차가 쌓이면서 관리자 역할을 하는 것에 대해 두려움을 느낀다는 것이었다. 관리자는 기술직이 아니며 관리자로 일한다는 것은 자신의 개발자로서의 전문성을 발휘하지 못하고 점점 도태된다고 느끼기 때문이다. 그렇기에 많은 개발자들은 자신이 백발이 될 때까지 개발을 하고 싶다는 환상을 가지고 있다. 반면 우리가 많은 회사에서 경험한 관리자들은 과거에 개발자였다가 어느 순간 관리자를 맡게 된 사람들이며, 주로 일정 관리나 여러 미팅에 참여하면서 기술적 전문성이 떨어지는 경우가 많았다. 더욱 큰 문제는 과거에는 이들이 한때는 뛰어난 개발자였기에 자기 중심적으로 판단을 내리는 경우가 많고 개발자들은 잘못된 판단임을 알면서도 어쩔 수 없이 따라야하는 상황들도 발생된다는 것이다. 이로 인해 피터의 법칙처럼 우리는 한명의 훌륭한 엔지니어를 잃고 무능한 관리자를 얻게 되는 경우가 많다. 그럼에도 불구하고 우리가 시니어 개발자로서 성장하면서 관리자(나는 개인적으로 리더라는 표현을 더 좋아한다)가 되어야 하는 이유는 그것이 개발자로서 나의 영향력을 넓혀 나갈 수 있는 방법이기 때문이다. 아무리 개발을 잘하는 개발자라고 해도 개인이 작성할 수 있는 코드에는 한계가 있다. 하지만 당신이 이끄는 개발팀의 많은 개발자들이 훌륭한 코드들을 만들어낼 수 있도록 돕는다면 한명의 개인으로서 코딩을 하는 것보다 훨씬 큰 효과를 만들어낼 수 있다. 그럼 우리가 개발자로서 선택할 수 있는 리더 포지션인 엔지니어링 매니저와 테크리드는 어떤 것일까? 테크리드에 대해서는 한번쯤 들어본 개발자들이 있을 수 있지만 엔지니어링 매니저는 한번도 들어보지 못한 사람들도 많을 것이다. 물론 테크리드라는 포지션 역시 막연하게 기술을 리드하는 개발자 같은 느낌일 뿐 구체적으로 어떤 역할을 해야하는지 모르는 경우가 많다. 그래서 오늘은 두 포지션의 역할과 비교를 해보고자 한다. Tech Lead많은 개발자들은 여전히 리더가 된다는 것에 부담을 느끼지만 만약 꼭 리더가 되어야한다면 테크리드로 성장하고 싶어한다. 왜냐하면 테크리드가 기존에 개발자로서 하는 일에 가깝다고 생각하기 때문이다. 사실 작은 조직에서는 테크리드라는 포지션이 필요없다. 어차피 개발자가 얼마 없고 스스로 모든 것들을 해야하기 떄문이다. 하지만 서비스가 성장하고 개발조직이 커지게 되면 기술적인 측면에서 리딩을 해야할 필요성이 생긴다. 모든 개발자가 어떤 기준이나 컨벤션 없이 저마다 만들고 싶은 방법과 사용하고 싶은 기술 스택으로 개발해나간다면, 퀄리티에 대한 기준이나 관리 없이 동작가능하게만 만들어나간다면, 서비스는 곧 정체되고 더이상 나아갈 수 없을 것이다. 테크리드는 여전히 일정시간을 코딩에 할애하지만 그것은 직접 문제를 해결하기 위함이 아니라 다른 개발자들이 문제를 해결하기 위한 환경을 만들기 위한 노력 중의 일부일 것이다. 우리는 좋은 개발자를 채용하기 위해 노력하지만 팀에는 다양한 역량과 경험을 가진 개발자들이 속한 조직으로 성장하게 되며 이들을 하나의 방향성으로 이끌어나가야 할 필요성이 생기게 된다. 테크리드는 개발자들의 생산성 향상과 품질 관리를 위해 힘써야 한다. 기술 컨벤션 논의를 이끌고 가이드를 작성해야 한다. 설계나 코드에 대한 리뷰를 직접 하기도 하고 리뷰 문화가 잘 활성화되도록 이끌어야 한다. 여러 팀에서 공통적으로 사용하는 기술을 표준화하고 공통 모듈을 개발하여 사용할 수 있게 하거나 공통 플랫폼을 제공할 수 있도록 해야 한다. 개발팀에서 사용하는 기술 스택들을 관리하고 노후화되지 않도록 전략을 짜야하고 개발자들이 역량을 키울 수 있도록 가이드 해야한다. 시스템 SLA를 수립하고 기술 부채를 어떻게 관리해나갈 것인지에 대한 프로세스를 수립해야 한다. 당신이 이런 것들에 관심을 기울이기 보다는 내 손으로 직접 기능을 개발하는 시간이 대부분이고 이런 부분들은 가끔 생각날 때 한번씩 한다면 테크리드라고 볼 수 없다. 이런 활동들은 엔지니어링 관점에서 매우 중요한 것들이지만 비지니스에 직접적인 영향을 미치지는 않고 급하지 않다고 판단되어 항상 우선순위가 뒤로 미뤄지게 되는 경향이 많다. 하지만 당신이 시니어 개발자로서 책임감 있는 사람이라면 이런 역할의 중요성을 인식하고 소홀히 하지 않도록 해야 한다. Engineering Manager테크리드는 주로 시스템이나 기술에 대한 부분을 주로 담당한다면 엔지니어링 매니저는 주로 사람을 돕는다. 사실 관리한다는 말은 요즘 시대에 맞지 않는다. 누군가가 나를 관리해줄 것이라는 기대는 버려야 한다. 우리 모두는 스스로가 관리자가 되어야 한다. 그럼에도 불구하고 엔지니어링 매니저가 필요한 이유는 뛰어난 프로선수들도 코치는 필요하기 때문이다. 엔지니어링 매니저는 개발자들이 잘 성장하고 회사에 만족하면서 기여할 수 있도록 돕는다. 1on1을 통해서 목표를 설정하는 것을 돕거나 구성원으로서 잘 성장할 수 있도록 피드백을 준다. 업무를 진행하는데 있어 방해되는 요소를 빠르게 파악하고 장애물을 제거한다. 이러한 것들을 수행하기 위해 엔지니어링 매니저는 소프트웨어 공학과 사람에 대한 깊은 이해를 가지고 개발 프로세스나 팀 문화를 만들고 성장해나갈 수 있도록 도와야 한다. 아쉽게도 개발자들이 테크리드에 비해 엔지니어링 매니저로 성장하기가 좀 더 어려운 이유는 있다. 먼저 엔지니어링 매니저가 하는 역할을 경험해본 적이 없다. 엔지니어링 매니저로서 역할을 수행해보기는 커녕 제대로 된 엔지니어링 매니저가 있는 환경에서 일해본적도 없다. 예를 들어 사람들과 1on1을 진행할 때 필요한 코칭 스킬이나 상담 기법에 대해 아는 것도 전무하다. 개발하면서 스탠드업 미팅이나 회고 같이 파편적으로 어떤 활동 들을 접해본적은 있으나 어떻게 문화를 만들어나가야 하는지 알지 못한다. 심지어는 칸반이나 스크럼을 사용한다는 조직에서 일을 해왔더라도 막상 내가 그것에 대해 제대로 알거나 공부해본 경우도 없다. 우리가 아는 관리자는 WBS 작성이나 간트차트를 그리면서 개발자들에게 업무가 얼마나 진행이 되었는지 확인하고 그래프를 채우는 모습밖에는 잘 알지 못한다. 하지만 테크리드의 역할은 테크리드가 없더라도 암묵적으로 일부 경험있는 개발자가 일정 역할을 수행하기도 하는 반면, 엔지니어링 매니저의 역할은 상대적으로 중요성을 인지하지 못하거나 아무도 수행하고 있지 않기 때문에 오히려 조직에서 크게 결여되는 부분이기도 하다. Tech Lead vs Engineering Manager이전 글에서도 소개한적이 있는 Engineering Ladder에 다음과 같이 두 역할을 비교한 좋은 내용이 있다.http://www.engineeringladders.com/TechLead-EngineeringManager.html Tech Lead (System) Engineering Manager (People) 기술적 탁월함과 혁신 경력관리를 위한 계획, 승진과 코칭 아키텍쳐와 시스템 통합 인원에 대한 계획과 고용 기술 멘토링, 채택 및 일치 팀 계획과 전달 기술적인 스파이크와 실험 목표, 성과와 피드백 코드 리뷰와 피드백 원온원 시스템 설계 발표 기술적인 결정에 참여 기술 생산능력 계획 상위 레벨과 관리 조직간의 커뮤니케이션 제품 이슈의 보고 팀 빌딩 활동과 문화 시스템 SLA, 지표와 모니터링 팀 보호와 행복 플랫폼 방향, 패턴과 연습 팀 생산력과 지표 다른 테크 리더와의 일치 다른 개발 매니저와의 일치 30%~70% 시간의 코딩 업무 시간의 0%~30% 시간의 코딩 업무 시스템 로드맵 (공유) 시스템 로드맵 (공유) 개발 프로세스 (공유) 개발 프로세스 (공유) 팀의 가시성과 인정 (공유) 팀의 가시성과 인정 (공유) 필요할 때 엔지니어링 매니저 역할도 가능한 능력 필요할 때 테크 리더 역할도 가능한 능력 작은 조직에서는 테크리드와 엔지니어링 매니저의 역할을 겸임하는 TLM(Tech Lead Manager)라는 역할도 있다고 한다. 두 역할의 상당 부분 중엔 겹치는 부분도 많고 상호베타적이지 않기 때문에 두 역할 모두 기술적인 이해를 기반에 갖추어야 하며 필요에 따라 양쪽의 역할을 겸임하거나 오갈 수 있어야 한다. 어떤 리더가 되고 싶은가?사실 포지션에 대한 이름이 중요한 것이 아니라 기술 리더로서 어떤 역할들을 수행해 나가야하는지가 중요하다. 테크리드나 엔지니어링 매니저가 우리 회사에 없더라도 이러한 역할을 누군가는 해야하는 중요한 것들이다. 내가 리더가 되고 싶지 않더라도 훌륭한 개발자로 성장하다면 결국엔 명시적이든 암시적이든 리더가 된다. 내가 명시적인 테크리드나 엔지니어링 매니저가 아니라고 해서 이런 역할을 수행하는 필요한 경험이나 역량이 필요없다는 것은 아니다. 뛰어난 개발자는 자기 일에만 집중하는 것이 아니라 큰 시야를 가지고 전체의 효율을 이끌어 내는 일들을 수행한다. 명시적인 리더가 아니더라도 리더들이 하는 역할을 잘 이해하고 돕는 사람이 된다면 리더에게도 굉장히 감사하고 큰 도움이 되는 개발자가 된다. 뿐만 아니라 실리콘밸리의 유명 IT 회사들의 Career Levels가 보여주듯이 결국 높은 레벨로 올라갈수록 리더의 역할을 할 수밖에 없게 된다. 그리고 냉정하게 생각해보자. 연차도 많고 나이도 많은데 할 수 있는 역할은 그저 개인의 개발자로서 코딩밖에 할 수 없다면, 그리고 그런 역할은 보다 나이 어리고 연차가 적은 사람도 할 수 있다면 어떤 경쟁력이 있을까? 많은 경력 개발자들이 면접 때 본인의 장점에 대해 이야기할 때 이런 이야기를 한다. ‘다양한 개발을 경험해왔고 빠르게 기술을 습득하고 적응하며 도입할 수 있다’ 라는 늬앙스의 이야기를 한다. 난 솔직히 이건 그냥 기본이라고 생각한다. 결국 내가 기존에 얼마나 많은 영향력을 발휘했고 팀에 기여하는 활동을 했는지, 어떤 리더십을 발휘했고 어떤 시도와 실패를 경험해봤는지를 말할 수 없다면 시니어 개발자를 채용할 필요가 없을 것이다. 참고 자료 http://www.engineeringladders.com/ https://blog.banksalad.com/tech/engineering-manager-role-growth/ https://sendbird.com/ko/blog/eng-leader-role-1","categories":[],"tags":[{"name":"IT생각","slug":"IT생각","permalink":"https://wonderer80.github.io/tags/IT%EC%83%9D%EA%B0%81/"},{"name":"커리어","slug":"커리어","permalink":"https://wonderer80.github.io/tags/%EC%BB%A4%EB%A6%AC%EC%96%B4/"}]},{"title":"경쟁력있는 시니어 개발자로 성장하는 방법","slug":"경쟁력있는-시니어개발자로-성장하는-방법","date":"2021-10-13T14:00:00.000Z","updated":"2026-04-13T13:36:46.815Z","comments":true,"path":"2021/10/13/경쟁력있는-시니어개발자로-성장하는-방법/","permalink":"https://wonderer80.github.io/2021/10/13/%EA%B2%BD%EC%9F%81%EB%A0%A5%EC%9E%88%EB%8A%94-%EC%8B%9C%EB%8B%88%EC%96%B4%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%A1%9C-%EC%84%B1%EC%9E%A5%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95/","excerpt":"","text":"개발자가 귀한 시대이다. 여러 IT 회사들이 개발자를 모시기 위해 경쟁을 하고 있다.국내에서는 여전히 생소한 용어지만 나름 이름 있는 IT 회사들은 Developer Relations(DevRel) 라고 하는 대외 개발자들을 대상으로 홍보하는 조직을 구성하여 운영하거나 최소한 HR팀에서 개발자 채용이나 홍보 등을 전담으로 하는 경우도 많이 있다. 필자도 얼마전 T사에서 근무하는 지인이 개발자 채용에 관련해서 조언을 구하기도 했다. 하지만 이 역시 빈익빈부익부 현상이 존재한다. 과거에는 영세한 IT 회사들이 돈이 없다보니 오히려 똘똘한 신입을 채용해서 가르쳐서 써야겠다는 생각들을 하는 곳도 있었지만 지금은 IT 업계에 자금이 넘쳐나다보니 바로 업무에 투입될 수 있는 경력직을 훨씬 선호한다. 그리고 경력직 안에서도 과거부터 현업에서 가장 가성비가 좋다고 했던 대리급 직원에 해당하는 연차가 4-6년차 정도 되는 개발자인 것 같다. 보통 4-6년차 정도 되면 어느 정도 소프트웨어 개발의 전반적인 부분을 경험하고 시간만 있다면 무엇이든 만들 수 있다는 자신감이 붙는 시기이다. 또한 이 정도 시기까지는 비교적 반복적인 경험보다는 새로운 경험을 많이 해왔기 때문에 연차와 실력이 어느 정도 상관관계를 유지할 수 있는 연차라고 생각한다. 개발자 커리어와 시니어의 현실문제는 그 이후라고 볼 수 있다. 개발자들과 관련된 통계 데이터를 보면 40대 이상은 최근의 여러 통계에서 최대 15%가 넘지 않는다. 어느 정도 오차가 존재할 수 있다고는 해도 여기에서 크게 벗어나지는 않을 것이다. 요즘같은 100세 시대에서 40대에 은퇴를 생각해야 한다는 것은 참으로 암담한 일이다. 왜 이런 일이 발생할까? 필자가 개발자 채용을 위해 10년 이상의 경력을 지닌 개발자의 인터뷰에 참여하다보면 연차에 비해 너무나도 부족한 경험과 역량에 큰 실망을 하고 나오는 경우가 많다. 누구나 개발자로 열심히 살아가다보면 4~6년차에 비교적 잘나가는(?) 시절이 온다. 그렇기 때문에 이제까지 해왔던 것처럼 열심히 일하면 계속 인정받을 수 있을 것이라는 착각을 하게 된다. 문제는 그저 그렇게 열심히 일하기만 한다면 이제까지 해왔던 반복적인 경험에 그치게 된다는 것이다. 뿐만 아니라 잘못된 습관이 배어있거나 개인의 경험에서 비롯되는 확증편향을 지니고 있는 경우도 많다. 역량을 향상시키려면 단순히 열심히 일하거나 지식을 쌓는 것만이 아니라 의도적 수련 이 필요하다. 그런데 의도적 수련도 필요하지만 어떤 역량을 향상시켜야 할지도 고민이다. 앞으로 어떤 역할들을 수행해나갈 것인가에 따라 발전시켜야 하는 역량도 달라질텐데 이러한 개발자 커리어에 대해 명확하게 누군가 제시해주는 경우도 드물다. 작은 IT 회사에서는 개발자를 주니어/시니어로 나누기도 하고 주니어/미들/시니어 로 나누기도 하는데 대략 3년차 정도까지는 주니어, 4년차 이상부터 미들, 10년차 이상을 시니어급 정도로 생각하는 것 같다. 근데 문제는 미들과 시니어가 어떤 차이가 있는지 개발자는 물론 회사에서도 명확하게 정의를 못내리는 경우가 많다보니 어떤 역량을 내가 향상 시켜야하는지 알기 어렵다. 필자 역시 그런 고민의 과정을 거쳤고 많은 시행착오를 거쳐왔다. 그래서 이제는 나를 비롯하여 같이 일하는 후배들이 길을 잃지 않도록 어떻게 커리어를 설계하고 방향을 제시해야하는지 고민을 많이 해왔다. Career Ladder실리콘밸리의 유명 IT 회사들은 저마다의 커리어 레벨과 보상체계를 가지고 있는데 구체적으로 레벨 별 필요 역량과 역할을 설명해주는 글은 찾기 어려웠다. 다만 작년에 참고할 수 있는 좋은 자료를 하나 발견하게 되었는데 Engineering Ladders 라고 하는 프레임워크이다. 좋은 자료라고 판단되어 회사 동료들과 한글로도 번역했으니 영문이 어려운 분들은 부족하나마 참고해주었으면 좋겠다. Engineering Ladder를 보면 Level, Seniority, Ladder로 구분했는데 여기서 Seniority를 보면 Senior 단계에서부터 Lead 급 Ladder 에 대한 역할들이 추가 된다. Tech Lead는 비교적 익숙한 표현인 반면 Engineering Manager는 국내에선 여전히 생소한 역할이다. 물론 Tech Lead 역시 익숙한 표현일뿐 구체적으로는 어떤 역할을 해야하는지 잘 모르고 그저 개발 역량이 뛰어난 사람 정도로 이해하는 경우가 많다. Software Engineering at Google을 보면 구글에서도 하나의 팀에는 Tech Lead와 Engineering Manager로 구성된 리더가 존재한다고 한다. 이러한 리더들은 굉장히 중요하고 넓은 영향력을 끼치게 되므로 팀에서 매우 중요한 역할을 하게 된다. 개발자로서 선택할 수 있는 커리어 단계로 이 두가지를 언급한 이유는 우리가 한명의 개발자 개인으로서 팀에 기여하는데에는 한계가 있기 때문이다. 개발자간의 생산성은 개인 간에 20배 이상의 차이도 있다고는 하지만 그것이 연차와 비례한다는 이야기는 아니다. 개인이 낼 수 있는 퍼포먼스에는 한계가 있기 때문에 냉정하게 보았을 때 회사에서도 굳이 역할이나 생산성 측면에서 큰 차이가 없는데 몸값은 비싸고 나이도 많은 개발자를 채용했을 떄의 메리트는 떨어진다. 물론 Engineering Ladder 에서도 Developer 로서의 Ladder 도 제안하고 있지만 나는 개인적으로 특정 기술에 대한 스페셜리스트로서 경력을 쌓아온 것이 아니라고 한다면 일반적인 IT 서비스 회사에서 높은 레벨의 Developer 로 성장하기는 쉽지 않다고 생각한다. 뿐만 아니라 결국 Developer 도 높은 레벨에 도달하려면 Tech Lead나 Engineering Manager가 갖춰야하는 역량을 지녀야 한다. 일정 수준 이상의 전문성을 갖추려면 결국 넓은 시야와 경험을 갖춰야하기 때문이다. 오늘은 시니어 개발자로서 고려할 수 있는 커리어 래더에 대해 간단한게 소개를 해보았다. 다음 글에서는 Tech Lead 와 Engineering Manager는 어떤 역할을 수행하며 어떤 역량을 갖춰야하는지 구체적으로 이야기해보도록 하겠다. 참고 자료DevRel http://channy.creation.net/blog/1194 https://techblog.woowahan.com/3799/ https://engineering.linecorp.com/ko/blog/line-plus-developer-relations-team/ 개발자 통계 https://insights.stackoverflow.com/survey/2021#developer-profile-demographics https://www.jetbrains.com/ko-kr/lp/devecosystem-2021/demographics/ https://programmers.co.kr/pages/2021-dev-survey#dev-part-2","categories":[],"tags":[{"name":"IT생각","slug":"IT생각","permalink":"https://wonderer80.github.io/tags/IT%EC%83%9D%EA%B0%81/"},{"name":"커리어","slug":"커리어","permalink":"https://wonderer80.github.io/tags/%EC%BB%A4%EB%A6%AC%EC%96%B4/"}]},{"title":"엔지니어링의 생산성은 어떻게 측정하나?","slug":"엔지니어링의-생산성은-어떻게-측정하나","date":"2021-07-14T13:00:00.000Z","updated":"2026-04-13T13:36:46.816Z","comments":true,"path":"2021/07/14/엔지니어링의-생산성은-어떻게-측정하나/","permalink":"https://wonderer80.github.io/2021/07/14/%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81%EC%9D%98-%EC%83%9D%EC%82%B0%EC%84%B1%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%B8%A1%EC%A0%95%ED%95%98%EB%82%98/","excerpt":"","text":"필자가 다니고 있는 회사는 소위 매트릭스 조직으로 운영을 하고 있다. 개발자는 교차 기능팀(Cross-functional Team)에서 공동의 목표를 가지고 가설과 실험을 통해 신규 기능 개발을 하거나 기존 기능의 개선 업무를 수행하거나 기능팀(Functional Team)에서 개발자들의 생산성 향상을 위한 레거시 개선 및 개발 환경 개선을 위한 업무를 수행할 수 있다. 대부분의 IT기업에서 개발자는 한정적이고 하고 싶은 혹은 해야만 하는 일들은 많기 때문에 어떤 일을 우선적으로 해야 하는지에 대한 가치 판단 및 우선순위 설정은 매우 중요하다. 교차 기능팀의 경우 서비스의 가치를 높이는 것이 주요한 목표이므로 최근 많은 스타트업들이 사용자 데이터에 기반하여 가설을 세우고 사람들의 반응을 살펴보며 방향성을 잡거나 우선순위를 매긴다. 그럼 생산성 향상을 목표로 해야 하는 경우에는 어떤 방식으로 우선순위를 설정해야 할까? 고민을 하던 중 최근 Software Engineering at Google 에서 ‘Measuring Engineering Productivity’ 라는 챕터의 내용을 보며 들었던 생각을 책의 내용과 함께 적어보고자 한다. 생산성을 꼭 측정해야 하는가?어떤 작업으로 인해 향상되는 생산성을 어떻게 측정해야 하는지를 이야기하기 전에 매우 중요한 질문이다. 왜냐하면, 생산성을 측정하는 것은 측정하는 것 자체에도 많은 비용이 들어가기 때문에 생산성을 측정함으로 인해 얻을 수 있는 가치에 대해 생각해봐야 한다. 또한 측정한 결과가 긍정적이든 부정적이든 그 결과에 따른 행동이나 결정에 변화가 없다면 측정할 가치가 없을 가능성이 높다. 생산성을 어떻게 측정할 것인가?과거에는 정해진 시간 안에 얼마나 많은 코드를 생산했는지(LOC)를 판단하던 시기도 있었지만, 최근엔 아무도 코드의 라인수를 통해서 생산성을 측정하려 하지 않을 것이다. 그렇다면 구글에서는 어떤 방식을 사용했을까? 구글에서는 GSM(Goals/Signals/Metrics) Framework를 이용한다고 한다. 개인적으로 요즘 많은 스타트업이 도입하고 있는 OKR과 비슷한 관점이라는 생각이 든다. GSM 이 어떤 것인지 더 알아보자. 목표(Goals)목표는 그 자체로는 측정할 수 없지만 모든 사람이 동의하는 것이여야 한다고 한다. 다만 생산성에 영향을 끼치는 요소는 다양하고 하나의 요소를 향상시키는 작업이 다른 요소는 저하시키는 상황이 벌어질 수 있기 때문에 구글에서는 “QUANTS” 라고 하는 다섯 가지의 요소로 분류하여 판단한다고 한다.(특성에 따라 해당하지 않는 항목이 있을 수도 있다고 한다) Quality of the code(코드의 품질)이 작업을 통해서 코드의 품질이 개선되는지를 의미한다. Attention from engineers(엔지니어의 집중)엔지니어들의 집중도를 향상시키는지 혹은 산만하게 만드는지를 의미한다. Intellectual complexity(지적 복잡성)업무를 완수하는데 있어서 어느 정도의 인지적 부하를 발생시키는지, 문제를 해결하기 위해 불필요한 처리를 하거나 내재되어 있는 복잡도를 얼마나 이해해야 하는지에 대한 상태를 의미한다. Tempo and velocity(주기와 속도)개발을 완료하는데 드는 속도와 주기의 측면을 의미한다. Satisfaction(만족)자신의 작업이나 제품에 대해 얼마나 만족감을 느끼는지에 대한 부분을 의미한다. 신호(Signals)신호는 목표를 달성했는지를 판단할 수 있는 기준이다. 다만 이 단계에서 모든 신호가 측정 가능한 것은 아니라고 한다. 즉, 정량적으로 측정되지 않아도 정성적으로 판단되거나 보여지는 어떤 현상을 의미할 수 있다. 하나의 목표에는 최소한 하나 이상의 신호가 존재하며 하나의 신호가 여러 목표에 공유될 수도 있다고 한다. 측정항목(Metrics)측정항목은 신호의 측정 가능한 proxy 라고 한다. proxy 라는 것이 완전히 일치함을 뜻하는 것은 아니기 때문에 하나의 신호에는 그것을 대표하는 여러 측정항목이 존재할 수 있으며, 일부 신호에는 측정항목이 존재하지 않을 수도 있다. 신호가 나타내는 것과 측정항목이 다른 경우가 발생할 수도 있는데 이는 잘못된 측정항목이 문제일 수도 있고, 인지적 편향에서 발생할 수도 있기 때문에 다양한 측정 항목등을 통해 검증이 필요할 수 있다. 훌륭한 엔지니어링 환경 만들기IT 기업에서 새로운 기능을 추가하는 일은 비지니스 관점에서의 가치와 쉽게 연결되며 전사레벨에서의 목표 과제가 되는 반면 엔지니어링 환경 개선을 위한 작업들은 개발자들 개개인의 의지로 짬짬이 이루어지거나 특별한 우선 순위 없이 개인의 흥미 위주나 하기 쉬운 과제 중심으로 이루어지기 쉽다. 하지만 엔지니어링 환경 개선을 위한 작업들은 단순히 개개인의 취향의 문제로 다루어져서는 안 되며 조직의 생산성 향상에 얼마나 기여하는지에 따라 우선순위가 정해져야 할 것이다. 또한 그 작업을 수행하는 개발자들 역시 그러한 작업이 가져오는 효과와 의미에 대해 잘 이해하고 내가 그 작업을 통해 조직에 어느 정도의 기여를 하고 있는지 이해하는 것이 동기부여에도 중요하다고 생각한다. IT 조직 내에서 개발 환경 개선을 위한 작업을 계획하고 있다면 위의 내용들을 고려해서 그에 대한 중요성을 설명하고 우선순위를 잡아보면 어떨까 싶다.","categories":[],"tags":[{"name":"IT생각","slug":"IT생각","permalink":"https://wonderer80.github.io/tags/IT%EC%83%9D%EA%B0%81/"},{"name":"개발문화","slug":"개발문화","permalink":"https://wonderer80.github.io/tags/%EA%B0%9C%EB%B0%9C%EB%AC%B8%ED%99%94/"},{"name":"생산성","slug":"생산성","permalink":"https://wonderer80.github.io/tags/%EC%83%9D%EC%82%B0%EC%84%B1/"}]},{"title":"당신이 아무리 공부해도 개발 실력이 늘지 않는 이유","slug":"당신이-아무리-공부해도-개발-실력이-늘지-않는-이유","date":"2021-06-23T13:11:08.000Z","updated":"2026-04-13T13:36:46.816Z","comments":true,"path":"2021/06/23/당신이-아무리-공부해도-개발-실력이-늘지-않는-이유/","permalink":"https://wonderer80.github.io/2021/06/23/%EB%8B%B9%EC%8B%A0%EC%9D%B4-%EC%95%84%EB%AC%B4%EB%A6%AC-%EA%B3%B5%EB%B6%80%ED%95%B4%EB%8F%84-%EA%B0%9C%EB%B0%9C-%EC%8B%A4%EB%A0%A5%EC%9D%B4-%EB%8A%98%EC%A7%80-%EC%95%8A%EB%8A%94-%EC%9D%B4%EC%9C%A0/","excerpt":"","text":"당신이 아무리 공부해도 개발 실력이 늘지 않는 이유지식은 기술이 아니다백엔드 개발자 4년 차인 A 씨는 퇴근 후에 자기 개발을 위해 기술 도서를 꾸준히 읽는다. 최근에는 리팩토링이라는 책을 읽고 사내의 개발자들에게 자신이 공부한 것에 대해 발표도 했다. 하지만 아쉬운 점도 있다. 마음만 먹으면 언제든 리팩토링 할 수는 있지만 항상 바쁜 일정 때문에 리팩토링 할 시간이 없다. 사실 지금도 그럭저럭 잘 돌아가고 있는데 리팩토링을 한다고 새로운 비지니스 가치가 더해지는 것도 아니니 그 시간에 새로운 기능을 하나 더 만드는게 낫지 않나 싶기도 하다. 이전엔 테스트주도개발이라는 책을 읽고 실무에 적용해보려고 했지만, 이 역시 막상 실무에 사용해보려고 하니 시간이 너무 많이 걸려서 실효성이 없어 보였다. Ruby on Rails로 유명한 DHH 가 ‘TDD 는 죽었다‘ 라는 글을 썼다는 걸 보니 실제로 실효성이 없는 것 같다는 생각도 들었다. 개발자 A 씨는 리팩토링과 TDD 에 대해 어느 정도의 기술(skill)을 가지고 있을까? A 씨는 지식은 풍부하지만 기술을 가진 것은 아니다. 왜냐하면 기술은 지식 자체에서 오는 것이 아니라 지식에 기반하여 훈련하고 실행하는 과정에서 습득되는 것이기 때문이다. skill 에 대한 영영사전에 의미를 보면 다음과 같다. an ability to do something well, especially because you have learned and practised it practise는 practice 와 같은 의미인데 연습하다, 훈련하다의 의미를 지니고 있다. 기술은 훈련과 실천의 과정에서 습득되며 기술로서 활용될 때 가치를 얻게 된다. 그래서 나는 우리 팀원들에게 항상 ‘지식은 기술이 아니다’ 라는 이야기를 꼭 한다. 규율 * 기술 = 역량Management 3.0 에 ‘규율 * 기술 = 역량’ 이라는 내용이 있다. 개인적으로는 무릎을 탁치게 하는 공식이라고 생각했다. 앞에서 분명 지식은 기술이 아니라고 했다. 그럼 기술만 있으면 전문가로서의 역량이 뛰어나다고 볼 수 있을까? 그것만으로는 뭔가 좀 부족하다. 엔진 점검을 자주 잊어버리는 조종사, 손씻기를 뺴먹는 외과 의사, 도마나 칼을 제대로 닦지 않는 요리사는 어떤가? 저런 부분들은 기술도 아니고 한 두번 깜박한다고 당장 큰일이 생기지는 않을 것이다. 하지만 이런 부분들이 전문가들은 중요한 규율 중에 하나라는 것을 잘 알고 있기 때문에 의식하지 않아도 자연스럽게 행할 수 있도록 노력한다. 개발자들에게 있어 규율은 어떤 것들이 있을까? 언어나 팀에서 지정한 컨벤션을 준수하거나, 개발한 내용에 대한 테스트 수행, 클린 코드를 위한 네이밍 규칙, 사용하지 않는 코드나 주석의 제거, 불필요한 임시 변수의 할당 등 여러가지가 있을 것이다. 이것들은 기술이라고 볼 수는 없지만 좋은 품질의 개발을 하는데 있어서 필요한 요소들이다. 사소한 차이가 명품을 만든다여러 개발자를 만나다보면 생각보다 많은 개발자가 개발 고수에 대한 잘못된 환상을 가지고 있다는 생각을 하게 되었다. 개발 고수는 남들이 잘 모르는 특별한 기술을 가지고 있다고 생각하는 것이다. 그래서 자신도 언젠가 그런 고수를 만나 마치 무협지에서 은거하고 있단 무림 고수를 만나 아무에게도 전수되지 않은 무공을 습득하는 모습을 기대한다. 하지만 현실에서의 고수는 그런 모습이 아니다. 누구나 머리로는 알고 있지만 여러 이유로 하지 않는 아주 작고 사소한 것들을 당연한 듯이 해나가는 사람이다. 요리 경력이 40년이 넘은 중식 전문 쉐프인 이연복 쉐프가 자신의 노하우가 담긴 레시피를 공개하는 것을 보고 누군가가 레시피를 다 가르쳐줘도 되냐는 질문에 그는 다음과 같이 대답한다. 식당을 창업하기 위해 레시피를 최소 수백에서 수천만원의 돈을 주고 구매한다고 한다. 그럼에도 불구하고 이연복 쉐프가 자신의 레시피를 공개하는 이유는 자신의 요리의 가치는 단순히 레시피에서 오는 것이 아니라 오랜 세월동안 다져진 본인의 역량에서 온다는 것을 알기 때문일 것이다. 나는 개발자의 역량을 향상시키기 위해서는 항상 내가 하는 일과 맞닿아있는 부분 안에서 새로운 것을 찾아내고 시도해야 한다고 생각한다. 내가 실제로 사용하지 않는 기술 지식을 공부하는 것은 교양의 측면에서 도움이 될 수는 있으나 내 기술이 되기는 어렵다. 초보자 딱지를 벗고 나면 무엇이든 만들 수 있겠다는 자신감이 들지만 그게 끝이 아니다. 명품과 짝퉁의 차이는 생각보다 아주 작은 차이에서 온다. 그 한없이 작고 사소한 것의 차이들이 누적되어 발휘되는 결과이다. 언제든 내가 마음만 먹으면, 혹은 어떤 환경이 주어지면 할 수 있다고 생각한 많은 것들은 착각이다. 그런 상황은 오지 않는다. 뛰어난 개발자는 어떠한 상황인지를 따지지 않고 그냥 해내는 사람이다. 그리고 지식이 아니라 결과를 통해 피드백을 받고 학습하게 된다. 그동안 이런 저런 핑계로 머리로는 알고 있었지만 실천하지 않고 있었던 것들이 있었는가? 혹은 이제는 더이상 내가 다루고 있는 기술 스택이나 도메인에서 배울 부분이나 개선할 부분이 없다고 생각하지는 않았는가? 이 글을 통해 자신을 되돌아보는 기회가 되면 좋을 것 같다.","categories":[],"tags":[{"name":"IT생각","slug":"IT생각","permalink":"https://wonderer80.github.io/tags/IT%EC%83%9D%EA%B0%81/"}]},{"title":"IT기업의 6가지 문화패턴","slug":"IT기업의-6가지-문화패턴","date":"2021-05-12T13:00:00.000Z","updated":"2026-04-13T13:36:46.814Z","comments":true,"path":"2021/05/12/IT기업의-6가지-문화패턴/","permalink":"https://wonderer80.github.io/2021/05/12/IT%EA%B8%B0%EC%97%85%EC%9D%98-6%EA%B0%80%EC%A7%80-%EB%AC%B8%ED%99%94%ED%8C%A8%ED%84%B4/","excerpt":"","text":"최근 IT 기업에서 개발자들을 모시기 위한 경쟁이 치열해지고 있다. 개발자들이 회사를 선택할 때 보는 요소 중에 금전적인 부분도 중요한 요소 중의 하나일 수는 있겠지만 좋은 개발문화를 가지고 있는지도 개발자들에게 중요한 관심사 중의 하나이다. 좋은 개발 문화에서 일할 때 개발자로서의 높은 성장도 기대할 수 있다고 믿기 때문이다. 그렇기 때문에 회사들은 몸값 경쟁 이외에도 회사의 개발문화를 홍보하기 위한 노력도 많이 기울이고 있다.근데 좋은 개발문화라는 것은 무엇일까? 애자일 프로세스를 적용하고 있다든지, 코드 리뷰를 한다든지, 회고를 한다든지와 같은 몇 가지 활동만을 보고 판단하기에는 참 모호한 부분이 많다. 내부에서 개발문화를 발전시키려고 하는 입장에서는 더욱 그렇다. 어떤 것을 시도하면 좋은 개발문화로 향하는 것인지 판단하기가 쉽지 않다.그런 면에서 IT 업계에서도 CMMi 나 SPICE 같은 성숙도 모델을 만들고 해당 모델에 기반하여 수준을 높이려는 노력을 하기도 했다. 오늘은 이러한 모델 중 QSM1 에서 설명하는 6가지 문화 패턴을 소개하고 내 생각을 함께 적어보고자 한다. Oblivious: “우리는 프로세스를 수행하고 있다는 사실조차 모른다.” Variable: “우리는 그 순간에 좋다고 느끼는 것을 수행한다.” Routine: “우리는 루틴을 따른다(패닉에 빠질 때를 제외하고).” Steering: “우리는 결과에 따라 우리의 루틴들 중 하나를 선택한다.” Anticipating: “우리는 과거에 경험한 루틴에 기반하여 루틴들을 수립한다.” Congruent: “모든 사람은 항상 모든 것을 개선하는데 참여한다.” 6가지의 종류라고는 했지만, 현실적으로 보여지는 패턴은 3까지라고 한다. 패턴0: Oblivious패턴 0 은 기업 안에 별도의 소프트웨어 개발 조직이 존재하지 않으며, 본인이 “소프트웨어 개발”을 하고 있다는 사실조차 인지 못한 채 소프트웨어 개발을 하고 있는 상황이다. 예를 들어 엑셀에 능숙한 어떤 직원은 lookup 테이블이나 VBA를 활용하여 고객을 관리하고 시각화하는 일을 처리하고 있지만 이러한 업무가 소프트웨어 개발과 관련성이 있다고 인지하지 못한다. 패턴1: Variable이 패턴에서의 이미지는 “슈퍼 개발자”이다. “슈퍼 개발자”가 모든 문제를 해결해줄 것이라고 믿고 있으며 나머지 개발자들은 “슈퍼 개발자”를 서포트하기 위해 존재한다. 초기 스타트업에서 자주 보이는 패턴으로 창업 때부터 기여한 “슈퍼 개발자”가 존재하며 조직이 커져 새로운 문제가 발생되더라도 새로운 “슈퍼 개발자”가 나타나 문제를 해결해주기를 기대한다. 패턴1 에서의 성과는 전적으로 개인의 노력에 의존하기 때문에 일정과 비용의 변동성은 개인의 변동성에 달려있으며 특히 “슈퍼 개발자”의 일정에 대한 의존도가 크다. 개인을 대상으로 한 연구에서 일정, 비용, 오류 등에 대한 변동 수준은 지속적으로 20배 이상의 변동을 보여왔기 때문에 그와 같은 리스크를 지니고 있다고 볼 수 있다. 개인적으로 이 조직이 변화하기 어려운 이유 중에 하나는 조직 내 높은 영향력을 가지고 있는 “슈퍼 개발자”가 변화를 원치 않는 경우가 많기 때문 인 것 같다. 사실 개발자라면 누구나 한번쯤은 빠르고 멋지게 기능을 만들어서 인정받고 싶은 욕구가 있을 것이다. 그러나 인정받고 싶은 욕구로 인해 한 행동들이 조직 차원에서 안좋은 결과를 가지고 온다는 것을 인지하는 경우는 드물다. 이 패턴에서의 다른 특징은 서로가 무슨 일을 하고 있는지 잘 모르며, 팀의 표준환경이나 개발도구도 없이 제각각 사용하게 된다. 이 패턴에서 사람들이 요구하는 것들은 일반적으로 다음과 같다. “무엇을 원하는지 명확하게 말해달라(그리고 나중에 바꾸지 말아달라)” “우리가 필요로 하는 자원을 제공해달라(그리고 우리가 요청할 때마다 계속 지원해달라)” “우리를 귀찮게 하지 말아달라(모든 불확실성을 제거해달라)” 패턴2: Routine(but Unstable)이 패턴에서의 이미지는 “슈퍼 관리자”이다. 패턴 1에서 조직이 커지기 시작하면서 개발자들 개개인을 관리할 필요성이 있다고 느껴질 때 발생한다. 이 패턴 의 관리자는 패턴 1의 “슈퍼 개발자”가 자연스럽게 맡는 경우가 많은 것 같다. 다만 개발을 잘 하는 것과 관리를 잘하는 것은 다른 영역이기 때문에 많은 문제가 생기게 된다. 일반적으로 본인의 경험을 기준으로 지나친 일반화를 하는 경우가 많으며, 거기에서 발생되는 예외를 무시하고 정해진 루틴을 그대로 수행하려고 하는 경우가 많다. 그러다 문제가 크게 터지면 다시 패턴1 로 회귀하게 되는 경우도 발생된다. 패턴2에서 잘못된 확신성을 가지게 되는 이유 중 하나는 핵심 사고 패턴이 선형적이기 때문이다. 어떠한 결과는 하나의 원인에서 기인한다는 생각을 가지고 있는데 이러한 오해에서 나온 해결책은 단기적으로는 문제가 해소된 것처럼 보이나 장기적으로 더 큰 문제를 가져오는 경우가 많다. 패턴3: Steering패턴3의 관리자는 패턴2의 관리자에 비해 좀 더 전문성을 가지고 있다. 패턴2의 관리자는 “말로 하는 관리” 이외에 별다른 기술을 가지고 있지 않은 경우가 많다. 패턴3의 관리자는 다양한 기술을 기반으로 상황에 맞는 대처를 할 수 있다. 불확실성이 적은 상황에서는 패턴2의 관리자와 큰 차이가 없이 느껴질 수 있기 때문에 종종 패턴2에서 일이 잘 풀리면 패턴3로 착각하기 쉽다고 한다. 둘 다 계획된 절차를 사용하지만 패턴3 에서만이 계획에서 벗어난 상황에서 효과적으로 대응하는 방법을 알고 있다고 한다. 패턴4: Anticipating패턴4의 관리자는 패턴3와 비슷하지만 품질관리에 대해 더 높은 수준의 이해를 가졌다고 한다. 패턴5: Congruent패턴5는 최고 수준의 품질 관리를 유지한다고 하며 품질 관리를 회사 시스템의 필수 부분으로 간주한다고 한다. 패턴5의 조직은 구성원들이 프로세스의 지속적인 개선과 최적화에 기여할 수 있는 기반을 제공하며 구성원들은 항상 모든 것에 개선하는데 기여한다고 한다. 위의 6가지 패턴 중 내가 속한 조직의 문화 패턴은 어디에 속해있다고 생각하는가? 일반적인 IT 기업이라면 1-3의 패턴을 가지고 있을 것이다. 얼핏 보기에 아래로 갈 수록 더 좋은 문화라고 볼 수 있을 것 같지만 사실 어느 한쪽이 꼭 우월하다고 볼 수는 없다. 조직의 규모나 상황에 따라 적절한 패턴이 존재하는데 이러한 패턴을 인지하고 조직의 변화에 따라 적절하게 변화를 할 수 있는지가 중요할 것 같다. 3-4명으로 시작한 스타트업에서는 패턴1이 충분할 수 있지만 스타트업이 성공해서 100명 이상의 규모로 성장했음에도 불구하고 여전히 패턴1을 벗어나지 못하는 경우도 많이 보아왔다. 이들은 과거에 성공한 경험을 가지고 있기 때문에 변화의 필요성을 받아들이기 어렵게 되고 그렇게 정체되거나 도태되는 상황을 겪기도 한다. 다음에는 패턴을 변화하기 위해 필요한 것이 무엇인지 다뤄보도록 하겠다.","categories":[],"tags":[{"name":"IT생각","slug":"IT생각","permalink":"https://wonderer80.github.io/tags/IT%EC%83%9D%EA%B0%81/"},{"name":"개발문화","slug":"개발문화","permalink":"https://wonderer80.github.io/tags/%EA%B0%9C%EB%B0%9C%EB%AC%B8%ED%99%94/"}]},{"title":"소프트웨어 품질이란 무엇일까?","slug":"품질이란-무엇일까","date":"2021-04-14T14:28:12.000Z","updated":"2026-04-13T13:36:46.817Z","comments":true,"path":"2021/04/14/품질이란-무엇일까/","permalink":"https://wonderer80.github.io/2021/04/14/%ED%92%88%EC%A7%88%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C/","excerpt":"","text":"오래전부터 개발자로서 품질에 대한 고민이 많았다. 나에게 좋은 품질이라고 한다면 버그가 없는 코드를 의미했고, 유지보수하기 쉬운 설계와 코드, 기획 의도가 잘 구현된 것을 의미했다. 나는 품질이 높은 코드를 만들고 싶었지만, 현실은 항상 녹록하지 않았다. 항상 시간에 쫓겨서 만들어야 했고 품질을 유지하기 위해서는 비개발자 뿐만 아니라 동료개발자도 설득해야만 했다. 나에겐 명확하게 보이는 것들이 많은 설득을 하거나 내 개인 시간을 할애하면서까지 품질을 유지해야 한다는 것이 이해가 되지 않았다. 오늘은 이런 여러 고민을 해결하기 위한 몇 가지 실마리를 안겨준 QSM(Quality Software Management) Vol1 에 있는 ‘What is Quality? Why is it important?’라는 챕터의 내용을 요약 및 내 생각을 정리해보고자 한다. 품질의 정의 결함이 없는 것이 고품질이다 많은 기능이 있는 것이 고품질이다 우아한 코드로 만들어진 것이 고품질이다 빠르게 개발할 수 있는 것이 고품질이다 유저 친화적인 것이 고품질이다 여러분은 어떤 것이 품질을 가장 잘 나타낸다고 생각하는가? 혹은 어떤 것은 품질을 나타내는 것이 아니라고 생각이 드는 것은 있는가? 아니면 모든 것을 종합적으로 고려된 것이 품질이라고 생각이 들 수도 있겠다. 품질의 상대성Quality is value to some person 품질을 정의하는 여러 관점이 있지만, 개인적으로 이 표현이 품질을 가장 잘 표현한 문장이지 않나 싶다. 품질이라는 것은 어떤 절대적인 기준을 가진 것이 아니라 누군가에게 어떤 가치를 주는 것이라는 의미이다. 그런 관점에서 동일한 제품이라도 제품 사용자, 개발자, 기획자, 디자이너, 영업 등 각각의 사람마다 중요시하는 가치가 다르며 그 가치의 우선순위에 따라 제품의 품질을 판단 내리게 된다. 그리고 어떤 품질을 우선한다는 것은 다른 품질을 희생하는 것일 수 있다. 예를 들어 많은 기능을 빠르게 만드는 것을 우선함으로 인해 결함이 증가하거나 유지 보수하기 어려운 코드를 생산할 수 있다. 반대로 유지 보수하기 좋은 코드, 낮은 결함, 높은 보안을 유지하기 위해 속도를 희생해야 할 수 있다. 품질의 정치적 딜레마위의 특성 때문에 생기는 딜레마는 품질에 대한 정의를 내리는 여러 사람 중에 누구의 영향력이 가장 큰지가 영향을 끼치게 된다. 어떤 서비스에 작은 버그가 하나 있다고 생각해보자. 그 버그에 대한 익명의 유저 CS와 대표님 자녀의 의견은 무게감이 다르다. 지나친 비약이라고 생각될 수 있을 텐데 만약 대표님 자녀가 아니라 우리 회사의 매출에 상당 부분을 기여하고 있는 고객사의 의견이라면 어떨까? 이러한 부분은 사실 합리적인 결정이라기보다는 감정에 기초하는 경우들이 많다. 개발자들은 절대적이고 합리적인 가치 기준에 의해 품질을 정의하고 싶겠지만 현실은 다르다. 품질에 있어 이러한 현실적인 부분을 인식하지 못하면 품질을 개선하는 일은 매우 어렵게 된다. 품질을 개선 시키기 어려운 이유이미 적당히 쓸만하다몇 가지 버그나 불편한 점이 있긴 하지만 그럼에도 불구하고 사용하는 사용자가 많다면 굳이 품질을 더 개선할 의미를 느끼지 못한다. 사용자들이 그러한 요소로 떠나기 시작한다고 판단되면 그제서야 품질을 개선하기 시작할 수는 있겠지만 이미 그때는 이미 늦은 시점이다. 보통 이런 문제들을 잘 해소한 경쟁업체가 나타나 시장 점유율을 뺏기기 시작하면 그제서야 인식하게 되는 경우가 많은 것 같다. 품질 향상의 가치를 알기 어렵다가치를 측정하려면 두 가지의 측면을 이해해야 할 것 같다. 어떤 품질을 향상시키기 위해 들어가는 비용과 얻게 되는 가치의 크기일 것이다. 이 두 가지를 이해해야 품질 향상에 동기가 생길 것이다. 반대로 이것을 알 수 없다면 품질 향상을 위한 동기가 생기기 어려울 것이다. 문화의 보수성조직에 형성되어 있는 문화는 기존의 문화를 고수하려는 경향이 있다. 가족 치료로 유명한 버지니어 사티어는 이런 말을 했다고 한다. “People will always choose the familiar over the comfortable.” 편안함보다 익숙함을 선택한다는 것이 무슨 의미일까? 언뜻 보면 이해가 안 될수 있지만 생각보다 우리 주변에서 자주 볼 수 있다. 단축키를 익히면 훨씬 효율적이고 편하게 익힐 수 있는 방법이나 코드로 자동화 하면 훨씬 쉽고 편하게 할 수 있음에도 기존에 익숙한 수동 작업 들이 대표적일 것이다. 어떤 조직에서는 테스트 코드를 작성하는 것이 일상적이고 당연한 반면, 어떤 조직에서는 테스트 코드를 작성할 수 없는 백만가지의 이유가 있다. 그러나 사실 이유는 무엇이든 상관이 없다. 그저 기존에 그렇게 해오지 않았던 것이 크게 작용한다. 그들은(양쪽 모두) 기존의 품질에 적응한 상태이며 더 높은 수준으로 향상 시키는데 필요한 것이 잘 모른다. 또한 찾으려고 노력하지도 않는 경우가 많다. 품질 향상을 위한 조언책에서는 품질을 향상에 대해 아래의 두 가지 관점의 조언을 한다. 품질의 가치를 완벽하게 산정하기는 어렵지만 그렇다고 가치를 산정하기 위한 노력이 아무런 이점이 없는 것은 아니다. 그런 시도를 통해 어떤 가치가 어떤 사람에게 중요한지에 대해 잘 이해할 수 있다. 문화의 보수성 때문에 변화를 시도하는 것은 항상 저항에 부딪힌다. 변화를 시도할 때에는 기존 문화의 가치를 인정하고 좋은 점을 보존하고 더 향상시키고자 하는 시도로 접근하는 것이 저항을 줄이는 방법이다. 글을 마무리 하며최근에 마틴 파울러가 강연한 리팩토링에 대한 영상을 본 적이 있다. 마지막에 마틴 파울러가 왜 리팩토링을 해야 하는가에 대해 설명한 부분이 인상적이었기에 인용해본다. 일부 팀들은 ‘매니저가 리팩토링할 시간을 안 줘요. 중요하다고 말했는데도요.’ 라고 개발자가 말하면서 혼란스러워하는데요. 매니저는 ‘그건 나중에 하시죠’라고 합니다. 팀에서 리팩토링을 하려고 좋은 소프트웨어 설계에 대해 논의하고 모듈화에 대해 더 다가가고 전문성에 대해 이야기하면서 코드를 깨끗하게 만들려고 할 때는 이미 끝난 뒤입니다. 리팩토링에 대해 이야기할 때 이 단어들(Quality, Clean Code, Professionalism, Right thing)을 언급하면 그땐 망한 거죠. 이 단어들은 무시해도 좋습니다. 대신 리팩토링을 이야기할 때 경제성에 대해 이야기하는 것이 좋습니다. 개발자가 하는 모든 것들이 더 많은 기능을 더 빠르게 적용하기 위해서죠. 이게 바로 유일한 ‘리팩토링을 적용해야 하는 이유’ 입니다. <중략> 만약 개발자가 코드를 깨끗하게 만들지 않는다면 그것은 고객을 도둑질하는 것과 같습니다. 회사로 하여금 새로운 기능을 만들 때 더 많은 돈을 쓰게 하고 더 많은 시간이 걸리게 하는 짓이죠. 그렇기 때문에 개발자가 하는 일이 어떻게 경제적으로 영향을 미치는지 판단해야 합니다. 그러므로 기억하세요. 리팩토링은 경제성 때문에 하는 겁니다. 깔끔한 코드는 더 빠른 기능 개발을 할 수 있습니다. 이게 바로 리팩토링의 이면입니다. 마틴 파울러는 품질은 곧 가치이며 정치적이라는 것을 잘 이해하고 있는 개발자때는 생각이 들었다. 나는 여전히 어떻게 품질을 향상시킬 수 있는지, 그리고 그것이 어떤 가치를 지니고 있는지 판단하는 것이 어렵다. 하지만 나는 전문가로서 사람들에게 많은 가치를 주는 높은 품질의 제품을 만들고 싶다. 그러기 위해 앞으로도 품질을 향상 시키기 위한 시도와 학습을 하려고 한다.","categories":[],"tags":[{"name":"IT생각","slug":"IT생각","permalink":"https://wonderer80.github.io/tags/IT%EC%83%9D%EA%B0%81/"}]},{"title":"slack과 오픈커뮤니케이션","slug":"slack과-오픈커뮤니케이션","date":"2018-04-29T02:32:44.000Z","updated":"2026-04-13T13:36:46.814Z","comments":true,"path":"2018/04/29/slack과-오픈커뮤니케이션/","permalink":"https://wonderer80.github.io/2018/04/29/slack%EA%B3%BC-%EC%98%A4%ED%94%88%EC%BB%A4%EB%AE%A4%EB%8B%88%EC%BC%80%EC%9D%B4%EC%85%98/","excerpt":"","text":"필자의 아이들이 다니고 있는 대안학교에서는 학부모간에 대화를 나눠야하는 일이 많다. 주로 텔레그램으로 대화를 나누고 있는데 회사에서 슬랙을 경험해 본 필자 입장에서는 텔레방이 너무 불편하고 복잡하게 느껴졌다. 그래서 종종 학부모나 선생님들에게 슬랙을 소개하고는 했는데, 막상 장점을 말하려니까 설명이 어려웠다. 다행히 관심을 가진 분들이 계셔서 슬랙을 학교 월례회의 때 소개할 수 있는 기회가 생기게 되었고, 나도 다시 한번 슬랙의 장점에 대해 생각해보는 기회가 되었다. 오픈 커뮤니케이션 도구로서의 슬랙오늘은 슬랙의 장점 중 필자가 가장 중요하다고 생각하는 오픈 커뮤니케이션 도구로서의 슬랙을 이야기해보고자 한다. 슬랙은 여러 편리한 기능이 있지만 개인적으로 가장 인상적인 부분은 기본적으로 생성된 채널(단체대화방)이 공개라는 것이다. 현재 생성되어 있는 모든 채널 리스트를 볼 수 있을 뿐만 아니라, 채널에 올라온 과거의 글들까지 모두 볼 수 있었다. 누군가 초대하지 않아도 본인이 원하면 채널에 들어와서 대화에 참여할 수도 있다. 한번은 필자가 속한 서버팀 채널에 사람들과 워크샵 논의를 하며 워크샵 장소를 공유한 적이 있다. 그런데 항상 서버팀 채널에 상주하며 대화를 즐기던 데브옵스 리더가 공유한 내용에 이모지를 붙이더니 잠시 후 데브옵스도 워크샵을 가겠다며 같은 날짜에 근처 숙소에 워크샵 장소를 잡았다고 공표했다. 그러자 클라이언트팀, 기획팀, 애자일코치팀까지 모두 같은 날, 같은 펜션으로 워크샵을 잡는 사태가 벌어졌다. 덕분에 워크샵 장소에 가서는 팀과 상관없이 모두가 함께 즐거운 시간을 보낼 수 있었다. 이러한 해프닝은 슬랙의 정보 개방성의 특징이 보여준 일화라고 볼 수 있다. 다른 사람에게 딴지를 걸 수 있는가?김창준님의 협업의 5가지 미신 강연에서 인용한 Eduardo Salas 의 연구에 따르면, 팀의 효과성을 예측하는 중요한 변수로 Mutual performance monitoring 이라는게 있다고 한다. Mutual performance monitoring 이란 쉽게 말하자면 다른 사람이 일하는 것을 들여다보고 피드백(딴지)을 줄 수 있는가를 말한다. 슬랙은 이런 면에서 우리가 여러 채널에 관심을 갖고 의견을 표시하기 쉽도록 되어 있다고 볼 수 있다. 가볍게는 누군가의 대화에 이모지를 붙일 수도 있고 여러 사람들에게 의견을 묻거나 자신의 의견을 말할 수도 있다. 최근 IT기업에서는 사무실에 오픈 오피스를 도입하거나 confluence 같은 위키를 사용하는 기업이 많다. 이러한 모두가 협업을 위한 정보의 공유와 오픈 커뮤니케이션을 용이하게 해주는 도구라고 볼 수 있다. 잘 이해하고 쓰는 것이 필요하다하지만 이런 도구를 다 사용하고 있음에도 협업이나 오픈 커뮤니케이션을 하고 있다는 느낌이 들지 않을 수 있다. 이런 경우 다음과 같은 분위기가 있지 않은가 살펴보자. 채널에 초대받지 않은 사람들이 들어와서 구경하거나 의견을 내는 것이 불편하다 작성자 이외의 사람이 위키페이지에 와서 편집을 하거나 댓글을 다는 것이 불편하다 슬랙에 생성된 채널의 대부분은 주제중심이 아닌 조직구성을 반영한 채널이다 공개된 채널(혹은 위키페이지)이 별로 없고 비밀채널이 대부분이다 아이방에 공부책상을 사다 놓는다고 아이가 공부를 열심히 하게 되는 것이 아니듯이 도구는 결국 도구일 뿐이다. 이러한 도구들의 장점과 철학을 잘 이해하지 않고 단지 도입하는 것만으로는 회사의 문화가 바뀌지는 않는다. 우리가 회사에 입사할 때에는 특정한 역할로 지원하고 입사하게 되지만, 한 사람이 가지고 있는 재능은 다양하다. 서로가 서로의 일에 관심을 갖고 의견을 나눌 수 있을 때 조직에서 협업이 일어나고 효율이 좋아진다. 이번 계기로 필자도 협업과 오픈 커뮤니케이션이라는 것에 다시 한번 생각해보는 계기가 되었다. 우리들이 속한 환경에서 즐겁고 활발한 커뮤니케이션이 많이 일어났으면 하는 바람이다.","categories":[],"tags":[{"name":"IT생각","slug":"IT생각","permalink":"https://wonderer80.github.io/tags/IT%EC%83%9D%EA%B0%81/"},{"name":"개발문화","slug":"개발문화","permalink":"https://wonderer80.github.io/tags/%EA%B0%9C%EB%B0%9C%EB%AC%B8%ED%99%94/"}]},{"title":"개발자 채용 어떻게 해야하나?","slug":"개발자-채용-어떻게-해야하나","date":"2018-04-12T08:25:58.000Z","updated":"2026-04-13T13:36:46.815Z","comments":true,"path":"2018/04/12/개발자-채용-어떻게-해야하나/","permalink":"https://wonderer80.github.io/2018/04/12/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%B1%84%EC%9A%A9-%EC%96%B4%EB%96%BB%EA%B2%8C-%ED%95%B4%EC%95%BC%ED%95%98%EB%82%98/","excerpt":"","text":"‘개발자 채용 시 기술실력 검증 어떻게 해야 하나’ 라는 주제로 김창준님 강연에 다녀왔다.좋은 기회를 마련해주신 김창준님께 먼저 감사드린다. 전체적인 요약은 다른 분들이 이미 잘 정리해주셨기에, 이 포스팅에서는 강연 내용을 듣고 채용에 대해 필자가 생각해왔던 부분을 정리해보고자 한다. 이호성님 브런치 창천향로님의 칼럼 어떤 사람을 뽑을 것인가?필자도 평소에 ‘어떤 사람을 뽑아야하는가’에 대한 고민이 많이 있었는데, 그 이전에 ‘왜 사람을 뽑는가?’ 와 관련이 있을 것 같다. 대부분의 회사가 개발자를 뽑는 이유는 ‘할일은 많은데 개발자가 부족해서’ 이다. 하지만 아이러니하게도 개발자를 뽑으면 그에 맞춰서 할일도 늘어나기 때문에 똑같은 상황이 반복된다. 예전에 다니던 직장에서는 ‘사람이 부족해다고 뽑진 않겠다. 하지만 좋은 사람이면 무조건 뽑겠다’ 고 선언을 한적이 있었다. 지금 생각해보면 ‘좋은 사람에 대한 정의가 좀 더 명확했으면 어땠을까’ 하는 생각도 들지만 그 당시에는 꽤 마음에 와닿는 내용이었다. 어제 강연에서 ‘회사 내에서 좋은 평가를 받는 개발자들의 특징이나 습관을 추려서 채점표를 만들면 좋다’ 는 이야기가 있었는데 이런 방식을 통해서 회사에서 생각하는 좋은 사람의 정의가 가능할 것 같다. 그리고 추가적으로 드는 생각은 새로 채용하는 사람은 조직의 부족한 부분을 채워줄 수 있는 사람이어야 한다는 점이다. 이런 부분이 없으면 그냥 무난하게 같이 일하기 좋은 사람을 뽑게 될 확률이 높다. 예를 들어 우리는 코드 품질이 너무 낮아서 이런 부분을 잘 관리하고 보완하고 싶다고 한다면 다른 부분에서는 약간 부족하더라도 리팩토링이나 테스트 코드에 장점이 있는 사람을 채용하겠다는 기준을 가지고 사람을 채용하는거다. 물론 채용만 해서 끝나는 일은 아니고 그 사람이 자신의 장점을 잘 발휘할 수록 환경을 조성해주는 것도 필요하겠다. 어떻게 검증할 것인가?X로 테스트 하면 X를 잘하는 사람이 뽑힌다이전 직장에서 필자는 리더로서 기존 서비스의 레거시 코드에 대한 고민이 많이 있었다. 그래서 레거시 코드를 잘 해석하고 리팩토링도 할 수 있는 사람을 뽑고 싶었다. 창준님 강연에서 X로 테스트 하면 X를 잘하는 사람이 뽑힌다는 내용이 있었는데 지금 생각해보면 나름 그러한 부분이 반영된 테스트를 만들었던 것 같다. 기술 인터뷰 방식 과거에 사용되었던 어떤 기능을 가지고 있는 레거시 코드를 프린트 해서 보여준다. 이 코드를 보고 3가지를 설명해달라고 했다 ** 이 코드가 어떤 기능을 하는 코드인지 간단하게 요약해달라 ** ** 이 코드를 테스트 한다면 어떤 부분을 어떻게 테스트 할 것인가? ** ** 이 코드를 개선한다면 어떤 부분을 어떻게 개선할 것인가? ** 보완이 필요한 부분개인적으로 이 방식은 나름 노력대비 괜찮다고 생각했는데 어제 강연을 듣고 부족했다고 생각이 들은 부분은 다음과 같다. ** ​객관적이고 명시적인 채점 기준이 없었다 ** 사내의 개발자들을 대상으로 테스트해보고 채점표를 만들었으면 좋았을 것 같다. ** 말로만 듣다보니 모호하게 느껴지는 부분이 많았다 ** ​실제로 테스트를 해보고 리팩토링을 할 수 있는 환경을 제공해주었으면 좋았을 것 같다. 단 시간은 더 필요로 하게 될 것 같다. ** 스트레스를 많이 받을 수 있다 ** ​면접관 앞에서 짧은 시간안에 코드를 파악하고 설명해야했기 때문에 사람에 따라 압박감때문에 설명을 잘 못했을 수 있다. 좀 더 편안한 환경을 제공할 수 있으면 좋을 것 같다. 가급적 실제 상황에 가까운 환경을 제공하자강연을 들으면서 개인적으로 한가지 슬펐던 것은 인터뷰를 할 때의 기법 중에 하나가 미래에 어떻게 할 것인지가 아니라 과거에 어떻게 했는가를 물어보라고 하는 부분이었는데, 필자는 사실 “과거에 힘든 프로젝트는 뭐였나요?” 라던지 “최근에 프로젝트 한 것 중에 가장 도전적인건 어떤거였나요?” 라는 질문에 대답을 잘 못하는 경우가 많다. 필자는 과거의 사건들을 추상적인 개념으로 기억하는 경우가 많아서 디테일하게 무엇을 했는지 기억이 나지 않을 때가 많다. 또는 면접장소에서 압박감으로 인해 내가 원격으로 진행한 코딩 테스트에 대해서 왜 이렇게 했는지에 대해서 설명을 못한적도 있다. (집에 가는 길에 화장실에서 기억났다…) CTA같은 기법을 통해서 나의 전문성을 상대가 끌어내주면 좋겠지만 그런 면접관이 얼마나 있겠나 싶다. 그래서인지 가끔 필자는 인터뷰가 자신이 없을 때가 있다. 나 같은 사람은 질문보다는 실제 과제를 주고 하도록 하는게 더 효과적인 것 같다. 어떻게 좋은 인재를 유치할 것인가? 작거나 유명하지 않은 회사는 저런 고민할 필요가 없는 것 같아요. 제대로 된 지원자가 없으니깐요. 창천향로님의 포스팅에 붙은 어느 댓글의 내용이다. 필자도 비슷한 이유로 고민한 경험이 있다. 사실 이 부분은 회사의 규모와 상관없이 인재 영입에 대해 얼마나 중요성을 인식하고 노력하는가에 가까운 것 같다. 아무나 대충 뽑아도 상관없다고 생각하는 회사라면 빨리 그 회사를 나오는 것이 현명한 판단이지 않을까 싶다. 반대로 직장을 구하는 입장에서 어떤 것을 보고 회사를 지원하는가를 생각해보면 조금은 힌트가 있지 않을까 싶다. 기술 기반 회사란 무엇일까?에서 이야기 한 것처럼 좋은 개발자라면 자신이 보다 성장할 수 있는 환경을 찾으려고 노력할 것이다. 필자가 인터뷰할 때 가장 많이 들은 이직 사유가 ‘성장을 위해서’ 이다. 최근에 직장을 구하는 과정에서 가장 먼저 살핀 것중에 하나는 ‘회사에서 운영하는 개발 블로그가 있는가’였다. Job Description 도 중요한 부분이다. 그 회사에서 무엇을 중요하는지, 어떤 기술을 쓰는지, 가면 내가 어떤 것을 배울 수 있고 성장할 수 있을지에 대해 알 수 있다. 종종 외부에 공개된 대표 인터뷰나 기사 등을 살피기도 한다. 최종적으로는 인터뷰에 가서 그 회사에 대한 여러가지를 물어보고 이야기를 나누면서 회사를 파악하게 되었다. 보여주기 식의 홍보는 당연히 안되겠지만 회사 입장에서는 회사의 장점을 적극적으로 알리고 개발자들이 매력을 느낄 수 있도록 노력을 기울여야한다. 혹자는 회사에서의 최고의 복지는 좋은 동료와 함께 일하는 것이라고 한다. 반대로 직장을 옮기게 되는 가장 큰 이유 중에 하나도 사람 때문이다. 이게 우리가 인사권을 가지고 있지 않더라도 채용에 관심을 가져야만 하는 이유이다. 앞으로 일하게 될 직장에서도 이러한 부분에 대해 동료들과 함께 고민하고 발전시킬 수 있는 계기가 되었으면 좋겠다.","categories":[],"tags":[{"name":"IT생각","slug":"IT생각","permalink":"https://wonderer80.github.io/tags/IT%EC%83%9D%EA%B0%81/"}]},{"title":"티비를 보며 코딩하면 안되는 이유","slug":"티비를-보며-코딩하면-안되는-이유","date":"2018-04-10T05:28:12.000Z","updated":"2026-04-13T13:36:46.817Z","comments":true,"path":"2018/04/10/티비를-보며-코딩하면-안되는-이유/","permalink":"https://wonderer80.github.io/2018/04/10/%ED%8B%B0%EB%B9%84%EB%A5%BC-%EB%B3%B4%EB%A9%B0-%EC%BD%94%EB%94%A9%ED%95%98%EB%A9%B4-%EC%95%88%EB%90%98%EB%8A%94-%EC%9D%B4%EC%9C%A0/","excerpt":"","text":"게임업계나 스타트업에서 일을 하다보면 상당히 자유로운 분위기에서 일을 하는 모습을 볼 수 있다. 편하고 자유로운 환경은 스트레스를 줄여주고 자유로운 의사소통을 나눌 수 있으며 자율적인 분위기를 조성하는데 도움이 된다. 그런 가운데에는 음악을 들으며 코딩을 하거나 티비나 영화 등을 관람하며 작업하는 경우도 많이 보아왔다. 오늘은 티비를 보며 코딩을 하는 것에 대해 생각했던 개인적 견해를 밝혀보고자 한다. 필자의 경우는 주변소음을 차단하기 위한 정도로 가사가 없는 음악을 듣거나 아무 것도 듣지않는 경우가 많은데 그게 가장 개발에 집중하는 효율적이다고 생각하기 때문이다. 우리가 전문가로서 성장하기 위해, 그리고 좋은 품질의 결과물을 만들기 위해 새로운 기술을 배우거나 좋은 도구를 찾는 것은 매우 당연하다고 생각하는데, 마찬가지로 개발에 효율적인 환경을 갖추는 것도 중요하다고 생각한다. 그런 면에서 개발을 하면서 티비나 만화를 보는 행위는 집중에 상당히 방해가 되는 행위라고 생각하는데, 나는 이런 것이 프로답지 못한 행위라고 생각한다. 그 사람의 전문성을 평가할 때 태도나 외형만을 보고 평가하는 것은 분명 위험하다고 생각한다. 출퇴근시간이나 복장, 헤어스타일 같은 것들이 그런 것이다. 그럼에도 불구하고 개발을 하면서 영상을 소비하는 행위를 부정적으로 생각하는 이유는 다음과 같다. 고도의 사고와 집중력을 요하는 작업을 하는데 있어서 티비시청은 품질의 저하를 가져올 가능성이 높다우리 나라를 포함하여 여러 나라들에선 운전 중 영상 시청을 하게 되면 법적인 책임을 지어야 한다. 그 이유는 운전 중 영상 시청을 하게 되면 전방 주시율이 떨어지는데 이게 사고로 이어질 확률이 굉장히 높다고 한다. 근데 전방 주시율이 왜 떨어질까? 당연히 내용을 듣다보면 영상이 궁금해지기 때문이고 그렇게 잠시 눈을 돌리면 사고로 이어지는 것으로 생각된다. 필자는 평소에도 여러 일을 동시에 처리하는 것을 잘 못하는데, 그렇기 때문에 티비 뿐만 아니라 가사가 있는 가요를 들었을 때 집중력이 현저하게 떨어지는 것을 감지하게 된다. 피플웨어에서 소개된 내용에 따르면 일에 정신없이 집중해서 몰입상태에 빠지는 것을 심리학자들 사이에서는 플로(flow)라고 부른다고 한다. 엔지니어링이나 설계나 개발, 저작과 같은 업무는 고도의 집중력을 요하기 때문에 플로 상태에 있어야 일이 잘된다는 것은 굳이 책에서 설명하지 않아도 다들 느끼는 부분이라고 생각한다. 플로 상태가 되기까지는 소음이나 각종 방해 요인이 없는 상태에서 집중하기 까지의 시간을 필요로 하기 때문에 플로 상태를 오래 유지하는 것이 중요한데, 티비시청을 하면서 플로우 상태에 들어가거나 유지하는 것을 매우 어려운 일이다. 일부러 자신의 한계를 시험할 필요는 없다당신이 술을 취한 상태라면 조금이라도 코딩을 하는게 좋을까? 아니면 자는게 좋을까? 정답은 잠을 자는거다. 제 정신이 아닌 상태에서 개발을 하면 잘못된 설계를 하거나 버그를 유발할 가능성이 높다. 일반적으로 개발을 하는데 있어서 비용이 가장 많이 드는 건 개발 후에 설계를 변경하거나 버그를 잡는 것이다. 굳이 여러분의 집중력을 시험해 볼 필요성이 있을까? 술자리에 가서 금주하거나 부페가서 다이어트를 시도할 필요는 없다. 직장에서 당신이 동영상을 감상할꺼면 차라리 동영상을 보면서 휴식해라. 업무에도 적절한 릴렉스와 휴식은 필요하다. 프로란 무엇일까?“주방에서 쉽게만 하려고 하다보면 당신의 실수들을 고객들이 모를거라 생각할 때가 있습니다. 그 때가 그만둬야 할 땝니다. 누구나 버거를 뒤집거나 샐러드 소스를 뿌릴 수 있거든요. 전 19살 때 축구를 하다 쫓겨나야 했습니다. 두번째 기회를 주신게 신의 뜻이었죠. 지금도 제 식당이 영국에서 가장 오래 미슐랭 3성을 받고있는 식당이지만 전 절대 자만하지 않으려 합니다. 요리사는 마지막으로 만든 요리의 맛으로 점수를 받는겁니다.”<고든 렘지> 레스토랑 주방에서 티비를 보면서 요리하는 유명 쉐프가 상상이 되는가? 프로란 항상 자신이 낼 수 있는 최고의 기량을 낼 수 있도록 노력해야한다. 나는 단순히 월급을 받기 위해 직장을 다니는 직장인이 되고 싶지 않다. 항상 배우고 성장하며 가치를 만들어내는 전문가가 되고 싶으며 그러한 동료가 되고 싶다. 여러분은 어떠한가?","categories":[],"tags":[{"name":"IT생각","slug":"IT생각","permalink":"https://wonderer80.github.io/tags/IT%EC%83%9D%EA%B0%81/"}]},{"title":"초보를 위한 테스트 코드 없이 TDD 배우기","slug":"초보를-위한-테스트-코드-없이-TDD-배우기","date":"2018-04-04T07:31:35.000Z","updated":"2026-04-13T13:36:46.816Z","comments":true,"path":"2018/04/04/초보를-위한-테스트-코드-없이-TDD-배우기/","permalink":"https://wonderer80.github.io/2018/04/04/%EC%B4%88%EB%B3%B4%EB%A5%BC-%EC%9C%84%ED%95%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-%EC%97%86%EC%9D%B4-TDD-%EB%B0%B0%EC%9A%B0%EA%B8%B0/","excerpt":"","text":"이전 포스팅을 통해서 TDD를 배우기 왜 어려운지에 대한 이야기를 하였다. 그럼 TDD를 위한 기반지식이 없는 상태에서 TDD를 배우려면 어떻게 해야할까? 당연하겠지만 정석은 차근차근 필요한 지식들을 공부해나가는 것이다. 테스트 하는 법, 테스트 코드를 작성하는 법, 리팩토링을 하나씩 수련해나가는 것이다. 하지만 하나하나가 만만치가 않다. 나는 언제야 TDD를 해볼 수 있는 것일까? 그래서 이번 포스팅에서는 정석적인 학습법이 아닌 내가 시도한 사파의 수련법을 공유해보고자 한다. 이로인한 주화입마는 책임지지 않으니 판단은 각자에게 맡기도록 하겠다. 내가 처음 TDD를 접했을 때 당시에는 테스트 코드가 뭔지에 대한 개념이 전혀 없는 상태였다. 리팩토링에 대해서는 책을 조금 보고 조금씩 실무에 적용해보는 단계였다. 사실 테스트 코드가 뭔지도 모르는 상황에서 TDDBE를 봤을 때 나는 그게 정확하게 무엇을 하는지 이해하지는 못했지만, 딱 한가지 감탄한 접근 방법이 있었다. 일반적으로 개발을 할 때는 객체를 설계하고 그 기능들을 완성한 다음에 그 기능을 활용하여 개발을 해왔다. 완성된 하나의 서비스나 기능을 만들 때 그것을 위한 세부 기능 파트를 만들고 마지막에 그것들을 조합해서 완성하는 것이다. 그런데 TDD 에서는 그런 생각을 완전히 뒤집는다. 처음부터 완성되었다고 가정하고 개발을 하기 시작하는 것이었다. 메서드를 호출하는데 메서드 정의조차 하지 않고 메서드 호출을 한다. 그렇게 하면 당연히 에러가 나는데 거기에서부터 점진적인 개발이 시작된다. 이런 접근 방법에 감탄한 이유가 몇가지 있었는데 다음과 같다. TDD 초보자가 얻은 작은 통찰인터페이스 설계가 명확하고 간결하게 된다파트 단위로 먼저 개발을 하다보면 지나치게 범용적인 설계를 하거나 실제 호출되는 상황을 고려하지 못한 설계가 되는 경우가 많다. 그로인해 결과적으로 지나치게 많은 시간을 소비하거나 과도한 기능 설계나 잘못된 설계로 변경이 필요하게 되어 재작업하는 경우가 잦다. 점진적인 개발을 하기 편하다기존의 방식을 완성된 기능을 만들기 위해 그것을 위한 세부 기능들이 완성이 되기전까지 확인할 수 있는 것들이 매우 제한적이다. 하지만 사용하는 곳부터 구현하다보면 매우 빠른 지점부터 내가 확인할 수 있는 것들이 생긴다. 테스트 코드 없이 TDD 활용하기그럼 이제 본론으로 들어가서 기반지식이 별로 없는 상황에서의 TDD를 활용하는 방법에 대해서 이야기해보자. 이야기했듯이 나는 TDD를 처음 접했을 때 테스트 코드가 뭔지도 몰랐다. 테스트 코드가 뭔지도 모르고 만들줄도 모르는데 TDD가 역설적으로 들릴 수 도 있다. 하지만 테스트 코드를 만들 줄 모른다고 해서 테스트를 못하는 것은 아니다. 테스트에 대한 이야기도 나중에 좀 더 자세히 다를 수도 있겠지만 우선 그 부분은 생략하고 필자가 테스트 코드 없이 TDD를 활용한 방법을 소개해보겠다. 가장 끝단에서부터 개발하기위에서도 이야기 했지만 TDD의 특징 중 하나가 기능구현 이전 단계 부터 사용하는 부분을 개발하는 것이다. 본래 TDD에서는 테스트 코드가 수행되는 부분에서 그 로직을 호출하게 되지만 나는 그냥 메인 코드에서 그렇게 작업을 하기 시작했다. 이런 접근법은 매우 간단하게 개발을 시작하게 만들어주었고 나에게 빠르게 결과를 확인할 수 있게 해주었다. 위 다이어그램의 기능을 내가 구현한다고 생각해보자. 일반적인 방식에서는 Customer, Waiter, Chef 의 기능을 모두 설계, 개발 후에 최종적으로 해당 기능들을 조합해서 만들게 될 것이다. 하지만 TDD 방식으로 개발한다면 메인 로직에서 Customer의 order를 호출하는 부분(다이어그램상으로는 정의되어 있지 않다)부터 개발하게 된다. 미구현 부분을 Mock으로 처리하고 점진적으로 구현하기끝단부터 개발해서 역으로 채워나가는 과정에서 빠르게 결과를 확인하기 위해서 단계별로 기능을 구현하고 미구현 부분은 하드코딩을 통해서 Mock으로 처리한다. 메인 로직에서 Customer의 order 메서드로 기능이 시작된다고 가정했을 때 Waiter의 order, Chef의 orderfood 라는 메서드가 내부적으로 호출된다. 처음에 메인로직에서 Customer의 order를 호출하고 Customer의 order를 만들 때에는 Customer order의 전체를 Mock 처리한다. 여기서의 Mock 처리는 보통은 하드코딩을 통해서 의도한 결과를 리턴하는 것이다. 이 과정에서 Customer 객체의 정의나 order 메서드의 인터페이스가 정의 되는데, 이 과정을 통해 order라는 기능이 전체적인 프로그램에서의 흐름을 확인할 수 있게 되면 다음엔 Waiter의 order를 호출하는 로직을 추가한다. 이 후의 과정은 앞서 했던 과정의 반복으로 이루어지는데, 중간 단계를 섣불리 생략하면 무한 재귀함수에 빠진 것처럼 뇌에서 stackoverflow 가 발생될 것이다. 초기 수련 단계에서는 반드시 모든 단계를 생력하지 않고 순차적으로 진행하는 것이 중요하다. TDD를 통해 무엇을 배울 것인가?위에서 내가 접근한 방법을 보고 어떤 생각이 드는가? ‘에이~ 이게 무슨 TDD야’ 라는 생각이 들지도 모르겠다. 저렇게 하는 것만을 가지고 ‘난 TDD 한다’라고 말하기에는 분명 부족함이 많다. 그런데 여러분이 TDD를 하려고 하는 이유는 무엇인가? 내가 다른 사람들에게 TDD를 할 줄 안다고 말하는 것이 중요하다면 이런 접근은 별로 의미가 없을지도 모르겠다. 하지만 엔지니어로서 새로운 기술을 습득하고 역량을 발전시키는데 목적이 있다면 필자는 이런 접근 방법도 괜찮다고 생각한다. TDD의 아이러니 중 하나는 TDD가 테스트 기술이 아니라는 점이다(워드 커닝엄의 선문답이다). TDD는 분석 기술이며, 설계 기술이기도 하다. 사실은 개발의 모든 활동을 구조화하는 기술이다. <켄트 백, 테스트 주도 개발> 이러한 접근 방식을 내가 추천하는 이유는 TDD에서의 점진적인 개발과도 맞닿아 있다고 생각하는데, 모든 걸 완벽하게 이해하고 완성해야만 그 결실을 얻을 수 있는게 아니라 내가 이해하고 있는 수준 안에서 실천하고 그 안에서의 이점들을 취할 때 TDD를 지속할 수 있는 힘이 된다고 생각한다. 마지막으로 혹시라도 이 포스팅만을 보고 TDD에 대해 이해했다고 착각하는 실수를 범하지 않았으면 좋겠다. 이 방식은 앞서 말했다시피 필자가 밟아온 시행착오 중의 하나일 뿐이며, 단순히 TDD를 글로만 이해하는데에는 한계가 있다. 여러분의 실제 개발 환경에서 직접 시도하는 과정에서만 TDD에 대해 배우고 이해할 수 있다. 이 글을 통해 다른 많은 분들의 경험담을 전해들을 수 있었으면 좋겠다.","categories":[],"tags":[{"name":"TDD","slug":"TDD","permalink":"https://wonderer80.github.io/tags/TDD/"}]},{"title":"당신이 TDD에 실패하는 이유","slug":"당신이-TDD에-실패하는-이유","date":"2018-04-03T01:51:12.000Z","updated":"2026-04-13T13:36:46.816Z","comments":true,"path":"2018/04/03/당신이-TDD에-실패하는-이유/","permalink":"https://wonderer80.github.io/2018/04/03/%EB%8B%B9%EC%8B%A0%EC%9D%B4-TDD%EC%97%90-%EC%8B%A4%ED%8C%A8%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0/","excerpt":"","text":"TDD가 나온지 많은 세월이 지났지만 TDD를 잘알고 활용하는 개발자는 흔치 않다. 그럼에도 잊을만하면 어디선가 한번씩 언급되는 TDD이기에 자세히는 몰라도 관심을 가지고 있는 개발자는 많다. 어떤 개발자는 테스트 코드를 작성하는게 TDD가 아니냐고 하는 개발자도 있었다. TDD라는게 뭔가 자동화 테스트와 관련이 있는 것 같은데 자세히는 모르겠고, 막연한 뭉개구름 같은 감각적 느낌으로만 알고 있는 개발자가 흔하게 있을 정도로 TDD는 그 이름에 비해 잘 알고 있는 사람은 별로 없다. 나 역시 처음 TDD를 배워보겠다고 TDDBE라는 유명한 책을 구입했었다. 책을 구매해서 고개를 끄덕끄덕 하며 감탄하며 읽었는데, 다 읽고 난 후에 현실로 돌아왔을 때 남은 것은 막연함 뿐이었다. 사실 그 때는 잘 몰랐지만 지금 와서 생각해보니 TDD를 제대로 익히기 어려운 이유가 있었는데 그건 TDD가 여러 기술을 요구하기 때문이다. TDD를 위해 필요한 기술Testing테스트를 만들어야 하니까 결국 어떤 것을 테스트할 것인지에 대한 정의가 중요하다. 안타깝게도 많은 개발자들은 테스팅 기술을 익힐 수 있는 기회가 없다. 누군가 알려준적도 없을 뿐더러 QA(라고 쓰고 테스터라고 부르는)담당자가 별도로 있는 경우가 많기 때문이다. 그래서 대충대충 빠르게 만들고 테스트는 QA 혹은 사용자에게 미루다보니 스스로 테스팅을 잘 하고 익힐 수 있는 기회가 없다. Test AutomationTDD에서의 테스트 수행 방식은 테스트 코드를 이용한 테스트 자동화를 의미한다. JUnit이나 RSpec 같은 Testing Framework를 주로 이용한다. 많은 개발자들은 TDD에서 이 부분이 가장 어려울 것이라고 생각하지만 실질적으로는 무엇을 테스트해야할지를 어려워하는 경우가 더 많다. RefactoringTDD의 개발 Cycle 중 필수요소로 들어가는 것이 Refactoring이다. Refactroing은 기존의 동작을 변경하지 많으면서 효율적인 코드로 개선하는 작업이다. Refactoring을 하려면 Refactoring을 하기 앞서 어떤 코드가 좋은 코드인가에 대한 기반지식이 뒷받침되어야 한다. TDD를 배우기 어려운 이유위의 3가지 중에 하나라도 어렵게 느껴지는 것이 있는가? TDD를 잘 하려면 위의 3가지를 기본적으로 할 수 있어야한다.인지 부하 이론에 의하면 일반적으로 과제 해결에 요구되는 인지자원의 양이 인지구조가 보유하고 있는 자원의 용량을 초과할 때 인지과부하(cognitive overload)가 발생한다고 하는데 이는 학습 부진의 주요 원인으로 본다. 쉽게 말하면 우리가 어떤 것을 배우거나 문제를 해결할 때 필요한 기반지식이 충분히 뒷받침 되지 않으면 많은 어려움을 겪게 된다는 뜻이다. TDD는 위의 3가지 기술을 기반으로 설계와 개발을 어떤 식으로 할 것에 대한 개발 방법론인데 기본적인 기술에 대한 이해가 없는 상황에서 TDD를 시도하게 되면 결국 인지과부하가 발생될 수밖에 없게되고 결국 TDD 적용에 실패하게 된다. TDD를 안할지언정 정신 승리는 하지말자간혹 테스트 코드를 짜냐는 질문에 자긴 TDD를 좋아하지 않는다고 답하는 개발자들을 보고는 한다. 그들이 내세우는 근거는 대부분 테스트 코드는 짜는데 시간이 많이 걸려서 효율이 좋지 않다는 것과 TDD는 죽었다 - 번역의 내용을 인용하는 것이다. 여기서 문제는 보통 이런 주장을 하는 사람들의 대부분은 테스트 자동화와 TDD를 구분하지 못할 뿐더러, 당연히 제대로 테스트 코드를 짜보거나 TDD를 경험해보지 못했다는 것이다. 사실 ‘TDD는 죽었다’라는 글을 쓴 DHH 는 테스트 자체를 반대한 것은 아니다. 완벽한 기술이란 없다. 하지만 본인이 지금 못한다고 해서 무조건적인 비하는 하지말자. TDD를 못한다고 볼품없는 개발자가 되는 것도 아니다. 하지만 배우기도 전에 거부하는 것은 스스로 배움의 기회를 멀리 차버리는 것과 같다. TDD를 꼭 배우고 싶은데 그럼 어떻게 하면 좋을까?어쩃든 여러분이 TDD를 배우기 어렵다는 것은 잘 알았다. 그럼 어떻게 TDD를 익혀나갈 수 있을 것인가? 가장 쉽고 빠른 방법은 TDD를 이미 잘 이해하고 사용하는 개발자에게 배우는 것이다. 페어 프로그래밍을 할 수 있으면 금상첨화다. 여러분 주위에 그런 사람이 있으면 그건 정말 큰 행운이라고 생각한다. 하지만 불행하게도(일반적으로) 주위에 그런 개발자가 없다면 결국 혼자 익히는 수밖에는 없다. 솔직히 필자는 TDD를 처음 접할 때 테스트 코드라는게 무엇인지도 전혀 이해를 못했다. 그럼에도 TDD를 개발에 적용할 수 있었는데 오히려 무지했기에 가능한 방법이었던 것 같다. 필자가 TDD를 어떤 방식으로 활용했고 배웠는지 궁금한가? 나는 무슨 방법을 써서라도 TDD를 익혀보고 싶다면 필자의 방법을 참고해보도록 하라. 다음 포스팅을 통해 필자가 익힌 邪派의 기술을 전수해주겠다.","categories":[],"tags":[{"name":"TDD","slug":"TDD","permalink":"https://wonderer80.github.io/tags/TDD/"}]},{"title":"기술 기반 회사란 무엇일까?","slug":"기술-기반-회사란-무엇일까","date":"2018-03-29T09:22:26.000Z","updated":"2026-04-13T13:36:46.815Z","comments":true,"path":"2018/03/29/기술-기반-회사란-무엇일까/","permalink":"https://wonderer80.github.io/2018/03/29/%EA%B8%B0%EC%88%A0-%EA%B8%B0%EB%B0%98-%ED%9A%8C%EC%82%AC%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C/","excerpt":"","text":"예전에 다니던 직장에서 ‘우리 회사는 기술 기반 회사인가?’ 라는 주제로 엔지니어 그룹에서 토론을 한적이 있었다. 그렇다고 하는 사람도 있었고, 아니다라고 하는 사람도 있었는데 왜 그 토론을 주제로 삼았는지는 기억이 안나지만 어느 쪽이든 기술 기반 회사의 회사에서 일하고 싶다는 마음은 같았던 것 같다. 그렇게 몇 년이 지나 그 직장을 그만두고 회사를 알아보러 이곳 저곳에 면접을 보러 다니는 와중에 8년차 서비스를 하고 있는 유명 스타트업 E사의 대표님과의 최종 면접이 있었다. 왜 이전 직장을 나왔냐는 단골 질문에 기술적인 성장과 자극을 위해라는 단골 답변을 했는데, 그 대표님은 한숨을 쉬며 기술이 중요한 것은 알겠는데 솔직히 우리 같은 스타트업은 하루하루 생존의 위협에 시달리고 있는데, 기술 개발 같은건 N사나 K사 같은 큰 회사나 할 수 있는거 아니냐며 푸념을 하였다. 그 이야기를 나누면서 확실하게 알게 된 것은 이 곳은 기술 기반 회사와는 아주 거리가 멀다는 것이었다. 보통 우리가 기술 기반 회사라고 하면 떠올리는 이미지는 최신 기술에 민감하게 반응하고 기술을 선도하는 기업의 이미지를 가지고 있다.최소한 플랫폼 서비스나 솔루션과 같은 기술을 경쟁력으로 하는 회사를 떠올릴 것으로 생각한다. 내가 생각하는 기술 기반 회사하지만 나는 조금 더 넓은 의미에서의 의미를 적용하고 싶다는 생각을 하는데, 사업의 핵심 경쟁력을 기술에 두고 기술 개발 및 발전을 위한 계획을 가지고 있는 회사라고 생각한다. 요즘 아무리 작은 스타트업이라도 CTO 가 없는 회사는 거의 없다. 그만큼 기술에 대한 중요성은 인식하고 있다. 하지만 CTO가 있어도 기술에 대한 로드맵이나 계획, 정책을 가지고 있는 회사는 별로 보지 못했다. 이제까지 아무도 만들어내지 못한 기술을 새로 만들어내야만 기술이 있는 것인가? 난 아니라고 생각한다. 처음에는 그런 기술이 없었을지라도 서비스를 운영하는 과정에서 생기는 경험이나 노하우도 일종의 기술이라 볼 수 있다. 문제는 그 과정에서 생기는 기술이나 경험을 제대로 공유하고 학습하기보단 주먹구구식의 임기응변으로 대처함으로 인해 기술이 내재화 되지 못하는 것이다. 과거에 습득한 지식과 경험은 잘 정리하여 구성원들에게 공유함으로서 기술 기반을 축적시켜 나가고, 그 기반을 바탕으로 새로운 기술들을 학습을 할 수 있는 체계를 갖추고 있다면 훌륭한 기술 기반 회사라고 생각을 한다. 이러한 것들은 회사의 규모나 형편과는 상관없다. 모든 회사가 항상 위기라고 한다. 계획을 가지고 있는가? 그리고 그것을 상황에 맞게 꾸준히 실천해나가고 있는가? 그 차이 뿐이라고 생각한다. 엔지니어들이 다니고 싶은 회사다시 E사의 이야기로 되돌아가보자. E사의 대표님은 본인이 이제까지 월급 안밀리고 잘 운영한 것을 자랑으로 생각하신다고 했다.그래서 그럼 내가 이 회사에 다닌다면 월급 이외에 무슨 메리트가 있느냐는 물음에 머뭇거리면 대답을 잘 하지 못하셨다. 한 회사의 경영자로서 회사를 안정적으로 운영한 것은 분명 훌륭한 일이다. 하지만 훌륭한 엔지니어가 이런 곳에서 일하고 싶지 않을 것이라는 것은 확실하다.결국 난 다음 날 입사 제의를 거절하였다. 왜 엔지니어들은 기술 기반 회사에 다니고 싶을까? 엔지니어들은 누구나 기술적 성장에 대한 갈망을 가지고 있다. 기술의 성장과 회사의 성장을 동일 시 여기는 회사. 즉 엔지니어 개개인의 성장을 중요 시 여기고 그에 대한 비전을 가지고 있는 회사라면 엔지니어라면 누구나 다니고 싶은 회사일 것이다.","categories":[],"tags":[{"name":"IT생각","slug":"IT생각","permalink":"https://wonderer80.github.io/tags/IT%EC%83%9D%EA%B0%81/"}]}],"categories":[],"tags":[{"name":"AI","slug":"AI","permalink":"https://wonderer80.github.io/tags/AI/"},{"name":"하네스","slug":"하네스","permalink":"https://wonderer80.github.io/tags/%ED%95%98%EB%84%A4%EC%8A%A4/"},{"name":"시스템","slug":"시스템","permalink":"https://wonderer80.github.io/tags/%EC%8B%9C%EC%8A%A4%ED%85%9C/"},{"name":"생각","slug":"생각","permalink":"https://wonderer80.github.io/tags/%EC%83%9D%EA%B0%81/"},{"name":"소프트웨어","slug":"소프트웨어","permalink":"https://wonderer80.github.io/tags/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4/"},{"name":"개발","slug":"개발","permalink":"https://wonderer80.github.io/tags/%EA%B0%9C%EB%B0%9C/"},{"name":"UX","slug":"UX","permalink":"https://wonderer80.github.io/tags/UX/"},{"name":"UI","slug":"UI","permalink":"https://wonderer80.github.io/tags/UI/"},{"name":"키오스크","slug":"키오스크","permalink":"https://wonderer80.github.io/tags/%ED%82%A4%EC%98%A4%EC%8A%A4%ED%81%AC/"},{"name":"디자인","slug":"디자인","permalink":"https://wonderer80.github.io/tags/%EB%94%94%EC%9E%90%EC%9D%B8/"},{"name":"개발문화","slug":"개발문화","permalink":"https://wonderer80.github.io/tags/%EA%B0%9C%EB%B0%9C%EB%AC%B8%ED%99%94/"},{"name":"코드리뷰","slug":"코드리뷰","permalink":"https://wonderer80.github.io/tags/%EC%BD%94%EB%93%9C%EB%A6%AC%EB%B7%B0/"},{"name":"IT생각","slug":"IT생각","permalink":"https://wonderer80.github.io/tags/IT%EC%83%9D%EA%B0%81/"},{"name":"커리어","slug":"커리어","permalink":"https://wonderer80.github.io/tags/%EC%BB%A4%EB%A6%AC%EC%96%B4/"},{"name":"생산성","slug":"생산성","permalink":"https://wonderer80.github.io/tags/%EC%83%9D%EC%82%B0%EC%84%B1/"},{"name":"TDD","slug":"TDD","permalink":"https://wonderer80.github.io/tags/TDD/"}]}