‘막연히 번역 한 번 해보고 싶은 분’, ‘번역 과정이 궁금하신 분’, ‘글 좀 잘 써보고 싶으신 분’
을 위한 유쾌! 발랄! 부끄! 안내서입니다.
첨 쓰기 시작한 게 1년 반은 된 거 같은데, 묶혀뒀다가 이제서야 오픈합니다.
아래 그림을 클릭하면 링크로 갑니다.
곧 출간할 『프로젝트 성패를 결정짓는 데이터 모델링 이야기』의 원고 검토를 위해 저자와 함께 써 본 독자 페르소나(persona)입니다. 페르소나는 대상 독자층을 명확히 드러내 책 전반에 걸쳐 글의 흐름, 다루는 내용, 깊이(난이도)를 일관되게 유지하는 데 큰 도움을 줍니다. 중간중간 스스로 페르소나의 인물이 되어, 혹은 원고를 검토해줄 지인에게 페르소나를 함께 건네주어 독자의 눈높이에서 글을 바라보는 것이죠.
내 책을 읽어 줄 독자가 얼마나 되는가를 대략 가늠해보는 수단이 되기도 합니다.
처음 책을 써보려 하는 예비 저자께 특히 강추합니다. ^^
__
인적사항: 나독자 / 32세 / 남자 직업: 소프트웨어 개발자 (주로 백엔드) 경력: 컴퓨터학부 졸업, 입사 4년차 성격: 자기 실력을 믿고, 그 결과에서 자부심을 얻고 싶어한다. 좌우명: “백년주택은 뼈대에 돈이 많이 든다” [출처] 싫어하는 말: 대충대충. 돌아가기만 하면 되지. 고객의 목소리: 내게 데이터 모델링의 원리를 깨우쳐줄.. 잘하고 있다는 확신을 갖게 해줄 멘토가 필요해!
개발 경험 / 숙련도: * 언어: 자바(중고급), SQL(초중급) * 데이터 모델링(초급) 학부 때 데이터베이스 과목은 수강하였다. … 회사에서는 주로 선임 개발자나 전문 모델러가 건네준 설계대로 구현하는 역할을 하였다(SQL 정도는 부담없이 사용한다). … 구체적인 모델링 원리와 이론은 가물가물하지만 책/검색 등으로 금방 기억을 떠올릴 수는 있다. … 실무/응용 경험이 부족해 막히는 경우가 잦고, 해 놓고도 제대로 했는지 스스로 확인할 수 없다.
상황 (맥락, 니즈, 행동 패턴, 문제점): 나독자는 입사 후 3년 동안 몇 개의 프로젝트를 경험하며 애플리케이션 개발에 나름 자신이 붙고 있었다. 항상 시간에 쫓겨 버그투성이의 프로그램을 개발하던 것에서 차츰 벗어나, 이제는 요구사항을 정확히 만족하면서 효율적이고 안정적인 코드를 만들어 내고 있다. 객체지향 방법론과 패턴도 적용해가며 이제 큰 부끄럼 없이 남에게 코드를 보여주고 설명할 수 있는 수준이 되었다. 그런데 이번에 새로 시작한 프로젝트는 업무도 낯설고 그동안 해보지 않았던 데이터베이스 설계 역할을 맡게 되었다. 처음엔 객체 설계랑 비슷하려니 생각했지만 막상 해보니 곧 또 다른 세상임을 깨달았다. 결과적으로 초반의 데이터 모델링 진도는 지지부진하여, 몇 년 만에 느껴보는 부담감이 커졌다. 신입 때는 잘 몰라도 ‘신입이니까’라 생각하며 편히 지낼 수 있었지만, 뒤에서 지켜보는 후임도 생긴 지금의 부담은 여태껏 느껴보지 못한 무게다. 그간 직접 체험과 주변 사례를 통해 ‘일단 돌아가게 만들기’의 폐해를 잘 알고 있다. 이번에도 어찌 되었든 돌아가게는 만들겠지만, 원리를 깨우쳐 제대로 확신을 가지고 진행하고 싶다. 인터넷과 몇몇 서적을 훑어보았다. 하지만 인터넷에서 찾은 지식은 단편적이고, 책들은 마치 수험서처럼 아주 작은 것까지 모두 설명하려 하거나 너무 성능 최적화에 치우친 느낌이다. 모델링 전체를 관통하는 본질적인 이야기는 찾을 수 없었다. 어쩌면 너무 많은 잔가지와 디테일에 파묻혀 눈에 띄지 않았을지도 모르겠다.
목표: 후임에게 부끄럽지 않도록 새로운 프로젝트와 역할에 성공적으로 안착한다. 객체지향과 패턴의 원리를 깨우쳐 코딩에서 자신감을 얻었듯, 데이터 모델링도 그 본질적 원리를 제대로 깨우친다. 깨달은 원리를 바탕으로 앞으로 어떤 과제가 맡겨져도 완수할 수 있다는 자신감을 얻는다. 물론 계속 고민하고 더 배워야겠지만.. ^^
조직을 바꾸려면..오늘 관련 이야기가 나와서 내 생각을 떠오르는대로 정리해봤다.나름 ‘너무’ 거대한 조직을 바꿔보려 수 년간 시행착오를 거쳐 쌓아온 노하우(?)다.
<피플웨어 3판> 초반에 일정 예측 주체와 생산성을 정리한 아래 표가 나온다.
그런데 여기에 ‘경영진과 관리자 함께’가 빠져서 좀 아쉬워 모 기업에서 (마치 표준 프로세스인듯) 자주 겪은 경험담을 남겨본다.
경영진: 일정 내놔. 관리자: 여기.. 경영진: 땡겨. 관리자: 그럼 기능을 빼야.. 경영진: 확~! 관리자: 그럼 일정을 늘려야.. 경영진: 우쒸! .. (반복) .. 관리자: 해볼게요. 하지만 전 분명 안 된다고 말했어요. 경영진: 한다고 했으니 너가 책임져! 관리자: 자! 야근이다! 어차피 안 될 거지만 하는 척이라도 하자! 개발자: 뭐래.. (관심 없음)
경영진: 일정 내놔. 관리자: 여기.. 경영진: 땡겨. 관리자: 그럼 기능을 빼야.. 경영진: 확~! 관리자: 그럼 일정을 늘려야.. 경영진: 우쒸! .. (반복) .. 관리자: 해볼게요. 하지만 전 분명 안 된다고 말했어요. 경영진: 한다고 했으니 너가 책임져!
관리자: 자! 야근이다! 어차피 안 될 거지만 하는 척이라도 하자! 개발자: 뭐래.. (관심 없음)
결과야.. 얘기하지 않아도 ㅜㅜ
4~5년 전 스크럼 공부하며 정리해 놓은 마인드맵이다.
대부분 <스크럼: 팀의 생산성을 극대화시키는 애자일 방법론>의 내용이라 보면 된다.
이미지가 엄청 크니 확대해서 보시길..
스크럼에서는 기본적으로 ‘개인’은 별 의미가 없습니다. ‘팀’만 생각합니다. 누구 한 사람이 특정 작업을 완료하지 못했어도 결국 팀의 책임입니다. 누군가에게 잡무가 너무 많다면 이를 막거나 줄여주거나 대신 해주어야 하며, 방도가 없다면 어쩔 수 없는 거죠. 기술 문제에 봉착해 있다면 해법이나 길을 알려줘야 합니다. 팀은 공동 운명체..!! 이를 위해선 누가 뭘 하고 있는지, 어떤 문제가 있는지 활발히 공유하고 서로 도와야 합니다. 그 방법으로 태스크보드, 일일 스크럼 회의, 회고 같은 도구 쓰게 됩니다. 태스크보드는 팀의 목표와 진척 현황을 상시로 한 눈에 살펴보고, 목표를 상기하기 위한 도구입니다. 무언가 제대로 안되고 있다면 표가 나겠죠. 일일 스크럼 때 활용하기도 하고요. 보드에 붙이는 업무는 가능하면 (집중했을 때) 4시간 안에 끝낼 수 있는 단위로 나누는 게 좋습니다. 하루하루 지날 때 Done으로 옮기는 포스트잇이 있고 없고가 성취감에 큰 영향을 주기도 하고, 며칠이 지나도 계속 Doing 상태면 다른 이뿐 아니라 자신도 현황 파악이 안되고 목표도 불분명해져 관리가 안 됩니다. 일일 스크럼은 보다 적극적인 상황 공유 수단입니다. 매일 ‘같은 시간’에 ‘모든 팀원’이 모여 각자 다음 ‘세 가지’를 이야기합니다. 어제 한 일 오늘 할 일 봉착한 문제 이중 가장 중요한 것이 봉착한 문제입니다. 모든 팀원은 이 문제를 해결할 방법을 고민하고 알려줘야 합니다. ‘고민, 잘 모르겠는 것, 실수 등을 편하게 털어 놓으면 누군가가 노하우를 알려준다’는 분위기가 형성되지 않으면 서로 벽이 생기고 사람들이 위축됩니다. 회의 시간은 최대 15분으로 제한합니다. 길어질 이슈는 일일 스크럼 후에 담당자만 따로 모여 이야기합니다. <같은 시간, 15분 이내, 상황 공유>를 통해 다른 회의를 최소화하고 각자 일에 집중할 수 있게 합니다. 따라서 시작 시간이 들쑥날쑥 하거나 회의가 길어지면 효과가 반감됩니다. 회고는 주로 더 큰 관점의 노하우 공유나 제도 개선 방안 등을 논하는 자리입니다. 자아 비판이 아닙니다. 주로 이런 논의가 이루어집니다. 평소 이런 게 좀 잘 안된다고 생각했는데, 이렇게 하면 나아질 것 같다 이번에 이렇게 해봤는데 괜찮았으니 계속 해보자. 이 아이디어는 막상 해보니 처음 생각같은 효과가 없었다. 취소하거나 방식을 바꿔서 다음엔 이렇게 해보자.
보드에 붙이는 업무는 가능하면 (집중했을 때) 4시간 안에 끝낼 수 있는 단위로 나누는 게 좋습니다. 하루하루 지날 때 Done으로 옮기는 포스트잇이 있고 없고가 성취감에 큰 영향을 주기도 하고, 며칠이 지나도 계속 Doing 상태면 다른 이뿐 아니라 자신도 현황 파악이 안되고 목표도 불분명해져 관리가 안 됩니다.
라이브러리와 프레임워크는 프로그래밍을 조금만 하다 보면 접하는 흔한 용어이지만, 그 정의나 차이점을 물어보면 선뜻 답하지 못하는 이가 많다.
라이브러리는 자주 사용하는 기능을 미리 만들어 놓은 API 집합이다. 최댓값/최솟값을 구하는 간단한 함수부터 윈도우나 글상자를 그려주는 GUI 클래스 등 종류는 무궁무진하다.
당신은 자신의 프로그램을 짜며 필요할 때마다 이들 라이브러리의 기능을 호출해 사용한다.
프레임워크는 당신의 코드가 동작하는 규칙과 틀(프레임)을 규정해준다. 즉, 당신의 코드는 프레임워크가 정해준 규칙과 틀에 맞춰 짜여지고 동작한다. 이런 프레임워크의 대표적인 역할은 바로 생명주기 관리다.
비유하자면 이렇다. 아기가 태어나면 출생신고를 해야 한다. 그러면 정부는 그 아이의 일생에 걸쳐 여러 가지를 요청하고 그에 응하지 않으면 제재를 가하기도 한다. 예를 들어 나이가 차면 의무교육인 초등학교에 가게 하고 성인이 되면 주민등록증을 발급해준다. 남자라면 병역 의무도 져야 한다. 돈을 벌거나 공공 인프라(전기/수도 등)를 사용하면 세금을 내야 한다. 마지막으로 생을 마감하면 사망신고를 하고, 정부는 더는 그 사람에게 신경 쓰지 않는다. 여기서 사람은 당신이 작성한 코드, 정부는 프레임워크에 해당한다.
한 가지 더! 정부는 사람들이 공통적으로 많이 쓰는 기능을 직접 준비하고 운영하기도 한다. 철도나 버스 같은 대중교통과 전기와 수도 같은 인프라가 그렇다. 사람들은 자신이 필요할 때마다 이를 이용할 수 있으니, 사람 입장에서는 이는 라이브러리의 개념과 같다. 즉, 프레임워크는 보통 라이브러리를 포함한다.
이상을 이해하기 쉽게 도식화해보면 다음과 같다.
즉,
(원문) Introduce Parameter Object
Effective Unit Testing의7.3.9절에서 인용한 블로그 글이다.
항시 같이 몰려다니는 파라미터들이 있다. 그렇다면 이들을 묶는 객체를 만들어 대체하라.
“파라미터 객체 추출”이라 알려진 리펙토링 기법이다.
랄프 존슨(Ralph Johnson)은 리팩토링 책이 제시한 일반적 상황이 잘 이해되지 않는다 하였다. 거기서 말하는 일반적인 상황이란 이렇다. 서로를 호출하는 메서드가 한 뭉터기가 있다. 그리고 이 메서드들은 각각 수많은 파라미터를 가지고 있어서 파라미터 객체 추출 기법으로 리팩토링하고 싶은 상황이다. 하지만 각각에 파라미터 객체 추출을 적용하면 새로운 객체가 너무 많이 생길테니 고민이 된다. 우리는 객체 하나만을 주고받고 싶다.
그렇다면 연쇄적 호출이 시작되는 메서드에만 파라미터 객체를 적용하라. 그다음에 다른 메서드에는 다음의 ‘전체 객체 보존’ 기법을 적용하면 된다.
한 객체에서 복수의 값을 얻은 후, 이를 다른 메서드를 호출할 때 입력 인자로 넘긴다.
그렇다면 차라리 객체를 통체로 넘겨라.
나중에 더해져서 다른 개념을 보강 혹은 완성하는 것 A concept which is an abstraction from another concept, used to complete or add to the latter.
다른 데이터를 기술하는 데이터
책이라는 ‘실체를 훼손하지 않고’ ‘언제건’ 정보를 ‘더하거나 수정’할 수 있다. ‘실체에 접근하지 않고도’ 메타 데이터만으로 대상을 다룰 수 있다. 예> 분류, 검색, 정렬 등
프로그래밍에 메타 정보를 활용하는 것! 즉, 프로그램 본체 작성 후에 새로운 기능을 추가하거나 다른 용도로 사용할 수 있게 정보를 제공할 수 있다.
활용 예>
* 자바 어노테이션 (참고 – JUnit 4, 60초만에 익히기) * AOP(Aspect-oriented programming): 로깅, 동기화, 권한 확인 등 * C++ 템플릿 메타프로그래밍 * Ruby: 런타임에 객체 인스턴스에 새로운 메서드 추가
장점
부차적인 요소 혹은 변경될 소지가 있는 요소를 메타 정보로 추출하여 핵심 로직만 남겨둘 수 있다. 따라서 소스 코드의 가속성과 프로그램의 유연성이 높아진다.
단점
자칫 전체 로직의 연결 고리 일부가 사라져서 프로그램을 이해하기 어렵게 만들 수 있다.
