네이버가 개최한 개발자 컨퍼런스 ‘데뷰(DEVIEW) 2014’ 강연을 통해 훌륭한 소프트웨어(SW) 개발자에 대한 지론을 펼쳤다. NHN넥스트(www.nhnnext.org)는 네이버가 설립한 SW 인재양성 교육기관이다.
이날 이민석 학장은 훌륭한 개발자의 요건으로 ▲지적 호기심 ▲논리적 사고력 ▲수학적 배경지식 ▲문제 해결능력 ▲문제를 설명할 수 있는 커뮤니케이션(소통) 능력을 꼽았다.
이 학장은 훌륭한 개발자에 대해 “생산성이 높아야 한다”며 “이를 위해선 많은 개발도구에 익숙해져야 한다”고 말했다. 이어서 “개발 과정에서 알고리즘에 집중하기 전에 데이터를 먼저 살펴보라”고 조언했다.
또 그는 유명 개발자 조엘 스콜스키가 개발자의 요건으로 꼽은 ‘버그 데이터베이스(DB)를 가지고 있는가’, ‘새로운 코드를 만들기 전에 버그를 고치는가’에 대한 질문도 언급했다. 이에 대해 이 학장은 비슷한 실수를 되풀이하지 않기 위해 필요한 부분이라고 설명했다.
이 학장은 사회와 기술의 변화에도 주목할 것을 제언했다. 사회의 가치가 어떻게 바뀌는지 이해하고 이에 대한 대중의 반응도 두고 볼 필요가 있다는 것이다. 그는 기술과 그 기반이 되는 플랫폼의 변화도 살펴볼 것을 강조했다. 또 개발자 자신의 마음가짐이 변화를 주도하고 있는가도 곱씹어 볼 것을 주문했다.
그는 훌륭한 개발자가 곧 멋진 개발자라는 주장이다. 여기에서 말하는 ‘멋진’은 흔히 말하는 자뻑(자아도취)이 아닌 누군가의 멘토(가르침을 주는 사람)가 되고 동시에 멘티(가르침을 받는 사람)가 될 수 있어야 한다는 의미다.
이를 위해서 이 학장은 “커뮤니티로 가라”고 촉구했다. 개발자 자신이 배우고 베풀면서 많은 것을 얻게 된다는 것이다. 이를 통해 그는 흔히 말하는 선수(특출한 개발자)를 찾을 수 있게 되고 이들과 일할 수 있는 기회가 생긴다고 봤다.
마지막으로 이 학장은 훌륭한 개발자와 그렇지 않은 개발자 간의 생각의 차이를 설명하면서 “훌륭한 개발자는 커뮤니티를 항상 본다”, “데이터를 먼저 생각하고 알고리즘을 본다”, “보스보다 사용자를 생각한다”, “품질을 생각한다”, “수학을 고민한다”, “철야보다 휴가를 생각한다” 등 훌륭한 개발자의 요건을 다시 한번 강조했다.
저작자 표시
신고



Do First Dream Next

저자
조재천 지음
출판사
디지털북스 | 2012-06-11 출간
카테고리
경제/경영
책소개
개발자 출신 CEO가 들려주는 꿈과 성장에 관한 이야기『Do F...
가격비교 글쓴이 평점  



[추천독자]

- IT 업계에 종사하시는 분들, Developer가 되기를 꿈꾸는 분들


[느낌]

- IT 분야 외의 다양한 성공 스토리를 들을 수 있어서 좋다. 그러나 저자의 성공스토리는 조금 impact가 약했다.


[정리]

- 성공한 기업은 그들만의 스토리가 있다.

p 159~160 삼성과 현대의 스토리

  좋은 기업과 그렇지 않은 기업의 차이점이 여럿이겠지만 존경받는 기업들은 대체로 그만한 스토리를 갖고 있다.

  현대그룹 정주영 회장은 1952년 미국 아이젠하워 대통령의 방한 때 보리를 퍼 날라 잔디를 대신했고, 1984년에는 아산만 방조제 공사에 폐유조선을 활용한 이른바 정주영 공법을 만들었다. 또 현대조선 설립 당시 영국의 한 은행을 찾아가 500원짜리 지폐에 그려져 있는 거북선을 보여주며 차관을 도입한 일화도 유명하다. 그래서 많은 사람들의 그의 "해 봤어!"란 말을 많이 응용한다. 이러한 정신이 오늘날 현대의 '불굴의 도전정신'을 만들어 냈다. 모든 임직원들에게 실패를 모르는 자신감을 심어주는 원천이 되는 것이다.

  삼성의 이병철 회장은 1982년 72세라는 고령에도 불구하고 1,300 억원이라는 당시로 봐서는 천문학적인 손해를 감수하고서 반도체산업에 뛰어 들었다. 이병철 회장은 1등 기업을 만드는 것보다 10년 뒤 우리 국민이 무엇을 먹고 살 것인가에 더 관심이 많았다고 한다. 1995년인가 전 그룹적으로 10년 뒤 먹고 살 것을 구상하는 작업에 참여한 적이 있는데 이 또한 이병철 정신의 연장선이었을 것이다. 이병철 회장의 인재 육성에 대한 어룩은 참으로 많다. "교육을 시키면 사람의 몇 %가 바뀔 것 같은가? 많이 바뀔 것 같지만 5%만 그렇게 된다. 단 5%만의 효과를 얻더라도 교육을 시켜라. 그래도 공부를 하는 사람과 그렇지 않은 사람의 순서는 바뀐다." 이렇게 삼성은 '미래를 내다보는 혜안'이라는 스토리가 있다. 그래서 삼성은 미래를 여는 인재육성에 가장 큰 힘을 쏟는 기업으로 알려져 있다.


p.163 애플 스토리

  애플은 아무런 의미가 없어 보이는 것에 의미를 달아 놓은 듯 하다. 스티브 잡스가 어릴 적 과수원에서 살았고 사과를 좋아했던 것 때문에 '애플'이라고 정한 것은 참으로 단순 하다. 베어 먹은 사과 모양은 그대로 두면 체리와 같다 하여 사과임을 쉽게 인식할 수 있도록 했다. 그걸 '지혜의 습득'이라는 뜻을 붙인게 더 재미있다. (사실 여기에는 숨겨진 사실들이 있는데 베어 먹은 선악과 라는 의미도 있다고 들었다.)



- 불행함에 기죽지 말고 그것을 발판을 삼아 나아가라. 불행을 극복함으로 더 욱 강해 진다.

p.232 마쓰시다 성공 스토리

  '마쓰시다 고노스케'는 성공의 이유를 가난과 허약한 몸, 그리고 못 배운 세가지 은혜라고 했다. 가난 덕분에 부지런하게 일해야 잘 산다는 진리를 알았고, 혀약 덕분에 건강에 힘써 90대에도 30대의 건강함으로 겨울철 냉수마찰을 하며, 초등학교를 중퇴한 덕분에 배우는데 노력하여 많은 지식을 얻었다는 것이다. 불행을 오히려 축복으로 받아 들인 것이다.



- 유머있는 사람이 되어라, 유머는 적도 나의 편으로 만드는 힘이 있다.

p.257 처칠의 유머

  영국의 '처칠Winston Churchill' 수상은 유머감강으로도 유명하다. 처칠이 대기업의 국유화를 강하게 주장하던 노동당으 ㅣ요구에 시달리고 있을 때였다. 그날도 국회에서 정회 도중 처칠이 화장실에 볼일을 보러 갔다. 그곳에는 노동당 당수인 '애틀리 Clement Attlee'가 볼일을 보고 있었고 빈자리라곤 바로 그 옆 자리밖에 없었다. 하지만 처칠은 기다렸다가 다른 자리가 나자 그곳으로 가서 볼일을 봤다. 이에 애틀리가 "내 옆자리가 비었는데 왜 안 쓰는 거요? 내게 불쾌한 감정이라도 있는 겁니까?"라며 불만 섞인 말을 던졌다. 그러자 처칠은 "아뇨, 겁이 나서 그랬습니다. 당신들은 큰 것만 보면 다 국유화를 하려 들어서요."이라고 대답을 했다. 이에 애틀리가 폭소를 터뜨렸고 그 후에 노동당은 국유화 주장을 철회했다.


저작자 표시
신고

패턴의 필요성

- 전문 용어의 위력: 서로 알고 있는 패턴 용어는 정말 막강하다, 패턴을 이용하면 간단한 단어로 많은 것을 얘기할 수 있다. 패턴 수준에서 이야기를 하면 "디자인"에 더 오랫동안 집중할 수 있다. 전문용어를 사용하면 개발 팀의 능력을 극대화 할 수 있다. 전문용어는 신참 개발자들에게 훌륭한 자극제가 된다.

- 객체지향 기초지식만 가지고는 훌륭한 객체지향 디자이너가 될 수 없다.

- 훌륭한 객체 지향 디자인이라면 재사용성, 확장성, 관리의 용이성을 갖춰야 한다.

- 패턴은 훌륭한 객체지향 디자인 품질을 갖추고 있는 시스템을 만드는 방법을 제공해 준다.

- 패턴이 코드를 바로 제공해주는 것은 아니다. 디자인 문제에 대한 일반적인 해법을 제공. 특정 app에 패턴을 적용하는 것은 개발자의 몫



[객체지향의 기초]

- 추상화

- 캡슐화

- 다형성

- 상속


[객체지향 원칙]

- 바뀌는 부분은 캡슐화 한다.

- 상속보다는 구성을 활용한다.

- 구현이 아닌 인터페이스에 맞춰서 프로그래밍 한다.

- 서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용한다. (유연하고 변화에 강하다)

- 클래스는 확장에 대해서는 열려 있지만 변경에 대해서는 닫혀 있어야 한다. (OCP, Open-Close-Principle)


[객체지향 패턴]

- Strategy Pattern: 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. Strategy Pattern을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다. (interface)


- Observer Pattern: 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다 의존성을 정의합니다.

  스윙 및 여러 GUI 프레임워크에서 옵저버 패턴이 많이 쓰인다. 그 뿐아니라 다른 부분에서도 광범위하게 쓰인다(JavaBean, RMI)


- Decorator Pattern: 객체에 추가 요소를 동적으로 더할 수 있다. 데코레이터를 사용하며 서브 클래스를 만드는 경우에 비해 후러씬 유연하게 기능을 확장할 수 있다. (데코레이터 패턴을 사용하면 자잘한 객체들이 매우 많이 추가될 수 있고, 데코레이터를 너무 많이 사용하면 코드가 필요 이상으로 복잡해질 수도 있습니다)

저작자 표시
신고



글로벌 소프트웨어를 꿈꾸다

저자
김익환 지음
출판사
한빛미디어 | 2010-09-30 출간
카테고리
컴퓨터/IT
책소개
성공하는 소프트웨어 회사의 조건!소프트웨어의 문화, 본질, 그리...
가격비교 글쓴이 평점  


( 4일) 2012/12/2~2012/12/5    p.248


[정리]

글로벌 소프트웨어만이 살아남을 수 있다. 열심히 쌓아온 막강한 기술력만으로 충분할까? 제아무리 기술력이 뛰어나다 하더락도 개발문화가 뒷받침되지 않으면 글로벌 소프트웨어 회사로 성장하는 것은 어렵다. 개발문화는 소프트웨어의 본질이기 때문이다.


- 혁신하든가 사라지든가

  70년까지 살 수 있는 솔개는 대부분은 40년에 수명을 다 한다. 40년이 다되면 부리는 너무 길어져 먹이를 쪼기 힘들어지고, 발톱은 무뎌지고, 날개는 기름에 절고 무성해져서 사냥을 할 수 없는데. 여기서 엄청난 자기 갱생의 노력을 한 솔개는 사라남는다.(부리를 일부로 돌에 부딪혀 깨뜨려서 새부리가 나오게 하고, 새로 나온 부리로 발톱을 쪼아 없애서 새 발톱을, 날개를 뽇아서 새 날개가 나오게 만든다. 이 노력을 6개월 하면 30년 더 살아남는다.

  소프트웨어 회사에 필요한 혁신 : 오랫동안 습관적으로 일해오던 것들이 대부분 혁신의 대상 (따라 하지 않던 프로세싱, 문서쓰기, 아키텍처 재정립, 소스코드 청소, 기반시스템 정립, 소스코드 리뷰 등...)

  롤 모델이 필요 혁신을 가이디 할 수 있는 선각자를 발견해서 배워야 한다.


- 변하지 않으면 죽는다.

  앨빈 토플러 : 회사가 생존하기 위해서는 항상 변해야 한다. 변하지 않는 회사는 죽는다. 변하는 회사는 70%가 살아남는다.

  경영자가 바꿔야 할 것 : 하드웨어 마인드를 버려라(변경을 최소화), 소프트웨어는 아무나 개발할 수 있다는 생각을 버려라(개발자의 능력에 따라 결과는 28배나 차이가 난다고 파나스가 말했다), 관리자나 영업이 개발자를 좌지우지 하지 않게 하라, 빠른 개발의 경영전략을 버려라, 일정을 협상하지마라, 2% 부족한 것을 간과하지 마라, 조급한 생각을 버려라

  개발자가 바꿔야 할 것 : 자신의 능력을 정확히 알고 행동하라, 급할 수록 천천히 가야한다, 처음부터 제대로 배워야 한다, 항상 자신을 변화시키려고 노력해야 한다.


- 소프트웨어 회사는 두번의 재건축이 필요하다.

  첫번째 : 소스의 벤처회사에서 수십 명 정도의 중소기업으로 자라날때

  두번째 : 중견기업에서 대기업으로 성장할 때

  기반시스템, 조직, 프로세스, 기술, 문화 등을 전반적으로 바꿔야 한다. (소스관리시스템이나 이슈관리시스템, 개발 스피드보다 관리와 안전)


- 미국회사는 기본이 70점, 한국회사는 20점에서 시작

  실리콘밸리에서 근무하는 소프트웨어 개발자의 직장 평균 재직기간 2년이 안된다. 개발자가 직접 여러 회사를 다니거나 이직한 동료 개발자를 통해서 개발자, 회사 모두 다양한 경험을 쌓는다. 이러한 이직 문화가 가능한 이유는 인력 이동에 대한 준비가 되어 있기 때문(기반시스템 설치, 프로세스 정립, 코딩의 표준화, 문서화 방법, 개발방법론, 공유 문화 정립 등)


- 꼬여버린 프로세스 코드, 기반시스템

  조화가 필요한 도구들, 도구는 한번 사용하기 시작하면 늪처럼 빠져 나오기 힘들다. 보다 위험한 경우는 어떤 사용도구도 자기 회사의 특수한 문제를 해결하지 못한다는 생각에 도구를 자체 개발하는 것.


- 공유를 싫어하는 사람은 소프트웨어 회사에 적합하지 않다.

  소프트웨어 회사에서 중요한 것은 공유의 문화, 중요한 인재는 정해진 프로세스, 개발원칙을 잘 지키면서 공유하고 협업하며 묵묵히 일하는 사람.


- 회사에 필수적인 소프트웨어 전문가

  컨퍼런스 세미나 참석 : 새로운 기술을 습득하기 위한 방법

  회사에서 승진하려면 관리자가 되어야 한다고 생각하는 것이 한국사회의 통념, 나이 많은 최고의 개발자가 미국엔 수없이 많다.

  구글에서는 개발자와 영업자 사이에 이견이 생기면 대부분 개발자가 이긴다고 한다


- 소프트웨어 회사가 성공하기 위한 다섯가지 조건

  기반시스템 : 이슈관리시스템(필수), 소스관리시스템(필수), 테스트관리시스템, 빌르/릴리즈관리시스템, 프로젝트관리시스템, 작업관리시스템, 고객관리시스템, ERP, 등

  조직

  프로세스

  기술 : 기술은 시대에 따라 변한다, 평균 수명은 3년, 기술에 관한 한 당장 먹을 만큼만 사오는 것이 효율적.

  문화 : 웹 2.0의 3대 키워드인 참여, 공유, 개방. 다른일에 참여도 하고 자기 것을 공유도 하고 개방도 하면 된다. 구글에서는 입사 첫날 누구든지 모든 소스코드를 다운받아 컴파일해서 사용할 수 있다고 한다.

 

- 이슈관리스템을 보면 회사를 안다.

  이슈관리시스템은 대시보드 형식으로 모든 직원이 항상 모니터에 뛰어 놓고 모니터링 한다. 개발자의 업무지시가 대부분 여기에서 온다. 출근후 가장 먼저 본다. 오늘 하루의 일과 예상(시간절약), 모든 직원 사용한다(email,전화사용 최소화), 이슈를 등록한다(발견한 사람이, 전체 시간이 더 걸리기도 하고 지속적으로 계속 대리인에게 의존하게 되어 모두의 생선성을 떨어뜨린다. 특히 윗사람이 아랫사람에게 시키지 않도록)

  전사적으로 제품이 몇 개나 있는지 한눈에 알 수 있다. 각 제품의 버전과 컴포넌트가 몇 개나 있는지 알 수 있다. 핵심 제품을 알 수 있다. 고객이 누군지 얼마나 많이 팔리는 제품인지도 추측가능, 제품의 안정성, 버그나 기능 요청이 얼마나 있는지, 어제 새로 발생한 심각한 문제가 있는지, 개발 혹은 유지보수의 진행 상태, 이슈 해결 상태, 어느 개발자 혹은 어느 부서의 업무가 과도한지 혹은 한가한지를 알 수 있다, 데이터 베이스로 관리되어 필터 할 수 있다.


- 소스관리시스템은 개발팀의 축소판이다.

  가장 기본적인 표준 준수 문화를 본다. 소스코드의 코딩 컨벤션이나 프로그래밍 스타일은 통일되어 있는지, 주석은 이해가능한지, Check in할때 로그 남기는지, 이슈번호는 있는지, 동료검토한 이름은 있는지, 누가 개발했고 누가 개발하는지, 버전수 등


- 문서를 적으면 개발시간이 단축된다는 것을 진정으로 믿어라

  문서가 없이는 소프트웨어의 전체 구조가 깨끗하게 만들어지지 않는다는 것. (10층 짜리 건물을 설계 없이 쌓아 올리는 것과 비슷), 필자는 문서 없이 잘 개발하는 것을 보면 기적이라고 생각한다.


- 스펙(SRS) 이란 ?

  SRS(Software Requirements Specification)는 분석단계의 결과로 나오는 산출물 : 기능명세서, 요구사항명세서, 요구사항분석서

  좋은 품질의 소프트웨어를 최소비용과 최소시간에 개발하기 위해 적는 문서

  IEEE 에서 말하길 소프트웨어 개발에서 가장 중요하고 어려운 것이 SRS를 적는것.

  모든 부서의 사람이 동시에 제품개발에 참여 할 수 있는 문서를 만드는 것.

  SRS를 적을때는 왜가 더 중요하다. 예를 들어 개발언어를 계발 언어를 Java로 하는 것이 중요한 것이 아니라 왜 C++인지, 왜 Java로 하기로 했는지가 중요, 또 왜 DBMS로 MS-SQL이 아는 Oracle을 사용하는지. SRS의 처음부터 끝까지 모든 문장에서 '왜?'라는 질문을 던져보는 것. 그리고 왜에서 무엇으로 진행된 과정도 적는다.


- 장식용, 제출용, 실용적인 방법론

  장식용 방법론 : 외부 과시용

  제출용 방법론 : 개발 후반부에 작성 기계적으로 적기만

  실용적인 방법론 : 필요한 만큼 문서 몇 개만 골라서 작성, 그래야 유지 보수도 가능

  방법론은 제대로 됭어가서 일하다 보면 저절로 배우는 것이지 미리 배우고 가서 써먹는 것이 아니다.


- CTO의 역할은 아무나 대신하지 못한다.

  벤처투자가가 벤처회사에 투자할 때 보는 첫 번째 조건 CTO가 있는가 이다. (연구소장, 개발실장,R&D부사장 등 과 혼란하지 말자, CTO는 인사관리를 안한다)

  CEO는 회사의 비전과 돈을, CTO는 기술에 관한 모든 것을 책임 지는 것(장기기술전략, 실행전략, 아키텍처, 구현, 일프라구조 정립, 프로세스 등 개발에 관한 기술적인 것이라면 모두 책임), 나중에 개발자한테 물어봐서 답해 드릴게요 라고 하면 CTO가 아니다.

  CEO, CTO를 한 사람이 수행하는 것은 슈퍼맨과 같은 역량과 두배의 시간을 요구.

  CEO가 컨퍼런스 발표를 할 때 기술적인 질문에 대답할 수 있는 CTO대동하고 다닌다. 그 둘이면 어떤 질문이 나와도 답 할 수 있다. 구글에서도 게르게이도 기술적인 질문이 나올 경우 대비 같이 참석. 빌게이츠도 은퇴전까지 Chief Software Architect라는 직함을 가짐(마이크로소프트의 최고 기술 전략책임자, 현재는 레이 오지) 빌게이츠는 CEO와 CTO 사이를 넘나들었는데, 어떤 제품의 설계 문서를 검토하다 날짜 Format이 잘못될 수 있다는 것을 발견해 내고 질문했다는 일화도 있다. 구글의 CEO인 에릭 슈미트도 썬마이크로시스템즈에서 CTO를 했었다. 그는 UNIX의 유명한 구문분석기인 LEX를 개발한 대단한 개발자다. 에릭 슈미트처럼 CTO가 비지니스 감각을 배우고 CEO로 전향한 경우도 많다.


- 관리자는 기술 전문가가 될 수 없다.

  전문개발자가 되려면 인사관리를 할 시간이 없다는 것이다. 미국의 소프트웨어 회사는 모두 관리직과 기술직의 두 경로로 나누어져 있다. 소프트웨어의 전문성을 이해하지 못하는 개발자가 있다. 원하는 것이 너무 많다. 개발자 경로에 있으니 코딩도 해야 한다고 하고 실력이 있으니 주니어 개발자의 기술 리더, 팀장이 되어야 한다고 하고, 그러면서 팀의 평가, 인사관리, 일정관리도 해야 한다고 한다. 필요로 하는 기능이 무엇인가 잘 알 고 있으니 제품기획도 할 수 있다고 한다. 혼자서 기술 전문가, 관리자 PM, 제품 마케팅 등 모든 역할을 다 하고 싶어 한다. 이 개발자는 다른 업무의 전문성을 이해하지 못하고 있다. 그중의 하나만도 잘하는 것이 어렵고, 하나만 잘해도 충분한 가치가 있는 것을 모르는 것. 인사관리에 발을 들여 놓는 순간 기술에 쏟아야 하는 시간을 빼앗긴다.

  '과거를 자랑하지 마라, 자랑할 과거밖에 소유한 것이 없을때 처량해 진다' 세익스피어


- 200의 능력을 가진 회사가 100에 만족하면 위험하다.

  미래 사상가인 앨빈 토플러 '과거에 성공을 거두는 데 도움을 주었던 제품, 프로세스, 조직 형태가 이제는 파멸의 원인이 되는 경우가 많다. 여기서 생존 기업이 되려면 제 1법칙은 뚜렷해진다. 즉 과거의 성공을 미래의 가장 위험한 요소로 파악해야 한다.'


- 소프트웨어 회사의 종류

  행정적 관점 : 패키지 소프트웨어 회사, IT서비스 회사, 임베디드 소프트웨어 회사, 콘텐츠 소프트웨어 회사

  개발방법론적 측면 : 패키지 소프트웨어 회사, SI(system intergration) 회사, 게임 개발회사, 웹 포탈 회사, 전자제품 제조회사(휴대전화,셋톱박스, 에어콘, 냉장고, TV등), 보안장비 개발회사 (FireWall, IPS, IDS 등), 전산팀(은행,증권사,대기업), On-Line 쇼핑몰 회사, 비즈니스 솔류션 개발회사, 라이브러리 개발회사, 소프트웨어 공학이나 개발도구 개발회사, 스마트폰 앱 개발 회사

  소프트웨어를 최소비용으로 최소시간에 개발한다는 목적 하에서 모든 소프트웨어 회사가 해야 할 일은 같다.


- 임베디드 소프트웨어의 본질, 컴포넌트와 인터페이스

  임베디드 시스템 (Embedded System, 내장형 시스템)은 시스템을 동작시키는 소프트웨어를 하드웨어에 내장하여 특수한 기능만을 수행하는 컴퓨터 시스템. 임베디드와 일반 소프트웨어의 다른점은 성능이 중요하다는 것 그리고 하드웨어 비용문제를 고려해야 한다는 점.


- 영업팀과 개발팀의 다툼은 건전한 것

  영업팀의 힘이 센 회사에서 개발팀은 빡빡한 일정으로 바쁠 것. 영업팀은 항상 이번 고객은 진짜 중요한 고객이라서 무조건 빨리 개발해야 한다고 한다. 그런 상황에서 개발자가 어떤 삶을 살아갈지는 눈에 선하다. 근본적으로 영업팀과 개발팀은 서로를 이해하지 못한다. 같은 회사에서 10년을 같이 근무했다고 해도 영업팀이 개발에 대한 통찰력을 갖기는 힘들고 개발팀이 영업팀의 고충을 가슴으로 느끼기도 힘들다. 영업은 하나의 고객만 있더라도 당장 제품을 판매하길 원하는 단기 전략이 우선이고, 개발팀은 선행연구도 해야하고, 유지보수도 걱정해야 하고, 버전도 최소해야 하고, 컴포넌트화된 산뜻한 제품을 만들기도 해야 하므로 중장기 전략이 우선이다. 미래 제품에 대한 아키텍처도 준비해야 하고, 기술 전략도 수립해야 한다. 이 두 팀이 잘 맞는다고 하면 회사에 심각한 문제가 있다는 것을 의미다. 그 다툼은 회사가 성장하면서 제품 영역이 넓어지고 고객이 늘어날수록 영원히 계속된다. 이 다툼을 조율하는 부서는 통상적으로 마케팅 부서다.


- 깨진 유리창 법칙

  스탠포드대학의 심리학자 필립 짐바르가 교수가 다음과 같은 실험을 했다. 치안이 허술한 골목을 고르고, 거기에 보존 상태가 동일한 두대의 자동차 창문을 열어놓은 채로 1주일간 방치해 두었다. 그 중 한대는 고의적으로 창문을 조금 깬 상태. 일주일후 단지 유리창을 조금 파손시켜 놓은 것뿐인데도 그렇지 않은 차와 비교하면 약탈이 생기거나, 파괴될 가능성이 매우 높아진다. 이것이 '깨진 유리창의' 시초다.

  상태계에서 파괴적인 습성을 가진 두 개가 있는데 인간과 바이러스라고 한다. 영화 <메트릭스>에 나오는 대사다. 지구의 모든 생명체는 환경과 잘 조화를 이루면서 살아가는데 인간과 바이러스만 자기가 사는 환경을 파괴하고 계속해서 다른 곳으로 옮겨간다고 한다. 그래서 기계가 인간을 컨트롤해야 좋은 세상이 온다는, 매트릭스를 설계한 아키텍트가 한 대사다.


- 시장은 창조하는 것이다.

  개리해멀은 <경영의 미래>에서 '미래는 예측하지 말고 창조하라'는 말을 했다. 피터 드러커도 다음과 같이 말했다. '우리는 미래를 예측할 수 없다. 대신 미래를 창조 할 수 있다.' 또 알랜 케이도 '미래를 예측하는 가장 좋은 방법은 미래를 만드는 것이다.' 예측은 해야한다. 사업계획서가 계획대로 실행된 경우가 있다면 기적이라고 본다. 그렇다고 사업계획 없이 시작한다면 그것은 더 위험한 일이다.

  먼저 아이디어를 가진 개발자 두세 명이 모여서 돈을 투자받기 위한 사업 계획서를 작성한다. 작성한 사업계획서를 벤처투자가에게 보여줘야 하는데 만날 기회가 없다. 벤처투자가는 시간이 돈인, 매우 바쁜 사람이라 아무하고나 얘기하지 않는다. 우연한 기회에 같은 엘리베이터를 탈 기회를 얻었는데 엘리베이터 안에 함께 머물수 있는 시간은 30초 밖에 없다고 하자. 이 짧은 30초 동안 얘기를 해서 벤처투자가의 흥미를 끈다. 이것이 바로 '30초 엘리베이터 스피치'라는 것. 짧은 시간에 매력적으로 설명해야 한다. 벤처 투자를 받기 전까지 회사 운영비를 위해 친지들한테서 조그만한 투자를 받기도 한다. 그들을 엔젤투자가라고 한다. 3F라고 하는데 Friends, Family, Fool을 의미한다. 그런과정을 거쳐 벤처투자가가 투자를 했다면 첫 번째 투자를 Series-A라고 부른다. 약 일 년 후에 또 투자를 받는데 그것을 Series-B라고 한다. 그 다음은 어느 정도 성공한 단계. 마지막 단계인 Series-C에서는 투자를 받고 주식시장에 상장한다. 아니면 인수합병 대상이 되어서 대기업에 팔린다. 이러한 상장이나 인수합병을 출구전략 (Exit Plan)이라고 한다. 이게 가장 통상적인 시나리오다.

  어느 단계에서 누가 이 벤처회사가 잘 되기를 바라고 도와주겠는가 ? 당연히 Series-A,B,C의 벤처투자가다. 그다음이 이사회의 이사다. 이사회는 'Board Of Driectors' (BOD)라고 한다. 혹은 짧게 Board라고 한다. BOD 멤버는 업계에서 영향력 있는 사람을 불러들인다. 그것도 투자가와 창업자의 능력이다. 한국의 형식적인 이사회와는 다르다. 이 투자가와 이사들이 회사가 잘되면 엄청나게 돈을 버는 사람이다. 얼마 전 구글의 CEO인 에릭 슈미트가 애플의 이사로 있다가 서로 경쟁을 하게 되니가 이사직을 물러났다. 두 회사가 본격적인 경쟁에 들어갔다는 것을 확실히 알 수 있다. 전략적인 파트너를 소개시켜 주기도 하고 회사 제품의 베타 사이트가 될 만한 고객을 구해 주기도 하고 또 Analyst라고 하는 업계의 전문가들에게 소개시켜 주기도 하고 잘 부탁하기도 한다. 이런 Analyst와 관계를 듀지하고 계속 공생하는 것이 벤처투자가이며 영향력 있는 이사들이다. 이들은 기회가 될 때마다 Analyst에게 연결해 주고 평가 대상에 선택되도록 노력한다, 그러니 항상 제품을 이해하고 있어야 한다. 그래서 벤처투자가의 투자 원칙 중 하나가 자기 사무실 근처에 있는 회사에 투자하는 것이다. 그래야 오다가도 들려서 어떻게 되는지 살펴보고 도와줄 기회를 찾을 수 있다. 가트너나 IDC같은 연구조사기관도 관계를 가지고 있어야 한다. 회사의 임원에게 당신 회사가 미래에 뭘 하려고 하느냐고 묻는 것이다. 임원은 자기 회사나 이해관계가 있는 회사에 도움이 되도록 시장이 이러저러하게 움직이고 있다고 얘기해 준다. 그 얘기를 전해 들은 조사기관은 미래의 시장은 이렇다고 큰 소리친다. 결국 시장은 이들이 장단을 맞추어서 만들어내는 것이다. 소비자는 그런 기사를 읽고 그 방향으로 움직인다. 시장은 이들에 의해 그 방향으로 흘러가는 것이다. 즉 시장은 생성되는 것이다.


-  신입사원은 문서(50%), 포로세스(45%), 선배(5%)로 부터 배운다.

  입사 첫날 관리자가 팀원들에게 인사시키고 자리를 안내 했다. 책꽂이가 어디 있는가를 알려주고 문서 몇 권을 주면서 읽으라고 했다. 학교에서는 들어보지 못했던 소프트웨어 개발방법론에 관한 책이 었다. SRS(Software Requirements Specification)를 작성하는 법, SDS(Software Design Specification)를 작성하는 법, 형상관리 규칙, 코딩 규칙 같은 것들이었다. 선배는 내게 아랑곳하지 않고 자기 맡은 일만 열심히 하고 있었다. 가끔가다 쉴때면 그때서야 나에게 이런 저런 얘기를 했다. 관리자는 가끔 들러서 체크하고 다음 읽을 책을 알려 줬다. 단 둘이 붙어서 일방적으로 배운적은 한번도 없다.

  위와 같은 환경에서 문서가 없다고 가정을 해보자. 도저히 배울 방법이 없다. 문서와 프로세스가 잘 되어 있지 않으면 신입사원은 선배 없으면 생존할 수 없는 상황이 된다. 이를 한국에서는 사수-조수 시스템이라고 부른다. 가내 수공업 시대 때나 성행하던 사수-조수 시스템이 문명의 최선두를 달리고 있는 소프트웨어 개발 현장에 아직도 나타난다는 것이 아리로니컬하다. 지식 공유가 효율적으로 이루어지려면 잘 작성된 문서와 프로세스가 필 수 조건이다.


- 최소 비용과 최소 시간

  (초보자) 시간 없는데 문서 만들지 말고 빨리 코딩 시작해야 하지 않습니까?

  (전문가) 왜 빨리 코딩을 시작해야 하나 ?

  (초보자) 제품을 빨리 만들어야 하니까요

  (전문가) 내가 바로 좋은 제품을 빨리 만들기 위해 문서를 만들고 있는 거야

  소프트웨어 공학의 유일한 목적은 '최소 비용으로 최소의 시간에 좋은 품질의 소프트웨어를 만드는 것'


- 서로 배우게 하라

  온라인 상점의 시초였던 비아웹의 공동창업자인 폴 그래함(Paul Graham)dㅣ 다음과 같은 얘기를 했다. '같이 일할 사람 한 명을 설득할 수 없다면 창업은 시작하지 않는게 좋습니다. 인생을 바쳐서 같이 일할 사람 두 명을 설득할 수 없다면 희망이 없습니다. 다시 말하건데 누군가 다른 한 사람을 공동 창업자로 구하십시오, 그것이 당신이 성공하기 위해 필요한 최소한의 일입니다.'

  다른 부서 일에 참견한다는 안 좋은 말을 들을지 모르지만 이런 사람이야 말로 회사에서 키워야 할 핵심 인력이다. 문제를 숨기는 것보다 다른 사람의 잘 못을 지적해 내는 사람이 그 순간에는 거북할지 모르나 신뢰할 수 있고 중요한 일을 해낸다.

  진정한 소프트웨어 전문가가 되기 위해서 어려운 세 가지가 있다. 좋은 개발환경을 접하기가 어렵고, 좋은 스승을 만나기가 어렵고, 마지막으로 자기자신이 깨닫기가 어렵다.


- 동료검토는 권장하지마라.

  동료검토는 개발의 가장 앞 단계부터 수행되어서 정보 공유가 계속되어 왔어야 가치가 있다. 이런 선행조건이 없다면 필자는 동료검토를 권장하지 않는다.


- 조삼모사, 유지보수의 늪에 빠지다.

  어느 개발자가 설계도 안하고 스펙도 안 적고 그냥 100시간 코딩해다고 치자, 필자는 시간이 없어서 코딩한다는 개발자치고 제대로 스펙을 적고 개발한 사람을 본 적이 없다. 현명한 개발자라면 30시간은 스펙에, 30시간은 설계에 30시간은 코딩에 사용해서 총 90시간으로 단축할 수 있다.


- 머지 데이를 정해서 할 이유가 없다.

  두 개의 수정된 코드를 가져다 놓고 합치는 행위가 2-Way 머지

  최초의 원본과 수정된 2개의 파일, 모두 3개의 이용해서 머지를 하는 3-Way 머지.


- 배우려면 잔을 비워라.

  시간을 절약하는 방법을 가르쳐 주려는데 시간이 없어서 배우지 못한다는 것은 자기 모순적인 상황이다. 이를 소설에서 유래한 '캐치-22'라고 한다. 한 마디로 빈곤의 악순환이다.


-  백발이 성성한 프로그래머는 없다.

  프로그래머는 수년의 경력 정도면 한계에 이른다. 프로그래밍 기술은 소프트웨어 개발의 시초이며 핵심 역량이지만 개발자의 경력으로 계속 유지될 수 있는 기술은 아니다. 'Are you a softwear engineer?'가 맞는 표현

  코딩을 하고 싶어서 개발자가 된 사람에게는 미안하지만 아르바이트생 프로그래머와 별로 위상이 다르지 않다고 말하고 싶다.

  백발이 성성한 개발자는 프로그래머와 구별되어야 하고 가치를 인정받아야 한다.


- 비싼 도구가 기술 역량을 올려주지 않는다.

  과거에 메인프레임에서 포트란 프로그래밍을 할 때는 모니터와 키보드가 아니라 천공기에서 카드 한 짱씩 찍어가면서 프로그래밍을 했기 때문에 실수하면 카드 값도 들고 타이핑도 다시 해야 하고 또 컴퓨터 시간도 순번제로 기다려야 하기 때문에 코드를 적을 때 심사숙고 생각했었다. 그래서 그 때는 에러도 적고 항상 전체적으로 모든 것을 생각하는 버릇이 되어 있었는데 요새는 대충 준비되면 소스코드 적는다고 달려든다. 도구가 좋아서 생기는 나쁜 현상이다. 도구를 사용하되 생각은 도구가 없는 환경에서처럼 하라고 권유하고 싶다. 가장 성능이 좋다고 평가받는 컴파일러도 오픈소스인 gcc이다. 가장 많이 사용하는 소스관리 도구도 역시 오픈소스인 SVN이다. 이슈관리 시스템도 마찬가지로 오픈소스인 Mantis가 가장 많이 사용된다. 구글의 안드로이드 프로젝트도 리누스 토발즈가 만든 GIT라는 오픈소스 무료 소스관리 도구를 사용한다.


- 표현법이 진보를 가져오지는 않는다.

  표현법은 가장 마지막 단계일 뿐이지 모든 것은 머리로 생각한다. 설계의 핵심은 컴퓨넌트와 인터페이스를 간단하고 깨끗하게 정의하는 것이다. 이는 머리로 하는 것이지 도구로 하는 것이 안다. 그 결과를 표현하는 수많은 정형적인 혹은 비정형적인 방법이 있으니까 적절히 사용하면 되는 것이다. 지금까지 있었던 프로그래밍 언어 중 가장 뛰어난 객체지향 언어는 SmallTalk이라고 한다. 그 후에 나온 인기 있는 C++이나 Java가 객체지향의 진화를 가져오지는 않았다. 마치 표현법이 바뀌면 대단한 진화를 한 것처럼 생각하는데 착각이다. 머리 속으로 분석하고, 머리 속으로 설계하고, 머리 속으로 코딩하는 법을 익히는 것이 진정으로 소프트웨어 개발에서 전문가가 되는 길이다.


- 지식과 기법은 달콤한 사탕과 같다.

  세 가지 유형의 개발자. 첫째 원론적인 것에 치우친 사이언티스트, 둘째 테크니션형은 기법적인 것에 신경을 쓴다. 마지막으로 개발자는 현실에서 고객이 무엇을 원하고 어떻게 하면 좋은 품질의 제품을 빨리 개발할 수 있을까 하는 것에 초점을 둔다. 즉 표현은 못하지만 실행할 줄 아는 암묵적 지식의 소유자다. 세 유형 모드 소프트웨어 회사에 어느 정도 필요한 존재다.

  도구를 잘 아는 사람은 Technician, 알고르즘에 신경 쓴다면 Scientist, 워드프로세서 사용법을 잘 아는 사람은 문학 Technician이다. 문학의 역사, 문학의 종류, 소설가의 생애와 업적 등을 잘 알고 있다면 '문학 Scientist'이다. 반면 실제 소설을 잘 쓴다면 '문학 Engineer'이다.


- 스파트폰, 소프트웨어 공학을 경험할 좋은 기회

  스마트폰 앱은 혼자서 개발하는데 뭐 하러 문서를 만드나? 라고 반문할지 모른다. 핵심은 문서의 양과 질이다. 스마트폰 개발처럼 소프트웨어 공학의 여러 측면을 다양하게 경험 할 수 있는 기회도 드물다. 큰 규모가 아니면서도 여러 플랫폼, 수많은 버전관리, 수많은 언어 지원과 같이 세계화를 목적으로 만든 애플리케이션이라면 꼭 다루어야 할 주제를 다 포함하고 있다. 스마트폰 앱을 개발하려고 할 때 지원해야 할 스마트폰 플랫폼을 살펴보자. 통상적으로 3단계 지원계획. 1단계 아이폰(아이패드) 안드로이드 지원, 2번째 블랙베리, 윈도우폰7 ... 초기에 시간이 들더라도 정교한 계획과 아키텍처를 결정하고 시작하는 것이 현명하다. 전 세계에 제품을 팔고 싶다면 방법을 바꿔야 한다. 돈키오테 같은 무모한 열정으로도 드물게 성공하기 하지만 현명한 방법은 아니다. 멀티-플랫폼에서의 디버그 방식만 해도 여러 가지를 고려해야 한다. 일단 모든 오류번호와 오류메시지도 통일해야 하고 그러려면 공통 파일을 공유해서 사용해야 하고, 소싀관리시스템도 그에 맞게 정교한 구조를 가져야 한다. 또 수많은 플랫폼, OS버전, 기기종류에서 발생하는 이슈나 오류를 추적하기 위해선 지금까지의 관리 방식보다는 더 복잡하고 체계적인 이슈관리 시스템을 필요로 한다.


- 기업문화란 무엇인가 ?

  세계적인 소프트웨어 개발자가 이런 회사에 와서 일한다고 해도 상황이 바뀌지 않는다. 기술은 있지만 문화의 희생물인 또 한명의 힘없는 개발자로 남을 것이다. 학습된 무력감 (Learned Helpllessness) 현상이 나타난다. 개에게 전기충격을 주면 처음에는 충격을 피하려고 뛰기도 하고 도피하려고도 하며 활동적으로 움직이다가 전기 충격이 계속 가해지면 나중에는 도피하려는 의욕도 없고 아무것도 하지 않으려 하고 무기력해진다는 것이다.

  우슷갯소리를 하나 더 소개한다. 참새 세 마리가 줄에 앉아 있다. 이중 두마리가 날아가기로 마음먹었다. 잠시 후에 남아 있는 참새는 몇 마리인가? 답은 여전히 세마리다.

 

신고



프로그래머 그 다음 이야기

저자
임백준 지음
출판사
로드북 | 2011-07-08 출간
카테고리
컴퓨터/IT
책소개
『프로그래머 그 다음 이야기』는 프로그래밍 세계에서 다양한 배경...
가격비교 글쓴이 평점  

[느낌]

선배 프로그래머들의 경험을 얻을 수 잇엇던 귀중한 책.

내가 미래의 갈길을 미리 경험한 듯 한 느낌이다.

이제 막 프로그래머 로써의 길을 시작한 사람들을 위해 추천한다.

지금 현실에 안주하지말고 미래를 내다보는 그리고 즐거운일을 더욱더 전문가적인 견해로써 학습하여 구루가 되더록 하자.

신고



프로그래머의 길 멘토에게 묻다

저자
데이브 후버 지음
출판사
인사이트 | 2010-07-26 출간
카테고리
컴퓨터/IT
책소개
소프트웨어 개발 분야 새내기를 위한 프로그래머 가이드견습 프로그...
가격비교 글쓴이 평점  

[정리]

- 읽어야할 기초적인 책들 : object-oriented software construction, a pattern language, re-factoring to patterns, effective perl programming. effective c++, effective java, code complete,  the progmatic programmer.

배운것을 잊어버려라 흰띠를 맨다는 것은 감은 띠라는 방법은 알지만 흰띠를 배우는 것 말고는 다른 선택이 없다는 깨달음.
    --> 어리석게 여겨짐을 두려워하여 새로운 일을 시도하지 못했던 적이 얼마마 많앗던가?

- 깊은쪽으로 뛰어들어라 기다리지 마라.

- 가장 뒤떨어진 이가 되라. 주변을 당신보다 뛰어난 개발자로 채워라

- 온라인 대학강좌 등 배우라

- 부숴도 괜찮은 장난감 위키 캘린더 주소록 테트리스.틱택토 블로깅 소프트웨어, irc

- 빌게이츠 왈 프로그래밍 능력을 테스트 하는 가장 좋은 방법중 하나 프로그래머에게 30페이지 분량 코드 주고 통독 이해력 판단하는 것

- 브룩스의 법칙 지체된 프로젝트에 인력을 투입해 봣자 완료일이 더 지체

- 시간은 한정적 나는 훌륭한 것만 읽는다

- 성당짓는 사람들 팀내에서 디버깅하고 역컴파일하고 리버스 엔지니어링 기술 명세서 읽고 rfc 표준문서 읽는 사람

- 자기지식의 한계가 어디까지인지 이해하지 않고 새로운 것을 깨달을 수는 없다

- 명장의 침묵속에 담긴 실마리를 끄집어 내기위해 지식을 명시젇인 형태로 들어내도록 독촉해야 한다

- 프로그래머의 견습생 생활을 시작한지 일년동안 습득한 패턴들이 책에서 언급 할때 기분이 좋앗다. 그리고 내가 련재 계속적으로 수행하고 잇는 독서에 힘을 주는 패턴 역시 잇음을 확인햇다.

- 그러나 내가 견습 생활 중에 간과 할 수 잇던것들을 하나씩 되집어 볼 수 잇는 귀한 페턴들. 낮아지고 노력하자!


신고


손에 잡히는 정규 표현식

저자
벤 포터 지음
출판사
인사이트 | 2009-07-30 출간
카테고리
컴퓨터/IT
책소개
정규 표현식 입문서!어도비의 선임 기술 전도사 벤 포터의 『손에...
가격비교 글쓴이 평점  

[느낌]

DB Query에서 많이 사용되는 더 나아가 다양한 텍스트 조작을 사용하는 환경이라면, 그리고 정규식을 한번쯤 꼼꼼히 보고 가고 싶다면 볼 만한 책이다. 예제와 함께 쉽게 잘 설명하고 있다.


[정리]
정규 표현식은 텍스트를 조작하는 가장 강력한 도구 중 하나다. 정규 표현식 언어는 정규 표현식을 구성하는데 쓰인다. (이렇게 구성된 실제 문자열을 저규 표현식이라고 부른다). 그리고 정규 표현식은 검색과 치환에 모두 사용된다.


== 정규 표현식으로 해결하는 일반적인 문제들 ==
- 이메일 주소 정규식 : (\w+\.)*\w+@(\w+\.)+[A-Za-z]+
- 주민등록 번호 : \d{2}(0[1-9]|1[0-2])(0[1-9]|[12][0-9]|3[01])-[1-4]\d{6}

- HTML 주석 정규식 : <!-{2,}.*?-{2,}>
- 자바스크립트 주석 정규식 : //.*
- 신용카드 마스터카드 번호 : 5[1-5]\d{14}
- 신용카드 비자카드 번호 : 4\d{12}(\d{3})?
- 신용카드 아메리칸익스프레스 번호 : 3[47]\d{13}
- 신용카드 디스커버 번호 : 6011\d{12}
- 신용카드 다이너스클럽 번호 : (30[0-5]|36\d|38\d)\d{11}
- 신용카드 번호 모두 : (5[1-5]\d{14})|(4\d{12}(\d{3})?)|(3[47]\d{13})|6011\d{12})|((30[0-5]|36\d|38\d)\d{11})


== 기본메타 문자 ==
.       모든 문자와 일치
|       왼쪽 혹은 오른쪽과 일치
[]     문자 집합 구성원 중 하나와 일치
[^]   문자 집합 구성원응ㄹ 제외하고 일치
-      범위 정의([A-Z와 같은 형태)
\     다음에 오는 문자를 이스케이프

== 수량자 ==
*        문자가 없는 경우나 하나 이상 연속하는 문자 찾기 (탐용적 수량자)
*?      게으른 * 문자
+        문자하나이상찾기 (탐요적 수량자)
+?      게으른 + 문자
?        문자가 없거나 하나인 문자 찾기
{n}     정확히 요소와 n번 일치
{m,n} 요소와 m에서 n번 일치
{n,}    요쇼와 n번 이상 일치
{n,}?  게으른 {n,}

== 위치지정 ==
^       문자열의 시작과 일치
\A    문자열의 시작과 일치
$       문자열의 끝과일치
\Z    문자열의 끝과 일치
\<    단어의 시작과 일치
\>    단어의 끝과 일치
\b    단어의 경계와 일치
\B    \b와 반대로 일치

== 특수한 문자 ==
[\b] 역스페이스
\c    제어문자와 일치
\d    모든 숫자와 일치
\D    \d와 반대
\f     페이지 넘기기
\n    줄바꿈
\r     캐리지 리턴
\s    공백 문자와 일치
\S    \s와 반대로 일치
\t     탭
\v    수직 탭
\w   영숫자 문자나 밑줄과 일치
\W   \w와 반대로 일치
\x   16진수 숫자와 일치
\0    8진수 숫자와 일치

== 역참조와 전후방탐색 ==
()      하위 표현식 정의
\1     첫 번째 일치한 하위 표현식, 두 번째 일치한 하위 표현식은 \2 표기하는 방식
?=      전방탐색
?<=    후방탐색
?!       부정형 전방탐색
?<!    부정형 후방탐색
?(backreference)true   조건 지정
?(backreference)true    else 표현식 조건 지정

== 대소문자 변환 ==
\E     \L 혹은 \U 변환을 끝냄
\I      다음에 오는 글자를 소문자로 변환
\L     \E를 만날때까지 모든 문자를 소문자로 변환
\u     다음에 오는 글자를 대문자로 변환
\U     \E를 만날때까지 모든 문자를 대문자로 변환

== 변경자 ==
(?m)   다중행 모드



신고

+ Recent posts

티스토리 툴바